Except then you'd render things like infrared remote controls and 90% of the cheap IP surveillance cameras from China unusable. Most cheap (sub-$100) wireless IP PTZ cameras either omit the IR filter, or use one that intentionally allows most near-IR (~880nM, I believe) light to pass through, and quite a bit of the adjacent spectrum as well, because the equally-cheap CMOS video sensors washed by IR interpret it as "white" (possibly with some software assistance). Ultraviolet light wouldn't fly, because it's too hard to focus and would be a lawsuit magnet. Even if it ended up being 100% safe, people are so neurotic about "UV", anyone who tried selling a UV-based solution would be sued into oblivion regardless of merit just from the sheer bulk quantity of opportunistic lawsuits.
Light has its place, but 5.8GHz is better. It has enough penetration to be useful, but not so much that you can't easily attenuate most of it away if that's what you'd prefer.
Bad example... OpenMoko was a GPRS paperweight that couldn't do 3G in the US, mainly because the mfr. (like Trolltech, with the equally-useless GreenPhone) decided to skimp on the GSM baseband chipset and use one that couldn't even do EDGE, let alone 850/1900MHz UMTS). The chip was pin-compatible, and cost something like $2 more.
2 years ago, when most of the phones that shipped with 1.5 were still stuck in the 1.5 ghetto 6 months after 2.1 came out? Hell fuckin' yeah.
18 months ago, when most of the first-gen phones sold in the US were STILL stuck with 1.5, even after the rest of the world was enjoying 2.1? Grrrr...
I can name a few big ones that emerged with 2.1, and persisted long after everyone outside the US upgraded to Froyo months earlier -- carrier/phone-agnostic 4G and front-camera support.
1.5? Gestures, multitouch, and just about everything related to bluetooth besides the use of headsets for making phone calls.
The saddest part is that 99% of the pain was totally unnecessary, and almost entirely due to carriers locking phones down, then dragging their feet with upgrades that they prevented end users from getting on their own. If you're a carrier... lead (by releasing updates fast enough to keep me from caring), follow (and officially bless Cyanogen), or get the fuck out of my way (unlock the bootloader, release hardware documentation and non-proprietary drivers with source) so I can fix my own damn phone independently of your quarter-focused shortsighted incompetence.
Part of the blame lies with Linux itself. The Linux kernel doesn't have a stable ABI, so kernel modules compiled against some specific kernel version won't necessarily work on a newer one. Since every major release of Android involves a new kernel, this means that even when the manufacturer provides the proprietary drivers as loadable kernel modules, you can't necessarily use them with the new kernel without things breaking.
I'm not 100% sure, but I think this might be part of the reason why Android seems to have officially forked its Linux kernel and gone its own way with "3.0" for ICS. by getting off the 2.6 kernel merry-go-round, Google can enforce a stable ABI (or at least force its evolution in a way that's backwards compatible with older loadable kernel modules through thunking wrappers). Previously, every time Google came out with a new kernel, they were forced to go along for the ride with the ABI changes made to 2.6 in the meantime. I suspect Linus himself might have had a role in it -- he's obviously sympathetic to the plight of Android owners (I suspect most of his friends are Android users, if not Linus himself), but can't hold back PC Linux for the sake of Android. Forking Android's kernel to 3.0 isn't ideal, but it's probably the least-bad fix that anyone can do in the short term to fix a problem that would otherwise take years to solve.
Actually, this is a perfect example of Android's benefit over IOS. If Apple decides your old iPhone won't run the new version of IOS, it's not going to run the new version of IOS. Ever. Period. End of story. And if by some chance you figure out a way to trick it into installing the new IOS onto old, unauthorized hardware, Apple can unleash their lawyers on you to make you stop.
In the case of Android, it sucks when the manufacturer abandons a phone (especially when it does it prematurely), but if the phone has an unlocked bootloader and relatively well-understood hardware (the original Droid falls into this category, and the Nexus One OFFICIALLY and EXPLICITLY falls into this category), it's almost inevitable that the latest version of Android will be running on it long before it arrives on most phones that are theoretically being SUPPORTED by the manufacturer.
The truth is, it doesn't really *matter* all that much whether or not Google officially supports ICS on the Nexus One, because it'll have ICS limping along within hours of the source getting leaked, and fully working within a month or so of its official release. Google probably looked at their data statistics, saw that 94% of Nexus One owners were unofficially rooted and reflashed to community firmware months ago, and decided that it would be a waste of time and money to even bother trying to do something that Cyanogen will have finished before they do *anyway*.
Maybe we can finally have candybar-slider type phones back. You know... the nice, sensible design whereby the touchscreen is ignored when it's closed, and activates when you slide it open (not necessarily exposing a full qwerty keyboard... there were plenty of candybar sliders sold in Europe that had real numeric keypads with send/end keys. I remember seeing one cool Asian-market phone's design that exposed a physical keypad if you slid it down, a secondary LCD with touchscreen if you rotated the phone 180 degrees and slid it the other way, and a proper gamepad with fire buttons if you put the phone in portrait mode and slid it sideways. American carriers will never voluntarily let us have a phone like that, because the sliding mechanism might add $4 to the manufacturing cost. If slide-to-unlock were legally banished from official support on new American Android phones, it might be a blessing in disguise by forcing manufacturers to let us have real hardkeys again that we can just unambiguously actuate instead of having to screw around with stupid, increasingly-complex-and-latency-inducing-to-filter-out-false-triggering gestures.
I believe the cell phone infrastructure is in place (or will be, soon), but the actual policy for determining what gets reported is still contentious. Nobody's going to argue about nuclear bombs or tornadoes (and possibly earthquakes, with the idea being that the warning itself would be moot by the time you got it, but sending a message once the earthquake is confirmed at t=1 or 2 seconds might increase the likelihood that people 10-30 miles away would be physically holding their phone in their hand when the shockwaves arrived), but beyond that there's a long, slippery slope of potential mass public annoyance.
Youtube will never happen. If you were Youtube, would YOU ever consent to being required to get all software and infrastructure updates approved by the government, with service disruptions and bureaucratic certification delays along the way? IP multicast would be far more appropriate and service-agnostic. If you care about receiving them, you'd run the client app on your PC, and enable it with a firmware update to your router.
The day Verizon allows customers to walk into a Verizon store and buy a R-UIM card that will allow them to use any physically-compatible phone on Verizon, you might have a point. However, in the real world, Verizon and Sprint dictate the phones available for use on their networks, and have more or less complete veto power (the sole real-world exception being that Verizon will grudgingly allow you to use a Sprint twin of a Verizon phone that's been reflashed to Verizon firmware, but AFAIK nobody has EVER gotten a completely alien phone (with EVDOrev.A chipset) to do EVDOrev.A on Verizon, and as of a year or so ago, if you were willing to live with slow 1xRTT to use an alien phone on Verizon, you'd still have dysfunctional voicemail and MMS.
Remember, the T-Mobile and AT&T Samsung Galaxy S II has a better CDMA chipset than Sprint's does. In theory, someone able to create his own radio firmware and access to Verizon's internal docs could forcibly reflash one to do EVDO on Verizon. The catch is, to do it legally, he'd probably have to get his phone individually certified by the FCC, because Samsung only had the GSM SGS2 officially certified for GSM and UMTS, even though the Qualcomm chipset inside is perfectly capable of CDMA.
The main problem is that 802.11A/N is totally the wrong kind of protocol for crowded environments where you have lots of individual users who need reliable and robust connectivity that doesn't necessarily have to be individually fast. 802.11N in particular was optimized for the questionable use case of making your neighbors hate you so you can avoid running cat5 between your living room and den, instead of enabling lots of adjacent users to peacefully coexist. Hand-offs are still kludgy, and it's rare to find someone who doesn't do wireless networking for a living who can literally walk from the back yard down to the basement and upstairs, then out to the front yard without having his connectivity break (and break *hard*) at some point along the trip.
What do I propose? "802.11u" (as in, "UMTS"), running on unlicensed 5.8GHz. Stick private picocells in every room, hallway, and area. Multiple ones, in large areas. Wire them together with ethernet, or optionally create a peer to peer mesh network for the backhaul (5.8GHz where good links are possible, 2.4GHz for links between floors or "difficult" walls). Then take more or less canonical UMTS, and implement it as micro cell sites in devices with the approximate form factor of a smoke detector.
The nice thing about UMTS is that it's CDMA, just like 1xRTT (and ironically, unlike EVDO). You don't have to do local spectrum planning. If an area has poor throughput, just buy and add more femtocells or picocells to the congested area, let the devices negotiate lower power levels, and watch CDMA work its magic. By linking the PicoFemto/cells together, they'll magically work the same way a real cellular network does (sharing their bitstreams, and allowing them to reinforce each other and cancel out local/directional noise).
5.8GHz private UMTS wouldn't be fast (it would probably max out around 2.5mbit/sec at the cheap end, and max out around 10 or 20mbit/sec for a high-end corporate network where cost was no object), but it would be perfect for places like college campuses, offices, etc. where you have lots of people who need mainly internet access, but no single user necessarily needs GIGANTIC amounts of individual bandwidth. In other words, the exact places that are a total clusterfuck mess today, because you have hundreds or thousands of users stomping all over each other trying to use a wireless protocol optimized for streaming HD media from a point source to a single hungry consumer.
It might even be possible to make a cheaper "home" version that ran with uplink & downlink sprayed across the entire existing 2.4GHz wifi band -- the idea being that if Qualcomm has a chip designed to do 1900 & 2150MHz uplink/downlink UMTS, extending it to add ~2.4-2.5GHz would probably just be a straightforward next-gen upgrade that would be easy to add to any Android phone (or iPhone) that already had UMTS capabilities.
I have no idea whether this could possibly be cheap enough to justify doing at home, but I suspect the costs would be fairly competitive to what businesses, colleges, and hotels spend kludging around with high-end enterprise WiFi *anyway* today.
Do you have any idea what kind of jurisdictional and logistical issues would be involved if every incident involving a crime or misdemeanor on a train had to be handled by the local authorities? Most of Amtrak's police operate on the trains themselves, and they're independent so they can go about their business without having to stop the train and disrupt the travel of everybody on it until the local authorities showed up to handle it. When somebody commits a crime on a moving train, Amtrak's police deal with it while the train keeps moving without having to worry or care about what municipality the train happens to be located in right this instant.
Could they use local police for stations? Probably. But since they have their own in-house law enforcement agency anyway, why should they pay a premium to hire off-duty local police officers at overtime pay rates when they can just hire a few more police officers of their own and pay them normally? In most places, it's actually quite difficult to get dedicated police officers earmarked for your organization's exclusive use, even when you're paying 100% of their salaries on behalf of the host municipality. If Amtrak paid the salaries of 10 Baltimore police officers, the agreement allocating two members of the BPD to their station at all times would inevitably give the BPD the right to send them out to handle some other local problem if they deemed it necessary. Ergo, it would be silly and pointless political masturbation for Amtrak to screw around with local police departments instead of just handling station police duties themselves.
> The idea that these things won't exist if the federal government doesn't give each state handouts for it is ludicrous.
OK, I'll bite. Compare the cost of building Interstate 80 through northern Nevada to its current standards to its actual importance as a road to the actual taxpayers of Nevada. I-80 through northern Nevada is very important to the economies of California and states further east, because it provides a direct route between them. I-80 does almost nothing useful for taxpaying citizens of Nevada, the overwhelming majority of whom live in Las Vegas and could easily go their entire lives without ever setting foot in the northern 2/3 of that state.
Much of I-80's value comes from the fact that it's a single, high-quality road that runs from literally the Atlantic to the Pacific (or close enough to matter) without interruption, as a high-quality freeway every inch of the way. If I-80 were a patchwork of freeway segments here and there, with miles of lower-quality roads in between, it would be substantially less useful to everyone along the way. The same can be said for some of the most expensive rural bridges in America along the same interstate highways. In most cases, the people who actually live in their immediate vicinity don't benefit from them nearly as much as people and businesses hundreds of miles away.
Before anyone brings up tolls as an alternative, keep in mind that the very fact that most interstate highways have always been free to use was itself a major factor driving explosive economic growth across much of the US during the 70s and 80s. Most toll roads worldwide that get built with 100% private funds end up being INCREDIBLY expensive to use, especially in the years immediately following their completion. Why? Because that's the point when they have the highest debt load and the lowest number of users. The ability of a government to just swallow a huge chunk of that initial debt and go from "doesn't exist" to "exists, kicks ass, and it's free to use" induces nearly immediate use and demand that would have otherwise taken years or decades to develop -- if it ever developed at all.
You're overlooking an important detail -- most of the 'education' and 'outreach' activities involve the same staff as the 'hurricane' work, and exists mainly to give them something useful to do during the rest of the year. You can't just lay them off for 5 months per year and expect to save 5/12 their current salary costs, because they'll either lose interest outright in working for the NHC, or they'll force the NHC to schedule their consulting gig around their REAL jobs (probably as college professors). Even if they only taught one semester per year, hurricanes DO exist is January, April, and May. They're rare, but they happen.
Do we really want to risk having the NHC short-staffed when an off-season hurricane that looked like a tropical storm on the satellite and radar suddenly get recognized as a real hurricane when its outer rainbands are already smacking Miami's suburbs and the eye is 18 hours from landfall? Back before we had an army of NHC employees tracking hurricanes from the moment the first drop of rain falls on the Cape Verde Islands, that's basically what used to happen... and even hurricanes that were fairly mild by "Andrew" and "Wilma" standards killed hundreds who found themselves in exposed places with no time to prepare or evacuate.
Keep in mind that Andrew in particular was a very compact, very fast-moving hurricane that -- even with people watching it like a hawk -- literally went from "category 1" to "category 4 or 5" almost overnight, and showed up on Miami's doorstep with about 2 days advance notice. Had Andrew struck with the NHC running on a skeleton staff, believing Andrew was likely to strike Florida as minor hurricane or major tropical storm up to the point somebody noticed (after most of Miami already lost power) that a 20 mile swath of Eluthera Island basically ceased to exist a few hours earlier, the death toll would have probably been in the thousands.
Does the NHC operate with 100% economic efficiency? Of course not. In the grand scheme of things, though, the potential tax savings are literally piss in the ocean compared to the economic -- let alone humanitarian -- cost of having a hurricane strike an unprepared metro area somewhere in the US with minimal advance warning.
That was mainly because touchscreen controllers historically exposed only a single X and Y location to applications, and made their own internal decisions about how to handle multiple simultaneous rows & columns. Plenty of people realized 5-10 years ago that even "simultaneous" touches would involve one finger making contact a fraction of a millisecond before the other(s), and that you could intelligently make certain rectangular assumptions by simply noting which row & column made contact first & tracking their relative state throughout the gesture IF the damn touchscreen controller allowed you to see ALL the selected rows & columns instead of just a single (usually, random) pair.
Ironically, it was a cost-cutting move that made multitouch initially possible. Atmel simplified their touchscreen controller and eliminated the logic that attempted to decide which row and column to send, and instead simply reported all of them... and did it at a sufficiently high refresh rate that a program paying close attention could figure out which x and y came first, and which x & y came second. Ergo, hacked multitouch on first-gen Android phones (and the first iPhones). New controllers added additional logic to track touch order and automate the association of coordinates with fingers, but really, multitouch was kind of like using RGB LEDs for video and picture display -- people thought of the idea LONG before some crucial hardware element needed to make it work existed commercially. Pinch-zooming? OK, maybe Apple deserves a cookie. Multitouch soft keyboards that can recognize a soft shift key located off on the corner where it won't cross a row or column with the virtual letter keys? Yawn. Endless discussions about it way back in the Samsung SPH-i300 era (the i300 was the first PalmOS phone that used the LCD as its graffiti input area and pretty much introduced soft keyboards to PDA phones).
> Take GPS based alerts. Had that idea since the first week I had my iPhone 3G. > Why did it take nearly 4 years for Apple to add the feature?
Actually, you can find old archived posts going all the way back to the first bluetooth-enabled PalmOS phones about using an external GPS paired to the phone to enable location-based alerts. I myself had a few threads around the same time about my idea of driving around with your phone and sniffing the relative strength of visible CDMA towers, then using it to build a personal database of waypoints for a similar purpose.
Apple innovated nothing besides maybe making things guys from XDA-developers.com were doing with hacked ROMs and custom extensions 5-10 years ago usable by people who couldn't tell you the difference between JPEG and pdf if you put a gun to their head and threatened to shoot if they couldn't identify at least one difference, no matter how trivial.
Part of the reason why there's so much hate between Android fans and iPhone fans is due to Steve's determination that EVERYONE, not just clueless users, should be forced to do without features that couldn't be dumbed-down and uniformly offered to everyone in exactly the same way. Android allows you to tweak your phone to individual perfection. Apple makes sure a complete stranger can pick up your phone and figure out how to make a call, even if it limits what you can do to make the phone work the way YOU want it to work. After all, your individual preferences don't matter, because Steve Jobs was omniscient, and your dissatisfaction with His Work was merely due to your lack of enlightenment and understanding.
> Why should someone from Ohio pay for California's earthquake system?
Because roughly half of America's computer-related economy depends upon California's continued existence as a going concern? Because roughly a third of the cargo destined for Ohio gets unloaded from ships in Long Beach? Because 70% of the movies, TV shows, and music enjoyed by Ohio residents comes directly from California?
Need I remind you that Ohio itself is somewhat seismically-active? How much would it cost Ohio taxpayers to staff and run a completely independent Ohio department of Earthquake Preparedness? Think of it as insurance. Ohio pays a penny per year for a dollar's worth of earthquake-related services that it usually doesn't need, but will need very badly if a once-in-2,000-year earthquake tears a gash through Cincinnati.
Ohio has even gotten smacked by a few hurricanes over the years, including Camille. It slammed ashore in Mississippi as a category 5, and apparently kept skidding over the Appalachian foothills until it rolled into Ohio as something between a weak category 1 hurricane and strong tropical storm. In any case, if New York City were wrecked by a major hurricane, I guarantee Ohio would notice pretty quickly, because most of its gas comes from refineries in New Jersey.
> 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.
As others have pointed out, with the current prices of Android tablets from China, you'd have to be insane to even think about trying to cobble together your own solution. If you really have to make it look custom, buy a crateload of $100 (retail-price) tablets, take them apart, and mount their innards in your own enclosure. I seriously doubt whether you could buy the LCDs *alone* for what you'd pay for the whole tablet, let alone the touchscreen and everything else.
Once you've got the tablet running Android, 90% of your development work is done. Decide how you want to connect it to the rest of your system-- wifi, bluetooth, or hardwired. If you go the 'hardwire' route, you have two choices:
* the headphone jack. Forget its official purpose -- with a tiny bit of added hardware ( http://www.sparkfun.com/products/10331 -- I think this is actually a commercial version of an opensource project) and some host software, it's a serial port. Get a hold of the tablet's source, reverse engineer its schematic a bit so you can figure out what GPIO pins the 3 TRRS pins (not including ground) are connected to, and it's a a bitbang-able SPI interface.
* USB. Some actually use a crossbar chip to let you connect pins from the USB port to one of the CPU's UARTs, but don't even waste your time. Just check out the open-source schematics for "IOIO" ( ready to use reference board available from http://www.sparkfun.com/products/10748 ), which will give you more i/o options than you'll know what to do with.
Actually, there might be a third option by the time you read this. TI released a chip explicitly intended for use in Android tablets with zigbee (for home automation, industrial control, etc). If you hunt around Shenzhen and/or Silicon Valley enough, chances are you'll be able to find someone who already has a series in the design pipeline, if not manufactured and ready to buy today.
The point is, you'll never get hardware cheaper than for what you can buy off the shelf cheap Chinese Android tablets, even if you don't care about 99.9% of their capabilities. In return, you'll get a nice, ready to use host OS you can use to implement whatever higher-level display protocol you want to create. You don't have to use the tablet for anything besides an intelligent LCD host. Best of all, if you interface through something relatively vendor-agnostic, like IOIO, you won't even be tied to any single source in the future (as long as you aren't planning to disassemble them and reassemble them in your own enclosures, of course... then you'd be totally dependent upon a specific tablet).
To shave 14c from the manufacturing cost, consumer benefits be damned?
The problem is that consumers aren't Samsung's customers -- AT&T, Verizon, and Sprint are. The US isn't the world, but those three specific carriers are unquestionably Samsung's three biggest customers by several orders of magnitude, so their demands drown out pretty much everyone else on earth. All THEY care about is meeting a specific price point. As far as they're concerned, if the lack of things like microSD slots, discrete two-stage camera buttons, and even camera flashes won't ultimately stop a consumer from buying the phone, they have no reason to include it, regardless of how badly actual consumers want them.
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.
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 release to the general public, like driver source from Qualcomm, and build custom CM-optimized kernels for those developers to work with). In business terms, Samsung hit the jackpot when they hired him. They get lots of goodwill from the people who'd complain the loudest, and clueless consumers will replace their phones on schedule anyway. They know they aren't losing sales, because people who aggressively run the latest and greatest Cyanogen tend to be the same people who chuck their phones and upgrade the moment their anniversary date arrives.
> 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, and you're stuck with that one specific model, regardless of what version of Android it ships with.
> It's a smartphone, not a computer.
Maybe it is to you. To most of us here on Slashdot, it's a pocket laptop with universal wireless connectivity, and is expected to behave like one.
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).
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.
^^^ 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 up, and strong authentication doesn't kick in for a couple of minutes. Put the phone on the table face down, and it kicks in within 5 seconds. Maybe keep track of the current authentication level, so a corporate app that demands neurotic authentication levels could hide its content until the user authenticates without torturing the user and making him jump through the same hoops to answer an incoming phone call. This is an area with PROFOUND opportunities for improvement.
Slashdot Mirror
Except then you'd render things like infrared remote controls and 90% of the cheap IP surveillance cameras from China unusable. Most cheap (sub-$100) wireless IP PTZ cameras either omit the IR filter, or use one that intentionally allows most near-IR (~880nM, I believe) light to pass through, and quite a bit of the adjacent spectrum as well, because the equally-cheap CMOS video sensors washed by IR interpret it as "white" (possibly with some software assistance). Ultraviolet light wouldn't fly, because it's too hard to focus and would be a lawsuit magnet. Even if it ended up being 100% safe, people are so neurotic about "UV", anyone who tried selling a UV-based solution would be sued into oblivion regardless of merit just from the sheer bulk quantity of opportunistic lawsuits.
Light has its place, but 5.8GHz is better. It has enough penetration to be useful, but not so much that you can't easily attenuate most of it away if that's what you'd prefer.
Bad example... OpenMoko was a GPRS paperweight that couldn't do 3G in the US, mainly because the mfr. (like Trolltech, with the equally-useless GreenPhone) decided to skimp on the GSM baseband chipset and use one that couldn't even do EDGE, let alone 850/1900MHz UMTS). The chip was pin-compatible, and cost something like $2 more.
2 years ago, when most of the phones that shipped with 1.5 were still stuck in the 1.5 ghetto 6 months after 2.1 came out? Hell fuckin' yeah.
18 months ago, when most of the first-gen phones sold in the US were STILL stuck with 1.5, even after the rest of the world was enjoying 2.1? Grrrr...
I can name a few big ones that emerged with 2.1, and persisted long after everyone outside the US upgraded to Froyo months earlier -- carrier/phone-agnostic 4G and front-camera support.
1.5? Gestures, multitouch, and just about everything related to bluetooth besides the use of headsets for making phone calls.
The saddest part is that 99% of the pain was totally unnecessary, and almost entirely due to carriers locking phones down, then dragging their feet with upgrades that they prevented end users from getting on their own. If you're a carrier... lead (by releasing updates fast enough to keep me from caring), follow (and officially bless Cyanogen), or get the fuck out of my way (unlock the bootloader, release hardware documentation and non-proprietary drivers with source) so I can fix my own damn phone independently of your quarter-focused shortsighted incompetence.
Part of the blame lies with Linux itself. The Linux kernel doesn't have a stable ABI, so kernel modules compiled against some specific kernel version won't necessarily work on a newer one. Since every major release of Android involves a new kernel, this means that even when the manufacturer provides the proprietary drivers as loadable kernel modules, you can't necessarily use them with the new kernel without things breaking.
I'm not 100% sure, but I think this might be part of the reason why Android seems to have officially forked its Linux kernel and gone its own way with "3.0" for ICS. by getting off the 2.6 kernel merry-go-round, Google can enforce a stable ABI (or at least force its evolution in a way that's backwards compatible with older loadable kernel modules through thunking wrappers). Previously, every time Google came out with a new kernel, they were forced to go along for the ride with the ABI changes made to 2.6 in the meantime. I suspect Linus himself might have had a role in it -- he's obviously sympathetic to the plight of Android owners (I suspect most of his friends are Android users, if not Linus himself), but can't hold back PC Linux for the sake of Android. Forking Android's kernel to 3.0 isn't ideal, but it's probably the least-bad fix that anyone can do in the short term to fix a problem that would otherwise take years to solve.
Actually, this is a perfect example of Android's benefit over IOS. If Apple decides your old iPhone won't run the new version of IOS, it's not going to run the new version of IOS. Ever. Period. End of story. And if by some chance you figure out a way to trick it into installing the new IOS onto old, unauthorized hardware, Apple can unleash their lawyers on you to make you stop.
In the case of Android, it sucks when the manufacturer abandons a phone (especially when it does it prematurely), but if the phone has an unlocked bootloader and relatively well-understood hardware (the original Droid falls into this category, and the Nexus One OFFICIALLY and EXPLICITLY falls into this category), it's almost inevitable that the latest version of Android will be running on it long before it arrives on most phones that are theoretically being SUPPORTED by the manufacturer.
The truth is, it doesn't really *matter* all that much whether or not Google officially supports ICS on the Nexus One, because it'll have ICS limping along within hours of the source getting leaked, and fully working within a month or so of its official release. Google probably looked at their data statistics, saw that 94% of Nexus One owners were unofficially rooted and reflashed to community firmware months ago, and decided that it would be a waste of time and money to even bother trying to do something that Cyanogen will have finished before they do *anyway*.
Maybe we can finally have candybar-slider type phones back. You know... the nice, sensible design whereby the touchscreen is ignored when it's closed, and activates when you slide it open (not necessarily exposing a full qwerty keyboard... there were plenty of candybar sliders sold in Europe that had real numeric keypads with send/end keys. I remember seeing one cool Asian-market phone's design that exposed a physical keypad if you slid it down, a secondary LCD with touchscreen if you rotated the phone 180 degrees and slid it the other way, and a proper gamepad with fire buttons if you put the phone in portrait mode and slid it sideways. American carriers will never voluntarily let us have a phone like that, because the sliding mechanism might add $4 to the manufacturing cost. If slide-to-unlock were legally banished from official support on new American Android phones, it might be a blessing in disguise by forcing manufacturers to let us have real hardkeys again that we can just unambiguously actuate instead of having to screw around with stupid, increasingly-complex-and-latency-inducing-to-filter-out-false-triggering gestures.
I believe the cell phone infrastructure is in place (or will be, soon), but the actual policy for determining what gets reported is still contentious. Nobody's going to argue about nuclear bombs or tornadoes (and possibly earthquakes, with the idea being that the warning itself would be moot by the time you got it, but sending a message once the earthquake is confirmed at t=1 or 2 seconds might increase the likelihood that people 10-30 miles away would be physically holding their phone in their hand when the shockwaves arrived), but beyond that there's a long, slippery slope of potential mass public annoyance.
Youtube will never happen. If you were Youtube, would YOU ever consent to being required to get all software and infrastructure updates approved by the government, with service disruptions and bureaucratic certification delays along the way? IP multicast would be far more appropriate and service-agnostic. If you care about receiving them, you'd run the client app on your PC, and enable it with a firmware update to your router.
The day Verizon allows customers to walk into a Verizon store and buy a R-UIM card that will allow them to use any physically-compatible phone on Verizon, you might have a point. However, in the real world, Verizon and Sprint dictate the phones available for use on their networks, and have more or less complete veto power (the sole real-world exception being that Verizon will grudgingly allow you to use a Sprint twin of a Verizon phone that's been reflashed to Verizon firmware, but AFAIK nobody has EVER gotten a completely alien phone (with EVDOrev.A chipset) to do EVDOrev.A on Verizon, and as of a year or so ago, if you were willing to live with slow 1xRTT to use an alien phone on Verizon, you'd still have dysfunctional voicemail and MMS.
Remember, the T-Mobile and AT&T Samsung Galaxy S II has a better CDMA chipset than Sprint's does. In theory, someone able to create his own radio firmware and access to Verizon's internal docs could forcibly reflash one to do EVDO on Verizon. The catch is, to do it legally, he'd probably have to get his phone individually certified by the FCC, because Samsung only had the GSM SGS2 officially certified for GSM and UMTS, even though the Qualcomm chipset inside is perfectly capable of CDMA.
The main problem is that 802.11A/N is totally the wrong kind of protocol for crowded environments where you have lots of individual users who need reliable and robust connectivity that doesn't necessarily have to be individually fast. 802.11N in particular was optimized for the questionable use case of making your neighbors hate you so you can avoid running cat5 between your living room and den, instead of enabling lots of adjacent users to peacefully coexist. Hand-offs are still kludgy, and it's rare to find someone who doesn't do wireless networking for a living who can literally walk from the back yard down to the basement and upstairs, then out to the front yard without having his connectivity break (and break *hard*) at some point along the trip.
What do I propose? "802.11u" (as in, "UMTS"), running on unlicensed 5.8GHz. Stick private picocells in every room, hallway, and area. Multiple ones, in large areas. Wire them together with ethernet, or optionally create a peer to peer mesh network for the backhaul (5.8GHz where good links are possible, 2.4GHz for links between floors or "difficult" walls). Then take more or less canonical UMTS, and implement it as micro cell sites in devices with the approximate form factor of a smoke detector.
The nice thing about UMTS is that it's CDMA, just like 1xRTT (and ironically, unlike EVDO). You don't have to do local spectrum planning. If an area has poor throughput, just buy and add more femtocells or picocells to the congested area, let the devices negotiate lower power levels, and watch CDMA work its magic. By linking the PicoFemto/cells together, they'll magically work the same way a real cellular network does (sharing their bitstreams, and allowing them to reinforce each other and cancel out local/directional noise).
5.8GHz private UMTS wouldn't be fast (it would probably max out around 2.5mbit/sec at the cheap end, and max out around 10 or 20mbit/sec for a high-end corporate network where cost was no object), but it would be perfect for places like college campuses, offices, etc. where you have lots of people who need mainly internet access, but no single user necessarily needs GIGANTIC amounts of individual bandwidth. In other words, the exact places that are a total clusterfuck mess today, because you have hundreds or thousands of users stomping all over each other trying to use a wireless protocol optimized for streaming HD media from a point source to a single hungry consumer.
It might even be possible to make a cheaper "home" version that ran with uplink & downlink sprayed across the entire existing 2.4GHz wifi band -- the idea being that if Qualcomm has a chip designed to do 1900 & 2150MHz uplink/downlink UMTS, extending it to add ~2.4-2.5GHz would probably just be a straightforward next-gen upgrade that would be easy to add to any Android phone (or iPhone) that already had UMTS capabilities.
I have no idea whether this could possibly be cheap enough to justify doing at home, but I suspect the costs would be fairly competitive to what businesses, colleges, and hotels spend kludging around with high-end enterprise WiFi *anyway* today.
Do you have any idea what kind of jurisdictional and logistical issues would be involved if every incident involving a crime or misdemeanor on a train had to be handled by the local authorities? Most of Amtrak's police operate on the trains themselves, and they're independent so they can go about their business without having to stop the train and disrupt the travel of everybody on it until the local authorities showed up to handle it. When somebody commits a crime on a moving train, Amtrak's police deal with it while the train keeps moving without having to worry or care about what municipality the train happens to be located in right this instant.
Could they use local police for stations? Probably. But since they have their own in-house law enforcement agency anyway, why should they pay a premium to hire off-duty local police officers at overtime pay rates when they can just hire a few more police officers of their own and pay them normally? In most places, it's actually quite difficult to get dedicated police officers earmarked for your organization's exclusive use, even when you're paying 100% of their salaries on behalf of the host municipality. If Amtrak paid the salaries of 10 Baltimore police officers, the agreement allocating two members of the BPD to their station at all times would inevitably give the BPD the right to send them out to handle some other local problem if they deemed it necessary. Ergo, it would be silly and pointless political masturbation for Amtrak to screw around with local police departments instead of just handling station police duties themselves.
> The idea that these things won't exist if the federal government doesn't give each state handouts for it is ludicrous.
OK, I'll bite. Compare the cost of building Interstate 80 through northern Nevada to its current standards to its actual importance as a road to the actual taxpayers of Nevada. I-80 through northern Nevada is very important to the economies of California and states further east, because it provides a direct route between them. I-80 does almost nothing useful for taxpaying citizens of Nevada, the overwhelming majority of whom live in Las Vegas and could easily go their entire lives without ever setting foot in the northern 2/3 of that state.
Much of I-80's value comes from the fact that it's a single, high-quality road that runs from literally the Atlantic to the Pacific (or close enough to matter) without interruption, as a high-quality freeway every inch of the way. If I-80 were a patchwork of freeway segments here and there, with miles of lower-quality roads in between, it would be substantially less useful to everyone along the way. The same can be said for some of the most expensive rural bridges in America along the same interstate highways. In most cases, the people who actually live in their immediate vicinity don't benefit from them nearly as much as people and businesses hundreds of miles away.
Before anyone brings up tolls as an alternative, keep in mind that the very fact that most interstate highways have always been free to use was itself a major factor driving explosive economic growth across much of the US during the 70s and 80s. Most toll roads worldwide that get built with 100% private funds end up being INCREDIBLY expensive to use, especially in the years immediately following their completion. Why? Because that's the point when they have the highest debt load and the lowest number of users. The ability of a government to just swallow a huge chunk of that initial debt and go from "doesn't exist" to "exists, kicks ass, and it's free to use" induces nearly immediate use and demand that would have otherwise taken years or decades to develop -- if it ever developed at all.
You're overlooking an important detail -- most of the 'education' and 'outreach' activities involve the same staff as the 'hurricane' work, and exists mainly to give them something useful to do during the rest of the year. You can't just lay them off for 5 months per year and expect to save 5/12 their current salary costs, because they'll either lose interest outright in working for the NHC, or they'll force the NHC to schedule their consulting gig around their REAL jobs (probably as college professors). Even if they only taught one semester per year, hurricanes DO exist is January, April, and May. They're rare, but they happen.
Do we really want to risk having the NHC short-staffed when an off-season hurricane that looked like a tropical storm on the satellite and radar suddenly get recognized as a real hurricane when its outer rainbands are already smacking Miami's suburbs and the eye is 18 hours from landfall? Back before we had an army of NHC employees tracking hurricanes from the moment the first drop of rain falls on the Cape Verde Islands, that's basically what used to happen... and even hurricanes that were fairly mild by "Andrew" and "Wilma" standards killed hundreds who found themselves in exposed places with no time to prepare or evacuate.
Keep in mind that Andrew in particular was a very compact, very fast-moving hurricane that -- even with people watching it like a hawk -- literally went from "category 1" to "category 4 or 5" almost overnight, and showed up on Miami's doorstep with about 2 days advance notice. Had Andrew struck with the NHC running on a skeleton staff, believing Andrew was likely to strike Florida as minor hurricane or major tropical storm up to the point somebody noticed (after most of Miami already lost power) that a 20 mile swath of Eluthera Island basically ceased to exist a few hours earlier, the death toll would have probably been in the thousands.
Does the NHC operate with 100% economic efficiency? Of course not. In the grand scheme of things, though, the potential tax savings are literally piss in the ocean compared to the economic -- let alone humanitarian -- cost of having a hurricane strike an unprepared metro area somewhere in the US with minimal advance warning.
> but no one was doing multitouch.
That was mainly because touchscreen controllers historically exposed only a single X and Y location to applications, and made their own internal decisions about how to handle multiple simultaneous rows & columns. Plenty of people realized 5-10 years ago that even "simultaneous" touches would involve one finger making contact a fraction of a millisecond before the other(s), and that you could intelligently make certain rectangular assumptions by simply noting which row & column made contact first & tracking their relative state throughout the gesture IF the damn touchscreen controller allowed you to see ALL the selected rows & columns instead of just a single (usually, random) pair.
Ironically, it was a cost-cutting move that made multitouch initially possible. Atmel simplified their touchscreen controller and eliminated the logic that attempted to decide which row and column to send, and instead simply reported all of them... and did it at a sufficiently high refresh rate that a program paying close attention could figure out which x and y came first, and which x & y came second. Ergo, hacked multitouch on first-gen Android phones (and the first iPhones). New controllers added additional logic to track touch order and automate the association of coordinates with fingers, but really, multitouch was kind of like using RGB LEDs for video and picture display -- people thought of the idea LONG before some crucial hardware element needed to make it work existed commercially. Pinch-zooming? OK, maybe Apple deserves a cookie. Multitouch soft keyboards that can recognize a soft shift key located off on the corner where it won't cross a row or column with the virtual letter keys? Yawn. Endless discussions about it way back in the Samsung SPH-i300 era (the i300 was the first PalmOS phone that used the LCD as its graffiti input area and pretty much introduced soft keyboards to PDA phones).
> Take GPS based alerts. Had that idea since the first week I had my iPhone 3G.
> Why did it take nearly 4 years for Apple to add the feature?
Actually, you can find old archived posts going all the way back to the first bluetooth-enabled PalmOS phones about using an external GPS paired to the phone to enable location-based alerts. I myself had a few threads around the same time about my idea of driving around with your phone and sniffing the relative strength of visible CDMA towers, then using it to build a personal database of waypoints for a similar purpose.
Apple innovated nothing besides maybe making things guys from XDA-developers.com were doing with hacked ROMs and custom extensions 5-10 years ago usable by people who couldn't tell you the difference between JPEG and pdf if you put a gun to their head and threatened to shoot if they couldn't identify at least one difference, no matter how trivial.
Part of the reason why there's so much hate between Android fans and iPhone fans is due to Steve's determination that EVERYONE, not just clueless users, should be forced to do without features that couldn't be dumbed-down and uniformly offered to everyone in exactly the same way. Android allows you to tweak your phone to individual perfection. Apple makes sure a complete stranger can pick up your phone and figure out how to make a call, even if it limits what you can do to make the phone work the way YOU want it to work. After all, your individual preferences don't matter, because Steve Jobs was omniscient, and your dissatisfaction with His Work was merely due to your lack of enlightenment and understanding.
> Why should someone from Ohio pay for California's earthquake system?
Because roughly half of America's computer-related economy depends upon California's continued existence as a going concern? Because roughly a third of the cargo destined for Ohio gets unloaded from ships in Long Beach? Because 70% of the movies, TV shows, and music enjoyed by Ohio residents comes directly from California?
Need I remind you that Ohio itself is somewhat seismically-active? How much would it cost Ohio taxpayers to staff and run a completely independent Ohio department of Earthquake Preparedness? Think of it as insurance. Ohio pays a penny per year for a dollar's worth of earthquake-related services that it usually doesn't need, but will need very badly if a once-in-2,000-year earthquake tears a gash through Cincinnati.
Ohio has even gotten smacked by a few hurricanes over the years, including Camille. It slammed ashore in Mississippi as a category 5, and apparently kept skidding over the Appalachian foothills until it rolled into Ohio as something between a weak category 1 hurricane and strong tropical storm. In any case, if New York City were wrecked by a major hurricane, I guarantee Ohio would notice pretty quickly, because most of its gas comes from refineries in New Jersey.
> 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.
As others have pointed out, with the current prices of Android tablets from China, you'd have to be insane to even think about trying to cobble together your own solution. If you really have to make it look custom, buy a crateload of $100 (retail-price) tablets, take them apart, and mount their innards in your own enclosure. I seriously doubt whether you could buy the LCDs *alone* for what you'd pay for the whole tablet, let alone the touchscreen and everything else.
Once you've got the tablet running Android, 90% of your development work is done. Decide how you want to connect it to the rest of your system-- wifi, bluetooth, or hardwired. If you go the 'hardwire' route, you have two choices:
* the headphone jack. Forget its official purpose -- with a tiny bit of added hardware ( http://www.sparkfun.com/products/10331 -- I think this is actually a commercial version of an opensource project) and some host software, it's a serial port. Get a hold of the tablet's source, reverse engineer its schematic a bit so you can figure out what GPIO pins the 3 TRRS pins (not including ground) are connected to, and it's a a bitbang-able SPI interface.
* USB. Some actually use a crossbar chip to let you connect pins from the USB port to one of the CPU's UARTs, but don't even waste your time. Just check out the open-source schematics for "IOIO" ( ready to use reference board available from http://www.sparkfun.com/products/10748 ), which will give you more i/o options than you'll know what to do with.
Actually, there might be a third option by the time you read this. TI released a chip explicitly intended for use in Android tablets with zigbee (for home automation, industrial control, etc). If you hunt around Shenzhen and/or Silicon Valley enough, chances are you'll be able to find someone who already has a series in the design pipeline, if not manufactured and ready to buy today.
The point is, you'll never get hardware cheaper than for what you can buy off the shelf cheap Chinese Android tablets, even if you don't care about 99.9% of their capabilities. In return, you'll get a nice, ready to use host OS you can use to implement whatever higher-level display protocol you want to create. You don't have to use the tablet for anything besides an intelligent LCD host. Best of all, if you interface through something relatively vendor-agnostic, like IOIO, you won't even be tied to any single source in the future (as long as you aren't planning to disassemble them and reassemble them in your own enclosures, of course... then you'd be totally dependent upon a specific tablet).
To shave 14c from the manufacturing cost, consumer benefits be damned?
The problem is that consumers aren't Samsung's customers -- AT&T, Verizon, and Sprint are. The US isn't the world, but those three specific carriers are unquestionably Samsung's three biggest customers by several orders of magnitude, so their demands drown out pretty much everyone else on earth. All THEY care about is meeting a specific price point. As far as they're concerned, if the lack of things like microSD slots, discrete two-stage camera buttons, and even camera flashes won't ultimately stop a consumer from buying the phone, they have no reason to include it, regardless of how badly actual consumers want them.
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.
Cool, I didn't know that. Thanks! :-)
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 release to the general public, like driver source from Qualcomm, and build custom CM-optimized kernels for those developers to work with). In business terms, Samsung hit the jackpot when they hired him. They get lots of goodwill from the people who'd complain the loudest, and clueless consumers will replace their phones on schedule anyway. They know they aren't losing sales, because people who aggressively run the latest and greatest Cyanogen tend to be the same people who chuck their phones and upgrade the moment their anniversary date arrives.
> 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, and you're stuck with that one specific model, regardless of what version of Android it ships with.
> It's a smartphone, not a computer.
Maybe it is to you. To most of us here on Slashdot, it's a pocket laptop with universal wireless connectivity, and is expected to behave like one.
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).
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.
^^^ 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 up, and strong authentication doesn't kick in for a couple of minutes. Put the phone on the table face down, and it kicks in within 5 seconds. Maybe keep track of the current authentication level, so a corporate app that demands neurotic authentication levels could hide its content until the user authenticates without torturing the user and making him jump through the same hoops to answer an incoming phone call. This is an area with PROFOUND opportunities for improvement.