The Guts of Android
lwn.net
lwn.net
There is some community work in that direction, i'd hope google would endorse it more:
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.
--
[1] Remember Me? MagicProc(HWND hwnd,WORD msg,WPARAM wParam, LPARAM lParam);
By the way, from your statements you can at most conclude that the Java libraries are better than Win32.
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.
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.
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.
[1] http://www.forum.nokia.com/piazza/wiki/images/e/ef/Android-a... (strange the 1st Google hit for this was on Nokia)
[2] http://wiki.maemo.org/images/9/90/MaemoArchitecture.png
[3] http://www.99bits.com/wp-content/uploads/2010/09/meego-archi...
Anybody know what that means? Licensing conflict, perhaps?
In late 2007, BusyBox also came to prominence for actively prosecuting violations of the terms of its license (the GPL) in US courts.
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 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.