6 ms·

A few days of programming on iOS and Android illustrates a vast difference.

159 points by ssutch 15y ago

mahmud 15y ago
Android is not a toy, you can easily see it's an improvement over traditional mobile, and it highly influenced by the web. I fought Android until I decided to throw my entire weight behind Java and settled on it as a platform. Don't fight it: learn Java proper, do a few SWT & Swing apps, feel the burn .. then do Android. You can ignore the abstractions and just "draw up" your application with Eclipse, inside one giant activity, but you would be doing yourself a disservice. I told myself "Java sucks, it's bloated, it's big, yada yada yada. Just man up and learn it; no sense in bitching about what you don't know" :-) Glad I did. It gets work done.
- andymoe 15y ago
  I'd love to hear a good java book recomendation. Is there a K&R kind of book for java? I also have to say that maybe iOS is bit easier to get started with but have the author come talk to me after doing ten or twenty apps wrangling core data, list view, sprites, physics engines, universal apps and mixing c c++ and objectice-c and tell me that rabbit hole is not pretty damn deep.
  - mahmud 15y ago
    Hortsman & Cornell's, two volume "Core Java 1.2". I only read the first. Gosling's "The Java Programming Language". And Josh Bloch's "Effective Java". After that, Java Concurrency in Practice. Langr's "Agile Java" is good for just that. Bloch, Goetz, and Doug Lea have each written excellent books on java concurrency. That's just about all the java books I would want to recommend. Many j-books are trash.
    - RodgerTheGreat 15y ago
      Don't forget Java Puzzlers, also by Bloch: http://www.javapuzzlers.com/ http://www.javapuzzlers.com/ Not only is it a fun read, but it delves very deeply into case studies of the dark corners of the Java language.
    - rkalla 15y ago
      +1 Effective Java is a must-read once you understand Java. It points out what is magic and what is not. What takes up processing time and what doesn't. It pulls the sheet back on the abstractions and shows you how everything works and what you should be aware of. Doug Lea is a brilliant developer in the concurrency space. With his Executor framework that went into (Java 5?) he suddenly made threaded programming as easy as possible to get right.
    - andymoe 15y ago
      Awesome. Thanks so much for the recommendations everyone.
  - rattab 15y ago
    I don't know how relevant it is for mobile development but I'd recommend Effective Java by Joshua Bloch (http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683/ref=sr_1_1?s=books&ie=UTF8&qid=1312014425&sr=1-1 http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/032...). It's essentially the equivalent of Effective C++ for Java and it does a good job of explaining how to properly use the language. It also contains quite a few general programming advises which are applicable to other languages. Just keep in mind that it assumes that you already know the language and have a bit of experience under your belt.
  - cema 15y ago
    Also, consider The Well Grounded Java Developer which is now in Manning's Early Access Program (http://www.manning.com/evans/ http://www.manning.com/evans/).
- aerique 15y ago
  Since I recall you being a Common Lisp enthousiast: do you see, for example, ECL ever becoming a viable alternative for making Android apps? I've been exploring iOS using Objective-C and I'm about half-way done with my first real app for the Appstore and I can't wait to try and rewrite it using ECL once it is done. Otherwise it will probably be Unity for me since my main interest is games and game-like apps. I really don't have the time to become and expert in each and every differing mobile platform.
  - mahmud 15y ago
    I didn't look into any "alternative" ways of doing things. I tried to port ABCL to Android, but for my current needs, the standard-way is good enough, at least then I can hire help and focus on what matters, instead of doing everything myself. Our Android apps are all on the galaxy tablet, we plan to roll out a deployment of 50 devices by year's end.
- evinfinite 15y ago
  Just a point that needs clarification: how is any of this comment relevant to the points raised in the OP? That is, how does this help against the fact that Android has: * A much more complex set of (good!) abstractions that are poorly documented; * and, if I might add alongside the OP, requires a much higher workload in terms of code length and complexity, debugging, device configuration management and tools for what seems to be a much lower payoff? I have a successful iOS app out, and I tried to rearchitect it in a manageable way to port it on Android. What I found out is: * The code would be roughly twice as much as the iOS version. * A proper UI effort would require roughly 2.5x work than the iOS version, as I need to prep up a flexible layout that will work on phones (the buckets 'small' to 'large'), and then another for tablets (actually up to two: 'xlarge' and Honeycomb, which may require some rethinking to accommodate the new action bar). Contrast this to two, fixed-size layouts for the iOS version. * I already have a path for implementing backgrounding on iOS and it requires minimal change to account for services not available while backgrounded; otherwise, code is exactly the same. On Android, I would have to plan for it from the beginning and set up very poorly documented IBinder stuff to have my Activities talk to a background Service. * The general unwillingness of Android users in the face of paid apps, and a use model that does not lend itself easily to the insertion of ads, would make my (more costly) effort go unpaid. I must admit I have never used resources other than developer.android.com and Google, and the latter didn't help me as much as (as little as) developer.android.com did. There might be an excellent book on all of this, but I haven't bought any — any recommendations are welcome.
  - nextparadigms 15y ago
    There are several good Android books out there, you can Google for top 5 Android books. A lot recommend a subscription to this site where you also get these 3 books in that price: http://commonsware.com/books http://commonsware.com/books And you can try these sites for code snippets on anything: http://www.anddev.org/ http://www.anddev.org/ http://www.androidsnippets.com/ http://www.androidsnippets.com/
  - hahainternet 15y ago
    Could you give me an example of exactly why the claims you've made are true? Why would your app need twice as much code? Why is using the Android ui designer so much harder than iOS's equiv? What is so undocumented about IBinder? It's basic IPC? I would really like to hear reasons, not abbreviations.
