To give the quick answer immediately, I don't thinks so.
I was dealing the last weeks a little bit with Android, and I must say, that I like the concept a lot. There are several differences to existing systems that might be noteworthy:
Liberté
Android is published under a liberal Apache license and defines the complete stack starting from the Linux kernel up to the application API. This whole stack is Open Source, i.e. handset developers are free to implement this without license fees. Let's hope now, that the members in the Open Handset Alliance see the opportunity as well.
The concept of Android is in my opinion directly targetting the typical mobile-phone concept, where network carriers pretty much define the functionality of the handset. This was and is IT in cuffs and was a reason why hardly useful mobile applications and user interfaces existed. The new systems (not only Android, there are others like Open Moko) could change the game. A mass of developers could finally discover the mobile platform and develop innovative applications.
I personally think that this openness is also a chance for usage in developing countries, where mobile phone penetration typically is much higher than PC usage. Cheap, and locally produced Android handsets could provide richer access to information resources compared to conventional mobile handsets.
The concept of Android is in my opinion directly targetting the typical mobile-phone concept, where network carriers pretty much define the functionality of the handset. This was and is IT in cuffs and was a reason why hardly useful mobile applications and user interfaces existed. The new systems (not only Android, there are others like Open Moko) could change the game. A mass of developers could finally discover the mobile platform and develop innovative applications.
I personally think that this openness is also a chance for usage in developing countries, where mobile phone penetration typically is much higher than PC usage. Cheap, and locally produced Android handsets could provide richer access to information resources compared to conventional mobile handsets.
Egalité
First, opposed to e.g. the iPhone, all Android "end-user" applications are equal. I think this is a very important conceptual difference to other platforms. That means, that even "core" applications like the addressbook or the phone-manager could be exchanged. This is quite a different concept compared to typical Java ME applications that run "as Java" applications started from a special folder in the mobile. A home-brewn Android application runs on the same level as default-applications provided by the mobile phone.
Interestingly this seems to be a concept feared by Apple (iPhone) and other companies, however, IT history showed, that locked up systems were hardly capable to bring innovative solutions. Let's wait and see if this concept will work or not, I am personally optimistic.
Interestingly this seems to be a concept feared by Apple (iPhone) and other companies, however, IT history showed, that locked up systems were hardly capable to bring innovative solutions. Let's wait and see if this concept will work or not, I am personally optimistic.
Fraternité
Communication (between applications) is a core part of the concept. I like particularly three aspects:
- Activities and Intents: An Activity is e.g. a screen that interacts with the user. The interaction is actually expressed by an intent. Now the nice thing is, that these intents can use late-binding over applications. That means: If a user clicks e.g. on a telephone number in the address book the intent "dial phone" is initiated, however, which application "processes" this intent can be decided in the runtime configuration.
- Rich persistence and communication APIs including a relational database, a key/property store, network access, XMPP (Jabber) libraries and so on.
- Content Providers define interaction and data access between applications.
Applications have to be written in Java, which is good news for the large Java community, however there is one issue to be be taken into consideration: The Android platform uses the so called Dalvik virtual machine, which is a Google internal development and has the drawback (?) that it is not binary compatible with the other Java VMs.
This means specifically that it is not possible to use .class or jar libaries directly on Android. This does not work by two reasons (1) as mentioned, Dalvik cannot use .class files, these have to be converted to .dex files e.g. with the dx tool from Google. (2) The Dalvik VM implements only a subset of the Java 2 SE library.
This means specifically that it is not possible to use .class or jar libaries directly on Android. This does not work by two reasons (1) as mentioned, Dalvik cannot use .class files, these have to be converted to .dex files e.g. with the dx tool from Google. (2) The Dalvik VM implements only a subset of the Java 2 SE library.
However, this problem should not be too significant. One month after the Android launch first projects published special Android packages, e.g. the excellent db4o object oriented database, which could become quite popular on Android.
From the developers point of view, Google provides a quite good documentation, command line tools and Eclipse plugins including Hardware emulators for different types of mobile phones. I also suggest to check the Android Developer challenge!
From the developers point of view, Google provides a quite good documentation, command line tools and Eclipse plugins including Hardware emulators for different types of mobile phones. I also suggest to check the Android Developer challenge!
No comments:
Post a Comment