Learning Android: Shaving a Yak

I built another Android app: a bmi calculator. I spent a lot more time with it than I would have thought in the beginning. Basically I learned how to build a custom component with custom attributes and how to use an alternative layout for landscape view. I also learned to use the very good compatibility library ActionBarSherlock. Then I didn’t use any of those.

The custom component didn’t end up making sense as mostly it was an EditText in RelativeLayout’s clothes with couple of labels tacked on. In the end there wasn’t the screen real estate for the labels. Landscape view proved to be somewhat too difficult to get working with different screen sizes while in confines of one Activity. I used ActionBarSherlock mainly for the ActionBar. In the end I had to ditch it because the final installation of the app would have been over three times as large with ActionBarSherlock. Also ActionBar itself is easy to implement as a glorified TitleBar when you choose a titlebar-hiding theme as basis and roll your own.

Anyways, a useful thing I learned and actually used was to implement a generic OnEditorActionListener to move from one EditText to another in custom order:

private OnEditorActionListener getGotoNextListener(final EditText next) {
        return new OnEditorActionListener() {
            @Override
            public boolean onEditorAction(TextView v, int actionId, KeyEvent event) {
                if (actionId == EditorInfo.IME_ACTION_NEXT) {
                    next.requestFocus();
                    return true;
                }
                return false;
            }
        };
    }

The problem was that I changed my initial plans and used EditTexts that were side-by-side so the focus didn’t move properly from one to another.

Reindeers and Joy of Developing Software

Few reindeers

Aren't they cuddly

I published my Disc Golf Drive Measure at Android Market. So far the app has been downloaded about 50 times. This is the whole point of software development: that someone uses the software you make. Even better if the software is public in some way.

I’ve been testing the published version of the app a bit. The current conditions don’t support that very much as I’m looking after reindeers for couple of days and the nearest field is covered by two feet of snow. Anyways I’m now well aware that the app requires tweaking. Essentially the last X throws need to be remembered and some improvements to GPS handling and the UI need to be made. That will have to wait a bit as I’m currently developing another dinky little app: a BMI calculator.

The BMI calculator is basically very trivial app to write. However I’ve been learning bit about graphic design and ProGuard, ActionBarSherlock, custom components and other things that are needed for more polished apps. Also this time I actually did some interaction design. With the Disc Golf Drive Measure the design was basically the classical programmer design: a byproduct of programming. This time I had a very good idea about how the interaction with the dinky app should be, before I started coding. All these things mean that I’ve used quite a bit more time with the app than I thought at first. After finishing the BMI calc I’ll tackle refactoring the UX and code of the disc golf app, not to mention all the functionality that needs to be added.

Why Should I Learn TDD

I watched a good vid on TDD at InfoQ. Basically Keith Braithwaite explains in the beginning what I’ve been doing with this little Android project. Basically I’ve written some code, refactored the code, the written some more. Now that basic functionality and edge cases for it are pretty much handled, cleaning the code further becomes kind of waste in this project.

There is very little functionality to add. I suppose the main concern for me is that the current version being available at Bitbucket means that I could showcase that I can produce cleaner code. Unit tests will have to wait for the next project.

The way I see it, I’ll have to either do TDD or anyway start writing reasonable test suites. Larger projects than this could become more and more difficult to modify without the safety net of tests.

One thing I’ve struggled with a bit is that developing Android app is somewhat compared to say Java Swing app. For some reason separating concerns and limiting the responsibilities of different classes has been a lot of work. And it hasn’t succeeded as well as it could have. One thing I should do better is deciding how much functionality should Activity-based classes have. Currently the main activity is too long for my tastes. One solution would be to remove listeners from anonymous inner classes. However I’m not sure if any of the other options is much better. Update: I found out that you can define clickhandle in the layout files. That cleaned up my activities a bit.

Disc Golf Drive Measure First Beta

Disc Golf Distance Measure beta main screenFor last couple of weeks I’ve been spending some time developing a small Android app for measuring disc golf drives during practice. At this point the software I would say that the software is in early beta and it has been tested only a bit in emulator and a bit with HTC Desire.

This is quite simple app as you can see from the source(@Bitbucket). This is my first Android app so there have been a few hurdles cross. I fought long and hard with the layout, but I had to abandon my initial plans to wait for a time when I really dive into the documentation.

I actually made myself an Android Market account so after some testing the app is likely to find its way there. I’ve been toying with the idea of making the current version with some small modifications(like support for more units of measure) available with ads and then developing a further premium version with no ads and some more improvements. Obvious improvements would include saving the drives for future perusal, adding disc information to drives etc. The benefit with this approach would be getting experience in publishing apps and trying out the various ad systems.

The source at Bitbucket is licensed GPLv2. This basic version will be available from there. The code isn’t as pretty as it could be so refactoring and writing unit tests is one task on the list. Unit testing on Android is not very difficult, but it is a lot of work. Best way I’ve found so far is to use RoboElectric.

Hopefully this app will be the start of a diverse portfolio to showcase my software developing skills. Bit of Captain Obvious at the end: developing this little app has once again shown me that building something you actually have need of is motivating. I have a whole bunch of these little repositories of projects that never really went beyond the idea and first couple of lines of code, because the motivation to continue just wasn’t there.

Usability Research on the Rise: Small Piece of Original Research

I did some searches with ACM Portal for journal and magazine articles that mention usability. The results in table below.

