Good to see someone (of relative authority) pushing back against the FUD spread by iOS fanboys, such as the likes of Marco Arment & co. Android development is not something to be afraid of, and thankfully a lot of developers are finally coming to that realization, and it seems that with the release of Android versions of previously iOS-only apps like Flipboard, Instagram, and Instapaper, the final vestiges of differences between the two markets have disappeared for users.
I have to disagree. Marco recently laid out his (very rationale) reasons on why it took so long for Instapaper to hit Android. I encourage you to give it a read - http://www.marco.org/2012/06/06/instapaper-for-android.
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. "
A lot of people see that as the worst form of hypocrisy.
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.
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.
The Nook and the Fire are "Android" devices not Android™ devices. While related and important they are not the Android ecosystem most people talk about.
I would argue that this distinction is not that important from developers' point of view, as the same application can be made available on all "flavors" of Android.
It is important from a developers point of view because those devices don't get tested by Google for API/feature conformance and so potentially are more likely to have applications not run on them correctly.
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).
Right. Because everyone who dares criticise Android is an iOS fanboy.
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.
You appear to accusing Google of having different priorities from other platform vendors (the dreaded advertising perhaps? It's not clear) and of ineptitude in carrying out those priorities.
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.)
"The fact is that Google has handled the Android ecosystem poorly and reflects where their motivation lies."
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).
>It is the device makers and the carriers that are responsible for the situation you're talking about with updates.
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.
Exactly. As I said, the openness is also its greatest weakness. Fragmentation is still a huge issue (look at the average Market app for one star reviews of the format "Force Closes on $device")
I see what they were going for, but their execution frankly sucked.
Something else for new Android developers is to realise that Android apps are structured completely differently than iOS or desktop apps (if you follow best practise).
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
So, I spent some time trying to implement the architecture proposed in that talk. I kept finding myself adding just tons and tons of more or less boilerplate code. This felt wrong to me. Surely there must have been a better way.
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.
Unfortunately it is very easy to end up with boilerplate code when using Java. It isn't a direct fault of the language but rather that Java developers hate making decisions so you end up with endless layers of abstraction and indirection. (Immortalized as FactoryFactoryFactory.)
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):
Its nice to see an article that challenges the bizzare notion that you have to have a gigantic stack of physical devices to develop a quality android app. This very closely mirrors my experience developing for android except of course for the wild success bit.
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.
I'm the guy (from OpenSignalMaps) who found the 3997 Android devices, but I also love developing for Android. I think 3997 devices is very cool and just a tiny-tiny bit terrifying. So I love this post. Buying a low-end device is a great policy policy for two reasons. 1.the market for low end android devices is growing faster than for high-end devices. So if you want global traction that's what you should target. 2. If your device works well in Cupcake at 320x240 it's probably going to be even better on ICS at 1280x720. My three favourite devices for developing: HTC Hero (low-end although actually pretty great), Nexus One (workhorse), Galaxy Nexus (system is surprisingly buggy, but still super fast).
Of course they did not have any compatibility problems - the Pocket app is a textbook example of an app, you could find something like this in demo examples. Make no mistake, I love the design - it's perhaps the best design of an Android app yet. BUT, you can't compare it to any game or video playback app - it does not have to handle native libraries or fight with gazillion different screen aspects. It might not even contain a single custom drawn view (don't know about the "reader" view). Everything in Android is a fluid layout, and if you only use these layout components, everything should be fine on most devices. Pocket is even able to avoid very large images, which tend to crash older devices if they exceed available native bitmap storage. So.. yes, most apps won't need testing on ~4000 devices - if it runs on the emulator, it should be fine (make sure to severely limit memory there).
But don't dare to leave the well-tread pathways, or get ready to buy 100 or more devices (obviously that's an estimation :)).
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.
Yep - the more specialized and low-level it gets, the more stuff will break on devices you have not tested - that's what I mean.
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.
Finally some great advise. I will like to add my experience to it. When I first started developing on Android (around a year and half ago) I had just a HTC Hero which my employer then (I was interning) bought on CL. I had to share this phone with a fellow developer. Using just that one device we managed to make an app which totally blew away its IOS counterpart . Then one of my friends bought Motorola Atrix . This phone was first phone with such a high resolution (~275 ppi) as far as I can remember with slightly different aspect ratio. When I loaded my app on this phone everything worked perfectly. It was a realization that Android provides so many tools and ways like 9 patch images, different assets folder, layout mechanism which makes handling such differences easy. All you need to do is to get out of single screen mentality (or 2) and think more like a web developer developing for different browsers and screens.
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.