jan_g 15y ago
I mostly agree with the blog post. It is perhaps too hard to make proper app in Android, but all those abstractions are powerful, imho. Consider quick search/suggestions. If done properly, then you can plug your implementation also to system-wide search with just some config changes (and user permission, of course). Sure, content providers seem far too difficult (search dictionary example in dev docs), but then you can reuse them for your list activity or quick search or access them from another app.
InclinedPlane 15y ago
There are other ways to do it: http://android.xamarin.com/ http://android.xamarin.com/
- fdb 15y ago
  Mono on Android sounds tempting. But how much overhead does the core runtime on the platform add? What is the impact in KB's and runtime performance?
  - andybak 15y ago
    And how well integrated into Android 'proper' is it? For example - intents and fragments?
    - bad_user 15y ago
      I played with it -- integration is very good, mirroring the Java API quite well. I would still use Java directly on Android though. I do agree with the author that Android's SDK is a little complicated, but it has good reasons for it and whenever I choose new platforms I take it as a given that I have to make an effort to learn it. I don't see much value in bitching that the learning curve is steep, when once you get to know the platform it becomes easy to make it do what you want -- in general I bitched about Java frameworks because power and ease of use are completely missing, even once you learn them properly, but that's not the case with Android. And as far as iOS development goes, I work on apps more complicated than drawing Hello World with a couple of buttons -- and to me Android is better because it allows me to do mostly whatever the hell I want; compared to iOS where I always ask myself "is this even possible"?
gary4gar 15y ago
I would love to see some scripting language in Android AND iOS which is Officially supported. Something like Python,Ruby or JavaScript which will make app development much easier. Hey Google, Give us a nice scripting langauge. Pretty Please?
- ratsbane 15y ago
  Scripting Layer For Android (SL4A): http://code.google.com/p/android-scripting/ http://code.google.com/p/android-scripting/ Though for stuff you're going to distribute it's much better to go native, bite the bullet, and do it in Java.
- deleted 15y ago
  [deleted]
malkia 15y ago
Then again you won't find such names in iOS SDK https://plus.google.com/101253020771610439991/posts/YKKyGFdq2MT https://plus.google.com/101253020771610439991/posts/YKKyGFdq... :)
- getsat 15y ago
  Your link is a 404
shaunfs 15y ago
Screw it, I'm psyched! It's a great time to be a mobile developer! I was going to write a whole response regarding iOS vs Android until I realized the debate is like religion or politics. Currently both platforms are great and only getting better with each iteration. I'm developing for both platforms and loving it. Just in the latest iterations look at what we can do. iOS * AirPlay - My phone will be my gaming console and media center, genius! * iCloud - Good, no more transferring files back and forth. * CoreImage & AVFoundation - 30 lines of code to add video editing and filters to my application, sounds good! * GLKit - High-level 3D libraries for a game developer noob like me. I'm in! * TwitterAuth - I'm still going to integrate FB authentication but this is cool too. Android * Ice Cream Sandwich - No more fragmentation. Unifies hundreds of devices (not just phones). Brand new UI library. I can't wait! * ADK - My home, car, and toaster will soon be at my mobile command while giving me status updates. This is so awesome! I foresee Android powered cleaning robots in the future. * Face-tracking - So my phone can recognize me and focus in on my face and voice automatically. This sounds like fun. * USB Host - I can plug anything USB into my Android phone. Hot damn!
- bignoggins 15y ago
  Couldn't agree with you more. I started off doing iphone dev part time just over a year ago. Since then, I've managed to quit my job, become a full time indie developer, and travel the world. The opportunities for independent developers in the mobile space are just incredible right now. I'll have my first android app coming out in a few weeks too. To quote some 90s hip hop, "damn, it feels good to be a gangsta"
- hahainternet 15y ago
  Here's my question. In this (somewhat ungrounded in Android reality) article the poster makes the claim that on iOS, you 'just get' a few seconds to finish off everything. This does not seem like a sustainable model. If my app and the next app a user launches are both memory heavy, I expect my app to be killed to make space. How does this process work on iOS? Also, nobody really seems to understand how amazing Intents are before they use Android :)
  - 15y ago
jinushaun 15y ago
My problem with Android development is that, being a non-Java developer, I never knew when to use the Android SDK or the Java SDK or the Apache stuff for certain tasks. For example, networking. Googling online for solutions, I don't know if any of the Java code I find is Android compatible.
- babebridou 15y ago
  My rule of thumb: - if you see "java.awt" or "javax.swing" in any package import, run away. - if you need to download a native library to run a hello world, run away too. The rest is/should be fair game. Try to run a hello world on the device.
  - DannoHung 15y ago
    Is there a good library for doing graphics in Java? I was thinking about trying processing, but it doesn't seem quite appropriate.
    - babebridou 15y ago
      What kind of graphics? - for charts on android, http://code.google.com/p/afreechart/ http://code.google.com/p/afreechart/ - for maths calculations, http://commons.apache.org/math/ http://commons.apache.org/math/ - for opengl graphics on android, it's already a pain with all the fragmentation here. There's OpenglES10 (but no longer implemented on Xoom), OpenglES20 (2.2/2.3 and up, but no VBO support on 2.2), Renderscript (3.0 and up), JNI (if you want to program in C), MonoAndroid (for mono, you need to pay for that though)... - otherwise, just go with the official Canvas API http://developer.android.com/guide/topics/graphics/index.html http://developer.android.com/guide/topics/graphics/index.htm...
