As Android grows in visibility, more and more developers, particularly those coming from other mobile platforms, are starting to learn Android development. For example, there seems to be a growing influx of Windows Mobile developers starting to get involved in creating Android ports of their applications.
If you are one of those people, welcome!
One problem we encounter, though, is that some newcomers seem insistent upon Android necessarily supporting whatever sort of implementation patterns they are used to from past development environments. So, we get complaints about Android lacking thread-blocking dialogs, or ways to terminate the app, or whatnot. And, sometimes, when those complaints are met with “sorry, that’s just not the way things are done around here”, those lodging the complaints get nasty.
Android development may be better than what you’re used to. It may be worse. More importantly, though, it is just plain different. This should be no surprise, since each development environment is different across the board: WinMo is different from iPhone, Ruby Web apps are different from Java Web apps, Visual Basic for DOS is different than FoxPro…
(oh, wait, I’m showing my age on that last one)
…and so on.
Whenever you start developing for a new platform, you need flexibility in your mental model, particularly if you are trying to do a straight-up port of one app to a new platform. Things that you did in the original app just may not make sense in the new environment, and trying to force the issue is only going to cause you pain. Your goal should be to deliver significantly similar business logic on the new platform, not to replicate every last button or icon. So, while people “terminate” their Windows Mobile app, they don’t really “terminate” an Android app, any more than they “terminate” a Web app.
Similarly, programming techniques you used in the old environment just might not make sense in the new one. Android, like many GUI toolkits, is highly event-driven. This means that some conveniences you may find in other platforms — such as displaying a dialog and blocking the thread that started the dialog until the dialog closes — just flat out aren’t available. Does this mean that event-driven GUI toolkits are inherently inferior? Not really. They are just different, requiring different code structures (e.g., event handlers instead of blocking threads).
Whenever you move to a new programming environment, it is important to keep an open mind and find the right balance between your design models and the approaches that are most conducive to solid apps on the platform. In this respect, Android is no different.