Google Android reviewed by a Delphi developer

With the major part of my background in Delphi, but also some in C, C++, Assembler, Java, C# and others, I threw myself at the Android platform in order to figure out how it works.

The main language is Java, the obvious IDE is Eclipse, and after installing the Android SDK things are well integrated with each other. The fundamental structure is very similar to Delphi - but things have different names and formats, of course. Forms are called Activities, DFM files are XML files, there is a manifest XML-file like in Windows, a message queue like in Windows, and each application has a main thread that receives messages and is reponsible for updating the GUI (don't update the GUI from other threads).

The platform comes with some APIs. For storage, we have a file system (SD flash ram), an app-specific database (SQLite-based) and a preference storage (like .ini files or registry). There are also APIs for network access, location, sharing data between apps, phone calls, user interface integration etc.

Generally, things are straightforward, but Eclipse isn't as smooth as Delphi. Examples are usually missing from the documentation, so Google and sample apps are great friends - and even though the form designer does integrate with the IDE so that you can design something graphically, it's not as simple as putting a button on a form and double-clicking it, in order to create a "hello, world" app. One nice thing is that you only have to design one user interface, and it looks ok on many different phones with very different screen resolutions. You can also adapt the user interfaces to different resolutions, of course, especially when rotating the phone, but many standard user interfaces immediately work on all screens.

You need to programmatically attach event handlers etc., and generally, the form designer is not as neat as a typical form designer for Windows apps. Since the screen is usually very small on a phone, the user interfaces usually try to solve only one problem, like showing a list, editing one record of information etc. Therefore, there are special user interface classes for these purposes, like a "ListActivity" which is basically a form that focuses on supplying a list to a user. One of the benefits of this, is that the form then has handler functions, like OnListClick, which are implemented using class inheritance.

The Java language still does not have "procedure of object" constructs, so some event handling stuff is more complicated, like using inheritance, extra classes etc. Also, Java still feels a bit behind Delphi 2009/2010 in several aspects, but on the other hand, Java has better features in some areas, too. One interesting thing is the Google advice "Avoid creating objects" in the Android developer guide, in the "Designing for performance" section. Considering that almost all API functions require you to pass a recently constructed object, you need to create an huge amount of objects compared with typical Delphi apps, so I guess the advice tries to say, only create huge amounts, don't create extreme amounts of objects.

Performance is definitely a key issue when creating mobile apps. Performance is not so much about instructions per second, but more about responsiveness of the GUI and battery usage. Many of the things that you would want to do on a phone requires external systems to react, and they may not react immediately. For instance, a GPS fix takes time, and looking up an address over the internet can take a long time. Such things need to be handled using separate threads on Android, so if you don't master multithreading in Java, this is one of the first things to learn. Fortunately, it is not that difficult, so don't let it scare you off, Java does many of the things you need, in easy ways.

Debugging is great - the SDK includes an emulator that can emulate different kinds of devices, and you can even simulate incoming phone calls and see stacktraces from the emulator inside the Eclipse IDE. I see no reason why you should need hardware in order to develop Android software, except that I couldn't make GPS simulation work. It's probably just an option somewhere that I didn't find.

Besides a great Delphi-like form designer, one thing I really missed was a non-SQL local database similar to BDE or DBISAM. It seems to be overkill and a waste of CPU cycles to use SQL on app-specific databases that are single-user and cannot be shared by multiple applications - and somewhere I also saw some benchmarks that proved that SQL is a bad idea in this context. Data sharing to other apps is handled using Content Provider interfaces and not SQL, but that is outside the scope of this blog post.

Publishing to the Android Market is extremely simple. There is a guide for it in the Android Developer Guide, and if you follow that, your application is worldwide available immediately, and the market reports, how many phones downloaded your app and how many still have it. Upgrading is also quite simple: Just upload a new version of your app, that's it, and all users will be notified next time their phone checks for upgrades.

If you know the Java programming language and Eclipse, I would say that it should take less than a day from scratch, to install Java, Eclipse, the SDK, to create a simple app and publish it on Android Market. There are no expenses for the tools, but it will cost $25 as an initial fee to sign up as a publisher for the Android Market. I guess this fee is meant as a kind of spam-protection and also makes it possible to trace your identity, if needed.

Bullshit Bingo for programming

A Bullshit Bingo card for software developers:

Remember the rules, you need 5 in a row before you win!

Nexus One: touch screens do not solve all problems

When I first learned about Android and iPhone, it was fascinating to see, but I didn't leave my old Nokia phones before I saw somebody demonstrate to me, that it was actually possible to operate these phones with one hand. My Nexus One is still mostly handled with one hand, meaning that I don't use multitouch pinch-to-zoom much, even though it is available, instead I use the zoom buttons on-screen.

However, I still cannot type on my Nexus One with one hand, without looking at the on-screen keyboard. Also, physical keyboards produce higher typing speeds than on-screen keyboards, so the current solution isn't optimal. Also, the Nexus One only has 3 physical buttons: Volume, Activate and the trackball. Everything else requires you to look at the phone. This choice is not optimal: while handling the phone in an unlocked state, you may easily adjust the ringer volume by accident (!), so there are applications that restore the ringer volume, in case you do this. Also, it takes much more time to activate and unlock a Nexus One, than to unlock a modern Nokia phone. The phone is great, no doubts about it, and Nokia is seriously behind these days, but there is still improvement to be made.

In a recent CNet review of the Kindle and the Nook, the reviewer gave Kindle significant more points on usability, mainly because it had dedicated buttons to support the operations that the user did most, whereas the Nook's touch-screen was not as easy to operate. Considering, that we get more and more devices, it is also fair to assume that the devices get more and more specialized, meaning that it will become increasingly easy to identify frequent operations that should be supported using special buttons, and that the best devices will get more physical buttons. Who knows, maybe we will see bluetooth remote controls for Android phones, that enables you to do calls and write SMS messages without taking the Android phone out of your bag. I would buy one.