- ZoFreX 15y ago
  > being a non-Java developer I'm a Java developer and I don't know, either. I suspect the expertise you're looking for might be described as an "Android developer" ;)
babebridou 15y ago
Java APIs are not designed to "just work" but rather to "eventually work with anything".
stretchwithme 15y ago
Haven't tried programming Android, but not crazy about objective c. But Apple's documentation is stellar and easy to access.
- aerique 15y ago
  Agreed. I have no love for Apple and I'm developing directly on my jailbroken iPhone through SSH and even then the documentation is very useful.
  - conradev 15y ago
    Heh. iphone-gcc sucks.
Tractiable 15y ago
Develop for the iOS platform in Cocoa, develop for Android in Adobe AIR. Best combo I have found!
- dpcan 15y ago
  Why not develop for iOS in Flash/Air too and have one code base? I personally think the Air download requirement on Android is a still a pretty big deterrent for most users. I really wish Adobe could have found a way to build Android apps so you basically distribute a small Air runtime bundled with your AS code as an App instead of requiring the Air system be installed separately.
1880 15y ago
Maybe I am going off on a tangent here, but... why not just use an AsyncTask with a synchronous HTTP petition inside? I am a novice in the Android SDK, but it just seems easier.
bendmorris 15y ago
Counterpoint: I just began developing my first Android app a few days ago, a turn-based strategy game. I've only had an Android device for a month or so so the platform is relatively new to me, and I didn't even know Java (although, to be fair, I knew C# fairly well a couple years ago, which is arguably the same thing plus type inference.) In a few days, with relatively few problems, I was able to build an app and I'll be releasing it in various markets soon (once I stop polishing and let it go, which is hard for me to do.) I found the experience to be straightforward and intuitive. I was able to find tutorials for any task I couldn't figure out myself and the API documentation is perfectly adequate. Working with images and settings files are two areas where I was very pleasantly surprised at just how easy it was. There were some minor frustrations. The Android emulator fought me a little so I started just debugging on my actual device. Debugging certain problems can be difficult, Eclipse can cause headaches and throw random nonexistent exceptions, etc. but overall I think you've vastly overstated the difficulty level of jumping into Android development. "The depth of knowledge of in design patterns required is so great..." It's really not. With almost no experience with Java or Android, I've put together a working app in a few days that, in my opinion at least, is pretty good, and that works on various mobile devices with different resolutions and capabilities. Some other things I'm happy with about the Android platform: the SDK is free, Android is open source, you're very unrestricted with regards to what your app can do, and Android Market developer accounts cost a one time fee of $25 instead of $100 a year.
- dpcan 15y ago
  Just a word of advice on Android, polish your app really well before launch. The Android Market comment system is relentless. If you don't have a smashingly nice app out of the gate, you'll probably get a couple 1-star "sucks"/"rubbish" reviews before you can finish your post-launch exhale.
  - ZoFreX 15y ago
    This is interesting because I, having no knowledge of the Android market but a lot of knowledge of development in general, would give the exact opposite advice! In general I think it's agreed that the best thing to do is release, and then tweak. If the Android Market punishes people that do this then I think that's a very real problem with the market that will directly lead to poorer quality software.
d99kris 15y ago
For higher abstraction layer on Android, there's Corona SDK and other similar tools.
zyb09 15y ago
Well you're new to Android so things seem weird at first. It's all a matter of picking up the underlying concepts. To be fair ObjC and Cocoa looks for most Java devs like voodoo, but once you get it it becomes easier, too.
- dpcan 15y ago
  Exactly. This article was completely one-sided. He also failed to see the huge amount of community support there is for Android developers too. There's so much information inside multiple forums you would almost never be unable to find an answer to a problem.
  - Pooter 15y ago
    > This article was completely one-sided. It was one person's subjective experience of switching platforms; it's not intended to be a balanced examination of API design across platforms. Why so tetchy?
  - mirkules 15y ago
    There's an insane amount of support for both platforms. Without StackOverflow, 50% of the developers would be unemployed :)
huntergdavis 15y ago
Counterpoint, and like I said on the original post: Within a few days of programming Android I had published a few apps. You just need the App-titude, and the attitude as they say. I'm on day 60 and have done 65 Android apps thus far. Perhaps my live-coding video that was up last week would help? http://www.youtube.com/watch?v=x8bu8nNUZSY&feature=channel_video_title http://www.youtube.com/watch?v=x8bu8nNUZSY&feature=chann...
- lurker14 15y ago
  Why 65 rush jobs instead of few polished apps? Skillful Surround could be an attractive game if it got some TLC.
KirinDave 15y ago
So of all the things which might be singled out as "over-engineered" in the Android developer kit, he singles out the mechanism of _message passing_ as worthy of the propeller beanie? That's confusing to me. Message passing is one of the simplest actionable metaphors we have in the world of programming. I'm new to android development, but they seemed pretty straightforward to me.
deleted 15y ago
[deleted]
methodin 15y ago
The only thing I know for sure is it took me about 4 hours to write a concept Android app that used an existing app the market (barcode scanner) which I could interact with via intents. It was free and I can install the APK on devices without using the market. I don't really know what more I could ask for. Well that's not true, the other thing I know for sure is Objective C makes me dry heave.
amurmann 15y ago
I worked on an Android app for about 2 months together with some experienced Android developers. Most things, like displaying dialogs, storing things to the Db, etc. worked quite well and I really came to like intents. However, I completely agree with the authors criticism of the implementation of asynchronous calls. We implemented in app purchase functionality for our app and it was a huge pain. Google provides lots of documentation around this. However it's very convoluted and looking at their example IAP app makes you wonder if they had some contest going on to achieve the highest number Gang of 4 design patterns per lines of code. That massively distracted from what the example was supposed to teach you. We ended up spending around 2 weeks to get a solidly tested implementation of IAP working and get all edge cases covered. My main complaint about this is, that we weren't doing anything fancy and 99% of the code we had to write was not specific to our application. Something that just takes our vendor information and one callback for the success case and one for the error case would have totally done the job. I am sure there are hundreds of dev teams out there writing the exact same code as we did. Many of those probably are not testing their code or even just copying Google's example, without understanding what's going on. This is a huge waste of everyone's resources and will probably lead to many buggy apps. I understand that Google wants to allow for the flexibility to cover 99.9% of all use cases. However, they could still have offered a simple library method for the 99% case and have allowed the other 1% to write their own thing. Now everyone has to write their own solution. I hope someone will open source their IAP solution. If not, I actually might do it, since it's just crazy right now.
ristretto 15y ago
Wouldn't it be better though if we did not have to rely on either apple or google for mobile programming? How about extending trusty old HTML to provide low level Apis for mobile devices? Phone gap does it and it's already proving valuable. As mobile bandwidth is becoming more stable it makes more sense to quit the app store madness and embrace the wild open web as the only app platform. In principle I do not see why there isn't a set of mobile browser extensions already; i suspect that both google and apple will use their platforms as a tool to lock in developers to their own strategies.
- lurker14 15y ago
  Phonegap is a common JavaScript interface to native APIs. HTML is only tangentially related. Building apps with JavaScript is doable, but has performance consequences that are severe on low-power mobile devices. It's hard to fault Google for providing an open-source Java-compatible OS. It's not their fault if other OS builders are not compatible and actively block cross-platform solutions. I haven't tried it, but I don't know a reason why one couldn't write an Android native app on Objective-C. You'd need a cross-compiler and technical/legal ability to port Cocoa though, the latter which I suspect would be quite challenging.
schiptsov 15y ago
This guy it seems trying to say that Android's APIs were developed by (talented) engineers for engineers (skilled programmers) on the go, while Apple just adopted mature libraries from OSX which are providing set of hight-level abstractions and APIs understandable by any mediocre coder (the way of 'easy/cool' java/php frameworks). But one should remember that too high-level APIs and abstractions has its cost in terms of performance and bloatedness of required runtime (J2EE/Spring/Hibernate way) especially on resource-limited (lack of FPU, etc) platforms.
hackbod 15y ago
"For example, to correctly implement asynchronous HTTP requests is an entirely different challenge in iOS and Android. On iOS you use the built in libraries, and if your user happens to change applications during the request, you can be sure you have up to 30 seconds, usually more, to complete whatever actions need done before termination. On android, you must implement the `android.app.Service` API for all your important web calls. The app can be killed at any time, and you must retain your arguments, and retry the call in case it happens to die." Except... no, you don't. :/ The first sentence of the documentation on Service: "A Service is an application component representing either an application's desire to perform a longer-running operation while not interacting with the user or to supply functionality for other applications to use." Do you need to do either of those things? If you say no, then don't use Service. http://developer.android.com/reference/android/app/Service.html http://developer.android.com/reference/android/app/Service.h... In the Processes and Threads documentation: http://developer.android.com/guide/topics/fundamentals/processes-and-threads.html http://developer.android.com/guide/topics/fundamentals/proce... It describes how when the user leaves the activity in a process, it goes in the background. It doesn't kill the process. You can continue doing networking. You don't need a Service to have background threads in your process. (In fact again from the Service documentation, a Service is not a thread at all.) Just continue doing your work, and if the system needs your RAM for other processes, it will kill your process, but otherwise you can continue downloading in the background. This is exactly how for example the web browser, and any app using a WebView, works. This is similar in many ways to iOS. Not surprising, iOS seems um inspired in its multitasking design by Android.
TheRevoltingX 15y ago
WTF? This guy is an idiot. I make iOS and Android applications for a living. It is ridiculous to have to create a service to make a few HTTP calls. For that, Android/Java provides various threading classes so that you can keep multi-threaded code nice and neat. With iOS, out of the box, you get NSURL and its family. You have to setup callbacks in your class and you have to keep track of your http calls per class by using things like action=whatever. What a pain. ASIHTTPRequest makes things much easier. Ugh, this just makes me mad. Why would people listen to shitty developers? Why are you spreading this ignorance? Objective-C is a giant paint, with opaque types. Having to remember what class you've put into a dict can get messy. I have to work with both frameworks every day, and Android is the better framework BY FAR.
- jcizzle 15y ago
  I definitely laughed at the irony of this post.
  - TheRevoltingX 15y ago
    Care to rebuke? BTW, read hackbod's comment. She's an Android engineer. This guy is flat out wrong and failed to read documentation. She puts it much nicer than I can.

159 points by ssutch 15y ago

Android is not a toy, you can easily see it's an improvement over traditional mobile, and it highly influenced by the web. I fought Android until I decided to throw my entire weight behind Java and settled on it as a platform. Don't fight it: learn Java proper, do a few SWT & Swing apps, feel the burn .. then do Android. You can ignore the abstractions and just "draw up" your application with Eclipse, inside one giant activity, but you would be doing yourself a disservice. I told myself "Java sucks, it's bloated, it's big, yada yada yada. Just man up and learn it; no sense in bitching about what you don't know" :-) Glad I did. It gets work done.

