Programming Android: Three Weeks On

As much as I hate to admit it, I think I’ve finished my app. It’s a proper monstrosity of bad design, hastily drawn graphics and butchered code but in the space of less than a month I’ve gone from not knowing a thing about the Android SDK to being in the final stages of testing a functioning app that does everything I originally intended plus a little bit more. Three weeks ago I began this adventure by thinking: I wish I could find an app that does X,Y, and Z. Now I have an app that does X,Y, and quite a bit of the Z and it has probably saved me 69p had this app originally existed in the Play Store.

I can’t say that it’s been an easy three weeks and I’m not sure I would have liked to have attempted this without some programming experience. Yet, had I been learning from scratch, I’m not sure Android is the worst place to begin to learning to program. It’s certainly a friendlier developing environment than some I used when I started out many years ago. I remember the misery of coding on an old Vax in a cold university basement room when we all had to wear mittens to stop our fingers from freezing. And people wonder why it’s taken me so long to come back to software engineering…

Although I’m not exactly a new code monkey, I began not really knowing much Java and I’m not entirely comfortable with it now since it’s clearly a language that’s easy to learn but difficult to master. At a few points, I wanted to add features which just proved beyond my skillset. One required me to catch, buffer and then process MotionEvents (the data generated when the user touches the screen) but it led to a wasted two days and my utter defeat. Perhaps I’ll try again with my next app...

Things I know now but wish I’d known back then:

• It’s easy to use transparent PNG graphics inside a SurfaceView so long as you clear your bitmaps with the eraseColor(android.graphics.Color.TRANSPARENT) instead of filling your bitmap with white. Took me three days to figure that out.


• The word ‘Activity’ in Android is almost synonymous with screen or process. Think of each functioning element in your program as individual Activities. So, if you’re making a database program, you could have an activity for the screen where you add records and another activity for the screen for modifying records. If it’s a game: one activity for the main menu, another for settings, one for the high score table, and another for the main game itself…


• Learn about ‘context’. I think it’s the single most confusing and difficult element of the Android API. I’m not entirely sure what it is myself and I’m still not entirely sure how to ‘get’ it from different points in the code.


• Learn to nest layouts right at the start. Setting up screens is a nightmare until you understand that you can, for example, drag a horizontal layout onto the screen and embed elements inside that. That layout can then be dragged into a vertical layout, making it really easy to arrange elements both vertically and horizontally on the screen.


• Don’t go looking for ‘file open’ dialogs. They don’t exist natively in Android and, to be honest, I’m not entirely sure they are needed. It’s really easy to throw data out to other apps, such as email, Evernote and Dropbox.


• Be quite liberal debugging with Log.d(“Activity1”, “Loop7”). As your app runs, it throws up messages to a console on your PC so you can track the code and see where it stops, throws errors or is trapped in loops.


• Saving preferences inside your app is unbelievably easy with the SharedPreferences object.

Except for those really ambitious things that were just beyond me, I can’t say anything has been unbelievably difficult. The problem now it to stop myself from adding more features. I’ve got my widget working and I think that was the last big addition I’ll make. In the last two days, I’ve added a ton of new functions. I’ve even done the unspectacular work of programming the settings page so that the app remembers the user’s preferences and adjusts the internal workings accordingly. In a way, this part has pleased me the most since I’ve tried to make the whole thing flexible so anybody can use the app as they see fit. It needn’t be used for the purposes I intended, which is probably good because I’m not sure anybody would want to use it for the purposes I intended.

The next stage is when things get difficult. I have to test the app and make sure that it runs on devices that have different sized screens. Device fragmentation is probably the worst thing about programming for Android. There are so many devices out there with completely different capabilities and hardware. The chance that this app will run on all of them is slim to zero. However, I want to be sure that it can be used on the majority of current Android devices and that means either getting my hands on a range of test devices (impossible) or using an Android emulator on my PC.

And that’s where I have a problem…

The Android emulator that comes with the Android Development Kit runs really slowly. However, you can install an Android kernel that’s built with Intel code. If you have an Intel based PC, the Android emulator runs pretty quickly and you can run it in a variety of configurations so you effectively have every type of Android machine at your fingertips. Want to emulate a small phone running an earlier version of Android? You just run the emulator with all the settings turned down and you get to see what you app looks like running on a low spec phone. You see a problem and jump straight back into the code to fix it. It’s a great way to test and bugfix your app if you have an Intel based machine.

Only, I don’t have an Intel based machine. My PC has an AMD Phenon II X6 and it completely incapable of emulating Android via the Intel kernel. There is one emulator called Bluestacks available for AMD machines but, as far as I know, it’s not customizable, which means it’s pretty useless for my purposes. There is an online Android emulator which can be set up to emulate different devices but I can’t say that it runs particularly quickly and I know I don’t intend to spend money testing an app which will never earn me a penny.

It means I’ll either have to beg to borrow a friend’s PC or be happy just to test the app on my Samsung Note 10.1 (2014) edition running Jelly Bean and my old Galaxy S2 running Android 4.1.2. I have no idea what it would look like on a seven or eight inch tablet or how it might run on a bigger tablet even a year old. Ideally, I should buy a really cheap 7 inch Android tablet, such as the Tesco hudl, but it’s an expensive way to test compatibility.

Meanwhile, sometime this week, I hope to figure out how to upload my app to the Google store or I might not even bother. My app will never be the next Flappy Bird and given it might only be downloaded five or six times, I might simply stick the finished app on this site for anybody to try, if that sort of thing interests you. If it doesn’t, I’ll probably be back to cartooning and moaning about The Guardian ignoring my submissions until I come up with my next ridiculous plan.