The Intent system is indeed awesome, but Google seems to have forgotton something.
How does a developer know all the possible intents?
If i define a new intent, it isn't registered anywhere globally for other developers to use, so every app developer has to communicate it through some unofficial channel.
There is some community work in that direction, i'd hope google would endorse it more:
Google does document Intent constants that work with the standard application compliment of AOSP, and SDK add-ons typically document their Intent constants. An SDK add-on would be one way an app with a rich Intent interface could make that interface known in a more-formal way.
This is indeed a huge problem. My friends were once building an app that needed to talk to a bunch of other apps via intents. It required hours of reverse engineering and hit-and-trial to get it working. They gave up on it after a few weeks.
Intents are an open messaging system. The fact that they use java package names shows you they're meant to be user-extensible and infinite.
Compare this to the bit-packing retardedness that is the Win32 message crackers[1]. Commercial software companies used it just like intents, and whenever you licensed "components" you got a print-out of all the magic constants the developers thought were available.
Dammit, Java IS a better language than either C and C++ for application development.
What do you mean fewer features? Intents are how everything is done. Android is basically four major components: Activities, Intents, ContentProviders and Services (Views are not really a components, just a nice hack which uses reflection & XML to make the GUI DOM-like .. but without having the foresight to allow for DOM-like manipulation -- why can't I configure layouts & content with xpath-like selectors?)
Android has the cleanest architecture of any visual environment out there, bar none. D-Bus is far lower level than Intents (you can't send a D-Bus message to fire up the default "camera" application to take a picture, then fire up another message to the default "email" application sending the picture you just took as an attachment.)
Java libraries ARE better than anything on win32. They're equally verbose, but java has better tooling, and it wears toddler gloves, so it doesn't scratch itself and doesn't gouge your eyes out while you feed it.
Can you explain what you mean about 'cleanest architecture'? Having written a content provider, service, activity, and of course used intents in the past few weeks (and for months before), I would not really identify Android as "clean".
Compare it to any major API and tell me what you think. there are just about 4-5 platforms of the same calibre, and none come close. They thought it out well, and whatever other platform got you spoiled, I can tell you it's not win32, .net, mac, symbian, java2 anything, XNA, or anything on X. Enjoy the sub-single digit market share! ;-)
(you can't send a D-Bus message to fire up the default "camera" application to take a picture, then fire up another message to the default "email" application sending the picture you just took as an attachment.)
Sure you can. Or at least you could, if you defined a well-known bus name and interface for the camera app and email app. DBus supports auto-activation, so it'll take care of starting the apps that register themselves as providing those bus names. That's all more or less what you have to do with intents, even.
Two things that I find to be very nice/cool when developing for Android:
- As mentioned in the article, applications are bundles of components and have no specific entry point. To be more accurate, they have multiple entry points.
- The Intent system. Not only does it provide an easy and robust way to integrate deeply with other apps, it also provides a simple IPC mechanism. Intents can be used to publish and subscribe to events between applications and are incredibly simple to use.
- As mentioned in the article, applications are bundles of components and have no specific entry point. To be more accurate, they have multiple entry points.
Like Web sites.
The Intent system. Not only does it provide an easy and robust way to integrate deeply with other apps, it also provides a simple IPC mechanism. Intents can be used to publish and subscribe to events between applications and are incredibly simple to use.
Almost RESTy. Except for the callback part. But using an app model that is similar to Web service and Web app development is quite handy.
You know, when I first learned android development, its similarity to web development stuck me. Xml layouts (html), content resources (rest), the back button etc etc. I don't think its a coincidence or my web dev background
Here's a nice diagram of the framework / structure of the Android / Linux libraries [1]. It's interesting to compare it to Nokia's Maemo [2] and Intel's MeeGo [3], which are much closer to a desktop Linux. I haven't been able to find a diagram for WebOS but expect it to be fairly similar.
Very nice description of the Android architecture. I understand that all the applications have to be written in Java. But how did Firefox port its browser to Android? I doubt they have ported it from C++ to Java. At least from the article I do not understand what is necessary to write Android applications in non-Java languages. Can anybody please explain or give a link?
To expand on this - apps on Android do not need to be written in Java.
To use the full Android SDK, you can write in any language that produces Java .class files (eg, Java, Scala, etc).
However, if you are happy to work at a lower level you can use the NDK (= Native Developer Kit, linked in the parent), which lets you work in C with a fairly traditional Linux/C API. It also gives you access to OpenGL etc etc.
[The NDK] also gives you access to OpenGL etc etc.
The Java interfaces also give you this. Unfortunately, since OpenGL is mostly about making a ton of little function calls that build up a list of GL commands, it can be kinda slow since each call has to cross the JNI boundary. But it's performant enough for most things, and you can find your bottlenecks and drop down to native code where necessary.
For example in Android development we do not use java serialization but instead use a parcelable interface to store stuff and write to an android OS bundle to pass data between activities, etc as it is somewhat faster than java serialization.
There is some community work in that direction, i'd hope google would endorse it more:
http://www.openintents.org/en/intentstable