Linked by Thom Holwerda on Mon 19th Dec 2011 20:11 UTC
Google Once upon a time, in a land, far, far away, there were two mobile operating systems. One of them was designed for mobile from the ground up; the other was trying really hard to copy its older, desktop brother. One was limited in functionality, inflexible and lacked multitasking, but was very efficient, fast, and easy to use. The other had everything and the kitchen sink, was very flexible and could multitask, but had a steep learning curve, was inconsistent, and not particularly pretty.
Permalink for comment 500648
To read all comments associated with this story, please click here.
Some corrections...
by Panajev on Tue 20th Dec 2011 10:25 UTC
Panajev
Member since:
2008-01-09

@Thom

However, on iOS, applications still don't really know whatever's happening to other applications. Switching between multiple applications really means switching between applications; when you switch to another application, the previous one is killed.


No, it is suspended. Unless you ask not to use iOS 4.x+ multitasking feature, your app is suspended and not killed.
Also, who are we kidding? True multitasking on any mobile device without a swap file?!?
Android or iOS, apps in background (as well as services, which are usually restarted whenever the system is able to do it) can be killed at any time if another app needs resources badly.

On iOS, whenever I need to switch to a different application, I feel hesitant, because I never know what's going to happen to the previous application. Will it remember the text I just typed in? Will it remember my location inside the application?

That's the same thing you should be worried about on Android, it is ultimately up to the app developers to make sure that they save and restore the complete application state (as it makes sense for the app of course) whenever the application is paused/stopped/killed and resumed/restarted. I think you, as in Thom, have a false sense of security in Android.

It is true that Android did go some way to make their kind of multitasking possible, but it comes with a good set of side-effects.
Unless you access memory which Google cannot yet regulate well enough (not as they would want to) with the NDK, the resources you can allocate are quite limited even on fairly beefy handsets.
Want to use more than 32 MB of RAM in your Android App on a device with 512 MB like the Xperia Play? Good luck without the NDK, as your heap is limited by design (a limit that is being raised, but considering the devices ICS is meant to be running for, that is devices with about 1 GB of RAM, ...).

Having a high level language like Java is nice, less so when you have to mix it "native code" through JNI. Debugging applications that mix both approach is also not my definition of fun (which is why I prefer the Objective-C approach Apple took and how easy it is to mix C and C++ code with it... and debug the whole thing). Another approach could have been the C#/.NET way of integrating native code (P/Invoke would have a close relative in the Java field called JNA, but Google preferred to keep full old school Java for a reason that seems academical and not practical).

While on iOS it will simply open the Twitter.com webpage, on Android, you can tell the phone to open your Twitter application instead


Technically not true, you can also open other applications, URI's are not just for webpages ;) . Ever tried sending an e-mail using iOS's mail client from your own app? It requires a few lines of code and works basically the same way. How about an SMS?

What you discover using both, and coding for both, IMHO is that Apple has been more pragmatical in the software and hardware choices they took, maybe a bit too restrained in some of them... not forward looking enough, where Android has kept the Linux attitude of let's keep adding any new cool sounding feature sometimes forgetting to fix long standing bugs and improving on what the OS already delivers...

Was NFC support in the OS really the best way to spend Google's limited Android Software R&D budget (it must be limited, else I'd expect a different SDK and development tools experience for starters... more attention to bugs being reported, better TOOLS and SDK web sites, etc...)?
How about lots of Android handsets still suffering from clock drift? Thanks to the fact that Android only uses NITZ by default (instead of also supporting NTP for example) and a lot of mobile networks do not support it, handsets like the Xperia Play (which I own) suffer from a clock drift of several seconds a day (Android does not let you use apps to automatically fix the clock's seconds component without being root... you cannot do it by hand either). This does not work too well with GTalk's chat for example (unless you correct it when it goes over 30 seconds of clock drift... you have this kind of granularity).

Apple has its fair share of problems, but it has 1.) more experience in Software R&D (OS, development tools, developers support, documentation [seeing a new OpenGL ES extension in the changelog and being redirected, upon click, to the 0x hexadecimal string definition in the Javadoc documentation instead of the Khronos web page detailing what the extension actually does is quite nasty], etc...) and 2.) it seems more inclined to withhold something 90% complete than Google which seems to be happier about releasing unpolished applications and let the bake over time.

Reply Score: 3