Android SDK is out - first impressions
After watching the video about the introduction of Android for developers, I'm convinced that the new phone will generally be as useful and user-friendly as e.g. the-also-newcomer iPhone.
Well, it came as no surprise to me, I'm just expecting a lot of
innovation from the new player in mobile space. I don't expect that the
new platform will offer as many features as traditional Symbian-powered
devices and I can even dare to say that it's not going to be as stable,
either ... yet. However, I'm pretty sure that they will catch up soon
and offer real alternatives for users, phone manufacturers, operators,
etc.
What has totally escaped my attention, though, was that the programming language for this platform would be Java.
Based on the fact that it's going to be a Linux-based OS I kind of
anticipated that the programming language would be C/C++. I don't know
the rationale behind this decision, but it will definitely give a boost
to the otherwise stagnating JME programming environment.
I wonder, though, how Google is planning to solve the infamous Java fragmantation problem for mobile phones. What is that? Well, even though Java is a very popular and platform-independent (aka portable) programming language, it's just the set of Java core services that is available on every mobile device. The presence of additional features, such as advanced mobile graphics, security, etc. depend on phone manufacturers' decision, whether it's worth adding them. Which makes Java mobile applications market very fragmanted (some features are available, some are not)
and development very frustrating. You know, I have heard an example
that a mobile Java game programmer had to make 100(!) variants of his
game "just" to be able to distribute it to as many phones as possible.
Another
thing about mobile Java development is that most mobile phones are
running on another operating system than Java. In fact, Java is not an
operating system at all, even though there have been attempts to make
Java-based mobile platforms, see e.g. SaveJe for more details. But Symbian OS is similar to Android platform in that they both have their native platform (Symbian OS and Linux, respectively) meaning that platform features are usually available in native programming language first and then some JNI layer added on the top and there you are, it's ready for Java programmers. So far so good. However, it introduces some latency
in the equation as it requires some time to write features in native
environment first and wrap it in the second round. Will Android suffer
from the same problem?
My regular readers already know that I
was involved in S60 Browser development and it was very challenging and
I really liked it. For that reason, I'm happy to see that Google chose WebKit for their mobile browser (S60 Browser
is also based on this rendering engine) and in the demonstration it
worked well. I was wondering which display method they would choose for
web pages:
- S60 approach that displays the web page in its entirety without scaling
- or iPhone approach that scales down the web page to so that it fits to display dimensions, though it's hardly readable, but lets the user zoom it very conveniently (e.g. by double-tapping on screen)
So these are my first impressions after spending half an hour with Android after midnight. I'm really keen to hear your comments - just as usual!
Originally from mobile-thoughts.blogspot.com.
Tote
| Attachment | Size |
|---|---|
| logo_android.gif | 2.78 KB |
Re: Android SDK is out - first impressions
Hi tote,
In light of the developer challenge put forward by Google, how do you see the possibility to truly innovate on this platform? I analysed the APIs offered in the current SDK release in detail and saw no capabilities that would not be offered by current J2ME/MIDP-based devices. What is Google looking for with this challenge that could not be already done on the millions of J2ME phones out there?
Cheers,
Pawel
Re: Android SDK is out - first impressions
I'm shocked, check this out: Dalvik: how Google routed around Sun's IP-based licensing restrictions on Java ME. It basically says that Android phones will NOT be JME-powered, but you can write JSE programs to them. With Android, Google has introduced their own VM, Dalvik, which eventually does not make use of Java bytecode, but their own Dalvik format. It's all to get rid of Sun being involved in licensing.
It's another question how good or bad will it be to the community. It means a new variant on the horizon, a VM incapable of running so-far-standard Java bytecode, thus your midlets will have to be re-compiled. I can see why Google is happy to have their own solution to this problem, but I can also see why developers would be unhappy due to that they'll have to take just another Java variant into consideration. Even if their pockets will be full with (Google's) money.
Cheers,
Tote
Re: Android SDK is out - first impressions
The most interesting aspect of this I found was the SDK page entitled "Security and Permissions in Android".
The whole security architecture is going to be fun to deal with.
Overall it looks like what j2me should have been were it not run by a whole group of self interested observers.
The interesting thing is whether or not google will persuade phone manufacturers to intevest in engineering their OS's to support Android underneath.
The major limitation is that if its not in the SDK its going to be hard if not impposible to add due to the sandbox effect.
Of course as Tote pointed out fragmentation is going to be a problem as each manufacturer tries to differentiant themselves from the competition by adding in new classes or adding new methods to classes.
Re: Android SDK is out - first impressions
Well, this is another way for Google to make money. Google *is* already making money on desktop so why not to put the same things in to mobile world? Dunno... Anyway someone talked about fragmentation: isn't Symbian fragmented with tons of SDKs already in Forum Nokia alone? Different editions and feature packs have done this already.