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

A few days of programming on iOS and Android illustrates a vast difference.(plus.google.com)

159 points by ssutch 14 years ago | 91 comments

bendmorris 14 years 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.

SomeCallMeTim 14 years ago | |

I'm a long-time game programmer, and not at all an Apple fan (somewhat the opposite, in fact). When I picked up Android I really, really wanted to like it.

Every time I turned around, the Android platform surprised me. In a bad way. Full disclosure: I'm also not a Java fan, and think it was a completely brain-dead idea to make Java the first-class API. I'm certainly not a Microsoft fan, but even C#/Mono would have been better (not that I know any C#), if only so they wouldn't have had to waste time reimplementing the VM for licensing reasons. But it's not Java that I had a hard time with.

I've developed games on 12 different hardware/software platforms. There are so many things missing and/or broken about the way Android does things that I feel embarrassed for Google. Some of those things have subsequently been fixed, but many haven't, and some have been ignored in the bug database for YEARS now. A LOT of those things wouldn't have been problems if they didn't have so many layers between the app and the hardware (Java being one of those layers, but not the only problem).

As you say, it's really Not That Hard to just throw a simple app together that does what it needs to. Intents and Services are also ABSOLUTELY not the problem. The developer who wrote the original article didn't read enough of the docs or the right docs, or isn't as smart as he thinks he is -- the concept of Intents is not rocket science. The application lifecycle isn't even hard to understand -- it's laid out in the intro docs pretty clearly.

If only Android actually DID what those docs said, things would be a lot easier for a game developer. In fact, an "app" can be stopped and then a new one started before the old one actually receives its shut-down message. In the same (Linux) process -- so any native code with static data is still sitting around. One of many annoying problems I ran into.

I think the core mistake of almost every new platform is one of ego. "We'll design this NEW AND DIFFERENT platform in some revolutionary and awesome way, and make everyone rewrite their apps in this way feel is Better." When dealing with platforms, the one most important thing to do, in my opinion, is to HIDE the differences between one and another platform as much as possible. Android does this to some degree WITHIN the Android ecosystem, but we simply DON'T NEED multiple ecosystems. I submit it would be better for everyone if there were a single cross-platform engine that everyone used. Before I get dismissed as a kook, please think about OpenGL, and the fact that something as complex as a rendering subsystem IS in fact supported on all platforms, to everyone's benefit.

What would have been better is a library that abstracts away the fact that Android is its own unique OS, period. When I write code, I don't want it to be Android code, or iOS code, or WebOS code, or Windows [Mobile] code, or Linux code. I want it to be, as much as possible, completely cross-platform. I want the platform to fade into the background. You could bootstrap this by creating all the UI and other OS code as a portable layer that can run on many different systems.

But no new platform developer ever seems to get that, and so we end up with a new ecosystem for every new platform, and it's left to third parties to fill in the gap with cross-platform libraries. But it's not the developers -- or the users -- that big initiatives like Android get funded to satisfy.

/rant

extension 14 years ago | | |

But no new platform developer ever seems to get that

I think everyone gets the value of cross-platform development, but in reality it's very difficult to achieve without enormous compromises and history tends to plot against it.

Apple's platform (Objective-C/Cocoa) can be traced back to NeXTstep. In 1988, it was the most progressive thing out there and some would say it still is. Apple leveraged their existing technology and ecosystem through OSX and all the way to iOS.

But the rest of the industry went in other directions. Objective-C/Cocoa would have been a strange choice for Android and would only have made it even more vulnerable to Apple's formidable patent arsenal. Instead, Android uses Java, which is also an attempt to leverage an existing ecosystem. But Android's fairly novel models of user interaction and application lifecycle required a whole new API. And Google had to reimplement the VM to avoid license fees, which still wasn't enough to avoid a patent attack.

In summary, as long as we have a) innovation and b) lawyers, we will constantly have to learn new development platforms which may not always be entirely novel.

MichaelEGR 14 years ago | | |

@SomeCallMeTim >I submit it would be better for everyone if there were a single cross-platform engine that everyone used.

>What would have been better is a library that abstracts away the fact that Android is its own unique OS, period. When I write code, I don't want it to be Android code, or iOS code, or WebOS code, or Windows [Mobile] code, or Linux code. ---

There are options out there. I'm one of those 3rd parties soon releasing a comprehensive middleware solution for app dev including a lot of game dev oriented effort that provides a clean abstraction layer via a component architecture that uses a large majority of advanced Java language features under the hood without sacrificing performance.