Years Articles Mentioning Usability Total Articles % of Articles Mention Usability
1991-1995 62 2273 2.7%
1996-2000 377 5949 6.3%
2001-2005 861 8909 9,7%
2006-2010 970 10076 9,6%

I also did a rudimentary check on how many articles mention both usability and web. Results in the table below.

Years Articles Mentioning Usability and Web % of Articles That Mention Usability That Also Mention Web
1991-1995 12 19%
1996-2000 221 58%
2001-2005 581 67%
2006-2010 630 65%

One could theorize that web has made usability research lot more prominent. Or the other way around. Or perhaps there is hidden factor in play. Or perhaps ACM Portal’s search engine gives nonsensical results.

Estimating: Frustration and Amusement

It goes like this: someone estimates how long it should take you to code a piece of software. You know the estimate is unrealistic and that no way you are going to make it. So you would imagine that you would just shrug your shoulders and code at whatever pace you are comfortable, not really considering the deadline at all. The thing is, you will still feel the anguish anyway.

The same point was made in Facts and Fallacies of Software Engineering by Robert L. Glass.

I’ve noticed similar phenomenon in playing poker and while doing other estimates, like trying to set up the timetable for writing my thesis. One approach, though not practical for software development, was presented in Elements of Poker by Tommy Angelo. The idea is that you don’t want to have goals, but rather targets. In context of poker this essential means: aim to play every hand as well as possible, but don’t have for example monthly goals to earn set amount of money or play set amount of hours. Tommy proposes that having goals isn’t productive due to missing goal having much larger negative impact than vice versa.

All this is highly amusing, until it happens to you. As with all emotions, it is very difficult to ignore the anguish of missing unrealistic deadlines. Like making a new year vow that this year I’ll drop 30 pounds/quit smoking/etc. and missing year after year. You know the surrealism of it all when making the vow, but still you feel bummed when you fail.

Nearly a year with ZFS – thoughts.

I’m happy with my OpenSolaris fileserver even before upgrade.. It has been a marked improvement over the earlier Windows 2008 server in performance at least. Ease of maintaining has been pretty much the same. Basically the problems I’ve had are:

  • WD15EARS 1,5TB drives are tad slow. There is noticeable delay when opening say video files from the smb shares when scrub is running.
  • When transfering files from my OpenSolaris home folder to the smb shares the ACL permissions aren’t inherited like they should. I have no idea whether this is due to user error or bug.
  • I haven’t been able to install SqueezeServer on the OpenSolaris. Partly this is laziness as it should be possible.
  • Laziness. I haven’t really scripted everything as far as I should.

HDD goes boink, to upgrade fileserver

I’ve kinda felt that maybe I went too far with raidz2 when building my fileserver. Now I noticed that one of the 1,5TB Western Digital Green Power WD15EARS -drives had broken down and there is still two to go before losing data. Maybe not so bad decision after all.

Because of the broken drive and some mild performance problems I’ll be upgrading the server within couple of weeks. I’ve chosen to make the server even more reliable: I have couple of Hitachi 1 TB drives and I’ll be adding a third for 3-way mirror for the important stuff. I’ll also dump the 6 disk raidz2 pool of the WD disks and replace it with pool of 3 mirrors of 2TB Samsung Ecogreen F4G drives. Those too are internally 4k sector size drives and show to os as 512byte. There is performance penalty for this, but pooling mirrors should compensate for that. I’ll also add a Intel SASUC8I raid card for more SATA ports and better performance over the Dell Perc 5/i.

I did toy with the idea of enabling dedup on the imporant documents along with hourly snapshots, but apparently zfs dedup isn’t yet ready for home servers. Would have been neat though.

On Android Piracy – Perhaps Pirates Are PC Users

I read a recent discussion on Slashdot about Android Piracy. Some company claimed that:

Over the course of 90 days, the [KeyesLabs] app was installed a total of 8,659 times. Of those installations only 2,831 were legitimate purchases, representing an overall piracy rate of over 67%

Basically for the last ten years there has been huge explosion of free(open source, freeware etc.) software for Windows pcs. Contrast this to cell phones: nearly everything costs money. You have to pay to get many very basic utilities and tools, let alone more complex productivity software. So perhaps the people doing the pirating are coming from the PC culture, where there is abundance of pretty good quality free software for most purposes.

Learning Programming Languages

I think learning new programming languages is both easy and very difficult. Syntax is nearly always easy, but understanding when to use a language and what are its strong points. Failing at this leads to the familiar “when all you have is a hammer, every problem looks like a nail.” On the other hand I read a quote somewhere along the lines “a good programmer makes the solution look like the language was made for solving it.”

Then again there is the huge job of learning all the common libraries and services languages have. Consider this: I’ve used Java on and off for various little programs at the university over the years, but it has been so occasional that I still need to refer to documentation for a lot basic stuff like accessing files etc. It is kinda tough when you don’t have a very good memory for stuff like that. Similarly for the last year and a half I’ve needed Perl steadily, but occasionally on my job: I really need the documentation to check pretty basic functions.

The point I’m rambling to is that routine is in my opinion the biggest factor in mastering a language. If you don’t use it, you lose it. Basics may stay, but the finer stuff goes away.

My current part time employment is coming to an end and yet again I’ve been wondering about applying to programming jobs. The thing is, I’d really like to finish my thesis first. The problem is that while I finish my thesis I lose most of what little routine I have for programming. That makes it tad more difficult to ace interviews in the winter. Luckily I’ll propably have couple of odd jobs at the Library during the summer, but those are more likely to be configuring software rather than developing it.