Slashdot Mirror
Android Ice Cream Sandwich SDK Released
Hitting the front page for the first time, ttong writes "The highly anticipated Android 4.0 (codenamed Ice Cream Sandwich) has been released and finally brings the features of 3.x Honeycomb to smaller devices. Some of the highlights include: a revamped UI, a much faster browser, face unlock, a vastly improved camera app, improved task switching, streaming voice recognition, Wi-Fi Direct, and Bluetooth Health Device Profile. ... The API level is 14, download the new SDK here."
calc noted that the source code has yet to be released (Google account required) except to legally required GPL components. Supposedly progress is being made toward getting AOSP back online: "We're working on it and we're making good progress, but we're not ready to announce any additional details yet." How many of the new features will remain proprietary and tied to Google services remains to be seen.
is the miserable battery life. My droid Incredible goes barely a day and a half with little to no good smartphone usage. If I use the internet or video at all the battery is gone in less than a day. I even have all the default auto-running programs deleted. I will probably go back to iphone after this just because of its incredible battery life. I had the 3g and it was amazing.
I hear that complaint a lot, and even made it myself when I had an Evo4G. However, I found that if you disable all the features that are not present in the iPhone, like 4G, live wallpaper, widgets, flash, live weather, etc, I think you'll find the battery life to be comparable to what you had on your iPhone. My Evo3D is as good or better than my buddy's iPhone4 by simply turning off live wallpaper and 4G.
There is no "I disagree" mod for a reason. Flamebait, Troll, and Overrated are not substitutes.
They do use version numbers; Gingerbread = Android 2.x, Honeycomb = Android 3.x and Ice Cream Sandwich = 4.x This way satisfy the enthusiasts craving for a sweet desert and the professional's need to not sound like an enthusiast.
Gingerbread = 2.3 more precisely. 2.1 is Eclair and 2.2 is Froyo.
I just hope that my phone gets updated to this. I'm still stuck with Froyo and my phone just came out in July. That's one of the most frustrating aspects of Android phones - the manufacturers do not upgrade the phones. With the quick turnover in phone OSes, it's inexcusable for manufacturers to stick with old OSes. I can understand if the phone hardware cannot handle the upgrade but I know that many phone manufacturers simply do not want to support their devices. Instead, to get updates we have to turn to CyanogenMod. This is one reason iPhones are so popular (yes, I know Android is overtaking iOS but the iPhone is the most popular smartphone model), at least Apple does a good job of updating iOS and getting it to as many iPhones as possible.
All this being said, Android 4.0 looks great.
The API is horrible - standard Java classes replaced by poorly designed alternatives for no apparent reason
So your rationale is that the API is horrible because they added in some bespoke classes? In the platform developer's opinion, those classes are better suited to mobile devices. But, guess what, you don't even have to use them. What Java classes did they "replace" that aren't still there? I haven't found anything in particular that has been replaced, they just gave you the option of using the newer stuff. The analagous Java class is still there. And how are the new classes poorly designed?
those horrible XML files as the preferred way of designing a UI
Er, if you don't want to use XML files to do your UI, you don't have to. You can use pure Java all day long. Besides, the XML files are exploded into Java on the device anyway. You use the XML to quickly design the static elements of your UI and use Java code to do the interactive stuff. What is there to bitch about?
When I got to the bit in the tutorials about apps being forcibly restarted when the orientation changes I cried with laughter.
This is not even true. The activity does not "restart", the ui reinitializes to use the layout prescribed for that particular orientation. You don't want a long list of single column buttons in landscape, you want them more logically laid out so the UI for the activity restarts. It is trivially easy to keep all of the ui data like form contents, etc. and reinsert it into the layout when the screen rotates and it happens instantly so the user isn't even remotely aware. Poor app developers that don't take the very small amount of time to make this happen is what gives it a bad rep.
It feels a proof of concept rather than a polished development platform
Nothing you've said supports this conclusion. The points you make are what I would expect from someone that is looking for a reason to hate before he's even given the platform a chance.
The soylentnews experiment has been a dismal failure.
Not quite. Orientation changes do, in fact, terminate and restart activities. It works fine if you do literally all network activity with background services and strictly observe canonical model-view-controller design, but kills newbie Android developers left, right, and diagonally, and is the single biggest reason why so many non-MVC Android apps forcibly lock views to a single orientation (the only way to prevent it from happening).
You can tell the scheme was originally concocted based on the G1's hardware -- flip out the keyboard, the screen rotates. A specific, unambiguously deliberate act. The problem is, they extended rotation to the accelerometers, and all hell broke loose because you started to get spurious, accidental rotations caused by users holding the phone in their hand and changing its orientation when something else captured their attention for a moment (like the cashier at a store or fast food restaurant, or putting the phone down while driving because the light turned green). The teardown behavior is sensible in a pure MVC design, and is tolerable when orientation changes are deliberate and rare, but breaks down and becomes totally dysfunctional when you add the current accelerometer-driven orientation dynamics.
Don't get me wrong -- I think accelerometers are a great way to determine orientation. I just wish there were a big, easy to deliberately press (and hard to accidentally press) hardkey that meant, "take an accelerometer reading now, and adjust the orientation if appropriate. Then stay that way until I press the button again". Right now, with tablets like the Xoom, you're forced to either lock the orientation (and go through 20 seconds of annoyance to switch between portrait and landscape), or deal with endless spurious orientation changes that seem to be far easier to trigger than to undo (ie, a slight tilt in the wrong direction changes the screen, but when you try to get it to go BACK, the new orientation is "sticky" for a few seconds. Pure frustration.) In the Xoom's case, I'd overload the power button so that a rapid double-press (that would normally turn off the screen, then turn it back on with the screen lock annoyingly activated even though the screen was only off for ~300 milliseconds) would trigger an accelerometer reading and orientation change.
The other hugely stupid thing Android did that causes endless misery, and will probably cause misery forever, was to implement a SUBSET of BouncyCastle without changing the namespace, which totally fucks up any program that needs to use a part of BouncyCastle that's not part of the core API. You can't just drop the BouncyCastle jarfile into your project, because then you get namespace collisions and Bad Things Happen(tm). So, you have to basically take BouncyCastle, then rebuild it with a different package name, then change every reference to use your new namespace instead of the original.