andymoe 15y ago
I'd love to hear a good java book recomendation. Is there a K&R kind of book for java? I also have to say that maybe iOS is bit easier to get started with but have the author come talk to me after doing ten or twenty apps wrangling core data, list view, sprites, physics engines, universal apps and mixing c c++ and objectice-c and tell me that rabbit hole is not pretty damn deep.
- mahmud 15y ago
  Hortsman & Cornell's, two volume "Core Java 1.2". I only read the first. Gosling's "The Java Programming Language". And Josh Bloch's "Effective Java". After that, Java Concurrency in Practice. Langr's "Agile Java" is good for just that. Bloch, Goetz, and Doug Lea have each written excellent books on java concurrency. That's just about all the java books I would want to recommend. Many j-books are trash.
  - RodgerTheGreat 15y ago
    Don't forget Java Puzzlers, also by Bloch: http://www.javapuzzlers.com/ http://www.javapuzzlers.com/ Not only is it a fun read, but it delves very deeply into case studies of the dark corners of the Java language.
  - rkalla 15y ago
    +1 Effective Java is a must-read once you understand Java. It points out what is magic and what is not. What takes up processing time and what doesn't. It pulls the sheet back on the abstractions and shows you how everything works and what you should be aware of. Doug Lea is a brilliant developer in the concurrency space. With his Executor framework that went into (Java 5?) he suddenly made threaded programming as easy as possible to get right.
  - andymoe 15y ago
    Awesome. Thanks so much for the recommendations everyone.
