Pocket team's tips for aspiring Android developers: It’s not really terrifying.
getpocket.com
getpocket.com
Instead of a single main() entry point, consider your app to be a mashup of ui (activities), data (content providers), processing (services), broadcast state (receivers) etc. You can just as easily incorporate those components from other apps as from your own. You don't have to do most things yourself - eg to include Dropbox/Facebook/Twitter/Google or your own account system you can use the AccountManager instead of building your own credentials user interface (the sign of an iOS ported app).
If your app will be talking to a server, along the lines of providing a user interface to view data and make changes, with the underlying data flowing over REST or something similar then watch this talk which talks about best practises. It is especially a good idea to remember that mobile platforms can arbitrarily kill applications at any time for any reason, and the same can happen to the network. Consequently you need to record what is going on in a local database to be resilient. Talk is from Google I/O 2010 but applies today: http://www.youtube.com/watch?v=xHXn3Kg2IQE
Fortunately, Google released the source for the Google I/O app, built using the same architecture. What did I discover? A giant pile of boilerplate code to accomplish very little in terms of actual functionality. Moreover, this was for an app which fit pretty well into the relational model (small objects with few relations each).
It may be current best practice, but there has to be a better way.
You may find this list of libraries used in Android apps useful. There are several that cover this architecture pattern if you want to use them (eg data access, networking, format parsing):
Choice quote from the article: "Simply put, Instapaper needs to be on popular reading devices. That category now includes at least three 7” Android tablets, probably with more to come. I realized last winter that I needed to address this demand, but I couldn’t do it myself. "
Marco writes articles post with a headline "Why I hate Android"[1]. Then when it turns out that (despite his attitude) people are making money on Android he decided to jump on board.
Many developers have hated the platforms they have developed on but do so because the platform allows them to make money.
It's worked this way since the beginning of industry i.e. decades.
The hate isn't the hypocrisy. Plenty of people, for example, hate Windows and develop for it without being hypocrites.
The hypocrisy is extensively claiming that the platform in question isn't profitable ("terrible development economics", "unlikely to recover those costs" [referring to development costs"), etc.), playing up issues like fragmentation and generally arguing in almost every way possible to other developers that you shouldn't be on this platform... and then turning around and jumping on board anyway.
In fact, given the timeframe Marco talked about (last winter), it is entirely possible he was publicly arguing against Android development while Instapaper for Android was being developed. I can understand why he'd do that from a business perspective: Marco wouldn't want to tip off competitors to his change in thinking (note that Readability launched on Android and ReadItLater had gone radio-silent before relaunching as Pocket during the period in question), but that doesn't make him less of a hypocrite.
Given the wide variety of applications shared amongst the three markets (plus the successful installation of Google services including the Play Store on both), I think there's zero evidence that, from a developer's perspective, the Nook Color/Tablet and Kindle Fire are materially different from any Google-blessed Gingerbread-based tablet with the same specs, except that the Google-specific libraries and services are not installed.
I can understand compatibility worries about cheap, no-name non-Google-certified tablets, but that doesn't describe the Kindle Fire and Nook Color / Nook Tablet. The cheap, no-name tablets (and other devices) aren't a big part of the market outside the developing world. And the developing world is a whole different ball game for all sorts of reasons, not just Android device compatibility (e.g. the most significant competing platforms are Symbian and, arguably, SMS).
The fact is that Google has handled the Android ecosystem poorly and reflects where their motivation lies. Microsoft for decades has shown that it is possible to support a wide variety of innovation on top of their core OS whilst still allowing updates to be made. People such as yourself who continue to make excuses for ineptitude do nobody any favours.
Google has handled the Android ecosystem neutrally, not poorly. It is the device makers and the carriers that are responsible for the situation you're talking about with updates.
It is in Google's interest for device makers to support updates to the latest Android release so long as the hardware is capable of supporting the newest versions (of course, limits to this sort of backward compatibility would always exist, just as they do in the iOS world).
Google could have just as easily bargained for the same kind of terms that Apple gets on iOS devices with carriers. No pack-in garbage, no mucking about with the OS. If not with the G1, certainly with the later releases.
Their desire to have Android be "open" is also its greatest weakness.
Right, and what about the hundreds of other manufacturers of Android phones?
I see what they were going for, but their execution frankly sucked.
You can't really accuse them of both, either they were trying to copy Apple's business model and failed spectacularly, or they were following their own business model with great success. Personally I'd lean towards the latter, particularly as their own business model has found them providing search, video and maps by default to Apple's platform as well and getting map data in return.
(Also, one of Microsoft's biggest problems in recent times is... getting people to upgrade. This applies to the OS, the browser and Office. As a response they tried to move people to a model where they pay by subscription regardless of whether they upgrade or not, much like Google's advertising based model.)
I started my first app the day I got my n1 and until this year when i added a transformer prime to cover ics and tablets that's the only device I used save the emulator. In that time I supported every device 2.1 - 4.x including tablets with just the emulator. Fragmentation has just never caused much of a problem for me.
My user base isn't huge (4000ish) so it could be that scaling up would bring the fragmentation issues out of the woodwork. Nice to know that it doesn't at least in this case.
But don't dare to leave the well-tread pathways, or get ready to buy 100 or more devices (obviously that's an estimation :)).
Perhaps they are bad developers.
The guys with the 4000 Android devices explain what they are trying to do here: http://www.animoca.com/en/2012/05/the-varieties-of-android-e...
Both of these are game developers. So I think that at the moment the type of app you are developing may effect how easily it is to get good compatibility. Also the type of markets you want to tap may matter.
UPDATE: Perhaps I should tell about my background here: I have been developing Android apps since 1,5 years now, among them an app for my master thesis which makes heavy use of OpenGL. One xample of what can break: If you load OpenGL textures, you should choose a texture size of 2^n pixels - or at least I found out when they did not show up in some of my test devices. Some newer devices showed the non-2^n-px texture (500x500) without problems, but older did not display anything. Now imagine you code a game or interactive info display - is that the kind of issue you want to have? You won't run into this issue on iOS, because there are only so many OpenGL drivers.
Apps like Pocket do not touch these issues, they don't do "hard" things.
My experience so far has been (I have around 40 apps on Android Market) unless OEMs do something stupid or have bugs and you are not handling some platform bugs (these are rare but can get quite annoying) especially from 2.1 to 2.2 and 2.3 to 4.0, you should be fine.
In some instances I had to use jar-jar (http://code.google.com/p/jarjar/) for common libraries like GSON (json parser) since some OEMS (I think it was some phones from HTC) were modifying the implementations and it was resulting in errors in my app.
Lets talk about look and feel. Android has a very vibrant open spurce community. If you want to follow design guidelines (http://developer.android.com/design/index.html) (you should, even though you are not needed to) , just use open source libraries like action bar sherlock , android theme generator and you can achieve 95% identical look and feel between 2.3 and 4.0. You can always grab the holo theme assets from Android 4.0 source (which is shipped with SDK) and create your own holo theme (if you are using holo for Android 4.0).
Lastly, you can always use support library to get fragment functionality. Fragments are most important defragmentation tool. Some other niceties like Loader manager are also part of support package.
Enjoy developing on Android!