Android Ice Cream Sandwich SDK Released 309
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.
Comment removed (Score:2, Insightful)
Seriously? (Score:3, Insightful)
face unlock
Does that mean if someone steals my phone and my wallet, all they have to do is hold the drivers license up to the cam to unlock? Sounds like a very bad idea.
Re:Seriously? (Score:1, Insightful)
face unlock
Does that mean if someone steals my phone and my wallet, all they have to do is hold the drivers license up to the cam to unlock? Sounds like a very bad idea.
Then, perhaps, you might not want to use the facial recognition feature, and instead go with one of the other lockscreens. It's not a bad idea, just one you won't use.
Updates to phones (Score:5, Insightful)
All this being said, Android 4.0 looks great.
Re:Andriod app development (Score:5, Insightful)
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.
Re:Andriod app development (Score:4, Insightful)
I looked at the implementations of the alternative to many of the Collections classes in particular, and they had nothing in them that suggested they were "better suited to mobile devices". And I'm not going to dig through the API docs, but they were certainly no improvement on the equivalent Java classes, and I recall them often being less intuitive.
The use the Java classes. Why complain about choice?
I know you can construct your UI directly in code, but virtually all the documentation I have seen assumes you'd never want to do that and omits coverage of it. Hence why I said the XML format was presented as "the preferred way".
Yes, because the XML way is going to be easier and more intuitive for many people. For the hardcore olde thymers such as yourself, you can use Java. Again, the choice is yours.
The process is exactly the same as when the app is explicitly shutdown by the user or the app developers code, so it is true. That's why you have to store the current state of the application, as you allude to in your comment.
No, it most assuredly is not. Android apps are not like desktop apps. The lifecycle is totally different and more suited to an "on-the-go"/everything runs fullscreen device. onCreate initializes the logic of your activity and it is called once when that activity is first run. When you shut down an app explicitely, it calls onCreate when you go back to it. When you rotate the screen, it calls onPause and onResume so that your portrait layout (for example) isn't just jumbled together and resized for landscape. You can have a completely different layout for the two modes. Or you can just use onPause and onResume to fill form data back in and to hell with having multiple layouts. When the screen is rotated, everything done in onCreate is maintained that includes all variables, etc. You save form data with onPause and refill it with onResume. It's trivially easy and in the context of the system makes sense. I'm not a teacher, I'm a programmer so my explanation likely sucks. My suggestion is you read this [android.com].
Well, if you feel it's more than just adequate then I dread to think what your own code looks like.
Because I disagree with you and think Android is an elegant system to develop for, that means my code sucks? I'm sorry, who are you and what are your credentials again that I should just slavishly follow what you say? When you can give me compelling reasons for why Android supposedly sucks (and you haven't), I'll believe it. So far, you've just given biased opinions based on your impressions of a platform that you don't code for and obviously don't have any real intentions of even giving a fair chance. With that attitude of inflexibility, I'd really hate to see your code.
Re:Seriously? (Score:4, Insightful)
Ahhh, yes.... biometrics: the weak, insecure password you can't change.
Re:Andriod app development (Score:5, Insightful)
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.
Re:Updates to phones (Score:5, Insightful)
It's starting to look like one of Android's greatest weaknesses is that people flame manufacturers, but don't mention their name yet do mention Android's name in spite of the fact that Android had nothing to do with the problem they had.
Dude: name names. Someone sold you an un-upgradable phone and you won't say who? Thanks, now they will be free to pull the same bullshit on me.
If we were talking about desktop computers instead of phones, you wouldn't be talking shit about the OS not being upgradable; you'd be warning the world against the desktop computer manufacturer and their user-hostile BIOS.