- rattab 15y ago
  I don't know how relevant it is for mobile development but I'd recommend Effective Java by Joshua Bloch (http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683/ref=sr_1_1?s=books&ie=UTF8&qid=1312014425&sr=1-1 http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/032...). It's essentially the equivalent of Effective C++ for Java and it does a good job of explaining how to properly use the language. It also contains quite a few general programming advises which are applicable to other languages. Just keep in mind that it assumes that you already know the language and have a bit of experience under your belt.
- cema 15y ago
  Also, consider The Well Grounded Java Developer which is now in Manning's Early Access Program (http://www.manning.com/evans/ http://www.manning.com/evans/).
aerique 15y ago
Since I recall you being a Common Lisp enthousiast: do you see, for example, ECL ever becoming a viable alternative for making Android apps? I've been exploring iOS using Objective-C and I'm about half-way done with my first real app for the Appstore and I can't wait to try and rewrite it using ECL once it is done. Otherwise it will probably be Unity for me since my main interest is games and game-like apps. I really don't have the time to become and expert in each and every differing mobile platform.
- mahmud 15y ago
  I didn't look into any "alternative" ways of doing things. I tried to port ABCL to Android, but for my current needs, the standard-way is good enough, at least then I can hire help and focus on what matters, instead of doing everything myself. Our Android apps are all on the galaxy tablet, we plan to roll out a deployment of 50 devices by year's end.
evinfinite 15y ago
Just a point that needs clarification: how is any of this comment relevant to the points raised in the OP? That is, how does this help against the fact that Android has: * A much more complex set of (good!) abstractions that are poorly documented; * and, if I might add alongside the OP, requires a much higher workload in terms of code length and complexity, debugging, device configuration management and tools for what seems to be a much lower payoff? I have a successful iOS app out, and I tried to rearchitect it in a manageable way to port it on Android. What I found out is: * The code would be roughly twice as much as the iOS version. * A proper UI effort would require roughly 2.5x work than the iOS version, as I need to prep up a flexible layout that will work on phones (the buckets 'small' to 'large'), and then another for tablets (actually up to two: 'xlarge' and Honeycomb, which may require some rethinking to accommodate the new action bar). Contrast this to two, fixed-size layouts for the iOS version. * I already have a path for implementing backgrounding on iOS and it requires minimal change to account for services not available while backgrounded; otherwise, code is exactly the same. On Android, I would have to plan for it from the beginning and set up very poorly documented IBinder stuff to have my Activities talk to a background Service. * The general unwillingness of Android users in the face of paid apps, and a use model that does not lend itself easily to the insertion of ads, would make my (more costly) effort go unpaid. I must admit I have never used resources other than developer.android.com and Google, and the latter didn't help me as much as (as little as) developer.android.com did. There might be an excellent book on all of this, but I haven't bought any — any recommendations are welcome.
- nextparadigms 15y ago
  There are several good Android books out there, you can Google for top 5 Android books. A lot recommend a subscription to this site where you also get these 3 books in that price: http://commonsware.com/books http://commonsware.com/books And you can try these sites for code snippets on anything: http://www.anddev.org/ http://www.anddev.org/ http://www.androidsnippets.com/ http://www.androidsnippets.com/
