What do you think of Android API design?

Question

When I got acquainted with Android platform my first impression was WOW, that's must be a super awesome thing. But when I started developing for it I felt that its learning curve could be simpler. Don't get me wrong, it is not hard, but it feels so javish ... I am an experienced Java developer and know how most Java apis looks like. I think that Android API could be designed with less patterns in mind and still be effective.

Just to name a couple of design decisions that have puzzled me:

1. Activity concept is too generic
2. Content providers seem to be odd, especially when it comes to real-world examples of retrieving data from the SQLite storage
3. Too many callbacks - Java 5 isn't the best fit for it
4. Dialogs are asynchronous - is that so crucial for the platform?

Answer 1

I am an experienced Java developer, the language, patterns etc are not an issue for me. Here are my thoughts about the android platform:

• too much boilerplate in the API: constants everywhere (though for performance reasons so it is understandable), inappropriate methods and fields (who would ever use this thing, but still its there making the API more difficult with hundreds of other similar cases), poorly written javadoc (no, describing fields in one sentence is not enough sometimes), poorly written samples.
• poor packaging: I have not seen such nightmare since I started using 3d party APIs. Just look at the Paint class. I mean c'mon Paint.Style, Paint.FontMetrics, Paint.FonMetricsInt and many other embedded classes ... how hard is to create a paint package and put Style class inside it. There are many such cases.
• style and theme concepts are masochistic when you start working with something else than the default UI. Understanding and customizing it for the first time feels like making voodoo.
• writing custom widgets is difficult because of the cumbersome APIs.
• Spinner widget and its broken stretching background. I prefer how it was done in the oldest versions.
• 1 right way an 10 wrong ones of doing the same thing.

But still I am using it and develop exclusively for this platform so the pain is just part of the job.

Answer 2

It's really sophisticated and it works great. However, you can't just read an "android quick-start" guide and then just think you're going to have fun making your new app. It's not simple because it's a production device platform that has to take into consideration security concerns, performance, etc.

I would suggest before you start development - thoroughly study the Android APIs and Java OOP design patterns. Only after that will Android dev be a satisfying venture.

Just have a good read of any Android Book.

Answer 3

I dabbled in Android a year ago and found the experience horrible. IIRC putting a "Hello World" widget on the home screen took 3 classes and 5 XML files. Its verbose, requires way to many files, uses XML (which I always despise), baffling API, awkward GUI, and very strange to write code for.

I constantly ran into issues about shared state between widget and app. The docs seemed focused on the "Hello World" scenario instead of actually writing complex apps.

I also couldn't wrap my head around the API since it was so large. It was like learning a new language with a similar syntax to Java. I spent weeks reading the docs, reading the API, writing code and example apps, but just could never get it.

After a few weeks I gave up my dream of a Android App. Haven't touched it since, although NBAndroid or whatever its called is still installed in my Netbeans profile. Maybe some other time

Answer 4

I'm in the exact same situation. I've spent the last seven years writing code in C/C++ and the last three writing RISC PPC Assembly and scripting in Python. I never touched Java until I was hired by a small start-up and asked to write an Android app.

My first impressions upon using the SDK were "Wow, this is surprisingly simple. I don't even have to formally know Java to write a simple splash screen and menu for my app." Now that I'm trying to write more complicated layouts though I'm quickly turning against my initial impression. I hate not being able to give elements a relative X, Y coordinate on the screen. It seems every element I use is just a little bit higher or a little bit lower than I would like it to be. And I hate how some of the objects like seek bars and timers work. They're implemented a bit more complexly than they need to be.

Right now I'm experimenting with the NDK and looking at trying MonoDroid. So far I like the NDK much more (but probably because I'm C/C++ biased).