Keep a watch out for TyphonRT; drop me an email via the contact address and I'll be glad to discuss more and make sure you get early access. I'm aiming to get it out ASAP and before I give an all day game dev workshop at AnDevCon II in November. I suppose one thing that makes TyphonRT unique is that it's a tool, framework, and future platform (PaaS). At the heart of things you can pick and choose individual blocks of functionality (tool), or utilize the runtime framework (framework), and soon there will be optional PaaS features aiding Android and cross-platform dev in the coming year after launch.

Another Java based cross-platform effort which is similar in purpose though significantly different at the architecture level is libgdx. For C/C++ check out Battery Tech and the Proton SDK for similar cross-platform efforts (both of these with even more device coverage).

TyphonRT provides that layer of sugar you seek without losing performance and creating full cross-platform execution for OpenGL apps without changing a line of code for J2SE -> Android. TyphonRT is not limited to OpenGL though and can utilize any graphics API potentially allowing a hybrid UI, but the rest of an app still being cross-platform.

Having worked intensely with Android since v1.0 and the G1 hit my hands in Oct '08 I have more than a few stories on the difficulty of low level development / games, etc. across different OS and major device hardware generations. I've experienced first hand a good deal of general engineering blunders and have found and reported a few major ones myself (you know when big G fixes a bug immediately upon being reported you found a good one; the 3.0 & 3.1 / NIO immutable endian swap issue comes to mind!).

Middleware will mature and soon provide a lot that the Android SDK lacks for certain app development areas. In many ways the Android SDK while novel in several areas is still being developed from an old engineering model, but that is seemingly unavoidable for a large organization such as Google. There are of course additional inherent problems with tying the SDK to firmware, but such is life.

I do agree with your last point though that generally the SDK in addition to the particular ecosystem quirks that have occurred over time isn't exactly indicative of satisfying developers.

seclorum 14 years ago | | |

I've ported some 3D games, written in C++, to both iOS and Android .. and I don't get what the problem is? If you want to use OpenGL ES - just use it. Its quite feasible to have a full C++ - based game on Android and iOS, using the same codebase, with some environment-related (OS specific) glue code to get it working on the target platform.

I got my apps ported and basic iOS/Android shells set up, and I haven't had to go back to the code for the OS-specific stuff in 6 months - all the continued development work has been in C++ at the GL ES level.

So, I would say, if you do your work properly you can set up a very comfortable environment, as a games programmer, to support cross-platform development on these platforms with ease.

anyidiot 14 years ago | | |

Yes, C# is way better for games because you can write mixed format display buffers, but Java isn't that bad as long as its JITed. It limits you to post 2.2 droids, but if doesn't have 2.2 on it, it probably has the shitest of graphics hardware anyway.

I dont get your other complaints though. Show me a developer guide for a console platform that doesn't have outright lies in it and I'll show you my unicorn.

There is a single cross-platform engine, btw, its called Unity, and if you can live with its constraints, then off you go.

Its not in the platform creators best interest to make it compatible with other platforms. So dont hold your breath for write-once that doesnt suck.

koko775 14 years ago | |

You're high on the post-development rush. It's addicting. But it doesn't mean the platform will scale with you. I've done extensive iOS and Android development (more extensive on the Android side due to business necessity). Here's some gotchas that I've encountered, from memory, because these are only the recent ones (plus one or two memorable ones from way back).

EDIT: Disclosure - I am one of the rare types who is actually a big fan of both Java and Objective-C's syntax, though I'm more partial to Scala's approach than Java's, overall. I view Objective-C, conceptually, as somewhat in between C and Python, with good parts from both (though of course ObjC is far older)

Example #1:

I made the mistake of using ArrayAdapters, and hand-writing my own wrappers around the android sqlite libraries to manage my app's data. What did it get me? Garbage collection cycles that crashed the app, among other things.

Example #2:

I am of the opinion that in order to build a stable, robust app, Content Providers, at the very least, are required (for many reasons, the primary one currently being the ability to use LoaderManagers and CursorLoaders). But where was the documentation that explained why this was so? The complete lack of a centralized, high-level overview of Android systems have lead me to several development dead-ends, resulting in rewrites. While I'm wiser for the effort, and have finally settled on a sane, reusable, fairly general pattern for data-driven Android apps, I used up some really valuable development time finding this out. And you know what? Looking at the codebase before my (just-deployed) rewrite, and looking at the Android codebase at the job I left before it, everyone is making these same mistakes, and not many are realizing it until later.