- hahainternet 15y ago
  Could you give me an example of exactly why the claims you've made are true? Why would your app need twice as much code? Why is using the Android ui designer so much harder than iOS's equiv? What is so undocumented about IBinder? It's basic IPC? I would really like to hear reasons, not abbreviations.

jan_g 15y ago

I mostly agree with the blog post. It is perhaps too hard to make proper app in Android, but all those abstractions are powerful, imho. Consider quick search/suggestions. If done properly, then you can plug your implementation also to system-wide search with just some config changes (and user permission, of course). Sure, content providers seem far too difficult (search dictionary example in dev docs), but then you can reuse them for your list activity or quick search or access them from another app.

InclinedPlane 15y ago

There are other ways to do it: http://android.xamarin.com/ http://android.xamarin.com/

fdb 15y ago
Mono on Android sounds tempting. But how much overhead does the core runtime on the platform add? What is the impact in KB's and runtime performance?
- andybak 15y ago
  And how well integrated into Android 'proper' is it? For example - intents and fragments?
  - bad_user 15y ago
    I played with it -- integration is very good, mirroring the Java API quite well. I would still use Java directly on Android though. I do agree with the author that Android's SDK is a little complicated, but it has good reasons for it and whenever I choose new platforms I take it as a given that I have to make an effort to learn it. I don't see much value in bitching that the learning curve is steep, when once you get to know the platform it becomes easy to make it do what you want -- in general I bitched about Java frameworks because power and ease of use are completely missing, even once you learn them properly, but that's not the case with Android. And as far as iOS development goes, I work on apps more complicated than drawing Hello World with a couple of buttons -- and to me Android is better because it allows me to do mostly whatever the hell I want; compared to iOS where I always ask myself "is this even possible"?

gary4gar 15y ago

I would love to see some scripting language in Android AND iOS which is Officially supported. Something like Python,Ruby or JavaScript which will make app development much easier. Hey Google, Give us a nice scripting langauge. Pretty Please?

ratsbane 15y ago
Scripting Layer For Android (SL4A): http://code.google.com/p/android-scripting/ http://code.google.com/p/android-scripting/ Though for stuff you're going to distribute it's much better to go native, bite the bullet, and do it in Java.
deleted 15y ago
[deleted]

malkia 15y ago

Then again you won't find such names in iOS SDK https://plus.google.com/101253020771610439991/posts/YKKyGFdq2MT https://plus.google.com/101253020771610439991/posts/YKKyGFdq... :)

getsat 15y ago
Your link is a 404

shaunfs 15y ago

Screw it, I'm psyched! It's a great time to be a mobile developer! I was going to write a whole response regarding iOS vs Android until I realized the debate is like religion or politics. Currently both platforms are great and only getting better with each iteration. I'm developing for both platforms and loving it. Just in the latest iterations look at what we can do. iOS * AirPlay - My phone will be my gaming console and media center, genius! * iCloud - Good, no more transferring files back and forth. * CoreImage & AVFoundation - 30 lines of code to add video editing and filters to my application, sounds good! * GLKit - High-level 3D libraries for a game developer noob like me. I'm in! * TwitterAuth - I'm still going to integrate FB authentication but this is cool too. Android * Ice Cream Sandwich - No more fragmentation. Unifies hundreds of devices (not just phones). Brand new UI library. I can't wait! * ADK - My home, car, and toaster will soon be at my mobile command while giving me status updates. This is so awesome! I foresee Android powered cleaning robots in the future. * Face-tracking - So my phone can recognize me and focus in on my face and voice automatically. This sounds like fun. * USB Host - I can plug anything USB into my Android phone. Hot damn!

bignoggins 15y ago
Couldn't agree with you more. I started off doing iphone dev part time just over a year ago. Since then, I've managed to quit my job, become a full time indie developer, and travel the world. The opportunities for independent developers in the mobile space are just incredible right now. I'll have my first android app coming out in a few weeks too. To quote some 90s hip hop, "damn, it feels good to be a gangsta"
hahainternet 15y ago
Here's my question. In this (somewhat ungrounded in Android reality) article the poster makes the claim that on iOS, you 'just get' a few seconds to finish off everything. This does not seem like a sustainable model. If my app and the next app a user launches are both memory heavy, I expect my app to be killed to make space. How does this process work on iOS? Also, nobody really seems to understand how amazing Intents are before they use Android :)
- 15y ago

jinushaun 15y ago

My problem with Android development is that, being a non-Java developer, I never knew when to use the Android SDK or the Java SDK or the Apache stuff for certain tasks. For example, networking. Googling online for solutions, I don't know if any of the Java code I find is Android compatible.

babebridou 15y ago
My rule of thumb: - if you see "java.awt" or "javax.swing" in any package import, run away. - if you need to download a native library to run a hello world, run away too. The rest is/should be fair game. Try to run a hello world on the device.
- DannoHung 15y ago
  Is there a good library for doing graphics in Java? I was thinking about trying processing, but it doesn't seem quite appropriate.
  - babebridou 15y ago
    What kind of graphics? - for charts on android, http://code.google.com/p/afreechart/ http://code.google.com/p/afreechart/ - for maths calculations, http://commons.apache.org/math/ http://commons.apache.org/math/ - for opengl graphics on android, it's already a pain with all the fragmentation here. There's OpenglES10 (but no longer implemented on Xoom), OpenglES20 (2.2/2.3 and up, but no VBO support on 2.2), Renderscript (3.0 and up), JNI (if you want to program in C), MonoAndroid (for mono, you need to pay for that though)... - otherwise, just go with the official Canvas API http://developer.android.com/guide/topics/graphics/index.html http://developer.android.com/guide/topics/graphics/index.htm...
