I have to second that. I'm a rather experienced java-developer, I've done two Android apps and the Android-SDK is one of the worst SDKs I've ever seen. Substandard doesn't even begin to describe it. No matter where you look it seems to throw in a Gotcha! with every step you're doing.
* The IDE-Integration is meh: I do like Eclipse, but even the SDK-Manager for Android bugs around. The Layouting-Screen is so slow that everybody edits the XML directly anyway.
This should get a bit better with Android Studio.
* The API seems to have been converted from a (bad) C-API. Loads and loads of useless inheritance. Whenever you instantiate an object in Android it brings along at least 15 methods that make no sense to call. It often doesn't even use generics. Happy casting. Why use enums when you can have Bitfields!
* Hardware acceleration is just a gamble. The doc here [0] says that you can enable it or disable it, except that sometimes that get's overridden and that you can enable and disable it partially as well, except that with some parts that doesn't work, especially in conditions that might apply sometimes.
In practise I've seen that enabling acceleration made some parts of my applications smoother, and some slower. This behaviour changes with every minor version update on the tablets, of course. Way to go Android!
* If you ask the Android API (on GalaxyTab 3) if an SD-Card ("external storage") is inserted, it will always return true, because the internal memory uses sd-card drivers and is always there.
That is one of these thousands of gotchas that cost you 30 minutes of debugging.
* Android's standard Activity has methods for storing and restoring state, which is reasonable except that those are not persistent and should be only used when the Activity get's destroyed and recreated during turning of the display, for example. If you want persistent state, so that your App can be killed, you have to invent it yourself. At this point, I did the turning-thing with my own mechanism as well, because it was less cumbersome and less code-duplication.
* MultiTouch is just messing around with raw values. There are 10 pinch-zoom libraries out there, and none of them is perfect.
I could rant on endlessly, so I will some it up:
* The android SDK is 50% crap, by which I mean that if you are doing something slighty complex than you will find yourself outgrowing the extremely limited usecases that it's Views allow you and reimplement new ones yourself. I even had to modify the TextView because it performs so badly.
* The android section of StackOverflow is the lowest-quality section I've seen there. Many questions are answered by workaround and hacks ("copy/paste this"), by, what seem to be programming-beginners. This is sad, because I assume that many people learn Java via Android, and the style it teaches or rather requires is plain awful.
Most in-depth questions are not answered at all, because no-one has a clue, I asked a couple of things regarding performance and the rendering-pipeline on the mailing-list, but never get answers other than "your app is slow? make it simpler and read our beginner's howto."
Most of the answers I got, I got by reading the sourcecode [1].
* Performance is terrible. Most of the performance it get's is gained by faster CPUs. Just think about this: In most animations android will need time in every frame to recalculate the height of each letter of whatever text is on the screen. Because most aren't cached. And you can't tell Android which things will change.
At some point I was even thinking about reimplementing a layout manager myself, because of stuff like this.
I've never had a problem with the Activity state, but then I always shove data in an SQLite database anyway, which isn't hard. Is it really that troublesome to implement?
No, but it get's on my nerves that Android always says "Hey I have something in my API for that", and I after a (short or longer) while I realize it doesn't work as expected.
I most often just use Json (because with Google Gson, you can just serialize it into an object without boilerplate).
Activity state is persisted to disk (by the ActivityManager). That's why your process can be killed to free memory then woken up again when the user task switches back to it.
* The IDE-Integration is meh: I do like Eclipse, but even the SDK-Manager for Android bugs around. The Layouting-Screen is so slow that everybody edits the XML directly anyway. This should get a bit better with Android Studio.
* The API seems to have been converted from a (bad) C-API. Loads and loads of useless inheritance. Whenever you instantiate an object in Android it brings along at least 15 methods that make no sense to call. It often doesn't even use generics. Happy casting. Why use enums when you can have Bitfields!
* Hardware acceleration is just a gamble. The doc here [0] says that you can enable it or disable it, except that sometimes that get's overridden and that you can enable and disable it partially as well, except that with some parts that doesn't work, especially in conditions that might apply sometimes. In practise I've seen that enabling acceleration made some parts of my applications smoother, and some slower. This behaviour changes with every minor version update on the tablets, of course. Way to go Android!
[0] https://developer.android.com/guide/topics/graphics/hardware...
* If you ask the Android API (on GalaxyTab 3) if an SD-Card ("external storage") is inserted, it will always return true, because the internal memory uses sd-card drivers and is always there. That is one of these thousands of gotchas that cost you 30 minutes of debugging.
* Android's standard Activity has methods for storing and restoring state, which is reasonable except that those are not persistent and should be only used when the Activity get's destroyed and recreated during turning of the display, for example. If you want persistent state, so that your App can be killed, you have to invent it yourself. At this point, I did the turning-thing with my own mechanism as well, because it was less cumbersome and less code-duplication.
* MultiTouch is just messing around with raw values. There are 10 pinch-zoom libraries out there, and none of them is perfect.
I could rant on endlessly, so I will some it up:
* The android SDK is 50% crap, by which I mean that if you are doing something slighty complex than you will find yourself outgrowing the extremely limited usecases that it's Views allow you and reimplement new ones yourself. I even had to modify the TextView because it performs so badly.
* The android section of StackOverflow is the lowest-quality section I've seen there. Many questions are answered by workaround and hacks ("copy/paste this"), by, what seem to be programming-beginners. This is sad, because I assume that many people learn Java via Android, and the style it teaches or rather requires is plain awful.
Most in-depth questions are not answered at all, because no-one has a clue, I asked a couple of things regarding performance and the rendering-pipeline on the mailing-list, but never get answers other than "your app is slow? make it simpler and read our beginner's howto."
Most of the answers I got, I got by reading the sourcecode [1].
* Performance is terrible. Most of the performance it get's is gained by faster CPUs. Just think about this: In most animations android will need time in every frame to recalculate the height of each letter of whatever text is on the screen. Because most aren't cached. And you can't tell Android which things will change.
At some point I was even thinking about reimplementing a layout manager myself, because of stuff like this.
[1] http://grepcode.com/file/repo1.maven.org/maven2/org.robolect...
It is my opinion that the main reason many Android apps lack quality compared to iOS is not Apple's review-process but the crippling SDK.
PS: If I google "Android SDK sucks" i get a lot of results. If I google "iOS SDK sucks" I mostly get the same results about Android.