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.
I heard my bother talking on the phone about this awhile ago... It seems like one of the most weird and random names to call something. I get it, code names are cool, and people readily recognize them. But you sound absolutely silly for doing so. Who wants to go to a meeting and tell their bosses that they're thinking of: "Replacing Honeycomb with Ice Cream Sandwich on all our android devices"?
Use the damn version numbers, PLEASE.
WARNING! This girl exceeds the MAXIMUM SAFE standards established by the FDA for BRATTINESS
Do you get wafers with it?
What flavours are available?
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...)
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.
It says there on the website that "The new voice input engine lets users dictate the text they want, for as long as they want, using the language they want.", but... well, is it really true? Can I just start blabbing out in Finnish, or does that actually mean "using the language they want as long as it's one of the few select languages"? If it's the latter then it's obviously not all that useful or wonderful as they make it out to be.
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.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
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.
When our name is on the back of your car, we're behind you all the way!
That's been a huge issue for me too. I went and got the extended battery for the Evo 4G which worked wonderfully, although it made the phone heavy as a brick. I've found a surprising solution though. Recently upgraded to the Galaxy S2 (Or whatever the hell you call the thing) and there wasn't an extended battery available yet that I could find. So, against my better judgement I tried JuiceDefender. It works. It works *well*. Basically it shuts down the sensors when they aren't in use, and turns them on when you unlock your phone to use it. Worried about email? No problem, it turns on the data every so often to allow apps to synch that need to synch. I'm actually not sure why a similar strategy isn't just a default part of the operating system.
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).
ICS should improve battery-life quite a bit. As it says in the TFA they're now requiring all devices with ICS to do hardware-accelerated graphics, and as you likely know a GPU is a lot better at handling such tasks and at shifting around large amounts of data in memory than a regular CPU is, so the more you actually use the device the larger the difference in battery-life should be. Obviously it won't affect idle standby-life, but from your comment I understood that that wasn't the problem anyways.
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.
So you would rather not have them at all?
I'll meet you at the intersection of "Should be" and "Reality"
So you would rather not have them at all?
The device has to be usable. If the battery consumption is such that I have to be within reach of a power supply every few hours, then no - I don't want the features. I'd rather have the battery life.
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.
Do you really need Bluetooth on all the time? How about a data connection? I tend not to look at the web in my sleep or if I'm gonna be in a long meeting, so I turn that radio off. Its a swipe and a press to turn them back on, it really isn't a hassle at all and the difference it makes isn't small.
I've really been thinking about purchasing the Samsung Galaxy Player 5. I don't have a need for a smartphone as I find wifi + Google Voice to be more than adequate to meet my needs since I shut down my Verizon account and kept my Droid. It's like having a portable landline; I can go to the park without being tied into an endless stream of information.
Are these PMP devices rootable? And will custom ICS ROMs support them?
I don't need it on all the time. I also know that realistically there's no way I'm going to remember to turn things on and off on my phone when I need them. My brain doesn't work that way at this stage of the game. That's why I'm glad there's an app for that.
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.
ICS still doesn't improve lagginess.
http://flyosity.com/iphone/androids-touch-responsiveness-is-terrible.php
That may be, but after having owned a 10-inch Honeycomb tablet for several months I just personally don't share his opinion on it. I don't find it "totally unacceptable" or anything like that and can perfectly fine live with it, I care a lot more about all the new features and improvements ICS brings to the table.
I'm pretty sure we'll see the source of 4.0. Generally Google doesn't release the source immediately, it makes a source code drop a little after the OS is announced and released.
You are not alone. This is not normal. None of this is normal.
When I got to the bit in the tutorials about apps being forcibly restarted when the orientation changes I cried with laughter
Err.....lolwut? Was it perhaps a how-to-spread-FUD - tutorial?
So you don't deny his facts. There is a lag.
It's just your opinion that lag features.
I get that, I just think the lag would drive me nuts after a while. Especially after having used an iPad for a bit.
What would you do for an Android SDK?
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.
No, I have never laid eyes on the development platform for Apple devices, but I do know that the one for Android does feel entirely immature. It's everything I have come to expect from open source projects.
But to be fair, Google also have another problem that Apple just doesn't have and which has always been Apple's strength: A small set of known hardware to support. I mean, the rate at which they cancel support for old devices should prove that this is part of their success. The main gripe with Windows has always been "this doesn't work. that old graphics card crashes" aso. Everything that crashes on a platform reflects on that platform. So a stable known environment is a huge advantage.
I think some specifics might make this a more useful post. I've not come across the issues you describe.
As far as the "XML files (being) the preferred way of designing a UI", that's kinda dubious at best. Generally most of the specifics are coded in Java, with only basic metadata about the app being specified in XML. True, there's more metadata than there is in a desktop Java application, but it's not a lot.
I should state here I hate XML with a passion, so if I thought Android development burdened people with large amounts of entirely unnecessary and pointless XML coding, I'd be the first to be screaming from the hilltops. I just don't see that as being the case, however.
You are not alone. This is not normal. None of this is normal.
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.
So you don't deny his facts. There is a lag.
No, I don't deny that. I just see very little lag, so little that it doesn't bother me in the least, whereas the guy makes it sound like you see one frame every 5 seconds and that it takes 10 seconds for anything you type to appear. And that obviously ain't true.
I get that, I just think the lag would drive me nuts after a while. Especially after having used an iPad for a bit.
Indeed. That's called "differing tastes"; I have used an iPad and I just didn't find it any better than my tablet, a little smoother animations but lacking features.
Where's the full disk encryption? I shouldn't have to rely on a 3rd party app like that Whisper Systems product to provide some fundamental data security for the device.
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.
Finally had enough. Come see us over at https://soylentnews.org/
Yeah, 2 years after we see Honeycomb.
Coming real soon now.
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.
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 starts making weird recognition errors). On my Xoom, Graffiti is fucking unusable. It lags worse than my Hero did at 508MHz with stock HTC kernel and 1.5. I suspect Motorola did the same thing HTC originally did -- said, "Hey, we're displaying a soft input area, which is just sitting there idle with a bitmap waiting for a blunt keypress, so let's drop the speed down to something absurd like 200MHz" -- totally ignoring the fact that somebody might be using an input method that depends upon frequent sampling at close intervals.
It's sad when a tablet with 1GHz dualcore CPU can't accurately do something a 16MHz glorified 680x0 could almost do in its sleep with 99.999% lag-free accuracy.
We don't need more aggressive power management, we need 4800mAH batteries so we can enjoy our phones and have them last all day. The problem is that manufacturers like HTC, Samsung, and Motorola are all afraid to release a phone that's thicker than last year's iPhone, so they all ship with anemic & undersized batteries. Take a phone with a 4.25+ inch display, make it a millimeter thicker, and redistribute the innards to make full use of every cubic millimeter of interior space for either electronics or battery (the Evo 4G, for instance, wasted nearly 25% of its internal volume on an empty orange plastic frame, and most new phones are no different). Maybe ship the phones with TWO batteries -- a custom, non-(easily)-replaceable battery that takes those space-filling frames and fills them with 1800-2400mAH worth of Lithium gel, and a second ~1700mAH battery that's replaceable and gets used first and recharged last. If you add the volume of the space-wasting frame with another ~3.5" x 5.5" x 1mm of lithium gel spread out across the entire area of the phone, it would be no big deal to make phones with 4,000+ mAH batteries.
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.
Use a body part that isn't visible in your ID photo.
I'm the real Vorokrytin P. Winterbuttocks.
So in effect you are stating that your brain does not work well so for you an iPhone is better?
I had to!
Not at all. I'm saying my brain doesn't work so well, so I need the phone to manage its resources for me. I have an android phone and the solution for me was an application to help do that. I'm not trying to argue iPhone vs Android, to me it's all the same. I'm just sayin'. I have an android, and this is what worked well for me.
Google made it clear from the beginning that Honeycomb wasn't going to be opened. There's been no problem getting the source for Honeycomb's mobile peer, Gingerbread - I'm running it right now courtesy of Cyanogen.
I don't like the fact that Google didn't open Honeycomb, but they had their reasons, and I respect them. Unlike ICS, Honeycomb was always a rushed "production" beta, and Google didn't want developers working from it. ICS, on the other hand, is the future direction of Android. There's no reason to suppose that Google isn't going to release the source for it, as failing to do so would pretty much kill the platform.
You are not alone. This is not normal. None of this is normal.
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 definition tag in the xaml, and add the attribute:
SelectedItem="{Binding TheSelectedItem}"
Where "TheSelectedItem" is the property name in the object set as the data context. The Apple method is more like, "ok, I need to find the menu item that does binding, click on that, then click on the combo box, and drag the arrow to the objective c file that contains the class description, then select the attribute I wish to bind and the variable name I want to bind to."
Again, I'm not going to say that one method is better than the other, because I know people have different preferences, and I bet you can be pretty proficient if you know your way around interface builder better than I do. That said, I can tell you that my personal preference is for editing the xml manually.
The implications of your post sadden me.
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.
...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.
Sometimes the light at the end of the tunnel is the headlight of an oncoming train.
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 have been an endless flood of cheap tablets that totally sucked and made Android forever look bad compared to the iPad. Google HAD to do something, and do it fast, to forcibly raise Android tablet specs to realistic levels, and restricting access to Honeycomb was the only real sledgehammer they had available.
Obviously, ICS is going to quickly end up on those same cheap under-powered tablets anyway. The difference is, at least now the market has had about a year to mature, so faster tablets at least EXIST now so consumers can directly compare them side by side and see firsthand why a faster tablet with higher-res screen is worth the extra cost.
I do think Google went a little overboard by mandating a minimum screen size, as opposed to sticking with a minimum RESOLUTION. Given a choice, I would have rather bought a tablet with the same 1280x800 resolution, but a *slightly* smaller screen (say, around 8 or 9 inches).
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.
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
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!
This is the first time I've seen XML presented as easy or intuitive.
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 since both platforms have easily surpassed critical mass. Also, your statement isn't just restricted to phones. You have to include all iOS devices: phones, tablets and the iPod Touch (and possibly Apple TV, although you don't get the App Store for that). This pushes iOS much higher than Android.
If you want to talk only smartphones, then Apple is outselling them all.
As far as the "XML files (being) the preferred way of designing a UI", that's kinda dubious at best. Generally most of the specifics are coded in Java, with only basic metadata about the app being specified in XML.
You're lying, or just very inexperienced with Android development. The typical, standard, preferred way of describing an Android app's UI is via XML; this allows you to very simply leverage the platform features that display the correct UI based on device capabilities such as screen size, resolution etc. Not to mention there are some things you simply cannot do in java, such as easily applying a style to a UI element (via something like textView.setStyle(R.style.text_view)) .
Professional android developer (over 40 released apps) here with a deep, ingrained distaste for XML.
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, various different ways of saying "use globals".
Assuming you understand how intents work, how is
a global in any conceivable way?
The soylentnews experiment has been a dismal failure.
Maybe actually try developing an Android app or two. Throw in a full dose of intellectual honesty and then you can come back and tell us all if creating an XML based layout is intuitive or not. I'll be waiting.
The soylentnews experiment has been a dismal failure.
VPN client API
Developers can now build or extend their own VPN solutions on the platform using a new VPN API and underlying secure credential storage. With user permission, applications can configure addresses and routing rules, process outgoing and incoming packets, and establish secure tunnels to a remote server. Enterprises can also take advantage of a standard VPN client built into the platform that provides access to L2TP and IPSec protocols.
this, to me, is the most signifigant part of the release. End-users and IT people have been asking for this forever.
Or I don't code the way you've chosen to.
I appreciate the quantity of Android apps you've written, but if a particular feature of development is bugging you so much, I have to wonder why you've not even tried to avoid it?
You are not alone. This is not normal. None of this is normal.
You're clearly having a bad day. I'm not arguing the iPhone. It's a perfectly good phone. I don't have one. I'm not against having one, but I have an android and my comment was regarding the android, battery consumption, and the act of turning on/off sensors. Contrary to your analysis, my reading comprehension is perfectly sound. I stand by my suggestion on the decaff, by the way.
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.
4,65" hd super-amoled display, 1280x720 pixels
1,2 gigahertz dual-core
HSPA+ 21Mbps DL; HSUPA 5.76Mbps UL
Size: 135,5 x 67,94 x 8,94 millimeter, 135 gram
16GB internal memory
Front cam 1,3 mipxel for videoconf
Back cam 5 mpixel
NFC, Bluethooth 3.0, wifi 802.11 a/b/g/n, usb 2.0
More information at http://www.samsung.com/se/news/newsRead.do?news_group=productnews&news_ctgry=&news_seq=29470
Yeah, I should give that a try huh.. oh wait, I already did! I stand by my comments. Creating a layout in XML is intuitive? Nope, not. What else you got?
Well, at least now they can just hold the phone up to your face while you're tied up instead of beating you senseless with a $5 wrench...
http://xkcd.com/538/
Maybe, but your statement was effectively "claiming XML is preferred is dubious.. the general way is to use java". Which, IME, is certainly *not* the case. But since "preferred" and "general" are both anecdotal at best, I don't think either of us is in danger of changing the other's mind about which approach best fits those terms.
Read my reply to myself.
The soylentnews experiment has been a dismal failure.
Cool, I didn't know that. Thanks! :-)
Just as an aside, I recently did the same to my Evo 4G. I really was surprised, Cyanogenmod is some good stuff. The installation process is also easy enough that even someone who hasn't done such things before should be able to handle it without issues.
Fair enough - that reply was anonymous, so I did not automatically associate it with your good self.
I've actually been very pleased with the update support from Verizon/HTC for my aging Droid Incredible (original, not version 2). This phone started out with 2.1 (Eclair), and shortly received an update to 2.2 (Froyo). The phone was actually 'end-of-life'd this past March but that didn't stop them from providing an update to 2.3 (Gingerbread - the latest version available for phones prior to 4.0's imminent release) just this past September. These are all vendor-sponsored updates mind you, no CyanogenMod required.
So essentially, I've been provided with an update to the latest Android every time a new version has come out since the release of the phone. Can't ask for much more than that.
That's not to say that I'm necessarily expecting an update to 4.0 (Ice Cream Sandwich), but with today's uber-short product lifecycles I'm pretty happy with the support for this 1.5-year-old phone. And if they *do* update the Droid Incredible to 4.0, that's going to significantly enhance my loyalty to Verizon/HTC to the point where I'll probably insist on the same carrier/vendor when I upgrade.
Orientation change doesn't have to terminate and restart activities it's just the default and recommended way it done. You can configure it via the manifest to not restart your activity on orientation changes. Then it becomes completely your responsibility to manage the layout. Android does a lot of stuff in the background like loading layout dependent resources etc. and if you let it restart your activity then you don't it have to manually think about all these stuff. Also the activity is meant to be a lightweight UI. any background processing is meant to go into services and like.
Once you understand the actual application stucture of an android app with activities, providers, services, etc. it actually makes sense. But like you said one needs to read the (not so good docs) and understand the concepts behind it. But for those who have come from the background of having all work being done on the UI window control this is a major hassel.
I completely agree with the accelerometer comment. I simply disabled the automatice orientation change on my phone and found it to much more simpler to use.
As a reply to grand parents comments. Best practices meant to a enterprise app doesnt always work with a memory constrained real time device like a mobile phone. Like Raymond Chen says best practices are best under certain ciruimstances not everywhere.
Android has it's weakneses but it's nowhere near as what grandparent says. My peeve has to do with all the undocumented stuff.
That's pretty much a gross exaggeration of battery consumption. Not only that, but you seem to keep comparing battery life for Android phones under heavy load to the expected battery life of an iPhone under ideal conditions with no use. Apple doesn't own some magic technology that lets its phones do lots of work with no negative impact on battery life; they drain just as fast under heavy load.
I have my Evo 4G with me all the time with bluetooth enabled and I easily get 2 days out of the battery unless I'm doing a lot of web surfing or playing a lot of games.
--Jeremy
Jesus was a liberal
Actually, there are plenty of Android apps that will automatically start/stop applications/services based on your location/time of day/whatever, so your brain doesn't need to remember to do all that manually if you don't want to.
--Jeremy
Jesus was a liberal
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.
So Google suck in various OEMs and open source enthusiasts, release two major upgrades and still not release the source code? I'll stick with MeeGo/Mer/Tizen, etc. thank you very much.
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.
Umm. No you can't. There are many widget aspects that are only configurable through XML. There is no Java API for them.
Besides, the XML files are exploded into Java on the device anyway.
Nope the XML files get bundled in your apk as is. Android might interpret them later in java but so what? It's gotta do it somehow.
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?
Oh, I don't know. That your UI code is now spread across some a few unverifiable XML files and Java instead of being in one place where it would be easy to maintain.
I have had an extended battery for my Droid Incredible since not long after I got it, and was never disappointed with battery life. Then one day, I went back to a (new) standard-sized battery. I haven't gone back. I'm the kind of user that plugs in my phone on the nightstand to charge while I sleep, and even if I forget a night I can generally make it through the next day as well. My usage profile does include quite a bit of widgets, web browsing, et cetera (though no games), and I'm quite satisfied.
I think for a lot of users it's the games or Netflix that does it. Or, living in an area with poor signal quality where the radio power (and power consumption) is automatically increased to compensate. With those situations, I could definitely see someone being disappointed in the battery life - but that's on just about any smartphone platform.
When I got to the bit in the tutorials about apps being forcibly restarted when the orientation changes I cried with laughter.
Kind of tough to take the rest of your subjective criticisms seriously when you get this objective one completely wrong. The activity is restarted, not the app. If you don't know how to engineer an app to make it so that activity != the whole app, it doesn't speak very highly of your software engineering ability. I'm not even a Java dev and I had that 'problem' solved within hours.
--Jeremy
Jesus was a liberal
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 require menu navigation. I'm impatient. I like things like "press and hold button one with the left index finger, press and release the right button with the right index finger three times, press it a fourth time and hold it, then press and release the left button two more times and release the right button" (just to give an example of some hypothetical multi-shifted multi-click gesture you could do with two hard buttons), because they're self-clocking and you can execute them as quickly as your muscle memory can actuate the buttons. I hate having to stop, look at the screen, touch something, wait, touch again, wait, wait, wait, and complete a gesture. I grew up triggering Mortal Kombat fatalities that involved 17 discrete key gestures within 800 milliseconds, and miss the old fashioned immediacy of hardkeys and muscle-memory instantaneous gestures.
no stunning new features that'd prompt Jobs to pick up chalk and go back to the drawing board
If Google actually managed to get Jobs to pick up chalk and start innovating again that would SURELY generate some ginormous press.
Google/Samsung/et al. don't have a separate timeout for slide lock & security lock feature. This was originally an HTC Sense feature but now is also available in CyanogenMod.
Why CyanogenMod? Well, that's because after I wrote the code to replicate & improve upon the Sense feature, I only submitted a patch to CyanogenMod. (Hey, it's what I use...)
The feature is in CyanogenMod 7.1 or later, and any other ROMs that pull from CM 7.1 as an upstream. As stated before, a similar feature is also found in HTC Sense-derived ROMs. However, HTC's implementation isn't as versatile as mine, so I suggest you disregard that and just use CM instead (haha).
Pull the source if you want; port it anywhere you like:
Framework code
UI code
Umm. No you can't. There are many widget aspects that are only configurable through XML. There is no Java API for them.
First of all, who cares? Second of all, by definition, this can't be true as the xml files are translated into java by the device.
Nope the XML files get bundled in your apk as is.
No shit, Shirlock. Android running on the phone translates them into the relevant Java code.
Oh, I don't know. That your UI code is now spread across some a few unverifiable XML files and Java instead of being in one place where it would be easy to maintain.
Welcome to modern software design. Here, I'll provide a linky.
The soylentnews experiment has been a dismal failure.
Coming from the Apple world this concept may be new to you but these things are called "options." You can "choose" to turn them on or off. So if you want to remove them for better battery life you can do so. You don't even need to root your phone to do so. And if you want those features back you can do that too. Apple won't even sue you for doing so!
"Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
Hmm, I have one of those cheap borderline useless chinese tablets. I use it all the time to check my email, facebook, play tons of games, as a big screen gps, watch netflix and hbo-go, etc, etc, etc. What sorts of things can I not do with it that would magically come about if I used a more expensive android tablet with 'appropriate hardware'. Whats weird is that my cheap noname tablet has virtually the same hardware as the original ipad, except some people say the screen isnt as good. Which I dont seem to give a @#%$$ about.
Amazon also appears to have solved the problem with the Fire, since they realized that almost nobody gives a #$%$@ about what the hardware is, only that its inexpensive, does 98% of the stuff that 98% of users want, and has a full market of products behind it. Thus the consumer gets cheap access to content, amazon makes their profits on that, and everyone lives happily ever after.
Except for Apple, who will need to learn to either give away ipads and iphones, or lower their content prices to remain competitive. And Google, which will have to take on turning out cheap tablets/phones through their new motorola subsidiary and back it up with cheap market content. Everyone else might as well just get out of the business entirely, since nobody is going to buy $400-500+ tablets anymore, and anyone without a fully fleshed out market wont make any profit on the sale of the devices.
Yeah, you're about the only one. Ever.
http://androidcommunity.com/forums/f41/home-screen-lag-12132/
http://androidforums.com/android-lounge/7884-htc-hero-reduce-lag.html
http://forums.androidcentral.com/verizon-fascinate-rooting-roms-hacks/34047-lag-fix.html
http://www.youtube.com/watch?v=Rrpd-ZDHHlk
But you're right, you've never experienced it, so it NEVER happens.
There are two types of people in the world: Those who crave closure
There is a glimmer of hope for you yet. You have not been completely brain damaged by Android development.
First of all, who cares?
You said it was possible. I pointed out you were wrong.
Second of all, by definition, this can't be true as the xml files are translated into java by the device.
No. Use your terminology correctly. It interprets the XML. It does not translate anything. Its not generating new Java and it is not generating bytecodes. Huge difference.
And here is our glimmer of hope for you. You would expect that proper design would create a situation where "by definition" anything expressed in XML would be an expression of an underlying Java interface.
But it is not designed correctly. The XML interpreter does not use the public APIs available to the developer. It does its own thing and so you end up with two code paths for the same thing- bad design.
Don't believe me? Go look at the code.
No shit, Shirlock. Android running on the phone translates them into the relevant Java code.
Nope it doesn't. For someone who doesn't understand the basic difference between an interpreter and a code generator calling me clueless is a bit rich.
I use my Bionic pretty heavily. It's either got streaming radio or streaming scanner traffic (which is really the same thing) going at least 6 hours a day. I also surf, read news sites, play games, etc. It lasts from 8am when I unplug it until I plug it back in, usually at around 30% battery, sometime between 11pm and midnight. The stock battery would require a boost (I usually plugged it into my mouse's USB recharger while at my desk), but the extended battery (all of 25 bucks) pretty much means I'm good to go all day, and about 90% of that is on 4G.
I don't understand people bitching about having to plug the phone in at night. Really? This is a hardship? We have a device that fits in our hand that's more advanced than the portable computers depicted on Star Trek, and we're whining about batteries that only last 15 hours?
"I disagree with you" does not equal "flamebait."
I'll take a long hard look at what you've said. If you're right, thanks. If you're wrong, you suck.
The soylentnews experiment has been a dismal failure.
If the quality of your reply is an indication of the general quality of the developers in your office I'm not surprised they don't understand how Android is meant to be developed in. It's too complex for your average drone to figure out.
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
To be honest, just being able to link to stuff doesn't prove your point either. Lag is a very subjective thing and many people interpret almost anything whatsoever as "lag", and never stop to think what could be causing it. For example, googling "iphone lag" produces plenty of stuff:
https://discussions.apple.com/thread/1608445?start=0&tstart=0
http://www.youtube.com/watch?v=Ui9bPJfeRoM
http://www.iphonedevsdk.com/forum/iphone-sdk-development/59048-how-reduce-lag.html
http://techgeeks-online.com/2010/eliminating-lag-on-iphone-ipod-touch/
http://techgeeks-online.com/2010/eliminating-lag-on-iphone-ipod-touch/
http://www.wowza.com/forums/showthread.php?7745-How-to-reduce-Iphone-live-Latency
http://www.ifans.com/forums/showthread.php?t=37347
Does that mean that there's some inherent lag to it, or could it just be that... well, people are whining over misconceptions and issues they caused themselves?
Upgrade the battery. I have an incredible as well, and can't believe they actually thought the battery life was acceptable. I bought a huge battery for it that came with a new back cover to handle the increased size. It gets three times the life of the default battery, which finally got it to the point of me not having to really think about charging it.
Everything will be taken away from you.
This is from one of the Android devs:
https://plus.google.com/112413860260589530492/posts/DDTKFhiDS9U
"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.
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.
I'll just note two points:
1) Older Apple devices do get abandoned by Apple. My early iPod touch is locked at iOS 3.3 and Apple has made it clear that it will not receive updates.
2) The exciting "Siri" feature available on the iPhone 4S does not work on earlier phones, even though they do get an iOS 5 update. The official reasoning is that earlier phones are not powerful enough, but this seems to be dubious (even David Pogue, the super Apple fanboy seems to doubt this).
Bottom line: Apple plays the "obsolete" game pretty well, too.
On the other side, while Android has had painful fragmentation in the past, Google is claiming, at least, that Android from version 4.0 onwards will be able to run on older devices, though obviously not all features will be supported there. And Google is trying to muscle vendors into a consortium which *requires* them to provide updates for older phones. We'll see how well this happens! And this is all for future phones and Android versions, of course: current "early adopters" of Android will be stuck with the existing mess.
The correct question is: intuitive for whom? Tens of thousands of web developers around the world seem to manage okay developing layouts in HTML/XHTML (you might argue that HTML isn't XML, but I would argue it's close enough that you won't find one intuitive and the other not). Is it intuitive for them? For many it is. Would it be intuitive for my grandmother? Certainly not. Remember that creating a layout in XML doesn't actually require writing XML - the Android plugin for Eclipse enables XML layouts to be created by drag-and-drop of GUI widgets, no XML editing necessary.
Gnome and other GUI frameworks have allowed layouts to be specified in XML for a long time, and there are other frameworks like QML that allow declarative descriptions of layouts in non-XML based languages. Is it the declarative nature of the task that makes it non-intuitive for you? Or is it the use of XML, rather than another declarative language like QML? There are many programmers who find declarative GUI layouts to be preferable to programatic ones, and there are many who are familiar with XML and prefer to use it rather than learn another custom layout language.
I would argue that "familiarity with" != "intuitive". Since we're talking about Android here, can you really tell me that you are able to intuit that "fill_parent" *actually* means "match_parent" (which is why the former was replaced with the latter some time around SDK 8)? Or that an EditText needs a special declaration to make it multi-line? Remember, intuitive is by definition NOT something you already know.
That said, since the argument was about creating layouts in XML, I'm ruling out the use of drag-n-drop, since you're not actually creating the layout in XML at that point. Something is, but it isn't the developer.
And finally... yes, my biggest beef with XML is.. XML itself. It is a HORRIBLE language for humans to read or write, which explains in large part the enormous number of HTML/ XML/ SGML GUI editors.
None of your arguments have convinced me that anyone would consider XML *intuitive* - even to someone skilled in other languages (except perhaps HTML, but as you said, the two are so closely linked as to make no odds). You seem to be confusing intuitiveness with facility, and frankly I'm not convinced XML exhibits either property.
iPhone may not do heavy workload any better, but it definitely is better at not using battery significantly when idling. You can leave iPhone on (and idling) for two days easily, while all Android phones I've had would die by the end of the second day.
Ditto for iOS vs Android tablets, by the way. iPad, with a daily use of 1-2 hours, will easily last through half a week. Android tablet, not so much.
Given that I much prefer Android otherwise, I wish Google would pay more attention to this deficiency.
Google can't produce the same high quality apps on Android like it does on iOS.
Simply comparing Google Maps app side by side on iOS and Android (2.3) device is enough to disprove this statement.
Compared to creating a visual tree of widgets and wiring up event handlers for them in code? Yeah, it's pretty damn easy and intuitive.
There's a reason why all modern UI frameworks move on to some dedicated markup language rather than code for UI, and quite often it's XML. On Windows, WPF, Silverlight and Win8 Metro are all XAML-based. On OS X, most Cocoa developers use Interface Builder, which outputs XML files (though those are generally not meant to be hand-authored - but it's easy enough to do so in practice). Gtk has Glade. Qt has QML, which, while not XML-based, is still a tree markup language.
Intuitive? Ok, we'll find our mythical average man in the street, and ask them to code up an android app's UI in XML...Ok... Go!
Hmm.. less than satisfactory results.. Ok, I'll try one of the python guys here, after all perhaps the man in the street just had no frame of reference to even begin.
Nope, still not getting anything done. Ok, I'll make it easier. Find someone with no android-coding experience. You really think they'll be able to code up a UI in XML with NO reference to the docs?
Perhaps "intuitive" belongs in the same category as "inconceivable" ? And perhaps your "creating a visual tree of widgets" might need some expansion, since you could be using shutdown -p now's Useless Tool For UI Creation and we have no idea how effective that actually is at its purported task.
To put it bluntly, you have shown that *for you* creating a UI in ANY language is a breeze, because you've done it before. Once again, that does NOT make it intuitive!
If you want to nitpick on wording, fine. No-one said that it's "intuitive". GGGP (who is not me, by the way) said that it's "easier and more intuitive" - which it is. It's much easier to describe a tree structure (which is what the widget tree is) is in a markup language that is specifically geared towards describing tree structures, than it is to do so in an imperative language which has no syntactic sugar whatsoever for this.
> The official answer is stick your non-trivial object in a global hash map and pass the key in the intent.
Or subclass Application, instantiate it in the manifest, implement the code to serialize your values that need to persist IF it gets closed, and use it as a data repository for both the Activity subclasses and your background Service. From my experience, your application's (naturally) Singleton subclass of "Application" is pretty durable and long-lived if you declare & instantiate it in the manifest itself, unless the user is running some psychotic hyper-aggressive task killer (the kind that occasionally crops up at XDA, gets raved about for a few days, then gets abandoned almost as quickly by disillusioned users tired of having everything crash nonstop).
If you don't embrace canonical Model-View-Controller architecture, Android is pretty dysfunctional. If you DO embrace it, it works fine, and works more or less exactly the way canonical MVC architecture is expected to work. As others have pointed out, the biggest single problem with the Android API is its documentation and examples, many of which were written for the G1 era, and describe scenarios that have only a loose connection to modern Android reality.
As I've told others, if you're writing a networked client-server app, just forget that AsyncTask exists (it'll let you down, and cause you more long-term grief than it's worth) and just move the network communication directly into a multithreaded background service (with Application subclass as your transient backing store). Store returnvalues in the Application object, and fire off an Intent to let the Activity know something interesting happened and that it should update itself based on the new data in the Application object. It's a lot of work to get to "HelloWorld", but once you've gotten there, it makes everything several orders of magnitude easier to deal with. Kind of like Struts and Spring. In fact, if you've mastered J2EE web apps with Struts or Spring, Android's architecture actually makes a lot of sense. If you're coming from a PHP or C background, it'll seem more like the seventh level of Hell.
It's not a coincidence that people's opinions of Android tend to fall into two extremes, with very little middle ground. I can't speak for game development, but when it comes to networked client-server apps, Android pretty much forces you to go 100% MVC whether you like it or not. If you like MVC, it rocks. If you hate MVC, it sucks. And if you don't really understand MVC, you're going to find yourself thrown naked into the frigid North Atlantic to sink or swim. IMHO, the best background you can possibly have going into Android development is a few solid years of J2EE development based on Struts or Spring, with at least one Sun certification under your belt (just to make sure you really, REALLY have a solid grasp of object scope, multithreading, and object-oriented programming in general. Android really doesn't cut newbies much slack, and the entire Android API pretty much takes for granted that you've completely mastered the finer points of advanced Java. Android *really* isn't the place to learn Java as your first real programming language. You can learn enough Java to scrape by and write Android apps that kind of work, but they'll never be *good* -- let alone *great* -- until you move up to the next level of expertise.
So you've described another form of "stick it in a global" which you admit is still susceptible to the app kill\restart problem. In practice, this is not really a problem because your app can just unwind itself and start afresh and the user will be fine with that.
For reliable persistence you need to continually serialize your data which based on your detailed description you don't do either. I'll wager you don't do it because it is a cumbersome mess and are willing to pay the price of the app ocassionally not coming back in exactly the same state.
Given that you don't do it and apparently most other devs don't do it there is something wrong with the design.
Ironically, android activities were designed to allow this perfect restartability (by forcing the dev. to work like every activity is in a different memory space) and as a result are so ridiculously cumbersome to use. So cumbersome that everyone hacks around them and discards their design goals.
There is nothing wrong with MVC.
There is a huge problem with Android's architecture.
I don't understand people bitching about having to plug the phone in at night. Really? This is a hardship?
The point is that you don't know it will last til you get home at night, as for most people if you use the actual smartphone features the battery can drain at an alarming rate. I don't know what magic special battery you're using, but even so that's not an option for iPhone users.
We have a device that fits in our hand that's more advanced than the portable computers depicted on Star Trek, and we're whining about batteries that only last 15 hours?
No, we're moaning about batteries that only last 6 or 7 hours if you use it as an actual smartphone continuously accessing information.
To have a right to do a thing is not at all the same as to be right in doing it
There's no reason a type of device should magically become more relevant than the OS.
That's pretty much a gross exaggeration of battery consumption.
Not by very much. I have a Sony/Ericsson Xperia X10 Mini Pro which struggles to maintain useful charge for much more than a day with a new battery.
said that it's "easier and more intuitive" - which it is. It's much easier
.
Are you listening? My Archos 5 is still stuck permanently at 1.6. And now they're working on 4? It's getting a bit depressing.
The point is that you don't know it will last til you get home at night, as for most people if you use the actual smartphone features the battery can drain at an alarming rate.
I'd say streaming 6 hours worth of data, in addition to web browsing, etc, is fairly heavy use.
I don't know what magic special battery you're using
I told you. The extended battery made for the Bionic. It's $25 including the new back cover.
but even so that's not an option for iPhone users
I know someone will mod me troll for this, but the solution to that seems obvious. ;)
"I disagree with you" does not equal "flamebait."