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.
Interesting, I was searching few days for a review of Android from a Delphi programmer's perspective, I guess I was too afraid of the complexity of Java.
No way in hell other platforms will give same productivity and simplicity like Delphi any time soon, furthermore the Windows platform is too mature to compete with Android -- I believe.
I also began to look into Java/Android. I agree that tools are not match to easiness of Delphi RAD studio. Although, there is one tool that might offer better developer experience (it is not free) than Eclipse from jetbrains, intelliJIDEA.
Excellent over view. I too am a long time Delphi user who just finished an intense six month stint converting a Delphi app to Android. I found the Java coding to be very similar to Pascal and easy to translate. The GUI aspects of Android, however, were very time consuming and overly complex. The Android market is also a disappointment. Google does not provide the developer with the email address of those who have downloaded your app, so you have no way of contacting people who use your app. Anyone can rate your app, anonymously, and post irrelevant derogatory comments, and you have no way of responding to these trolls. And these ratings and comments are stuck to your app through all versions. Google needs to make the Market more relevant to users and developers.
Yes, I was able to duplicate all major functions of my Delphi Windows app in Android. I'm ready to tackle another Windows to Android conversion.
Thanks a lot for this over view and CernerSux about commenting the marketplace issues.
Not to hijack your excellent blog post. But I also wanted to mention that the Android community, like the Delphi community of developers, is very helpful to newbies, and sample code is quite easy to find.
I am also an old user of Delphi and have great interest in exploring Andriod world.
Can you please guide me where can I download the Delphi-like environment for Andriod?
Thanks a lot in advance.
Post a Comment