So I skipped a few days. As of today, I’ve created 6 public Apps published on Google Play. Five have done really well, one has a lot (about 30%) of bad reviews. Here’s a few things I’ve learned so far.

0. There are no functions. This is probably “wrong” on a number of levels, but that’s what helped me get my head around it. There are only methods, no standalone functions, and they can’t be passed around like other variables. You can’t say someInstance.someMethod = anotherInstance.anotherMethod. For someone who lives and breathes PHP, JavaScript, ActionScript, etc, this was tough to get. I use Runnables a lot – that’s a very simple interface that just has one implemented method – “run”. So instead of

you say

1. It’s all about the Activity. An Activity is similar to a “page” in a web app, or a Controller in the MVC pattern, or the document (maybe window?) in the DOM. It is not a view itself, but displays Views. Views must exist within an Activity. Activities have LOTS of functionality you need for all manner of things, like reading image data, saving preferences, showing alerts, etc.

2. Use Fragments. Fragments are natively only available from 3.0+, but you can use the support lib for use in older versions. Use it. A must for “HMVC” style architecture.

3. Use their stupid XML layouts. I hated this at first (still not a huge fan), and wanted to dynamically create all my Views, but after a few months realized it was almost essential.

4. Love the try/catch, and check everything yourself. Virtually any error will crash an Android app. If you’re used to jQuery where you can call 18 chained methods on a non-existant selector, you’re in for a rude awakening. Even if you don’t think there’s a chance a value might be null, or that a simple process doesn’t need to be caught, think again. Even simple routines should test every value or property for “correctness” first, and stick anything that might throw in it’s *own* try/catch block. You might be tempted to throw a big block into a single try/catch – DONT DO IT! Use a try/catch block for any line that might throw an exception.

5. Phone’s are wimpy. You’re going to get an Out of Memory Error. Really, you will. You’ll probably be able to memorize the error code for “bitmap size exceeds VM budget”. There’s a saying, something like “premature optimization blah blah is bad”… You’re going to have to optimize to as close as you can get to perfection, probably more than once, just to keep from crashing.

6. Native GC is unpredictable. In a lot of other languages, you can remove all references to an element and assume it’s going to be collected right away, but that’s not the case here. If you have an ImageView you’re done with, don’t just remove it from the display list and assume everything will be tidied up for you. Recycle the bitmap if you can (but don’t if you might need it again), and at the very minimum use setImageBitmap(null).

7. Account for any potential problem. You might be requesting a small JSON file from a server, that in a web app would be “no big deal” – when writing for Android apps, make sure you’re testing the whole time for an incoming stream, connectivity, and a parseable string. Good chance you might get half the JSON before it craps out as well – prepare for that, too.

8. Learn threading. This is not just for performance, or differentiating between the UI thread and everything else, but matters for a lot of other reasons. This is too broad a topic to get into deeply, but at the very least learn to use new Thread and Runnables.

9. Implementations vary wildly. In coming to a lower-level language, I was eager to get away from idiosyncratic browser implementations of JavaScript and embrace the “write once run everywhere” paradigm I think iOS developers enjoy. Not the case. Droid RAZR, for example, does not perform work in the Layout pass in the UI thread (Layout != UI?! OK…) Samsung Galaxy does not return a bitmap from the Camera app – why? Nobody knows. There are over 160 devices, and many have very distinct implementations of the framework.

10. User open source. When I say “open source” I really mean “crowd sourced”. With so many devices, and so many versions, it’s almost impossible to debug any app reliably. Instead of writing your own class to load remote images, find one on github that’s been used by a lot of people, and therefore already debugged in a lot of devices.

11. Dynamic drawing is impractical. Some simple things like rounded rectangles can be managed alright, but others (like a drop shadow) are ridiculously hard to implement. Use 9patches. I hated them and felt like it was 1999 all over again, but that’s the way they want us to do it, and IME the only practical approach for a lot of visual effects.

12. Don’t try to be iOS. Not only is it vocally discouraged, it’s just not going to work. I’ve had to put my tabbar on the bottom of all my apps so far (to maintain visual consistency between Android and iOS versions), and it’s always been a PIMA. If the keyboard shows, things get wonky. If your layout isn’t set to ignore it explicitly, things get wonky. If it’s a Thursday, thing’s get wonky. I tried to recreate CATiledLayer, and using incredibly small images, and creating only the barest possible pinch-zoom interface (about 80 lines of optimized code), it’s still not going to perform like iOS.

13. Remember that the platform is young, even immature. There’s a ton of documentation missing, more that’s so vague as to be useless, and some that’s outright wrong. I love stackoverflow, but IME the support there can be spotty – I’ve had much more luck on the google groups list (“Android Developers”).