On Apr 14, 6:04 pm, Fabrizio Giudici <[email protected]> wrote: > But it's not a black - white game. For instance, not everibody needs > to use that fresh and cool feature just rolled out - otherwise we > should infer that most of those HTC Android equipments, that are still > pre-2.0, are useless.
On Android, about 70% of all devices still use 1.5/1.6, so as an Android developer you may want to target 1.5 to have a wide audience (http://www.wired.com/gadgetlab/2010/04/android-fragmentation-declines- but-older-versions-still-rule). I don't know how much new APIs Android provides, but iPhone OS 3.0, 3.1 and 4.0 have brought / will bring a lot of things that are of use for pretty much every application (multitasking, in-app email, game center, map API etc.). I'm working on an iPhone app myself and see how few lines of code it is to use in-app email (the same UI as sending email from the Apple mail app), but there are still apps that I use that break out to the mail app instead. > Then, let's recall that the coding problem is twofold: language AND > runtime. The fact that we must respect the UI or use that fresh and > cool feature is 99% related to the runtime, not to the language. I > mean, from this respect at least Google offers the Java language and a > subset of the runtime at the core, making me save money and time. And > they could do even better (but deliberately chose not do to that) if > they provided API support, at least for things not related to the UI, > such as Bluetooth, Location, in a compatible form as the existing APIs > (JSR-82 etc). I could not object to the fact that I'm forced to > rewrite the UI part of an application, for the L&F fidelity. The same > holds for the idea that I could write the same stuff in Java and > having it translated to ObjC, etc... I don't really understand your argument here - mobile runtimes are a lot different from desktop runtimes since they offer stuff that doesn't exist on the desktop or isn't exposed there (location, accelerometer, map, iTunes library playback). But for efficiency purposed, you try to build your mobile runtime on something else so that you don't start from scratch or maintain multiple runtimes (iPhone OS based on Mac OS X, Android based on Linux and Java), so developers from those environments are already familiar with. And please, no more JCP for mobiles. If you're Google, do you really want to wait three years until you get a new rev of a JCP API just so you support some new hardware or fix bugs? -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