ZoFreX 15y ago
> being a non-Java developer I'm a Java developer and I don't know, either. I suspect the expertise you're looking for might be described as an "Android developer" ;)

babebridou 15y ago

Java APIs are not designed to "just work" but rather to "eventually work with anything".

stretchwithme 15y ago

Haven't tried programming Android, but not crazy about objective c. But Apple's documentation is stellar and easy to access.

aerique 15y ago
Agreed. I have no love for Apple and I'm developing directly on my jailbroken iPhone through SSH and even then the documentation is very useful.
- conradev 15y ago
  Heh. iphone-gcc sucks.

Tractiable 15y ago

Develop for the iOS platform in Cocoa, develop for Android in Adobe AIR. Best combo I have found!

dpcan 15y ago
Why not develop for iOS in Flash/Air too and have one code base? I personally think the Air download requirement on Android is a still a pretty big deterrent for most users. I really wish Adobe could have found a way to build Android apps so you basically distribute a small Air runtime bundled with your AS code as an App instead of requiring the Air system be installed separately.

1880 15y ago

Maybe I am going off on a tangent here, but... why not just use an AsyncTask with a synchronous HTTP petition inside? I am a novice in the Android SDK, but it just seems easier.

bendmorris 15y ago

Counterpoint: I just began developing my first Android app a few days ago, a turn-based strategy game. I've only had an Android device for a month or so so the platform is relatively new to me, and I didn't even know Java (although, to be fair, I knew C# fairly well a couple years ago, which is arguably the same thing plus type inference.) In a few days, with relatively few problems, I was able to build an app and I'll be releasing it in various markets soon (once I stop polishing and let it go, which is hard for me to do.) I found the experience to be straightforward and intuitive. I was able to find tutorials for any task I couldn't figure out myself and the API documentation is perfectly adequate. Working with images and settings files are two areas where I was very pleasantly surprised at just how easy it was. There were some minor frustrations. The Android emulator fought me a little so I started just debugging on my actual device. Debugging certain problems can be difficult, Eclipse can cause headaches and throw random nonexistent exceptions, etc. but overall I think you've vastly overstated the difficulty level of jumping into Android development. "The depth of knowledge of in design patterns required is so great..." It's really not. With almost no experience with Java or Android, I've put together a working app in a few days that, in my opinion at least, is pretty good, and that works on various mobile devices with different resolutions and capabilities. Some other things I'm happy with about the Android platform: the SDK is free, Android is open source, you're very unrestricted with regards to what your app can do, and Android Market developer accounts cost a one time fee of $25 instead of $100 a year.

dpcan 15y ago
Just a word of advice on Android, polish your app really well before launch. The Android Market comment system is relentless. If you don't have a smashingly nice app out of the gate, you'll probably get a couple 1-star "sucks"/"rubbish" reviews before you can finish your post-launch exhale.
- ZoFreX 15y ago
  This is interesting because I, having no knowledge of the Android market but a lot of knowledge of development in general, would give the exact opposite advice! In general I think it's agreed that the best thing to do is release, and then tweak. If the Android Market punishes people that do this then I think that's a very real problem with the market that will directly lead to poorer quality software.

d99kris 15y ago

For higher abstraction layer on Android, there's Corona SDK and other similar tools.

zyb09 15y ago

Well you're new to Android so things seem weird at first. It's all a matter of picking up the underlying concepts. To be fair ObjC and Cocoa looks for most Java devs like voodoo, but once you get it it becomes easier, too.

dpcan 15y ago
Exactly. This article was completely one-sided. He also failed to see the huge amount of community support there is for Android developers too. There's so much information inside multiple forums you would almost never be unable to find an answer to a problem.
- Pooter 15y ago
  > This article was completely one-sided. It was one person's subjective experience of switching platforms; it's not intended to be a balanced examination of API design across platforms. Why so tetchy?
- mirkules 15y ago
  There's an insane amount of support for both platforms. Without StackOverflow, 50% of the developers would be unemployed :)

huntergdavis 15y ago

Counterpoint, and like I said on the original post: Within a few days of programming Android I had published a few apps. You just need the App-titude, and the attitude as they say. I'm on day 60 and have done 65 Android apps thus far. Perhaps my live-coding video that was up last week would help? http://www.youtube.com/watch?v=x8bu8nNUZSY&feature=channel_video_title http://www.youtube.com/watch?v=x8bu8nNUZSY&feature=chann...

lurker14 15y ago
Why 65 rush jobs instead of few polished apps? Skillful Surround could be an attractive game if it got some TLC.

KirinDave 15y ago

So of all the things which might be singled out as "over-engineered" in the Android developer kit, he singles out the mechanism of _message passing_ as worthy of the propeller beanie? That's confusing to me. Message passing is one of the simplest actionable metaphors we have in the world of programming. I'm new to android development, but they seemed pretty straightforward to me.

deleted 15y ago

[deleted]

methodin 15y ago

The only thing I know for sure is it took me about 4 hours to write a concept Android app that used an existing app the market (barcode scanner) which I could interact with via intents. It was free and I can install the APK on devices without using the market. I don't really know what more I could ask for. Well that's not true, the other thing I know for sure is Objective C makes me dry heave.

amurmann 15y ago

I worked on an Android app for about 2 months together with some experienced Android developers. Most things, like displaying dialogs, storing things to the Db, etc. worked quite well and I really came to like intents. However, I completely agree with the authors criticism of the implementation of asynchronous calls. We implemented in app purchase functionality for our app and it was a huge pain. Google provides lots of documentation around this. However it's very convoluted and looking at their example IAP app makes you wonder if they had some contest going on to achieve the highest number Gang of 4 design patterns per lines of code. That massively distracted from what the example was supposed to teach you. We ended up spending around 2 weeks to get a solidly tested implementation of IAP working and get all edge cases covered. My main complaint about this is, that we weren't doing anything fancy and 99% of the code we had to write was not specific to our application. Something that just takes our vendor information and one callback for the success case and one for the error case would have totally done the job. I am sure there are hundreds of dev teams out there writing the exact same code as we did. Many of those probably are not testing their code or even just copying Google's example, without understanding what's going on. This is a huge waste of everyone's resources and will probably lead to many buggy apps. I understand that Google wants to allow for the flexibility to cover 99.9% of all use cases. However, they could still have offered a simple library method for the 99% case and have allowed the other 1% to write their own thing. Now everyone has to write their own solution. I hope someone will open source their IAP solution. If not, I actually might do it, since it's just crazy right now.

ristretto 15y ago

Wouldn't it be better though if we did not have to rely on either apple or google for mobile programming? How about extending trusty old HTML to provide low level Apis for mobile devices? Phone gap does it and it's already proving valuable. As mobile bandwidth is becoming more stable it makes more sense to quit the app store madness and embrace the wild open web as the only app platform. In principle I do not see why there isn't a set of mobile browser extensions already; i suspect that both google and apple will use their platforms as a tool to lock in developers to their own strategies.

lurker14 15y ago
Phonegap is a common JavaScript interface to native APIs. HTML is only tangentially related. Building apps with JavaScript is doable, but has performance consequences that are severe on low-power mobile devices. It's hard to fault Google for providing an open-source Java-compatible OS. It's not their fault if other OS builders are not compatible and actively block cross-platform solutions. I haven't tried it, but I don't know a reason why one couldn't write an Android native app on Objective-C. You'd need a cross-compiler and technical/legal ability to port Cocoa though, the latter which I suspect would be quite challenging.

schiptsov 15y ago

This guy it seems trying to say that Android's APIs were developed by (talented) engineers for engineers (skilled programmers) on the go, while Apple just adopted mature libraries from OSX which are providing set of hight-level abstractions and APIs understandable by any mediocre coder (the way of 'easy/cool' java/php frameworks). But one should remember that too high-level APIs and abstractions has its cost in terms of performance and bloatedness of required runtime (J2EE/Spring/Hibernate way) especially on resource-limited (lack of FPU, etc) platforms.

hackbod 15y ago

"For example, to correctly implement asynchronous HTTP requests is an entirely different challenge in iOS and Android. On iOS you use the built in libraries, and if your user happens to change applications during the request, you can be sure you have up to 30 seconds, usually more, to complete whatever actions need done before termination. On android, you must implement the `android.app.Service` API for all your important web calls. The app can be killed at any time, and you must retain your arguments, and retry the call in case it happens to die." Except... no, you don't. :/ The first sentence of the documentation on Service: "A Service is an application component representing either an application's desire to perform a longer-running operation while not interacting with the user or to supply functionality for other applications to use." Do you need to do either of those things? If you say no, then don't use Service. http://developer.android.com/reference/android/app/Service.html http://developer.android.com/reference/android/app/Service.h... In the Processes and Threads documentation: http://developer.android.com/guide/topics/fundamentals/processes-and-threads.html http://developer.android.com/guide/topics/fundamentals/proce... It describes how when the user leaves the activity in a process, it goes in the background. It doesn't kill the process. You can continue doing networking. You don't need a Service to have background threads in your process. (In fact again from the Service documentation, a Service is not a thread at all.) Just continue doing your work, and if the system needs your RAM for other processes, it will kill your process, but otherwise you can continue downloading in the background. This is exactly how for example the web browser, and any app using a WebView, works. This is similar in many ways to iOS. Not surprising, iOS seems um inspired in its multitasking design by Android.

TheRevoltingX 15y ago

WTF? This guy is an idiot. I make iOS and Android applications for a living. It is ridiculous to have to create a service to make a few HTTP calls. For that, Android/Java provides various threading classes so that you can keep multi-threaded code nice and neat. With iOS, out of the box, you get NSURL and its family. You have to setup callbacks in your class and you have to keep track of your http calls per class by using things like action=whatever. What a pain. ASIHTTPRequest makes things much easier. Ugh, this just makes me mad. Why would people listen to shitty developers? Why are you spreading this ignorance? Objective-C is a giant paint, with opaque types. Having to remember what class you've put into a dict can get messy. I have to work with both frameworks every day, and Android is the better framework BY FAR.

jcizzle 15y ago
I definitely laughed at the irony of this post.
- TheRevoltingX 15y ago
  Care to rebuke? BTW, read hackbod's comment. She's an Android engineer. This guy is flat out wrong and failed to read documentation. She puts it much nicer than I can.