Good news, but there is very few details about the platform itself.
I see 3 options for Android on the table:
Option 1) it comes with a native open source JVM. This is the Blackberry approach. It will enable running existing J2ME applications (thousands exist today) and Google will provide more powerfull APIs for their integrationg with their application suite, like GMail, Google Maps and YouTube. GPS APIs would be great too. They will also provide a custom Java based UI toolkit to make applications consistent with the phone UI. IDEs will be Netbeans and Eclipse. The low level access to the underlying Linux OS would be hidden from the developer.
Option 2) The JVM is not part of Android, but available as a addon. This is Palm approach (IBM provides the JVM for Treos). In this case, Esmertec will likely provide a non open source JVM to run J2ME apps to each phone vendor. This is OK but not very good, as the JVM may or may not be present and they will be no integration with existing app or UI toolkit. Developer will have to code all apps running on Android with C or C++ APIs using Eclipse. the SDK will be very similar to the now defund Palm Foleo or the Nokia Linux Maemo platform.
Option 3) No JVM, but a powerfull mobile Web Browser ala Safari, based on the Safari WebKit, which is open source, to run local mobile AJAX apps written in Javascript and DHTML. Google would provide in the browser custom APIs as Javascript libraries to integrate with the platform and custon Javacript UI compomenents. This will be similar to the current iPhone development and also like the Google widget developement. This is ambitious and risky and will not work for mutimedia or game apps. This is not GREAT, but this is OK, specially if they can integrate some version of Google Gears, enabling mobile AJAX apps to run offline.
OR ... all 3 options ? Anyway we will know in 1 week time.
Oh gawd, please let it be C++ as the default development environment. I'm so tired of sluggish interfaces that look like @$$. People may write lots of apps for the other Java devices out there, but there's a reason nobody likes to use them. Just build a nice framework in C++ and your product will automatically have a major advantage over all the other phones out there. Development may be slightly more time consuming (I wouldn't say more difficult), but you'll end up with a program you don't dread opening.
Quite apart from the fact that the ill-chosen word "ovi" (which, unfortunately, sounds like a plural of 'ovum') might sound a bit creepy to 50% of the world's population, where/when have you heard "positive things about Nokia's OVI platform"?
Just curious.
A few investment/stock picking blogs. Shares of Nokia are right on Apple's heels in terms of performance (no doubt benefiting from such a strong Euro) but interesting none the less. The word OVI means "door" in Finnish(?) Expectations are building for this platform. My background is not technical but I scan several websites for ideas and feedback and I really appreciate reading everyone's comments especially the technical ones.
I would go for the "infrastructure", which is probably why they didn't show it off. It sounds like the handset makers can make their own UI as they like, but it still means that it has a common back-end. I think much in the same way that a css file change can completely change the look & arrangement, but not the content, of a web site. Having that infrastructure already there frees up a lot of time to refine the front end.
I think that's probably right, although I think Google will also release a reference UI (which will be customized beyond recognition by the handset partners).
Still, "common back-end", while very useful from a services perspective, doesn't really seem poised to set the cell phone market on fire. As has been pointed out elsewhere, services aren't the problem so much as the tinkering by carriers (at least domestically).
I mean, are Nokia phones really hurting for apps or access to services? If a reference platform makes it easier to develop across multiple phones, that's great, but it doesn't appear that the lack of same has been much of a hindrance, does it?
Comments
Meaning: one OS from Apple with limited third party applications and one OS from Google with unlimited third party applications?
Apple did say they were going to open up the iPhone to the world somewhere around spring 2008. Which is pretty close to Google's Android.
Good news, but there is very few details about the platform itself.
I see 3 options for Android on the table:
Option 1) it comes with a native open source JVM. This is the Blackberry approach. It will enable running existing J2ME applications (thousands exist today) and Google will provide more powerfull APIs for their integrationg with their application suite, like GMail, Google Maps and YouTube. GPS APIs would be great too. They will also provide a custom Java based UI toolkit to make applications consistent with the phone UI. IDEs will be Netbeans and Eclipse. The low level access to the underlying Linux OS would be hidden from the developer.
Option 2) The JVM is not part of Android, but available as a addon. This is Palm approach (IBM provides the JVM for Treos). In this case, Esmertec will likely provide a non open source JVM to run J2ME apps to each phone vendor. This is OK but not very good, as the JVM may or may not be present and they will be no integration with existing app or UI toolkit. Developer will have to code all apps running on Android with C or C++ APIs using Eclipse. the SDK will be very similar to the now defund Palm Foleo or the Nokia Linux Maemo platform.
Option 3) No JVM, but a powerfull mobile Web Browser ala Safari, based on the Safari WebKit, which is open source, to run local mobile AJAX apps written in Javascript and DHTML. Google would provide in the browser custom APIs as Javascript libraries to integrate with the platform and custon Javacript UI compomenents. This will be similar to the current iPhone development and also like the Google widget developement. This is ambitious and risky and will not work for mutimedia or game apps. This is not GREAT, but this is OK, specially if they can integrate some version of Google Gears, enabling mobile AJAX apps to run offline.
OR ... all 3 options ? Anyway we will know in 1 week time.
http://www.unyverse.com
Oh gawd, please let it be C++ as the default development environment. I'm so tired of sluggish interfaces that look like @$$. People may write lots of apps for the other Java devices out there, but there's a reason nobody likes to use them. Just build a nice framework in C++ and your product will automatically have a major advantage over all the other phones out there. Development may be slightly more time consuming (I wouldn't say more difficult), but you'll end up with a program you don't dread opening.
Quite apart from the fact that the ill-chosen word "ovi" (which, unfortunately, sounds like a plural of 'ovum') might sound a bit creepy to 50% of the world's population, where/when have you heard "positive things about Nokia's OVI platform"?
Just curious.
A few investment/stock picking blogs. Shares of Nokia are right on Apple's heels in terms of performance (no doubt benefiting from such a strong Euro) but interesting none the less. The word OVI means "door" in Finnish(?) Expectations are building for this platform. My background is not technical but I scan several websites for ideas and feedback and I really appreciate reading everyone's comments especially the technical ones.
I would go for the "infrastructure", which is probably why they didn't show it off. It sounds like the handset makers can make their own UI as they like, but it still means that it has a common back-end. I think much in the same way that a css file change can completely change the look & arrangement, but not the content, of a web site. Having that infrastructure already there frees up a lot of time to refine the front end.
I think that's probably right, although I think Google will also release a reference UI (which will be customized beyond recognition by the handset partners).
Still, "common back-end", while very useful from a services perspective, doesn't really seem poised to set the cell phone market on fire. As has been pointed out elsewhere, services aren't the problem so much as the tinkering by carriers (at least domestically).
I mean, are Nokia phones really hurting for apps or access to services? If a reference platform makes it easier to develop across multiple phones, that's great, but it doesn't appear that the lack of same has been much of a hindrance, does it?