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.
Ice Cream Sandwich (Score:2)
Do you get wafers with it?
What flavours are available?
Re: (Score:2, Insightful)
Re: (Score:3)
If Google had invented the universal translator, they might have made a slightly bigger deal out of it.
So my guess is that it's limited to the languages you specify, just like the keyboard.
Re: (Score:2)
Re: (Score:3)
A marketing company lying? Say it isn't so!
Re: (Score:2)
Allowing input in multiple languages is not the same as translating multiple languages. Google could be allowing input through every and any language on the planet, and it still wouldn't be translating anything.
But seriously, the current Google voice input can't even handle accents, never mind handle any language. It's laughably useless in at least 50% of its attempts, which makes it totally useless. If they're being honest with their description here it will be a massive step forward.
And can I switch
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: (Score:2)
And do you really think that you won't have the option to turn this off?
Re: (Score:2)
Quick, you need to tell Google because there is no doubt that they didn't think about this workaround already!
Of course, that'll be one of the first things that I test out when I get ICS. :)
Re: (Score:2)
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.
When I first read the term "face unlock", I thought it was that system where they put up a grid of random faces and you pick the one that you recognize. I'd much rather see that in effect than this facial recognition system.
Mind you, if it could recognize my ear instead of my face...
Re: (Score:2)
Recognizing a face is probably a lot harder than distinguishing whether whatever is on the camera is dead or alive, so my guess is that it won't work.
Re: (Score:2)
Well it's more secure then just "slide to unlock" and it's not as inconvenient as a more secure screen lock.
Secure screen locks are a bit of a problem with smart phones, since (in order to save battery) the lock engages so often. It would be nice if there was an option to have different locks - just a slide if you haven't used the phone for a minute, and e.g. a PIN if you haven't used it in 15 mins or so.
Re: (Score:2)
^^^ what he said. Maybe take advantage of the Hall Effect sensor to be aware of when the phone ceases to be in close proximity to some large, blunt fleshy object (hand, thigh/butt adjacent to phone in pocket, etc) and progressively escalate the security as the phone's body-presence is interrupted or as time passes with inactivity. Perhaps monitor the accelerometer for motions that could indicate grabbing/dropping, setting down on a table, orientation (face up/face down), etc. Put the phone on a table face u
Re: (Score:2)
Well it's more secure then just "slide to unlock" and it's not as inconvenient as a more secure screen lock.
Secure screen locks are a bit of a problem with smart phones, since (in order to save battery) the lock engages so often. It would be nice if there was an option to have different locks - just a slide if you haven't used the phone for a minute, and e.g. a PIN if you haven't used it in 15 mins or so.
Yeah, it's a wonder they haven't thought of that... Er wait no they did that exactly. You can set the PIN to engage only after a set interval that can be longer than the screen timeout. Slightly less secure but a lot less annoying if you are prone to using your phone for short, frequent bursts during the day.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
From the video face unlock is enough of a pain that most people will probably turn it off after showing it to all their friends anyway.
Re: (Score:2)
A little digging into focus distance data will give the phone more than enough info it needs to tell the difference between an actual life-size face and a tiny little image of a face on a card... Also, most (all?) photo IDs have security features including watermarks, overlays, and holograms that could be detected and used to negate the scan. Or, as many have pointed out, just don't tell it what your face looks like and stick with putting in a pin or using a silly little puzzle to unlock it. Whatever lets
Simpler answer (Score:3, Funny)
Use a body part that isn't visible in your ID photo.
Re: (Score:2)
Facial recognition is not just a "how much does this pic look like that pic" type of operation. The algorithm (or a useful algorithm anyway) looks at the key metrics of your face, such as pupil separation vs distance from eyes to mouth (to judge distance and aspect ratio) and then looks at nose size, jaw width, ear width, and a number of other features to determine if the two faces are identical. Otherwise, you would lock yourself out of your phone (in this case) by simply growing a beard or adding/removi
Re:Seriously? (Score:4, Insightful)
Ahhh, yes.... biometrics: the weak, insecure password you can't change.
Updates to phones (Score:5, Insightful)
All this being said, Android 4.0 looks great.
Re: (Score:2)
Assuming the driver model is compatible, upgrading Android really shouldn't be as troublesome as it is.
It's a good point where iOS wins (though still by far not enough for me to even consider an iPhone).
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.
Re: (Score:3)
That's because pretty much ALL of the Android phones have this problem. The only phones I know that *may* not have a problem are the ones commissioned by Google.
Re: (Score:3)
Also why would a manufacturer spend money updating your phone when they rather you buy a new one?
I'm sure Apple would also rather everyone buy a new iPhone every year, and yet they bend over backwards to get the latest OS working on every conceivable model they have sold. Same with the Google phones, from what I understand.
The manufacturers who ship Android phones and then never publish updates obviously don't care one bit about their customers experience. It's as if they don't even perceive the people they sell to as "customers", but rather as "transaction generators". This approach might work fi
Re: (Score:2)
Re: (Score:2)
I think the biggest issue here is that the manufacturers and wireless carriers are responsible for the updates to the OS.
Wireless carriers _want_ to be responsible so they can force their custom OS and bloatware on customers. Indeed, there are costs to do this, but ultimately, it's about control. It really ought to be like a PC where the Android phone calls home to Google and asks for daily updates and bug fixes.
This fragmentation everyone talks about isn't a problem of hardware diversity, it is really a consequence of allowing wireless carriers to control Android updates.
Re: (Score:2)
When's the last time you changed the OS on your microwave?
When my microwave reads email, IMs, and browses the web, I'll update it's OS pretty damn regularly.
(Honey, the popcorn's been hacked again!)
Re: (Score:2)
Re: (Score:2)
Manufacturers and carriers that hold back Android updates are like IT departments that keep everyone on IE6. Developers have to decide whether or not to support new features given so many people running old versions. And if they do use the new features, do they lock out the old versions, or spend extra time writing workarounds and testing on those old versions?
Re: (Score:2)
> I'm assuming your phone met your needs when you bought it because if it didn't, you should have got something else.
You're assuming he's not American, more or less married to a specific carrier, and basically stuck with the half-dozen or so Android phones they have available at any moment in time. Want a slide-out keyboard? You've just eliminated 80-90% of them. Specifically want a 4.3+ screen that's LCD or a specific flavor of pentile (or non-pentile)? Your phone choice has basically been made for you,
Re: (Score:2)
They don't really care whether you replace your device, they just don't want to have to support it after you've taken it out of the box and activated it.
Cyanogen is actually a wet dream come true for Samsung, because it effectively means they can outsource the ongoing support and development of their phones' OS to an army of highly-skilled, unpaid volunteers whose work is loosely coordinated by a single employee (who, as an employee, can be given access to proprietary stuff that they aren't allowed to relea
It's not always whether the phone can support it (Score:2)
Mine technically supports 2.3 if I wanted to root and load my own OS, but the manufacturer/carrier only went to 2.1. It's the manufacturers and carriers: They sold you the phone, they don't give a damn about you anymore. Wait until the next upgrade cycle so they can sell you a new phone. At least Apple supports phones with the latest version for at least two years after release.
And the only relevance that has is for developer support, which is irrelevant si
Re: (Score:3)
So can you jailbreak an Android phone and update the OS to the latest yourself? Is there a blog or tracker anywhere with a phone-OS-company matrix that shows who lets you use what on what?
Yes or no, depending. (And thus the problem).
Some phones have the bootloader locked so you can't do that. (Although often there's a hack to unlock it).
Then the problem is drivers -- you can't install stock Android updates on your device and expect all the components to work correctly, as they all have slightly different hardware.
There are many 3rd party ROMs that package up Android releases for various phones (cyanogenmod is one of the most popular). If there's a cyanogenmod build for your specific phone
Ultimate Yawnsauce. (Score:2)
Considering what these devices are connected to (social networking, email, contacts, pictures etc) you'd think that this was a higher priority than a new font for the clock.
Re: (Score:3)
Re: (Score:3)
Re: (Score:2)
Re: (Score:3)
Why isn't multi-user support not more important? Maybe not so much in phones, but definitely tablets. If I am at my bro's and my nephew wants to play angry birds on my tablet, I should be able to hand it to him with confidence that he can't see my emails etc. And maybe a limited user (guest) account that can't install/uninstall stuff etc. Why does it have to be like win98 again?!
Re: (Score:2)
Re: (Score:2)
If Google provided full disk encryption, would you trust it?
Re: (Score:2)
Re: (Score:2)
Really? I haven't used android, so this may be a stupid question. Is everything stored in the cloud? Are android tablets just completely unusable without a network connection?
Full disk encryption is present (Score:3)
This is from one of the Android devs:
https://plus.google.com/112413860260589530492/posts/DDTKFhiDS9U [google.com]
"Support for Encryption for Phones
Honeycomb added full-device encryption, but ICS brings it to phones."
Guess they figured it too boring for the launch demo.
I took a look at ICS last night (Score:3, Interesting)
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
GPL (Score:3)
Like we did for all Honeycomb release, this is NOT the full source tree for IceCreamSandwich, these are only the GPL parts that are in the SDK (along with a few associated files), and they're not enough to build the whole IceCreamSandwich for a device.
One of the fundamental principles behind the GPL is that if you used GPL parts to make a whole work, then the whole work must also be GPL:
"You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. "
"These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. "
It's quite obvious that "IceCreamSandwich" is a whole work, and that it contains GPL parts.
Re: (Score:3)
See, that's why I don't like GPL - everyone has their own favorite interpretation of it, and they are often wildly different. According to yours, it would seem that even using a GPL'd web service in a program would make that program a "derived work" of the service. I'm glad to say that it's not a particularly popular one, but you are of course entitled to it - we'll never find out who's right until a court rules on this, and even then I expect it might arrive at different answers in different jurisdictions.
Re: (Score:2)
Might be related to your droid, my HTC Legend gets about a week of "idle" time. A bit less with CyanogenMod instead of the stock firmware (not sure why...)
Re:That's cool, but my one grip still (Score:5, Interesting)
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.
Re: (Score:2)
So you would rather not have them at all?
Re: (Score:2)
My reasoning has always been, if you have to turn off all the features to make the phone usable, why have the features at all? And turning them on only when I want to use them is too much hassle if I have to do it manually. I'm an American, I want it now and I want someone else to do it for me, damnit. Fortunately I found a workable solution (battery saving application).
My reasoning has always been: "reading, it's fundamental!"'
However, I found that if you disable all the features that are not present in the iPhone
In other words, if you make it feature-comparable with an iPhone it will also be battery life comparable with an iPhone. This has been my experience with battery life as well. If you turn off the cool but unnecessary features (Google Latitude is one example) and still retain its smartphone-ness (email, web, social media, etc) you will get plenty of life out of your Android phone.
Re: (Score:2)
You're looking for a fight where there isn't any and I have no idea why. My recommendation is decaff. While you're looking for the coffeepot, you might re-read my message and try to figure out where I had misunderstood anything I read.
Epic, you insult me then insist I simultaneously look for a coffeepot and re-read your post. The statement "if you have to turn off all the features to make the phone usable" is very clear and to the point, but is completely misplaced since no one ever suggested doing that. Thanks for trolling then complaining when someone called you out on it. You are really making the internet a better place!
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Truth be told, I think 98% of Android's "lagginess" problem is due to CPU scaling and power management. A few weeks ago, I was using my old Hero (overclocked to 711MHz, CPU scaling & power management disabled, CM7 installed, running balls-to-the-wall full speed), and it was actually smoother than my dualcore Motorola Photon. Graffiti input was absolutely flawless (on the Photon, it's mostly accurate, but has its moments when I'm left wondering WTF the phone's power management is trying to do because it
Re: (Score:2)
Re: (Score:2)
You can blame HTC and Verizon for that and not Android.
My wife has the same phone. MISERABLE battery life.
Last weekend I rooted it and tossed Cyanogenmod7 on it, which is about as vanilla a rom as you can get.
Her battery life has improved drastically. From dying around noon every day, to having 70% battery life left at dinner time.
Its because Verizon just loves to load your phone up with useless crap. Same reason Windows used to come preinstalled with MSN, AOL, etc.
Re: (Score:2)
Google have used types of desserts as naming scheme for Android since 1.5 (April 2009), and I can't see a problem with it.
No one is forcing you to use the names, however.
If you need to have a meeting with your bosses, feel free to use the actual version number, which is 4.0 for Ice cream Sandwich.
A lot of software use naming schemes, it's very common in OSS community.
Re: (Score:2)
At least naming them after deserts is better than the vulgar and juvenile sexual terms many FOSS projects use (gimp, kuntlik, fetchmail, jizm, I'm looking at you!)
Onanistic Ocelot?
Re: (Score:2)
he confused it with feltchmale. Common problem amongst those who are obsessed with sucking cum out of a man's ass.
Ahem, the proper term is "santorum"...
Re: (Score:2)
he confused it with feltchmale. Common problem amongst those who are obsessed with sucking cum out of a man's ass.
Ahem, the proper term is "santorum"...
Only in a "sanitorium" is it so.
*choke*
Re:Ice Cream Sandwich? Really? (Score:4, Informative)
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.
Re:Ice Cream Sandwich? Really? (Score:5, Informative)
Re: (Score:2)
Jam RollyPolly
Re: (Score:3)
Working up the ladder, non-copyrighted names: K - Key Lime Pie, L - Lollipop, M - Meringue, N - Napoleon, O - Orange Sherbet, P - Profiterole, Q - Quince or Quiche, R - Rice Pudding, S - Shortcake, T- Tiramisu, can't think of satisfactory "U" terms, "Upside Down Pineapple Cake" is too much of a... err... mouthful.
Re: (Score:2)
There was an awesome speed metal band that went by the name of Green Jello, but they were forced to change it to Green Jelly after Kraft foods the maker of Jell-O complained.
http://en.wikipedia.org/wiki/Green_Jell%C3%BF [wikipedia.org]
Re: (Score:3)
wow you're boring.
I just finished the cassowary version and now I'm working on the dingo version. Yes we use those terms in meetings, with bosses, and it gets a good chuckle. It's far more entertaining than version numbers.
Re:Ice Cream Sandwich? Really? (Score:4, Interesting)
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."
Re: (Score:2)
Re: (Score:2)
I told my wife that Google names all their operating systems after desserts in order of the alphabet. She seriously thought I was kidding and was trying to make her sound gullible. For the record she does use a Droid Eris. She just doesn't really care what operating system is on it.
Re: (Score:2)
Because it's easier to refer to a name than a version number.
Primarily these code names are used only internally but as companies have become more public about internal ongoings, so have the code names.
To the public it's still 4.0. I've never seen any non-developer-targetted ad mention anything besides "Android X.Y" for the Android OS.
Not to mention having an excuse for themed release parties.
Re: (Score:2)
Because it's easier to refer to a name than a version number.
Primarily these code names are used only internally but as companies have become more public about internal ongoings, so have the code names.
To the public it's still 4.0. I've never seen any non-developer-targetted ad mention anything besides "Android X.Y" for the Android OS.
Not to mention having an excuse for themed release parties.
Ah, this makes a lot of sense. I'll have to defer to non-developer targetted ads, since I haven't really looked at Android except through enthusiast who use the code names.
Re: (Score:2)
You can say 'upgrading from version 2.3 to 4.0' in that meeting with your boss if you prefer. People often prefer the code-names as they're easier to remember the distinguishing features; gingerbread and froyo mean more to me than 2.3.4 and 2.2.1, but whatever works for you.
Personally, I was really looking forward to the nexus prime as the 'flagship' for ice cream sandwich (or 4.0!) - but the hardware looks pretty unimpressive compared to the galaxy S II, the new Razr or even something older like the optimu
Re: (Score:2)
Oops, that should be the LG LU6200 [talkandroid.com].
Re: (Score:2)
gingerbread and froyo mean more to me than 2.3.4 and 2.2.1
Except as a non-enthusiast, I don't know which comes first. "The first initial of the code name tells you which order they came in, A-Z." Huh, I hadn't noticed that at all, and no one else is likely to notice without being told, excepting of course for the random insights that people make from time to time.
Re: (Score:2)
Re: (Score:2)
Using an ice cream sandwich as a phone is still less ridiculous than side talking on an NGage.
Re:Ice Cream Sandwich? Really? (Score:4, Informative)
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?
Re: (Score:2)
But not matching sequential versions. i.e. F=2, G=3, H=4
Re: (Score:2)
They're just using a letter sequence, the same as Ubuntu does.
Eclair
Froyo
Gingerbread
Honeycomb
Ice cream sandwich
I agree that "Ice cream sandwich" is a bit of a silly name, but it is part of a logical sequence.
And kinda like Ubuntu, everyone will now start second-guessing what the next code name will be.
I noticed this once I was clued in above. I don't really think Ubuntu code names are any better (or worse), honestly...
Re: (Score:2, Offtopic)
my first post!
Oh come on Anonymous Coward. You've been posting for as long as I've been on Slashdot. Nobody believes this is your first post.
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: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: (Score:3)
In addition to what the other responder said about android:configChanges="keyboardHidden|orientation", it's possible with most mobile platforms for the application developer to include a soft-button in their interface that does what you describe.
Personally, I do actually like the feature on the Xoom, included with Honeycomb 3.0, that allows one to globally lock screen orientation. Short of the 'orientation-flip' button you describe I find it a fairly reasonable alternative.
Re: (Score:3)
I'm not arguing that the 'orientation lock' feature shouldn't exist, just arguing that it would be nicer to use if a power button double-click were interpreted as "reorient the screen based on the accelerometer now, then lock it until the next time I double-click the button". A separate button would be even nicer, but making do with the hardware buttons the Xoom already has, a powerbutton doubleclick is just about the best unambiguous-yet-easy gesture I can think of.
I personally despise gestures that requir
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: (Score:2)
The proof is in the pudding. Android itself and Android apps cosistently don't hold a candle to iOS apps in their functionality, usability and general quality. The obvious culprit is the underlying over engineered misarchitecture and the resulting horrific APIs.
Silly me. Here I was thinking it had to do with the fact that there is much more money to be made developing for iOS so developers are going to target it first and hardest.
Case in point. For the very obvious and what should be mundane and simple task of communicating between activities you get this, http://developer.android.com/resources/faq/framework.html#3 [android.com], various different ways of saying "use globals".
Assuming you understand how intents work, how is
a global in any conceivable way?
Re: (Score:2)
Re: (Score:3)
those horrible XML files as the preferred way of designing a UI
Hmm...separating the UI description out in xml files is a good thing. In fact, it's a standard thing across all platforms. Android has those xml files, Windows has xaml, and iOS has .xib files.
Sure, interface builder abstracts you from the .xib files, and you never have to look inside it, but you can do xaml and android xml via their respective design interfaces too. The fact that you can also edit the xml manually is a feature, not a bug.
Re: (Score:2)
I am an android developer fulltime. The UI builder in Eclipse (which is the one that comes with the SDK) is crap. Just plain crap.
So what you end up having to do, is, to edit the XML manually, which is cumbersome and unintuitive.
Developers have different preferences. I readily admit that I've only played with iPhone and Android development, but I am a full-time windows developer, and I deal with .net and xaml all day long. I end up editing the xaml manually, but I don't find it cumbersome and unintuitive. Frankly, I find Interface Builder cumbersome.
After I've placed a combo box on a screen, I want to bind the selected item to a property. The editing xaml manually method is to click on the combo box to take you to its ComboBox
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
...I cried with laughter.
Same reaction I had when I read
When I got to the bit in the tutorials...
in your post.
I'll take your criticisms with the same level of credibility as the depth of your analysis.
Re: (Score:3)
Re: (Score:2)
They also did it to stop the flood of cheap, borderline-useless 480x800 $100-200 tablets from China that were destroying the Android tablet market by setting consumer price expectations to unrealistically low prices & making it almost impossible to sell Android tablets with more appropriate hardware (1-GHz dualcore, 1280x800 display). Google basically told manufacturers, "you can have Honeycomb if you want it, but you're only allowed to use it on appropriately high-end hardware". The alternative would h
Re: (Score:2)
Re: (Score:3)
Loads of people here care about the Android sources being available. Personally I work with the Android source, and need it available to me where possible. But for people who don't, many of them still want to be able to use Cyanogenmod or other ROMs developed from the source. Even if they don't see it personally, they can get benefit from it.