Android 3.0 Platform Preview and SDK Is Here 129
mikejuk writes "Google has released the Android 3.0 SDK, to allow developers time to create the apps that will run on the flood of tablet devices that should be availalble later in the year. The preview includes improved 2D and 3D graphics, new user interface controls, support for multicore processors, DRM and enterprise security features. It is complete with a 3.0 emulator that you can use to try applications on, but you can't add them to the app market just yet."
Better Link (Score:5, Informative)
Re: (Score:1)
From the link:
Activity fragments, for greater control of content and design flexibility
Starting with Android 3.0, developers can break the Activities of their applications into subcomponents called Fragments, then combine them in a variety of ways to create a richer, more interactive experience. For example, an application can use a set of Fragments to create a true multipane UI, with the user being able to interact with each pane independently. Fragments can be added, removed, replaced, and animated in
From iOS developer POV (Score:3)
The enhancements including new/improved GUI controls and built-in animation support will make re-hosting features from iOS easier. There seems to be some confusion (possibly only in my mind) or overlap between Views, Widgets, Fragments, and Drawables as well as between Canvas and Paint. The whole framework seems disorganized or lacking consistent application of patterns, but I admit that I may just not see the forest for the trees.
Re: (Score:2)
I develop for both, and kind of have to agree with you on the confusion. Hopefully they're closer to resolving this in 3.0.
Re: (Score:3)
Thanks. (Score:2)
Thanks. I have read much the same in the documentation. I suspect I just have to gain experience with the framework to get a feeling for which class to use when. For example, I don't see any reason why I can't draw in any old View rather than using a Widget, and Drawables don't seem to need Views at all; is that correct? I can have a Canvas and a Paint for a Drawable and see it on screen without a View?
I guess I'll just have to learn the intended roles of the classes. That is the nature of learning any fr
Re:Thanks. (Score:4, Interesting)
(Note: I'm the person who posted the first response too, but I wasn't logged in then so it came out as from anonymount).
If you want to do some custom drawing, then sure, you can start with a View and extend it to make your own Widget.
You can draw without a View, but only on bitmaps. Canvases from the screen come from Views. If you have a Drawable and you want it to appear on the screen, then the easiest way is to create any view you want and just make the background be that Drawable. This can all be done in XML in your layout resource file and it doesn't take a single line of Java code. It's very easy once you're used to it.
When I started out my biggest confusion was Activities, Apps, and Tasks. Those really mixed me up. But once I got used to them I found them very nice, it makes it easy to build modular apps that work together smoothly.
And for phones? (Score:3)
They're making a big deal about the new tablet features, but what does it add for phones? Will it even be released to phones? They don't even mention phones in their promo video. I hope they haven't forgotten about us...
Re: (Score:3)
3.0 is basically 2.3 for tablets. 3.0 is tablet optimized, where 2.3 is phone optimized.
Re: (Score:3)
Well it will be compatible with existing apps, and 2.3 already lay the groundwork for providing apps that work on both phones and tablets (by including ui elements for both via the *dpi and screen size groups).
Re:And for phones? (Score:4, Informative)
Honeycomb is for Tablets only. Ice cream will be the next phone OS.
Action Bar seems dangerously close to desktop... (Score:2)
In every application, users have access to contextual options, navigation, widgets, or other types of content in an Action Bar, displayed at the top of the screen.
Isn't this just a menu bar then? It seems like an odd idea for a tablet, basically it seems overly desktop like. Also unlike a desktop, the top of the screen may not be a fast place to house controls because on a touchscreen it's the furthest from where your hands naturally sit (at the bottom holding the device). In fact I'd say they got the Ac
Re: (Score:2)
I agree with you, however I do suspect that, with most tablets, one hand is used to hold the device and the other is used to operate it. It seems to me that most every interaction should be one hand based for tablets. Its not clear to me where the easiest to hit area is on a tablet.
Phones on the other hand are often operated with the thumb of the hand that is holding the device, so in that case the bottom of the screen is pretty clearly a good place for frequently used operations.
Still farther (Score:2)
I agree with you, however I do suspect that, with most tablets, one hand is used to hold the device and the other is used to operate it.
And I agree with that but even then, the top of the screen is still further from a resting hand than the bottom... when not in use the non-holding hand will not generally be resting in the middle of the screen or it would obscure content, it'll be sitting somewhere near the bottom or at the users's side. Even scrolling a list would end with your hand at the bottom of a scre
Re: (Score:2)
My guess is because of the keyboard location at the bottom, it would be better to keep a bar that's always on the screen at the top. This way it's always visible and you don't accidentally hit things on the bar with your finger or hand
Re: (Score:2)
The application menu bar then, would still seem to need to be at the bottom and hidden while the keyboard is up - because the System bar is even more important to leave up at all times, given that it's letting you really move around the system. So that's almost worse to have below a keyboard, or to hide...
Re: (Score:2)
In every application, users have access to contextual options, navigation, widgets, or other types of content in an Action Bar, displayed at the top of the screen.
Isn't this just a menu bar then? It seems like an odd idea for a tablet, basically it seems overly desktop like.
The 'Action Bar' isn't static, it's is customizable by the application so there is a standard place for all application controls.
Re: (Score:3)
The 'Action Bar' isn't static, it's is customizable by the application
In what way is that not a menu bar as on a desktop. It's the very definition of a menu bar...
Re: (Score:2)
The 'Action Bar' isn't static, it's is customizable by the application
In what way is that not a menu bar as on a desktop. It's the very definition of a menu bar...
It's meant to be context sensitive within the application, as opposed to a menu bar which is generally static per application. It is very menu-bar like but unlike iOS it gives the application a standard place to put controls when - and if - it needs to display them.
Re: (Score:2)
Re: (Score:2)
The danger (Score:2)
DANGER DANGER! ...actually that sounds a little sensationalist...what's 'dangerous' about a menu bar?
Ask Windows how they have fared on tablets for the last decade that stuck to the desktop metaphor,
The danger is to Android.
This is where Nokia missed the boat (Score:5, Interesting)
I used to be the biggest supporter of Nokia's Maemo/MeeGo OS. Except for the N770, I owned every single Maemo device they released (N800, N810, N900) and I loved them. They were true pocket computers running full, unlocked versions of Debian.
I still own the N900, which at the time it came out, was miles ahead of anything else available on the market in terms of features, customization, and hardware. It was amazing to have full desktop (not mobile) skype connectivity built into the phone. Just connect to wifi or 3G and make calls to any other Skype computer or N900. Full (not web) browsing enabled by default. Flash 9 preinstalled. But it is almost a year and a half later, and in the meantime Nokia has not released any new Maemo/MeeGo hardware, and only 1 major update to the N900 firmware. Even that update only fixed minor bugs and added the QT libraries.
In the meantime, Android went through at least 3 major revisions, and there are a multitude of devices to fit any need and budget. And now it matches pretty much all the features that made the N900 special. The worst part? Nokia hasn't even announced ANY MeeGo devices, let alone released them. They may still do it, but I think it's too little too late.
Re: (Score:1)
Honestly, the best thing Nokia could do would be to start putting out Android devices. I know they hate that idea, having poured so much into Qt, S60 and such but it's just the situation they are in. If they don't do it then they're going down in flames like all those other old businesses that couldn't keep up when the market went against them. The iPhone and Android markets are growing by leaps and bounds with thousands of new developers pouring in like crazy.
Nokia puts together superior hardware but th
Re: (Score:1)
Re: (Score:2)
Doesn't it bother you to have an US-centric view of the world?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Or something better in the aspect you weren't locked into only installing what Apple said was ok, as well as having the multitasking capabilities that the WinMobile phones had supported for a while
Re: (Score:2)
Honestly, the best thing Nokia could do would be to start putting out Android devices. I know they hate that idea, having poured so much into Qt, S60 and such but it's just the situation they are in. If they don't do it then they're going down in flames like all those other old businesses that couldn't keep up when the market went against them. The iPhone and Android markets are growing by leaps and bounds with thousands of new developers pouring in like crazy.
Nokia puts together superior hardware but they're not going to last unless they realize they have lost the OS/software war.
I completely forgot to mention Symbian, even though I used it on my E71. From I remember, it worked very well for devices without touchscreens, but it felt dated and some of the interface and navigation choices were just silly. One in particular was that sometimes closing an application would actually minimize it. A few hours later you'd wonder why the battery drained completely. Checking the task manager would show a whole bunch of applications happily churning in the background.
Nokia went on to invest a l
Re: (Score:2)
My understanding was that the majority of Symbian dev for ^4 was in modernising the platform through Qt.
In that sense, the UI should flow directly back to meego.
I guess nokia execs are wary of another deadend like hildon. In this way, they're letting their trolltech staff abstract away the underlying OS, while rewriting the core phone apps in Qt. When that switch is complete, any future n900 successor will feel more 'phoneish', in the meantime the linux layers will be crowdsourced, such as adopting wayland
Re: (Score:2)
Adding the Qt libraries to Maemo is pretty huge, though.
Re:This is where Nokia missed the boat (Score:5, Insightful)
But it is almost a year and a half later, and in the meantime Nokia has not released any new Maemo/MeeGo hardware, and only 1 major update to the N900 firmware. Even that update only fixed minor bugs and added the QT libraries.
I think they tried to get the community to shoulder too much responsibility for the OS - it's great that it's open source, but there isn't much open source that succeeds without corporate backing and for a predominantly consumer device that corporate backing has to come from the manufacturer. It would be nice to see meego flourish, and it certainly could given Nokia's market share, but consumers have been consistently disappointed by Nokia's high-end offerings, sure the N95 and N900 are great but the N93, N96 and N97 were all pretty awful IMO. Hopefully Intel and Nokia devote their full attention to Meego, if they don't then i see it ending up like Maemo.
Re:This is where Nokia missed the boat (Score:5, Informative)
Actually, it wasn't open-source enough. Many of the nasty bugs in the platform related to closed-source components. For example, I wanted to be able to simultaneously run a VoIP call and use the camera. But the camera "helpfully" wouldn't run during a call, because it needed the sound card to make the "click" noise. I tried to fix it, but was told that the camera app was closed source. There was an open-source camera library component...but only if I didn't want auto-focus! Another N900 killer was video-calling. Almost there, but pulse-audio was hogging 30% CPU doing (un-needed) sample-rate conversion - and we couldn't remove it.
Re: (Score:2)
I think Nokia got into this weird habit of just building a whole bunch of handsets and spraying them out randomly hoping that there'll be someone out there that the design appeals to. I think that strategy worked well for them back in the pre-smartphone days when physical design and feature sets was more important than now, where it's all about software, but I think it's totally biting them in the ass now - they're still churning out different units and just losing ground left right and centre because their
Re: (Score:2)
The problem with the N900 is not that there is a lack of open-source development but that too many critical pieces of the phone software were not open-sourced by Nokia.
MeeGo gets better, the only closed source components on that platform are:
Broadcomm Bluetooth chip firmware (closed source due to FCC regulations regarding bluetooth hardware)
userspace GPU drivers (closed source because PowerVR wont share its "valuable IP")
TI wireless chip firmware and certain user-space code related to it (closed source due
Re: (Score:2)
I don't know if the community actually has/had the opportunity to do all the required changes to the N900 even if they wanted to.
You're right, they couldn't do everything, but most of OS' bugs could potentially be fixed by the community.
Couldn't actually change the phone/modem software, because there's no source for it to edit. At least that's how I understood it, and which I found to be quite pathetic.
The OS is open source, but not all the drivers can be, same with Android, and with any proprietary devices on linux systems.
Re: (Score:2)
Not all of it. A fair number of bits were still closed source, and this irritated a lot of the user base.
MeeGo corrects pretty much all of that, as well as pushing to and pulling from upstream projects heavily. It is, to a great degree, what Maemo should have been.
It's too bad Google couldn't have pushed for that ages go, instead of reinventing the wheel.
Re: (Score:2)
Not all of it. A fair number of bits were still closed source, and this irritated a lot of the user base.
I can't really think of anything off the top of my head that was closed source apart from non-OS components (like the Media Player UI framework, device drivers, mapping framework, etc...).
Re: (Score:2)
MCE, which has long been a bone of contention. dsme was closed until they moved all the juicy bits out into MCE.
There's a listing of all the infrastructure bits that are closed:
http://wiki.maemo.org/Open_development/Why_the_closed_packages [maemo.org]
None of this is an issue in MeeGo aside from BME (annoyingly) and the 3D drivers.
Which are? (Score:2)
Name an NIT feature Android doesn't offer at this point.
Android is far better for development than J2ME, I know as I used to do a little J2ME development - enough to know it was a lot of work to support most devices. Android makes most things much simpler and has a much broader set of frameworks.
Hmm... (Score:1)
Re: (Score:3)
There are some ways to use other languages - the Mono project is pretty far along with getting C# working for Android, and you can write native C++ apps with the NDK (native development kit), but google strongly suggests not using the NDK just because you'd rather program in C++, as it is much easier to write bad programs in C++ than it is in Java (they suggest using the NDK when you're doing computationally intensive stuff like 3D games, or you have some game engine already written in C++).
For the most par
Re: (Score:2)
Not only that but google seem to have some bizarre ideas about C++. No exceptions, no STL, no RTTI. Apparently for reasons of "bloat", because the STL is ungodly huge compared to the java libraries supplied...
But that does make it much harder to write C++. No exceptions == no RAII.
Aparently they were thinking of changing this, however.
Re: (Score:3)
Don't be scared of learning Java on Android. It is the most pleasant experience I've ever had with Java. Basically, Google threw out all the onerous libraries and instead you're talking to the Android framework which is far simpler and easier to work with. A lot of the Java fear and loathing that you read about is based on the ridiculous stack of libraries and bloat that accompanies Java web stacks. Android has none of that.
Re:Hmm... (Score:4, Informative)
With a tablet android version, they might finally have gotten me into android app development. I'm not sure exactly how this works, would I have to learn and use java or could I just use any language?
If you have an existing C/C++ codebase it is possible to hive parts of it off as a library (.so) and load it into your java code via JNI, but for the most part your user interface has to be written in Java and compiled into Dalvik bytecode.
As of Android 2.3 it is apparently possible to write the entire program in C/C++, using a special option in the manifest file and an Android-specific entrypoint. 2.3 also adds event hooks to help with getting input, but AFAIK there is still no way to get at the user interface. You can, however, do OpenGL (probably OpenGL SE, but not sure) and roll your own, but that's generally most useful for games and things rather than, say, a text editor (which Android could use a few more of).
There are a few gotchas when using the Native Development Kit - it's got most of POSIX but not everything. pthreads is a little iffy in places and it doesn't support unicode properly (Android doesn't use Unicode, it does something else).
For example, passing a unicode string between C and C++ modules will cause a bus error, because unicode is 32 bits in C++, and 8 bits in C which caused a lot of head-scratching at first.
Re: (Score:2)
Re: (Score:2)
You'll really want to use the ADT plugin for Eclipse. I'm not a fan of Eclipse, but it is decent. The ADT provides you with just about everything you'll need and makes pushing your code to the emulator or a device easy.
Offtopic (Score:2)
Re: (Score:2)
No problem. Go get CyanogenMod 7.
Backwards Compatibility (Score:1)
This is the best bit from http://developer.android.com/sdk/android-3.0-highlights.html [android.com]:
"Compatibility with existing apps
Android 3.0 brings a new UI designed for tablets and other larger screen devices, but it also is fully compatible with applications developed for earlier versions of the platform, or for smaller screen sizes. Existing applications can seamlessly participate in the new holographic UI theme without code changes, by adding a single attribute in their manifest files. The platform emulates the
Re: (Score:2)
...Looks like this should run on existing platforms without too much tweaking by custom ROM builders/manufacturers.
Not sure why you say that. A new platform supports old apps (as has always been the case with Android), but that doesn't have anything to do with old hardware supporting the new platform.
Besides, most existing platforms are phones, and Honeycomb really isn't set up to run on a phone. I'm *sure* it would *run*, and I know enterprising hackers will do it for fun, but I can's imagine it being usable.
That said, there are some existing tablets, and they will seriously benefit from Honeycomb, so I'm sure devs wil
Cisco VPN Support? (Score:2)
Google, this is the enterprise feature [google.com] your users really want.
Joy. I see it still has no owner.
Death ray at Google! (Score:5, Funny)
From the video [youtube.com]
at 0:19
Attila Bodis 12/21/2010
CONFIDENTIAL: Death ray hardware rev 2.0
- Hi Mike, Please don't share; this is just a [cut off]
Available to the privileged few. (Score:4, Insightful)
Google did a bang up job kneecapping open source efforts in the mobile space, convincing the community to chase after an environment that discarded pretty much every existing open source tool in the name of NIH and withholds new versions from the community until their partners are done getting their releases out with it.
Then they sit back and have the nerve to tell us that Android is "open" while users are forced to jailbreak and deal with vendors [motorola.com] that try [samsung.com] to cripple devices so they can leverage later versions as a selling point for the next carrier contract.
I hope that MeeGo takes off with non-asshole hardware vendors, if not the we might as well right off the mobile computing space as being property of Microsoft, Apple, and Google.
Re:Available to the privileged few. (Score:5, Insightful)
Before Google "open" mobile platforms were a bad joke. I wanted them to succeed. But no hardware manufacturer or carrier took them seriously. Some companies like Motorola did build very bad phones based on Linux but they were very closed devices. Google comes along and gives you a platform that is completely open, gives it away for free. Do whatever the hell you want to do with it. Many vendors like Motorola take the bits and build phones around it. Most of these phones are locked. But you can hardly fault Google for it.
If somebody builds a device with Linux that you do not like, do you blame Linus Torvalds for it?
When I was in the market for a new phone a a month or so ago, I narrowed down my choices to:
iphone/iOS
Blackberry
Windows Phone 7
Android
Tell me, which one is the most open platform of them all? For me, I decided to go with Samsung Epic and have not regretted that decision for a minute. It is easy to root the phone and install whatever the hell I want on it, including my own damn Linux kernel.
I am thankful that Google is here. I have a crop of very capable devices running Linux to choose from. Without Google, these options would not be available to us. Give credit where credit is due.
Re: (Score:3)
Make no mistake, Android is better than the other, closed alternatives. I'm just annoyed that Google came out trumpeting how open they were, yet they expressed NIH syndrome to a ridiculous extent and reimplemented the wheel almost completely.
The end result is a nasty OS you have to root, that isn't compatible with anything else in the Linux world without a ton of hacking,
Re: (Score:2)
The end result is a nasty OS you have to root, that isn't compatible with anything else in the Linux world without a ton of hacking, code spread everywhere that doesn't go upstream (and except for the kernel, has no real upstream last I checked.)
Since when is compatibility with linux necessary for a platform to be 'open source friendly'? Android is VERY open, in particular i like the fact that i can run it on my N900.
As for upstream code, the idea is that developers make changes to those projects directly and they will be pulled into the Android project through the normal process.
importance of opensource (Score:2)
it's not required, but it helps a lot. It's one the major advantage of opensource over proprietary.
being compatible means a lot of code re-use.
code re-use means faster development and better security, because whatever (patch,new feature) done for one platform automatically benefits all the other using the same code. (Linus' law requires as much eyeballs as possible).
and having to *root* your very own phone you bought yourself and which is running opensource software ? That I find not exactly acceptable.
i en
Re: (Score:2)
it's not required, but it helps a lot. It's one the major advantage of opensource over proprietary. being compatible means a lot of code re-use.
Nothing stops code re-use as far as android goes. You can build native libraries from existing open source apps and utilise that functionality in Android applications.
and having to *root* your very own phone you bought yourself and which is running opensource software ? That I find not exactly acceptable.
The difficulty in getting root access is a part of the handset manufacturer modifications, the fact that it's not easy to put your own linux kernel on your tivo doesn't affect the linux kernel's conformity to the open source definition.
But there's no rooting/jailbreaking madness required to run custom code on it.
That's a disingenuous comment, im not sure whether you're doing that intentionally or you just have never use
Re: (Score:2)
it's not required, but it helps a lot. It's one the major advantage of opensource over proprietary. being compatible means a lot of code re-use.
Nothing stops code re-use as far as android goes.
That's "nothing besides the utter lock madness that handset manufacturer have thrown in". Or in other words : you're practically stopped on most handsets currently sold.
(Also, I don't know to which extent Google would be open to important architecture changes coming from outside. For most current facilities, they use the in-house developed software. Some 3rd party could start proposing modification to help the whole smartphone microcosm standardize on some common API + set of daemons. I don't easily see Goo
Re: (Score:2)
That's "nothing besides the utter lock madness that handset manufacturer have thrown in". Or in other words : you're practically stopped on most handsets currently sold.
So it's obviously NOT a problem with the android platform, just a problem with some handset manufacturers.
No, but *TiVo*'s linux-based system doesn't conform to what open-source was invented for, and the GPL has been updated accordingly to fight against this kind of abuses.
This is where the open source community is fragmented, some just want 'open source' in the case where the source code is available and any improvements/modifications must be freely available too. This is the view taken by Linus and applied to Linux (hence the strong opposition to GPLv3). And then there is the more hardcore FSF views that not only should the software be open source, but also for the devi
Re: (Score:2)
Then they sit back and have the nerve to tell us that Android is "open" while users are forced to jailbreak and deal with vendors [motorola.com] that try [samsung.com] to cripple devices so they can leverage later versions as a selling point for the next carrier contract.
Not quite forced. [blogspot.com] Agreed that this ability to gain root access should be mandatory across the platform, but at least Google is doing the right thing in this case, and publicly defending it too.
Re: (Score:2)
Google did a bang up job kneecapping open source efforts in the mobile space
How so? The Android platform is great for open source, im not sure which open source efforts you're referring to that Google have affected.
Then they sit back and have the nerve to tell us that Android is "open" while users are forced to jailbreak and deal with vendors [motorola.com] that try [samsung.com] to cripple devices so they can leverage later versions as a selling point for the next carrier contract.
Not sure about the significance of linking to vendors' landing pages but whatever... The fact that vendors lock down the devices isn't anything to do with Android, that's an issue with the vendor. And in the end if you want something that's almost completely open then there's always the N900, that will run just about any linux app you want, but i doubt the average user w
Re: (Score:2)
Google did a bang up job kneecapping open source efforts in the mobile space,
Which open source efforts were actually bearing fruit in the mobile space? The N900 has numerous closed components.
Then they sit back and have the nerve to tell us that Android is "open" while users are forced to jailbreak and deal with vendors that try to cripple devices
Uh no, they are forced to deal with vendors that try to cripple devices BY jailbreaking, that's one thing, not two things. No "and". And that's not Google's fault.
I hope that MeeGo takes off with non-asshole hardware vendors, if not the we might as well right off the mobile computing space as being property of Microsoft, Apple, and Google.
Maybe if anyone else had not basically abdicated their right to comment, then there might be another credible player. Nokia jerked off with Intel instead of producing the next revision of their OS and suffered for it.
moving to fast (Score:3, Insightful)
Re: (Score:2)
That's just the cost of innovation. Things are moving fast because there is a lot of fast moving that needs to be done to adapt to the changing market or just make things better. Deal with it. Once the the smartphone/portable_mobile_communications_computing_device space has stabilized, so will Android (and then you'll be bored with it and go chasing after the next shiny thing). Until then, don't be disturbed if "release early, release often" happens - that's how open source is done.
Re: (Score:2)
What we did is started treating each android handset as a different "platform". If our customers want mobile apps for iOS or Blackberry, we treat the OS as the platform, but with Android it was becoming extremely expensive to develop for compared to iOS and Blackberry.
Last year we lost money on android apps, we made money on iOS & Blackberry. This year so far it's looking like we'll at least break even on Android. But our customers are grumbling about the cost of "android" if they choose to support m
Re: (Score:2)
Those of us yearning for an openmoko/maemo solution long for the simplicity of upgrades being a simple apt-get dist-upgrade away.
Re: (Score:3)
That makes no sense.
Do you also complain that car manufacturers are advancing too fast with safer, cleaner and more efficient technology just because you can't buy a new car every year?
Should innovation stop and advance at the rate of your financial capability?
I think it's great that they're constantly improving Android, even if it does make me wish my hardware were more up to date. But there's a nice solution for that -- get a Nexus device (which is what I'll do when it's time to replace my current one).
Me
Software update failure (Score:2)
Meanwhile, don't worry -- your Android device won't become less useful over time.
Unless software designed for connecting to a specific server gets updates, the updated version is incompatible with your device, and the non-updated version is incompatible with changes to the server's protocol.
Re: (Score:2)
Has that happened to you?
Do you know of any instances of that happening?
e.g. an MMO that dropped Windows 9x support (Score:2)
Re: (Score:2)
I meant on Android
I too am extrapolating (Score:2)
Re: (Score:2)
First of all, that's not extrapolation.
Secondly, I was already suspecting you had no knowledge of what you were talking about. See http://en.wikipedia.org/wiki/Ultracrepidarianism [wikipedia.org]
You said that Android is advancing too fast, and that obsolescence is going to render older devices less useful.
I'm saying that up to now I haven't seen that happening, and there is no reason to believe it will happen faster on Android than on any other OS.
Emulator speed? (Score:2)
The preview includes improved 2D and 3D graphics [...] complete with a 3.0 emulator
Any word on the speed of this emulator? Running the 2.2 emulator 1.6GHz box, it takes several minutes to start, and then crawls so slowly that the screen is filled with "I can't tell whether the app is running slowly or is just dead" warnings -- If there haven't been improvements, I dread to think what the performance would be like for 3D graphics on a tablet-size screen...
Re: (Score:3, Insightful)
Re: (Score:3)
Speculative future; oh hell yes, but there may be reasons for getting rid of Java.
Re: (Score:2)
It might be even cheaper to Google to just buy Oracle.
Re: (Score:2)
Unless Google can whip out 166 billion from it's ass, there's a fat chance of that.
Re: (Score:2)
Re:Any chance we'll get rid of Java? (Score:4, Funny)
Google might just end up making a new VM system, similar to what Microsoft did with .NET.
This might have some advantages. Perhaps language independence could be put in, so Java source code files can be used, but they would compile to the new VM format, similar to how Microsoft's J# compiled to .NET. This way, someone can use Java syntax, C++ syntax, heck, even a version of BASIC and still get the same bytecode coming out. Add JIT, and there would be little performance overhead.
Oracle doesn't seem to be doing much with Java anyway, so if Google made a VM system from scratch, perhaps it might be better overall in the long haul, especially if it was designed from the ground up for security, learning the mistakes Sun/Oracle made.
Re:Any chance we'll get rid of Java? (Score:4, Informative)
Android has it's own VM system, and it's called Dalvik. It has language independence built in so Java source files can be used... they compile to DEX, the Dalvik bytecode format. It does JIT.
Please tell me that the above was (well-disguised) sarcasm.
Re: (Score:3)
Google might just end up making a new VM system, similar to what Microsoft did with .NET.
How would that be different though? MS still pay royalties to Oracle (initially to Sun) for patents used in the .Net system. If Google loses the case with Oracle over Java they will end up paying royalties just like MS does now.
Re: (Score:2)
Perhaps language independence could be put in,
I remember reading about Java years ago when it was new. One of the things they seemed proudest of was the VM, since it would allow many languages to be combined. Perhaps it was mis-designed and ended up begin Java specific, but I thought there were other languages now available.
Re: (Score:3)
Scala, Python, Ruby, Closure, Groovy and a few more.
Re: (Score:3)
Re: (Score:2)
Stability, architecture are also very important in phones. Apps written in a VM decrease the likelihood that they will destabilize the system such as by crashing unexpectedly, passing duff data around to other apps, accessing devices or files they have no permissions to access, consuming resources, hogging CPU or otherwise causing the phone to bug out. Using a VM also means
Why? (Score:1)
Can you give some reasons why Java is bad for Android?
Re: (Score:2)
It would be nice to be able to use a language that wasn't half boilerplate, as well.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I'll admit I am inclined towards C++ on these, but one has to admit given the variety of devices out there and potentially the variety of hardware that it could run on, having an abstraction layer like the VM does have it's benefits.
It has its benefits within the platform scope, but not when it comes to porting across platforms.
Re: (Score:2)
They call it Java, but technically it's not Java... it doesn't run on a JVM, and uses a custom development kit (not the JDK).
From: http://en.wikipedia.org/wiki/Dalvik_(software) [wikipedia.org]
"Dalvik does not align to Java SE nor Java ME Class Library profiles[8][9] (e.g., Java ME classes, AWT or Swing are not supported). Instead it uses its own library[10] built on a subset of the Apache Harmony Java implementation."
Re: (Score:2)
They call it Java, but technically it's not Java...
It's Java in the sense that the language used is Java, any Java programmer can code for Android because the language used is Java.
it doesn't run on a JVM
Using the android development kit the generated bytecode doesn't run on a JVM, but the code can by compiled to JVM bytecode because it's Java.
and uses a custom development kit (not the JDK).
It doesn't support the full JDK because it discards parts of the Java class library - that aren't really relevant or suitable for Android - and uses it's own.
Down to the VM it's all Java, it's just that for Android you generate Dalvik by
Re: (Score:1, Troll)
you can compile and run native code on Android,
Sure if you want code that still runs just as crappy as the regular stuff since it all still runs in the VM.
but that, of course, has the drawbacks of native code.
The drawback of having to be a competent programmer rather than a mouth-breathing Java code slinger?
Re: (Score:2)
Sure if you want code that still runs just as crappy as the regular stuff since it all still runs in the VM.
I'm not sure you understand what it means: it doesn't actually compile C/C++ to bytecode, it runs native code, which interfaces with a virtualized machine. So no, it doesn't run "just as crappy".
The drawback of having to be a competent programmer rather than a mouth-breathing Java code slinger?
Considering the Android platform, which runs on everything from ARM smartphones, TVs and tablets to x86 laptops, a JIT that can optimize to any specific architecture at runtime will probably outperform the native code objects, since no developer has thousands of dollars and enough time to optimize, test and debug fo
Re: (Score:2)
This is why you design for the lowest common denominator of the hardware you plan to support.
My whole point. The JIT can actually use each hardware's capabilities, by compiling to machine code specifically for it. And considering that with the multitude of platforms for Android, the lowest common denominator may be very basic.
Re: (Score:2)
Since Google is the new Microsoft, it would be available only on Windows. Android may be based on Linux but this is a mere technicality.