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 worked on a project with another Doctor Who fan and we were perfectly fine with upgrading Jon Pertwee to Tom Baker.
I'm glad I got laid off before I had to go from Sylvester McCoy to Paul McGann. Although if we made it to version 10, we had the idea of naming 10.5 "Handy."
Non impediti ratione cogitationus.
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.
Actually its not random. The Android releases are being done in alphabetical order.
2.2 Froyo
2.3 Gingerbread
3.0 Honeycomb
4.0 Ice cream sandwich
get it?
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.
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.
The soylentnews experiment has been a dismal failure.
Ahhh, yes.... biometrics: the weak, insecure password you can't change.
Use a body part that isn't visible in your ID photo.
I'm the real Vorokrytin P. Winterbuttocks.
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.
I do Android development, and I had a look at the SDK and emulator when it was released last night. I created an emulator and was testing my applications out on it.
The first thing I noticed is that there are more help screens. I believe they disappear after first use, but they tell users how to navigate around the phone. Or tablet as it may be - that's probably the biggest thing about ICS, it integrates Gingerbread (smartphones) and Honeycomb (tablets) into one OS. I've been getting the hang of Android layout, and it is not so hard once you get used to it, you just stick with the things they recommend - density-independent pixels, scale-independent pixels, objects sized by width and/or height by fill-parent (fill layout container object is in) or wrap-object (make object only as large as it need be), objects or layout containers being assigned by weight. One trick I learned - I start design with the smallest device - WVGA - a small device with a low number of dots per inch. I do a portrait (device held with more height than width), and if I have time a landscape (device held with more width than height) view. Sometimes that is enough, and those two layouts work from the smallest to largest devices. Usually it requires a little tweaking, especially Activity classes that make use of buttons. You take the layouts you made and increase text size, increase the distance between objects and other objects, or objects and the edge of the screen. Some people rethink the design, they use Fragments so that where something that would be done on a small screen with ten screen changes with ten different Activity views, is now done with five screen changes with the same ten different Activity views - you just use Fragments to put two or so Activity views per screen. The ICS smartphone/tablet integration will help in that department, although you can do it to some extent already. In fact Fragments were introduced in Honeycomb (the old tablet Android version, before this ICS tablet/smartphone integration), so some of this is just bringing Honeycomb advances back to the smartphone. Another example of this is the Actionbar - over time the Android designers realized it would help UI consistency, ease of programming etc. if they put a bar on top that let people do things (open an email, go to the next page, whatever). So Actionbar was in Honeycomb, now it is in ICS as well. I should mention there is a compatibility package which allows apps to use many (but not all) of these new features on older phones like Gingerbread, Froyo, Eclair etc.
The next thing I noticed when looking at my apps in the ICS emulator is the new Roboto font. It is said to be able to be a good font for everything from a small, low density to a large screen with a high density. Some of my apps use the Android non-default fonts, and the ones I looked at looked most the same, although there may have been small tweaks I did not notice. And Android lets you use your own fonts.
One of my applications runs in the background, doing a database search while updating a progress bar - and while all of this is happening, an ad is often being loaded as well via the web. It seems to be stalling on something in the ICS emulator, I will do some debugging later to see where it is getting stuck. It may be one of those cases where I was doing something wrong but Android allowed it, and they increased the strictness of things. With ICS's use of Fragments, I can probably just load one ad Fragment when my app starts and put that on every screen anyhow.
Regarding source code, I'm sure it will be released. It will be a month or so before you can buy a Samsung Galaxy Nexus anyhow. The sooner the release the better for me, but Android's open nature beats Windows 8 Mango and iOS any day. I can sit at my Linux box, use open source tools to develop everything, and then just push it out to Android Market (or some other market - Android does not lock phones to their store like Apple does). It is beyond me why Apple punishes developers with an app sto