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.
Thread beginning with 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

RE: Some corrections...
by JAlexoid on Wed 21st Dec 2011 00:23 in reply to "Some corrections..."
JAlexoid Member since:
2009-05-19

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...)?


I'm sorry, but I very much prefer Android's Reference to iOS's. Much easier to navigate. Though if you're not used to JavaDoc style documentation, I can understand the issue but I do not share it. And Eclipse is Eclipse.

And having Diane, Romain and Xavier on the android-developers Google Group is just marvelous. Does Apple allow their highest ranked developers help app developers?

As for API bugs, Android is pretty solid. There are bugs, but they are cleaned up with new releases.

And I share your concern about the time float, though Galaxy Nexus seems to be much better with it.



Why will not iOS have something like J2ME CHAPI? Really, why are all "Share" buttons result in such horrible experience on iOS. While being wonderfully easy on Androoid - a list of applications that handle sharing. And as Thom said - can the URL https://twitter.com/#!/YouTube/status/149281734347857920 result in opening of your Twitter client and show that status on iOS? At least in latest incarnation.

Reply Parent Score: 2

RE[2]: Some corrections...
by Not2Sure on Wed 21st Dec 2011 02:40 in reply to "RE: Some corrections..."
Not2Sure Member since:
2009-12-07

Uhh, iOS has custom URL support for app launch and 3rd party app intercommunication strategies: http://bit.ly/rM4jhI

Please consider getting at least a little informed about a subject before ranting.

Why anyone pays any attention to these "cross-platform" critiques from people with such little knowledge is beyond me. They are nothing more than arrogant displays of my arbitrary preferences make more sense than yours. Seems like a waste of time and energy.

Reply Parent Score: 1

RE[2]: Some corrections...
by Panajev on Wed 21st Dec 2011 12:27 in reply to "RE: Some corrections..."
Panajev Member since:
2008-01-09

I'm sorry, but I very much prefer Android's Reference to iOS's. Much easier to navigate. Though if you're not used to JavaDoc style documentation, I can understand the issue but I do not share it. And Eclipse is Eclipse.


It is not the style of the documentation. It is the fact that at times it is outdated (the tools.android.com website is constantly out of date), at times it contains not functional samples, at times it is not intuitive at all in its explanations (method which does not throw an IOException if the operation does not succeed, but in the Throws notes it is said that it does throw an IOException if it cannot perform that operation ?!?), some key parts are very poorly explained or barely touched (good luck on properly understanding LinearLayout weights based on their UI documentation alone), and quite often you are presented with method parameters which are not explained in structure and use anywhere near the method (and its documentation) in which you are supposed to use them in, but to be fair Apple's documentation sometimes suffer from this issue as well.

Javadoc style documentation usually means programmers making notes and briefly documenting parameters --> automatic tool generates some HTML. That is not enough if you really mean to properly maintain what is known as "developers support/relations". I am not saying that the Android engineers do not put effort in, but unfortunately it does not feel like they have staffed a team dedicated solely to documentation and technical writing...
Good documentation, IMHO, goes beyond describing what the class and methods should do (in general terms), what the functions are named, and how many and of what type its arguments are.
Something Microsoft and Apple do understand. Look at Facebook's iOS SDK for example... they make it trivial to use, they document it really well, and provide you with clear and to the point samples to get you started as fast as possible.

Eclipse is not a bad IDE, it does a lot for you, it just does not seem that good of a fit for Android. It's big, slow, complex, and I do not know if it is helping Google to design the best possible IDE for Android development as possible. UI and usability wise, neither Eclipse nor the ADT tools win any award IMHO. With an Eclipse plugin, using JNI and a not even very recent GCC release for the NDK and for C/C++ code compatibility... well, it does not look like what a company that size, dealing with a project of this much importance and weight, would do. Not even a customized and ready-from-start for Android Eclipse set-up like Aptana provides (in addition to their Eclipse plugin)?
Eclipse works really well with Auto-completion and code snippets --> the new onClick... CTRL+SPACE action saves a lot of time and allows you to do a good deal of what you would normally accomplish with Lambda expressions (Blocks in Objective-C, but obviously not as powerful).

How much have you used a recent Xcode release (4.x series)?

And having Diane, Romain and Xavier on the android-developers Google Group is just marvelous. Does Apple allow their highest ranked developers help app developers?


Let say that Chris Lattner (head of the LLVM project and Apple employee) regularly posts on their developers forums ;) . Many Apple employees regularly post on their forums, ask for bug reports (you mention something on the forum, an Apple developer who works on the area might ask you to please file a bug report and post the bug report number [the general developers bug reports team is probably another separate team from the one working on the Clang compiler for example]), give users some help, etc... Generally, they are quite reactive to developers reported bug reports, answering developers and trying to gather more information and test cases. I have had some good help from Tor Norbye as far as the ADT plugin and the layout editor are concerned, so I am not calling into question the quality of the people involved. They just feel overworked and understaffed.

Also, along with the yearly iOS developer license you purchase, you get 2 technical incidents requests in which you can ask Apple for technical help on your app directly.


And as Thom said - can the URL https://twitter.com/#!/YouTube/status/149281734347857920 result in opening of your Twitter client and show that status on iOS? At least in latest incarnation.


http://applookup.com/2010/09/iphone-apps-with-special-url-shortcuts...

http://wiki.akosma.com/IPhone_URL_Schemes#Facebook

You have pragmatical ways of doing what you ask (open an app from another app) on iOS too. Apple does not throw hundreds of thousands of ways of doing something if 90% of them might be replaced by something quite as powerful, but easier to use and to implement.

You might be against Apple as a company, you might not like the limits they place on you as developer, you might not like their App store model, etc..., but you cannot judge their tools, their support, the quality and polish of the user and developer experience they provide as being anything but great (I did not say perfect, they are not of course).

Reply Parent Score: 2