Review: Android
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.
E-mail Print r 6   · Read More · 100 Comment(s) http://osne.ws/jmo
Permalink for comment 500802
To read all comments associated with this story, please click here.
RE[2]: Some corrections...
by Panajev on Wed 21st Dec 2011 12:27 UTC 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