Aside - Rant:

BaseColumns (http://developer.android.com/reference/android/provider/Base...) has no discernible use other than for a class to inherit some static variables. This is kind of ridiculous, as there's no requirement to use the column constants anyways, and they're static. I use enums instead, for each database table. Works much better. At my last job I even wrote an automatic SQL create statement generator for use in onUpgrade(). Oh, and if you want to use anything other than _id for the column name for your objects' unique IDs, you're not going to have an easy time with automatically binding your database objects to your UI.

Example #3:

Lots of stuff requires contexts. Against your common sense, you should try to avoid supplying the current activity as a context when you can use the application context instead. Why? Because if an Activity, which is a context, is retained as a member variable in something - perhaps a class that is, itself, a member variable of the aforementioned Activity, voila! You've got a circular reference and a potential memory leak! Where was this in the documentation? Nowhere. It was in a blog post that isn't exactly on most people's radar: http://android-developers.blogspot.com/2009/01/avoiding-memo...

Example #4:

Changing orientation destroys and recreates an Activity. Did a AsyncTask run at an inconvenient time? Oops. Chances are you're going to crash if you needed to do anything special with your Activity's state.

Example #5:

Using Apache's HTTP client? Careful. Don't use RequestWrapper, because executing a POST request wrapped in one can cause it to drop headers from the request. Just use different methods for HttpGet and HttpPost, and add on (for example) authentication parameters, device model names, other info for metrics, etc. separately for each. Funny thing is, I had better luck duplicating code for GET/POST here than reusing it, which I found disgusting, because duplicating code is not a good solution to anything, but it just got the work done.

Example #6:

I've gotten unreasonable Cursor closings that weren't my fault because someone at Motorola thought they were being clever and closing Cursors in a finalize() method was somehow a good idea: http://stackoverflow.com/questions/6552405/android-compatibi...

TL;DR (my main argument):

Android has many avoidable gotchas that require a solid programmer to identify and work around, but which aren't immediately fatal if ignored. Android provides a lot of infrastructure, and some of it is even good! Despite its mess of poorly-written, poorly-documented, or incorrect APIs, it manages to allow decent programmers to write pretty decent solutions and some pretty robust code. But it does a damn piss-poor job of documenting its wrongness when it rears its ugly head, and it fails to make clear that while there's freedom to do things many ways in Android, there are really only a few ways to do them well.

Rant #2:

All android devices seem to suffer from gross over-logging, some far more than others, like Motorola, or some newer HTC phones., which is a huge pain in the ass when I'm just concerned with my own error logs, and not spurious calls to the logger that the software author or device manufacturer forgot to or didn't care enough to elide.

Rant #3 (emphatically):

The worst and most fundamental flaw with it, though, IMO, is that the classes for the views and the serialization format representing them (the layout xml's) do not have anything even close to a 1:1 mapping. Serializing a class - it's not that hard. iOS does it by literally serializing the state of the view objects as configured in Interface Builder into what was once a binary file, but now is an XML file (nib, xib). Anything you can initialize or style or otherwise edit to affect the initial state of a view in interface builder or (were it reasonable) another method of directly editing the serialized representation you can also do in code. Not so in Android.

Here's a link to a post of mine last month that addresses some more gripes with Android: http://news.ycombinator.com/item?id=2737284

P.S. I've talked to Bob Lee (of Square; former core library lead of Android) about this before. Even he agreed that Android's APIs were poorly thought-out and designed in places. That's pretty damning right there.

wallflower 14 years ago | | |

You've really nailed it here. The way I look at it, though, is that it is easier to become competent at iOS development because of the ability of the framework to support robust code and the sheer number of worked out examples. Being an Android programmer means that you've gone through your apprenticeship where you've spent hours if not days with ContentProvider, RelativeLayout, AsyncTasks, Handlers and maybe even ConcurrentLinkedQueue(s).

Most of my iOS developer friends have no desire to learn Android. That is what makes Android development hot - as you have very little overlap of iOS and Android. Believe me, I've paid for attempting to switch back between iOS and Android with splitting headaches (if not done on separate days). I don't believe people who specialize in both.

You left something off your list, the sheer insanity of async loading images into a ListView. iOS developers have EGOImageView, we have a few competing implementations, including writing your own.

> I am of the opinion that in order to build a stable, robust app, Content Providers, at the very least, are required (for many reasons,

One way to see if someone knows what they are talking about is to ask them about multi-table content providers.

Also, what phone does the candidate have in his or her possession...

dpcan 14 years 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 14 years 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.

bignoggins 14 years ago | | |

this is just as true on iOS. In mobile you can get away with releasing something that is unfinished, but you cannot get away with releasing something that is unpolished.

sjs 14 years ago | |

I prefer using and making software for iOS over Android but I think you're right. Cocoa programming requires a lot of up front knowledge about their design patterns and tools. It's no small undertaking for someone to learn about KVO, delegate pattern (so simple but confuses people for some reason, I think it's the name), MVC, and then add actions and outlets, resizing masks, and all the other unique things to Xcode/IB that people have to learn.

Once you know Cocoa and Xcode iOS development is faster and more fun than Android development but it's no small learning curve. It's worth it for the fast turnaround of using the simulator compared to Android where both the emulator and device are slow, you're looking at 5-10x as long to launch your app compared to the iOS simulator. Plus ObjC > Java if you ask me, but I'm a masochist who likes both C and dynamic languages. Individual statements are verbose in Cocoa but I'd have to look at how much boilerplate is caused by the Java straight jacket to speculate on which is ultimately more verbose.

You also have to be willing to put with some crusty stuff. Nothing compared to OS X programming but it still feels old next to Java's APIs. Two good examples are string manipulation and interacting w/ the filesystem, so verbose on iOS but pretty good in Java.

reidmain 14 years ago | | |

I agree whole hardly. I was doing C# and WPF dev right out of Uni and really loved the total power that you were given to create cutting edge apps (I worked primarily with the Microsoft Surface).

I don't really have anything bad to say about WPF but when I first got my hands on UIKit and Objective-C I fell in love.

In WPF you can do anything and customize everything. UIKit is Apple's magical black box but it will get you like 80-90% of the way to your goal so you don't need to engineer everything like I did with WPF. Couple that with Foundation and their other great frameworks like CoreLocation and so much boilerplate code seems to be hidden behind Apple's walls.

I'm also probably in the minority but I like the verboseness of Objective-C and the dynamic nature of it. Honestly it is a small thing but not having to put null pointer checks all over my code is the thing about the language I love the most.

serge2k 14 years ago | | |

Verbose is putting it mildly. Objective C isn't a bad language, but the syntax is just horrible IMO. So much extra typing to do something simple.

That said, the app I'm writing at work does a lot of stuff with strings, which you did mention specifically as a problem.

Properties also drive me crazy. just a ton of extra annoyance just to declare a variable.

I also prefer eclipse to xcode, and visual studio to both.

oh and good point about the simulator. The iOS simulators are MUCH better than the android simulator. So much faster.

rudy750 14 years ago | |

I keep hearing from iOS camp that NO ONE buys android apps. What are your experiences?

shaunfs 14 years 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 14 years 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 14 years 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 :)

jmelloy 14 years ago | | |

You get notified when the user switches apps away from yours, so at that point you quicky get your shit together and assume you could be killed at any time.

mahmud 14 years 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.

hackbod 14 years 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.h...

In the Processes and Threads documentation: 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.

zyb09 14 years 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 14 years 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.

mirkules 14 years ago | | |

There's an insane amount of support for both platforms. Without StackOverflow, 50% of the developers would be unemployed :)

jan_g 14 years 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.

jinushaun 14 years 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 14 years 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 14 years ago | | |

Is there a good library for doing graphics in Java? I was thinking about trying processing, but it doesn't seem quite appropriate.

ZoFreX 14 years 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" ;)

gary4gar 14 years 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 14 years ago | |

Scripting Layer For Android (SL4A): 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.

schiptsov 14 years 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.

methodin 14 years 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.

KirinDave 14 years 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.

amurmann 14 years 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.

InclinedPlane 14 years ago |

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

fdb 14 years 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 14 years ago | | |

And how well integrated into Android 'proper' is it? For example - intents and fragments?

1880 14 years 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.

huntergdavis 14 years 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=chann...

lurker14 14 years ago | |

Why 65 rush jobs instead of few polished apps?

Skillful Surround could be an attractive game if it got some TLC.

stretchwithme 14 years ago |

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

aerique 14 years 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 14 years ago | | |

Heh. iphone-gcc sucks.

d99kris 14 years ago |

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

ristretto 14 years 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 14 years 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.

babebridou 14 years ago |

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

malkia 14 years ago |

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

getsat 14 years ago | |

Your link is a 404

TheRevoltingX 14 years 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 14 years ago | |

I definitely laughed at the irony of this post.

TheRevoltingX 14 years 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.