Developing Android Apps: it's really not so bad
bendmorris.com
bendmorris.com
So let me give you some results: A bit over a year ago I became 1/4 of our new mobile team (2 android guys, 2 iOS guys) at work. We set out to write our apps, which have the same design, use the same visual elements, the same API, and have the same features etc. A year later, with thousands of lines of code and man hours behind them, both apps are still at the same level as each other, with neither being ahead of the other.
In short, anyone that tells you Android development is harder than iOS is lying, incompetent or has an agenda. Or simply mistakes his opinion for reality.
The problem with android remains, and these have been bought up a number of times. Why are we all of a sudden ignoring these problems?
To clarify, I am saying Android development is harder in the big picture (not just coding, but styling/graphic design/layout). Part of the reason why I believe this (my opinion) is harder is because the tools (Xcode, IB) are so much better for working in a team. Especially, when you have an on-site designer. You can give the designer a XIB file to style and modify to pixel precision. Android's layout editor still has a long way to catch up.
> same design... same visual elements
If you are using the same UX for both apps, you're doing your Android users a disservice. Android is different enough to command its own tweaks.
iOS's UI stack is clearly pre-web. Android is post-web.
Oh yes, we have a hand-maintained (pre-iOS5) very complicated UINib manager that loads Nibs and lets us "style" based on a system of plists and resource bundles.
+1 Android
And yes, our apps are not identical: Android has a drawer, dilaogs, spinners, toasts, uses the back button etc. But at the end of the day, you'll find the same functional screens, presenting the same information and offering the same functionality.
Android's layout is definitely more powerful but you cannot set every property in code that you can set in XML.
We've started using separate layout files for every screen resolution tranche (e.g. layout-land) but I am still hoping for a way to preview multiple resolutions simultaneously.
Thank you for respecting the Android consumer and not doing something like a "Back" navigation button on-screen.
I guess layout is, strictly speaking, more important to UX than pitch-perfect color. Still, it's one of the things that bugged me when working on my (aborted) iOS project.
I was just hoping you had some sweet solution because I think you could make a business out of layout, resolution, and color testing for mobile all on its own.
This is meaningless when you have variable screen sizes to deal with (or at least a large enough number of fixed screen sizes to make this impractical). You can get away with essentially making a UI out of images on iOS, but not on Android.
Android's layout containers are far more flexible than iOS's springs and struts system. I've found this to be true of MacOS desktop programming as well, in the face of something like Gtk or Qt. Maybe my brain is just wired to prefer fluid, auto-adjusting layouts, but I find the Apple way of UI layout to be very primitive and limiting.
The fact that the implementation phase takes about the same time is not very relevant, especially when considering that you're cutting corners and using the same UX on all platforms.
At a certain point of app complexity, writing an Android app becomes less about writing an Android app and more about writing a well-structured, async/decoupled and performant app in Java.
Why is iPhone development relatively easy? Well, for one thing, the territory is well trodden. And it is based on the beautiful foundational framework of Cocoa, which has its roots in NeXTSTEP. Cocoa masters have been able to switch to iOS and tell people/show people how to code properly. Cocoa has been around for a while; the Android SDK is a WIP (but it has come a long, long way since Cupcake). Also, Java lacks compiler-level support for/doesn't have blocks and categories (two of the things that make Objective-C a joy). And, love it or hate it, you will start to miss CoreData when you don't have anything near equivalent on Android.
Some of my favorite resources for learning Android:
The best book for the money (frequently updated, author has huge SO reputation)
http://commonsware.com/Android/
Reto Meier's blog
http://blog.radioactiveyak.com/
Styling Android blog
http://blog.stylingandroid.com
Android UI Patterns
The Google source (note, not all code is pretty but it shows one way of getting things done).
Android is known for its flexibility, power, and customization. There are many ways to setup/do things, some good, some bad. That just doesn't apply to the end user's experience but to developing apps for it.
It's a testament to the skills of the original authors of Objective-C that a 1989 technology is still competitive in 2011, but we've learned a lot about language and UI framework design since then.
I would say that graphical games are a step above the simple "standalone app" you mention.
I stand by my assertion that non-trivial app development on Android can be harder than on iOS. For example, take a look at the Google Music app source (an example of a complex app) and see if you can understand how it was designed and why it was implemented in such a way. I can't claim to fully understand it.
http://android.git.kernel.org/?p=platform/packages/apps/Musi...
> AsyncTasks to perform computer AI turns and implement a hack that makes Toasts last longer
I'm curious why you did not use a FrameLayout to overlay a Toast-like message on top of your SurfaceView game board.
Yes, the first thing to learn is concurrent programming in Java, and Android's classes that simplify it.
Then learn about components - everything that implements the ComponentCallbacks interface - and how lifecycles work. If you skip over this you are doomed.
Then learn how to keep your data model in a ContentProvider.
After that, you are through most of what is different and that might be strange.
Goes both ways, no? Not that your comment is without merit but this bit just struck me as really odd.
And, more importantly, the market isn't just there for Android apps. Not as many people want to code Android. I hate to say it but some of the projects I've been involved on - Android was a "checklist" item - as on 'We're on Android now, too'. I only know a handful of full-time Android developers, but I know many, many people who have quit their jobs and have gone full-time iPhone (contract/product).
The JVM also gives you alternatives. Currently none of the non-Java JVM languages is great for Android but Jetbrains' Kotlin project is looking very promising: http://blog.jetbrains.com/kotlin/
You've got to separate Java the language from all the other stuff. You aren't going to use J2EE for Android so how does that affect you? Java may not be the most elegant language but neither is Objective-C without warts.
> And, more importantly, the market isn't just there for Android apps.
Now you are just moving the discussion.. this is not what the OP was talking about nor was it the point of this discussion.
Apple clearly had the lead on developer mindshare because of the success of the App Store. Google is catching up but the reality is you can make a living off iOS easier than Android. You could do both but going from CoreData to ContentProviders in one day might make your head queasy.
Speaking of J2EE, I would love to have Spring or Hibernate ORM. I've tested the various Android ORMs and they do not yet seem to be 1.0.
Maybe I'm off-base here, but I think that if you understand the abstract concepts behind these on another platform (say GNU/Linux development with Qt or GTK) then it's simply a matter of translating your understanding of the concepts into the new platform's way of doing it. This is what a CS degree is meant to teach you (i.e. in my degree program, they never taught any programming languages -- only concepts in the abstract). Learning Services, ContentProviders, AsyncTask, etc. was really not bad at all and as you said, the SDK has gotten drastically better over the years.
The challenge is two parts: 1) creating an app that does what you want and does not ANR 2) creating an app that looks good and responds well. I stress that the 2nd part is what the users notice the most - they don't care about your well-designed network processor logic if it takes too long or lacks the shine and polish of an iOS equivalent app.
I'm not saying it is easy to polish an app on iOS. We've spent months polishing an iOS app to client satisfaction. The thing about Android is that clients are willing to accept less polish.
Yes, iOS is friendlier to newbies, but Android is more flexible and allows pretty much anything you can think of. More complexity is the drawback of having more flexibility, but after learning the platform it isn't really that bad (as the article says, with which I agree).
* installing Xcode is simple, minus the large download. For android I've got to get an IDE, android sdk, plugin for my ide, download platforms needed, create virtual machines (making sure to enable snapshot mode or wait forever on each reboot).
* the iOS simulator is nice and quick, though it gives you false hopes of how fast your app runs sometimes. The Android emulator is slow, almost unbearable at times. I've also gotta make sure I'm on power or my battery drains quick.
* programming for either is about the same in terms of ease or difficulty. Concepts are easy to get. Sometimes I think android is a little bit more straight forward.
* setting up a device to accept a dev build is a few clicks on iOS. On android I've got to enable the device for non market apps, etc on the device itself.
* I still have no clue which market is the best to put Android apps, the fact there is a choice makes everything even more confusing.
* fragmentation, though I've never had any major issues.
I really don't have much against Android as a platform, it's the development tools that drive me away. Apple has everything so it just works.
Isn't this a pretty big point though? As a developer, I'm willing to put up with some extra hassle up-front if it makes the bulk of the work easier.
Have fun fighting a terrible, custom Swing IDE that RIM wrote, because debugging via their buggy Eclipse plugin (which is downloadable as an entire Eclipse install, so you have to reinstall all your customizations and other plugins) doesn't always work (forget the actual step debugger, which doesn't work at all, I'm talking about getting the output from System.out.println). Cross-platform development is pretty weak: there's no official support for Linux, and there are no simulators and no support for older devices on OS X (50% or more of the BB subscriber base).
Enjoy the need for a round-trip to a RIM server which has a habit of being down (it's been better recently, I admit) just to put your app on a device during development. Users can change the permissions on a per-application basis, and can install and run apps without the required permissions enabled, so you need to manually check the permissions you need every time the app starts. API calls that need this care aren't documented, so you have to do basic science on the device to figure it out.
Want to make an HTTP connection? Great, here's a giant ball of accumulated wisdom on how to tiptoe around APNs and other transport-level bullshit. Or you can pay $2000/yr for access to an undocumented BIS string that might work a bit better.
Programming is hard. Some tools are shitty, but there's often someone on the other side of the fence who has it worse or better. There are a few senior devs here who have horrifying war stories about J2ME and Brew. It seems that even Blackberry development is a bit smoother than other mobile platforms. And I'm sure embedded programmers have even scarier tales of low-level Heisenbugs.
Edited to add: Oh yeah, BB is also all based on J2ME, which means Java 1.3. No collections, no generics, no auto-boxing, no for-each loop, no reflection. Yes, even on the new BlackBerry 7 devices, Java 1.3.
This is one of the most aggravating issues I have with the Android market at the moment. Every app that has a free version handles it differently: Some you buy a key and enter it (which means purchasing out of band), some use the Android Market micropayment system (so it often isn't clear you have to pay for the app at all), some use a free version and full version of the app (so if I play the first 15 levels in the demo, I have to play them all through again when I buy the game). C'mon, Google. Pretty common use-case here.
The range of sales for android paid apps are publicly available on the android market. Based on my own sales figures (I've been as high as #66 overall on the Top Paid iphone list) as well as knowing the sales figures of other highly ranked apps like Angry Birds and Doodle Jump, it is apparent that paid apps on android do an order of magnitude less in sales than their iOS counterparts of the same rank.
That said, I'm release my best performing iPhone app (currently makes about 1K/day) on android in a few days. So we'll see how it goes.
http://developer.android.com/guide/publishing/licensing.html
Time Required and Difficulty (or Ease) of developing on one platform vs another ...
... without factoring in the amount of money you can make (or if you don't want to make money, the amount of people you can reach).
It's also very, very strange to not talk about the huge number of devices that run on Android and the complexity of supporting some/a few/most of them.
*
What's the point of - It took exactly just as much effort and time and pain to make a great app on Android as on iPhone
without elaborating on
- how much profit there was - how many people it reached - various other factors like how much of the Android time was spent on supporting various devices - what the level of quality on each platform was.
Finally, don't mean to be a dick about this but -
Who cares if someone makes an app in 4-5 days worth of work and releases it.
Where are the people who have made amazingly good Android Apps?
What's their story?
Do we really want to focus on how easy it is to make an app that takes just 5 days and is nothing out of the ordinary?
I got "hello world" to work in about 15 minutes, and was doing asynchronous HTTP Posts of images from the gallery to a remote server the next day, with hooks into the Android sharing system and progress bars and the whole thing. All this while riding in a truck, without Internet, from Salt Lake City to San Francisco to demo to some investors (Android app was a small part of a larger demo).
I hadn't touched java in 8 years. Never done Android development previously. It was brain-dead simple.
If you're already established and successful in the iOS store then it makes sense to stay there. If you're starting from scratch then it's not quite so clear-cut, I think.
As an example I recently downloaded Words With Friends on the Android, became immediately annoyed with the ads and was at a loss when I tried to find a pay version. I emailed them and although they replied within hours (fantastic!) they said they don't have a paid version at the moment (it's in the works).
I'm reminded of John Carmack's ad-hock survey of iOS and Android users to find how many people would have spent at least $20 for apps[1], and then he explains in more detail why we won't be working with Android at that time. His reasoning is solid, but that survey puts an exclamation on the same point you're making, which is unfortunate.
It's easy to claim nobody pays for things on Android if there's nothing there worth paying for. It seems to me this would make Android a prime market rather than a poor one.
I've personally spent at least $40 on Android apps in the last year or so (mostly games) and will spend plenty more as developers come and give me reason (or at least a chance) to give them money.
For instance I wanted an app that would block calls and SMSs and do a better job than the built-in functionality.
I found an ad-supported app that did the job, but the UI was awful.
So I tried to buy a non-free app that had good reviews -- problem was that the developer wouldn't allow purchases from my country, so I couldn't purchase it.
Also, as a developer Android is a poor choice for me, not because there's anything wrong with the platform, but because Google doesn't allow me to be a merchant that receives money from them (I'm not in one of the approved countries).
So the only option available to me as a developer is to release ad-supported apps. And with ads the UI experience suffers, so this automatically puts me in a don-t-give-a-shit state of mind where I don't care about experience as much as I care about volume.
This goes round and round, but on the whole I think that the quality of Android's marketplace represents an opportunity precisely because the competition is doing a poor job.