It has been a week since the Android software development stack for mobile devices has been released. For me as the founder of the db4o object database this has been one of the most exciting events in the lifetime of our product and our company.
Android will converge the fragmented mobile development platforms and it will make it possible to develop mobile location-based applications for a worldwide user base. This is the start of the mobile tornado. Here is why.
Landscape for a Tornado
Looking from a global perspective, the landscape of mobile operating systems is highly fragmented. The key players are phone manufacturers and carriers, all with own proprietary technology. Thinking globally even Symbian, Microsoft and Apple are small, with 60m, 20m and planned 10m deployed phones per year.
- The user experience on small screens is not good.
- Applications only work with a connection to the Internet.
- There is no solution for local storage and caching of structured data.
- Complex interactive applications are not possible because of transfer lag and transfer bandwidth.
- The local processing power of the devices is not used.
- Scalable server side applications are challenging to develop.
- Ajax application development is cumbersome, expensive and slow.
- There is no standard to reach out of the browser to access local device services like GPS, camera, contacts, call list, microphone or speaker.
Imagine you have an idea for a mobile killer application today, and you want to deploy it worldwide, which technology would you choose?
If you are not in a hurry to release, you should use Android. Here is what Android has to be a winner:
Google has the knowhow for the server infrastructure to provide location-based services.
The Android SDK already comes with two very useful packages: com.google.android.maps and android.location. You can create your own overlays on top of Google maps. LocationManager allows writing a 'ProximityAlert' to wake up the phone and make things happen if you come within radius of a location.
Money and Advertising Resources
Android is free as in free beer, under the Apache License. Anyone can take Android components and use them in their own technology. Why should companies spend years and millions to reinvent wheels if they can reuse Android components? If Google engineers stay on top of developments, proprietary technology branches will eventually converge back into Android.
With Linux, Java and the Eclipse IDE, Google has chosen the strongest existing open source ecosystems.
Google has started a 10 million dollar developer challenge to make sure applications will be available quickly.
The very first SDK shows that some of the smartest Java engineers had enough freedom and time to build the foundation for a skyscraper from scratch.
The Dalvik Java VM runs with a compressed improved bytecode format and it can run multiple applications side-by-side with low resource consumption and without applications being able to disturb eachother. Both features have been on Suns Java RFE list for years, Google simply just built them.
The use of the Apache Harmony class library is a smart move. This way Google is independant of Sun's path to fully open source Java. Harmony also is a lot faster in many aspects.
Eclipse integration is amazingly good from day 1 of the SDK. Anyone who is used to working with Eclipse can write his first running Android application within minutes.
The DDMS perspective in Eclipse to control and monitor the emulator is the best emulator management console I have seen. Other emulators with years of time to mature, like the ones from Microsoft or Symbian give you the impression that they run far away from you and you have to "connect" to them with multiple tools. With the DDMS Eclipse perspective you immediately feel on top of what is happening, you have control from within. The logging view is not just a sequential dump of text, but you can filter, for instance by process, by severity or by your own tags.
You can see all running activities, their heap usage and what the threads are doing. The system sums up the time taken for each thread for you, very nice.
The tutorial tells you why it is very important to control the efficiency of applications on devices: Efficiency means longer battery life, less battery weight and lower device cost.
Most of the application framework concepts look well done to me. Some of the key building blocks are:
- Activity - a screen of an application
- Intent - an action request
- Intent Receiver - application code to react to requests
- Services - shareable non-visual application components
"Content Providers" are intended to provide database-like functionality. Now that's very interesting for us, let's take a look at the API:
public abstract Cursor query(
insert(ContentURI uri, ContentValues values)
delete(ContentURI uri, String selection, String selectionArgs)
Sorry, this is not Java, it's not object-oriented, it's not even SQL.
We will soon do a side-by-side comparison of db4o to this interface to show how much more elegant object persistence should be. In case you don’t know db4o yet at all, here is a PDF version of the tutorial that comes with the db4o downloads.
The Android database API is missing key elements for location based services:
How do you set up a query for the "next car rental station from here" or "all my friends within 1 mile"? Clearly a standard for geospatial querying must be part of the database API.
My first Android application
So I moved on to write my first small Android app....
Without tool support, I dislike XML for writing GUI. I am sure a visual editor for Eclipse is already being worked on. The widget set for GUI development looks more like a spike to have something visible ready than anything near a releasable final. Apple has set the bar for user experience high with it's iPhone. Possibly Google is hoping for the community to create something nicer since "Rethinking of traditional user interfaces" is explicitely listed on the developer challenge website as one of the areas where they are hoping for developments.
As part of my first Android application I simply store an object to db4o and I am pleasantly surprised. db4o for JDK 1.1 simply works as it is.
So let's see what's going wrong when I use the db4o library for JDK 1.2. Wow, debugging the emulator with Eclipse works extremely good and fast. There are no time lags for deploying the app onto the emulator or for stepping through code like I am used to see them for other emulators. Niiiice!
Now what's wrong? Apparently java.nio.channels.FileLock#release() throws an IoException without a further message. Looks like I have found my first Android bug.
When I remove the offending #release() line from our code, our JDK 1.2 version also runs perfectly with my small test. Now let's change the field on my persistent object to private to see if AccessibleObject#setAccessible() allows access to private fields. Yeaaaaah! This very important test for us has passed, we have a fully functional uncrippled db4o running on this system and the Java dialect is rich enough to support everything we do.
Android, let's be friends!
Summing up, the basic building blocks look extremely strong, very stable and extremely well done to me. GUI and database support are not world class yet, but both can be improved by third parties like us.
So finally the time has come to write:
Mobile Killer Applications
If I would not work on db4o, I would immediately try to found a startup to create the location-based applications I have been dreaming of:
It is not necessary that we all commute with one person in one car. We can do better than spending a tenth of our awake life in traffic jams. We can also do better for protecting our environment.
A location based system could discover that two people always take the same route at the same time and it could organize to put them together in one car.
With a huge installed base, you wouldn't even need a car to go from A to Z. You could just enter your planned route into your mobile and the system would find somebody that goes your way, in real time, changing cars could be part of the service.
Similar like we have smog laws to protect our environment, it could be mandatory to have a ride sharing system installed in the car (just installed, you can't force people to use it). The overall benefits for the economy by saving oil and reducing emissions would be gigantic. Maybe even the government could pay for such a system?
If security is considered an issue:
Ebay has shown how ratings ("good driver, doesn't smoke, tells nice stories about hiking") make people feel well at ease interacting with unknown people. Women could drive with women.
Today there are some internet-based ride sharing systems but to overcome the critical mass, the system has to be real-time, automated and extremely easy to use. Imagine your phone telling you by voice:
"Stop at the next mall on the right, your neighbour Sue needs a ride to Santa Monica. She offers a cold coke for the ride and she would like to tell you what your kids did the last weekend when you were not at home."
You run across old friends every day, but you usually miss them by half a mile or by a couple of minutes. Wouldn't it be nice if you would notice and could go for a coffee together? A mobile location based system could arrange this for you.
Imagine you are in a foreign city and you don't have anyone to go to dinner with. How about asking your mobile who is available? Maybe the classmate you haven't seen for 10 years now lives in this city and owns the best bar in town. Go and visit him!
You have a planned date for a meeting with someone in New York in two weeks and you were going to fly there just for this meeting. Currently you are in Philadelphia for another meeting and the person from New York happens to be there at the same time. How about using the opportunity and saving yourself a full travelling day?
A standard mobile Operating System will make the above two applications very easy to write.
Not just for the United States but for the entire world !
Just for phones?
While Android seems to have been written with mobile phones in mind, there is no reason that an open and free software stack should not be used for other applications and devices.
I can see the Android stack convincing device manufacturers that Java allows writing faster applications than C, given the same development time.
The 10,000 feet summary from a business perspective was already obvious before Android was released:
Web 3.0 will be location based and Google will be a big player.
Now we know how they will do it.
Android is not a half-hearted press release to make Steve Ballmer angry.
It already is excellent engineering work, a superb foundation for the future.
Well done! Good work!
Congratulations to all the Google engineers that made this possible.
Android is going to change the world.
Related Content on this site
Android brings handsets to the next level - and open doors a mile wide for db4o
db4A - database for Android
Android Password Manager Demo Application
Ideas for the Android Developer Challenge