Understand component lifecycle. Understand it well enough to know you have to design your app around it, because you can't subvert it. Do this first. Do not write code before you understand this. A good way of understanding this is to override all the lifecycle methods in Activity and log them, then watch what happens. Understand that Android can "destroy" both individual component instances and whole processes. Understand that you can't thwart "destroy" by holding a reference.
Understand Android's support for a data model in a sql database, abstracted by ContentProvider, and how to build an observer pattern around this.
Understand Android's support for concurrency, enough that you know the limitations.
That's a great question. If you look at the set of classes that enable you to build an observer pattern on top of databases in Android - Cursor, Adapter, and View, you see that you can skip the ORM and POJOS in most cases where you are simply displaying data, with some minor processing that can happen in the Adapter.
This works well in Android where each process's maximum heap is something between 16 and 48MB, and keeping your data model in a database is a way of continuously persisting it.
There are exceptions. You probably would not want to build a CAD program this way. Instead you would take the performance hit to rebuild your POJOs after the component they are contained in gets reaped.
It occurs to me I answered your question only obliquely: Android doesn't have ORM. It does have a database stack that makes ORM unnecessary in most cases.
Your profile link to the Android book indicates that you know what you're talking about.
As someone who has a decent grasp on the lifecycle part, could you sprinkle the other two points with a link or two? Or .. a general direction? "Enough to know the limitations" for example is .. hard to follow-up on.
The limitations of AsyncTask are hard to put in two sentences. It starts with AsyncTask referring to an Activity. Now let's say you create a configuration change by rotating your device, and the Activity you had is destroyed. There begins the tale of woe. Here is a good writeup: http://andreas-kluck.blogspot.com/2012/02/asynctask-and-asyn...
Only using 2.2 APIs at this stage would only hurt the development of your app. Targeting 4.1 and using the support package gives you full access to Fragments and Loaders while still supporting the older SDK versions.
Unlike with iOS where it is easier for users to upgrade their OS if their phone supports it, Android version upgrades come most often when people upgrade their phone and that means at the end of a 2 year contract for most people.
Targeting the most recent Android version seems like a poor way to get people to use your app.
Note the: Targeting 4.1 and using the support package gives you full access to Fragments and Loaders while still supporting the older SDK versions.
Sure, if you target 4.1, you can't necessarily use every single new feature in Android on older devices. However, from a design/UI point of view, Android's backports of many new features (and projects like ActionBarSherlock) such as the action bar means you can design for 4.1 and have the code work with many previous versions.
I agree with the grandparent post: design for 4.1 and set 2.2 as a minimum. In cases where you want to use new APIs, you can use conditional classloading techniques.
Both you and the blog author are misunderstanding what targetting an API means. You can target 4.1 and still have your app run on 2.2 or lower. As others said, many of the new APIs have been backported to earlier versions. And targeting newer APIs have many additional benefits. As an Android Developer, you should always use the newest SDK and target the newest API. But still try to design for older versions.
The Android Support Package enables you to back-port apps written for the latest API level and using a Fragment-based UI implementation all the way back to Android 1.6.
I think reading most guides on the developer.android.com website is the best way to start developing on Android. The SDK also includes sample codes that are worth looking at for good practices on various tasks.
Seconded and thirded. The linked article makes a few mistakes that would be avoided if the author paid some attention to the Android guide. Which is extremely common for third party tutorials. The Android guide is great and is often updated. There's ton great resources like videos and tutorials. It's by a huge margin the best place to learn android.
I would advise anyone beginning Android development to avoid third party tutorials as much as you can. Only use those if you cannot find a specific topic you need in the Android guide.
I'm also starting to learn Android. Being an Emacs user I tried android-mode, then Intellij IDEA and Eclipse. At the end I decided to settle on Intellij IDEA (Java is way more bearable with a good IDE.) Is there any drawback to not using the "official" google dev. environment (Eclipse+ADT)?
I haven't built any complex Android apps so far but I've found IntelliJ's Android support to be very good. The only thing I've really missed so far is the visual layout tool in Eclipse but IntelliJ does give you realtime previews of your layout so it's not too hard doing things in XML.
I suspect that it's only loosely correlated to the number of devices in the wild running that version, but very tightly correlated to the users likely to download an app that you write.
Since the Play/Market app periodically checks the servers to look for any app updates it's fair to say that Google's numbers comprise just about all devices running Google Play which is probably 99% of devices. The only notable device without Play is the Kindle Fire which is running Gingerbread 2.3.4
Understand component lifecycle. Understand it well enough to know you have to design your app around it, because you can't subvert it. Do this first. Do not write code before you understand this. A good way of understanding this is to override all the lifecycle methods in Activity and log them, then watch what happens. Understand that Android can "destroy" both individual component instances and whole processes. Understand that you can't thwart "destroy" by holding a reference.
Understand Android's support for a data model in a sql database, abstracted by ContentProvider, and how to build an observer pattern around this.
Understand Android's support for concurrency, enough that you know the limitations.