3 ms·

With all due respect to the developer who wrote this post, standalone apps are relatively easy - you start jumping into the rabbit hole when you start getting i

With all due respect to the developer who wrote this post, standalone apps are relatively easy - you start jumping into the rabbit hole when you start getting into server API integration and doing processing off the main thread (AsyncTask, IntentService, Service, unit tests lions tigers oh my), layouts that don't suck, and custom animations... Making an Android app look sexy/good is an art in itself that I am still trying to learn. 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/ http://commonsware.com/Android/ Reto Meier's blog http://blog.radioactiveyak.com/ http://blog.radioactiveyak.com/ Styling Android blog http://blog.stylingandroid.com http://blog.stylingandroid.com Android UI Patterns http://androiduipatterns.com http://androiduipatterns.com 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.

cageface 15y ago
Maybe eight months of experience isn't enough to judge it fairly, but I think Cocoa's almost mystical reputation is somewhat inflated. If you compare Cocoa Touch to Cocoa on the Mac you can see that Cocoa Touch is a much cleaner, simpler and more consistent version of Cocoa. There is still room for improvement. 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.
bendmorris 15y ago
(OP here.) I agree with you on most points, but I don't know how you'd write a graphical game without dealing with asynchronous operations. For example, this app uses an extended SurfaceView (uses its own thread to draw), timers to handle move animation, and AsyncTasks to perform computer AI turns and implement a hack that makes Toasts last longer. Otherwise the UI would be clunky and give a "not responding" message whenever it wasn't your turn. I would say that graphical games are a step above the simple "standalone app" you mention.
- wallflower 15y ago
  I apologize. I may have rushed to judgement. I didn't get a chance to check out your game, will do. Games are definitely not a simple standalone app. 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/Music.git;a=summary 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.
  - bendmorris 15y ago
    I certainly could've done that. I liked Toasts, found that you couldn't extend their duration beyond 3.5 seconds, Google'd the problem and found a hack to extend them. Either approach would've worked fine.
Zigurd 15y ago
> you start jumping into the rabbit hole when you start getting into server API integration and doing processing off the main thread (AsyncTask, IntentService, Service, unit tests lions tigers oh my) 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.
antrix 15y ago
Why is _Android_ development relatively easy? Well, for one thing, the territory is well trodden. ... _Java_ masters have been able to switch to _Android_ and tell people/show people how to code properly. ... _Java_ has been around for a while. Goes both ways, no? Not that your comment is without merit but this bit just struck me as really odd.
- wallflower 15y ago
  Java isn't the most flexible language. Java is notorious for having over-engineered frameworks and APIs (J2EE). There is lots of unavoidable copy and paste. The newer things that make Java look more modern, lithe and Ruby-like like Spring/Hibernate - don't work well within the power/memory limitations of a mobile device. 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).
  - cageface 15y ago
    It's important to distinguish Java the language from Java the framework-encrusted "enterprise" tool. Java as a language isn't so bad. Objective-C and Java each have their own strengths and weaknesses. For example, my Java code dealing with collections is much cleaner than comparable code in Obj-C because I don't have manually box & unbox primitives with incredibly verbose messages. 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/ http://blog.jetbrains.com/kotlin/
  - antrix 15y ago
    > Java is notorious for having over-engineered frameworks 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.
rryan 15y ago
> AsyncTask, IntentService, Service, unit tests... 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.
- wallflower 15y ago
  It's not just coding. 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.
  - bad_user 15y ago
    In my experience, the difference between Android and iOS for me is "How?" for the former versus "Is this even possible?" for the later. 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).

cageface 15y ago

Maybe eight months of experience isn't enough to judge it fairly, but I think Cocoa's almost mystical reputation is somewhat inflated. If you compare Cocoa Touch to Cocoa on the Mac you can see that Cocoa Touch is a much cleaner, simpler and more consistent version of Cocoa. There is still room for improvement. 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.

bendmorris 15y ago

(OP here.) I agree with you on most points, but I don't know how you'd write a graphical game without dealing with asynchronous operations. For example, this app uses an extended SurfaceView (uses its own thread to draw), timers to handle move animation, and AsyncTasks to perform computer AI turns and implement a hack that makes Toasts last longer. Otherwise the UI would be clunky and give a "not responding" message whenever it wasn't your turn. I would say that graphical games are a step above the simple "standalone app" you mention.

wallflower 15y ago
I apologize. I may have rushed to judgement. I didn't get a chance to check out your game, will do. Games are definitely not a simple standalone app. 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/Music.git;a=summary 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.
- bendmorris 15y ago
  I certainly could've done that. I liked Toasts, found that you couldn't extend their duration beyond 3.5 seconds, Google'd the problem and found a hack to extend them. Either approach would've worked fine.

Zigurd 15y ago

> you start jumping into the rabbit hole when you start getting into server API integration and doing processing off the main thread (AsyncTask, IntentService, Service, unit tests lions tigers oh my) 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.

antrix 15y ago

Why is _Android_ development relatively easy? Well, for one thing, the territory is well trodden. ... _Java_ masters have been able to switch to _Android_ and tell people/show people how to code properly. ... _Java_ has been around for a while. Goes both ways, no? Not that your comment is without merit but this bit just struck me as really odd.

wallflower 15y ago
Java isn't the most flexible language. Java is notorious for having over-engineered frameworks and APIs (J2EE). There is lots of unavoidable copy and paste. The newer things that make Java look more modern, lithe and Ruby-like like Spring/Hibernate - don't work well within the power/memory limitations of a mobile device. 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).
- cageface 15y ago
  It's important to distinguish Java the language from Java the framework-encrusted "enterprise" tool. Java as a language isn't so bad. Objective-C and Java each have their own strengths and weaknesses. For example, my Java code dealing with collections is much cleaner than comparable code in Obj-C because I don't have manually box & unbox primitives with incredibly verbose messages. 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/ http://blog.jetbrains.com/kotlin/
- antrix 15y ago
  > Java is notorious for having over-engineered frameworks 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.

rryan 15y ago

> AsyncTask, IntentService, Service, unit tests... 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.

wallflower 15y ago
It's not just coding. 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.
- bad_user 15y ago
  In my experience, the difference between Android and iOS for me is "How?" for the former versus "Is this even possible?" for the later. 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).