I agree that the iPod being successful contributes to the Apple dock connector being successful, but I don't think that is the only reason.
For example, we all know what the Sandisk Sansa series, the Microsoft Zune series, and the Creative Zen series are. They each have their own dock connector as well. They are that 5%. Yet companies do make accessories using their connectors. It's more than just two. There are speaker docks, there's desktop docks. Even high profile Apple accessory manufacturers like Griffin offer accessories customized for the Sansa and Zunes too. It's just that most of us don't consider that a success because there's simply so many more Apple accessories. If Apple wasn't in the picture, I'd consider this a success. And if we factor in Apple, then despite their tiny marketshare, I'd consider this pretty successful since there is external support for these manufacturers.
But yeah, that's not the complete picture either. I know the Sansa has a certification program as well. I can only assume that MS/Zune would too. The Sansa and the Zen use the same connector, but incompatible pinouts. Had they banded together on this, it would have worked out even better.
You're right that the dock connector can be an anti-feature. Buying accessories tied to a connector is an investment. You have to have confidence that you investment in accessories will continue to be there when you upgrade to the next model up. So if the manufacturer continues to support the same dock connector, they will in time encourage their customers to remain their customers by investment, and that the customers who have enjoyed their products in the past will continue to invest in their accessories as long as they enjoy the products in the future. An increase in commitment gives 3rd parties the confidence that making an accessory for the ecosystem is profitable as well, and then further contributes to its establishment. It's not the same kind of lock in that we as programmers complain about, since accessories wear out. If a company makes a music player series and eventually starts putting out awful designs, they will lose their customers regardless of the lock in because disuse of the device doesn't hurt the user as much as it hurts the company. They're gadgets, it's not a vital part of the customer's life, but it's vital to the company. The company has a vested interest in making their customers happy because they need them to ensure other companies will support them.
Outside of the mp3 player space, there are a number of proprietary or defacto standardized cables. It's less noticable if you don't buy tons of stuff or get exposure to a ton of devices. But the mechanics are the same. My Fuji F31fd digital camera uses a weird USB/AV connector... it's not an open standard as far as I know. But it just so happens to be compatible with Minolta, Nikon, Pentax, Vivitar, Panasonic, Olympus, a few Sonys, and a couple of Samsung devices as well. See here: http://www.digitalpowerpro.com/catalog/avusb-cable-nikon-coolpix-s6000-s3000-l110-p100-s8000-s5100-s4000-p-564.html
Buying that cable, to me, makes a lot of sense despite it being proprietary, since it's supported by a reasonably large number of cameras. Sure, a $20 usb cable is expensive, but at the same time, if I don't need it anymore, it wouldn't be hard to ebay it off or find a friend who'd get a use out of it either.
Finally, one last example is Japanese cell phones. Having a controlling authority who dictates the use of a docking connector is best exemplified by the cell phone carriers in Japan. If you go into a convenience store or electronics shop, and look for a power adapter, or external battery supply, or a non-bluetooth headset, or even video/audio connectors, you'll find that the most important thing to know is who your carrier is and what is it that you want to do. Why? Because the carriers have managed to wrest
Android didn't start out as the phone you see now. In fact, the early SDK resulted in something that looked like a Blackberry/WinMo clone. Quickly after iPhone, Android was being redesigned to mimic the iPhone. Having Google execs cancel the Kogan Agora sealed the fate of the old form factor.
Manufacturers only started jumping on the Android bandwagon after seeing the iPhone's success, their own smartphone failures, and that Google bought Android to provide them a platform.
We'll never find out what would have happened without the iPhone, but I'm not sure that Android would have gained manufacturer support had Google not bought it. And I'm not sure Google would have bought it on their own.
Except it hasn't. When you see a 1/8" TRS jack, it's an audio output of some sort, but you have no guarantees whether it's amplified or line-level. This in important since feeding an amped signal into another amp can easily cause clipping.
Bluetooth isn't easy to implement either, and requires a lot more hardware in order to do simple things. A wireless remote is not what everybody wants. Nor do they all want to experience the lag that bluetooth normally introduces when you're using a mobile device to feed into some audio systems.
A standard connector that includes power, audio, usb, and video isn't enough. There has to be some way of negotiating what's available on both sides of the connection. And yes, dozens of proprietary standards is not good. It'd be great if somebody took the time to make a well-designed standard mobile docking connector, but from the looks of it, it's not going to be as simple as somebody's slashdot post.
Apple's dock connector is an example of the best solution so far. Not perfect, but obviously the most successful. An entire ecosystem with rules that dictate how to interact between an unknown device and another unknown device using one connector. It has issues. And the latest devices do have DRM. But the result of having to abide by one central authority has resulted in many devices and accessories maintaining compatibility over longer periods of time. I'm fairly certain that the DRM resulted from the need to require standardized access for APIs and preserving expandability. (a free for all to the serial port would most likely result in some sort of protocol collision, and also remove the ability to automatically search and load applications that understand how to talk to the device)
(Yes, I did want to make hardware accessories for an iPhone. Yes, the auth requirement does annoy me. No, I didn't end up developing a device nor signing up for NDA and whatever in order to do so. But I totally understand why it is the way it is.)
As a person who recently joined a group working on both an iPad and iPhone app, I can say from experience that it's a quality control issues are real already with a fixed configuration. Moving the apps from two separate apps to a universal app (one app that switches based on form factor) would require us to rebuild the app once again despite half the app using the exactly same code already. The problem is that UI code isn't an insignificant amount, and some of it just doesn't make sense on one form factor versus the other. Making a single app that switches between the two would be doable, but significantly harder.
The problem with having the manufacturers and carriers sell Nexus-style (stock Android and unlocked bootloader) phones is that neither the manufacturers nor the carriers benefit from converting a chunk. They have no motivation to do so because they can't differentiate their offerings aside from hardware, and making more hardware models is expensive. If Google forced the manufacturers to all make some sort of Nexus-style device, I'd easily see many of them unhappy and considering leaving, especially since the diversity they provide is the only reason the Android platform is doing as well as it is. The vast majority of Android users wouldn't understand why they'd buy it either. Installing somebody else's homemade OS? To the common user, "home made" versus "provided by Google" are equivalent to "shoddy" versus "backed by the company with tons of money and (hopefully) trustworthy." Given the problems with the Market and malware, I doubt many of them would be keen on installing a third party ROM especially when people are now worried of third party software containing malware. I bought a Nexus S for dev. Even I don't want to install a third party ROM (well, partly since even Cyanogen doesn't support the Nexus S). I feel that I have to keep the stock ROM because it's closest to a common user's Android setup.
The sideloading, screen size, and Google Navigation reasons are fine with me. I was just thinking that official support for phones on the Android platform has been lackluster lately. Even Cyanogen is dropping support for the G1 and Ion. For me, it's starting to sound like I should look into the WP7 platform in more detail now.
Problem is micro USB can't be used for as much stuff as the iDevice Dock Connector.
The Dock Connector is better than what Nokia/Samsung/etc have done because for the most part, it's remained the same connector for a freakin long time. Yes, there have been devices where support has gotten dropped, probably due to having to own up to past decisions not being viable in the future. But for the most part, most accessories work. The additional serial and video lines are useful.
Others are converging on microUSB, but it's not going to give you the ability to link in a standard line-out, audio remote, or video out. And everybody puts it in a different location. And the phone sizes are different, so there's no chance of an ecosystem of compatible docking stations.
In theory, yes, there's a continuous gradient from 3" phone to 12" tablet. And sure, you could scale a UI from one end to the other. But the fact is, somewhere in between the two physical sizes, people start interacting with it differently. It's not a set point either. It depends on the person.
Why this matters is that once you get to a certain size, it doesn't make sense to directly scale the UI up from where it is anymore. Take for example, a dictionary app. When you draw it on a phone, it's a simple table with entries. If you scaled that up to a 7" screen, you'll either have silly amounts of white space and tiny text, or huge text that fills it proportionately as it did on the phone, but largely useless. This is bad. It's a waste of space, and it's simply a bad user experience.
If left up to developers to decide where and when to take the leap to the larger screen, it'd be chaos. Every developer will think, "well, it works for me, so it must work for everybody" and even the fact that you're asking this question proves that we're going all going to have differing opinions. The result would be that anywhere in the no-mans-land between 3" and 12", we'd end up with apps that behave like a phone on a 5" screen but a tablet on a 5.5" screen. Or maybe somebody crosses the line at 4". Or 6.78". The end result is that people who disagree, will stare and think "wtf? I thought I bought a tablet? why is this app look like a badly scaled phone?" or vice versa.
Apple took the solution of providing 2 physical screen sizes. This way, it's easy to target. It's large or it's compact. (it's not by resolution, it's by form factor)
Android took the solution of providing a different platform, and therefore declaring the device to be a tablet instead of a phone. (it's called a tablet, therefore it is a tablet)
Google's pushed for Nexus phones in the past, but people don't seem to want to buy them. Having more won't help, it's simply that Google is bad at selling phones. And it makes no sense for Google to become a retailer or carrier.
By the way, if your primary reason for leaving iOS for Android is because Apple screwed you over your iPhone 3G, you're going to the wrong platform. The equivalent phone, the Google Ion/ADP2, got abandoned around Android 2.0, in 2009, less than a year after launch. I suggest you find a different reason to switch.
Hmmm.... now i wonder, if apple gets to count the apple provided and or sponsored apps at launch time, why dont we do the same for google? Obviously, outside apps wont be ready as fast as the google apps. Also, correct me if i am wrong, but isnt honeycomb still in the final stages before official release, and most manufacturers are able to get it onto devices only because the development is happening out in the open?
1) Honeycomb has already been released, binary only. Get a Xoom. 2) Apple-provided apps for the iPad on launch? 3. Pages, Numbers, and Keynote. 3) Apple-sponsored apps for iPad on launch? Dunno. Most apps were developed quickly by independent developers as soon as the SDK was available, which was before the iPad itself was available. A few game developers might have contacted Apple for some assistance, but none that I know were actually sponsored.
Not an arbitrary artificial restriction. It's because not all versions of Amazon Cloud Player support those formats, as in doesn't include codecs for them.
Say, if you uploaded music as FLAC and it plays on your desktop, but not your Android phone, then you might be kinda pissed. You'd also be kinda pissed that your data plan ran your bank account out of funds for streaming FLAC, but that's a different problem.
Actually, it does kinda justify it. Because for every user who understands completely, many more won't really get it. Having a "don't show again" button would be much better for you and I, but maybe they decided it wasn't worth the time to implement. Or maybe they think that the common user would click it and not actually read the "hey, it's untested" message.
Some management guy probably decided this would help PR and/or support with handling problems with users who are not technical. For the non-techie, who's been handed an unsupported browser on an unsupported platform, it helps to remind them that any problems they experience can be fixed by using something that Yahoo has tested.
Keep in mind, you're taking their message as questioning your choice of OS. (and granted, I haven't read said message because I don't use said service) I expect them to simply state that you're running on an unsupported configuration, and that unexpected behavior might occur. It's the fine line between, "We didn't test it on your config" versus "We think your config sucks."
Now I kinda wonder what happens if I pull an old Mac LC475 out of the garage and try out Netscape 3...
Wow, a comment from a Linux fanboy who's prayers for an anti-not-Linux article has been heard.:P
You know why most people are giving him a hard time? Cuz he's a moron. We don't care if he's complaining about a Mac. Or about Windows. It doesn't matter.
What matters is that he has a laptop which has no problem installing and running Linux, which he obviously wants, AND DECIDES TO FUCKING WHINE INSTEAD OF INSTALLING LINUX.
Seriously? You want emacs? You already have emacs! Go to Terminal.app... it's a terminal. Got it? Now type "emacs". See? Happy now? No? That's okay. You want Linux? Then why haven't you installed it yet? Are you too cheap to buy a blank CDR to burn insert-favorite-distro-here? And instead you want to buy a Lenovo laptop?
Have you seen the cheap iPod knockoffs? They're running some sort of ARM processor with a UI prototyping layer already. Tack on a GSM modem or CDMA modem, and with some UI work, they can easily make dirt cheap phones easily.
If you don't believe that, then how about all those cheap touch screen iPhone/Android knockoffs? Yes, Android knockoffs. One more time, Android. Knockoff.
The Chinese can whip up a feature phone in any shape or size, even going as far as making a completely fake Android UI clone. Even when the fandroids think the Chinese should go and just use Android cuz it's open source and all that jazz, the Chinese know better. It's cheaper to fake the Android UI then to upgrade the processor by 10x clock speed and add 16x the SDRAM.
Look, if he thinks Android sucks balls AND can make it better, why complain? It's not like being an employee means you have to tow the company line.
Besides, the Castle and Moat scenario basically said to me that Google cares more about making money off me by selling my eyeballs than it does making a product that's well polished. It's the "we're done when it's good enough" condition that resulted in Windows being the primary computing OS.
The point I was making was that if the page is written properly it DOES NOT HAVE to be tested for any OS rendering about 80% of your argument moot.
Huh? If the page was written properly (and i'm not saying yahoo is or is not), and compliant to every open standard, it still does not mean you've tested it on every OS distribution.
From a corporate standpoint, you cannot and should not say some platform is supported, when you've not tested it. You can say "should probably work", but you shouldn't say "is supported" because your ass is on the line when somebody finds out something obscure that you never thought about doesn't work.
Cuz to imagine having the world end in a disaster in 2012 sounds interesting and entertaining, but having to imagine that people actually like Android tablets is more sad than anything else.
The problem with UMA is that it needs handset-side support. Was Google going to implement UMA for the G1? Probably not. Likewise, all those other phones which didn't have it.
Just because the primary radio chip supports the frequency doesn't complete the whole story, as there are additional pieces of hardware necessary in most chipsets.
Something I'm curious about is the extent of the difference between the privileges given to MobileSafari compared to the normal iOS 3rd party apps. We know they're different, but by how much?
I have a feeling that jailbreakme.com might not have worked from a UIWebView in a 3rd party app. But nobody ever bothered to try it since it's easier to use MobileSafari.
In 2003, I was in a class where 30 students attempted to use IR transceivers to send an ID and an answer. The system worked like shit for the reason spazmania said above in #3:
If a moderate number of students attempt to press the buttons on their remote, they all collide and attempt to transmit again. If a fewer number of students are sitting too far back in the room, they're unable to get a reliable signal to the receiver.
The solution rigged up helped a bit, but keep in mind, it barely worked for 30 students. Basically, we had 4 receivers all wired to the same computer. Students were to try each reciever in the room in order until their ID showed up on the projector screen and then stop. This way, eventually answers get in and then those students filter themselves out of the noise.
All of this was using an actual commercial IR voting product. How crappy. We each had to pay $20 for our voting clickers; I still have mine.
In iOS, apps are sandboxed by the kernel. Look up "seatbelt." The kernel is fed a permissions document which dictates what the app is allowed to do.
Basically, MobileSafari gets special privileges which other apps arn't given. Attempts to use the Nitro engine result in success in MobileSafari. Attempts to use the Nitro engine in other iOS apps is likely to just fail or get auto-killed by the kernel. (not sure which one)
Haha, I feel like perhaps we should call it Apache/Android to piss RMS off since nothing that interesting in Android is licensed GNU. (seriously, if it were based off FreeBSD instead of Linux, would any of its users actually give a damn?)
I dunno, I was just using Eclipse and found that it still feels weird to me. Not that Visual Studio is perfect. Nor Xcode. They all have their own little quirks, but for starters, I just don't like the workspace model that Eclipse uses. I'm used to the project folder model that pretty much every other IDE since the beginning of my career has used. It makes sense that my project world is contained in a folder/document that moves like any other documents I carry around in other apps.
Compiling basic Android sample code even takes much longer than I expect. And the plugin model, while flexible, doesn't add in the features in a way that feels comprehensive. In short, I feel usability is poor.
There's industry standards for tag/card communication like Mifare. But there's nothing to use it with. In fact, only recently Google released the ability to write to some NFC cards. This ability was not there on launch of the Nexus S/
Now that you have the lower layers set up, there's no standard on top of it which to use for anything that a common user would want.
Think about it this way, if NFC were networking technology, then it's as if FeliCa was AUI, Mifare was Token Ring, ISO 18000-3 is 10BaseT and nobody invented an equivalent to UDP, TCPIP, IPX, AppleTalk, nor ArcNet yet.
The summary of Google's lead is this: "We're selling a phone which could talk with cards if somebody would actually declare an application level protocol, implement it, and deploy it. Otherwise, it's a fun toy."
Slashdot Mirror
I agree that the iPod being successful contributes to the Apple dock connector being successful, but I don't think that is the only reason.
For example, we all know what the Sandisk Sansa series, the Microsoft Zune series, and the Creative Zen series are. They each have their own dock connector as well. They are that 5%. Yet companies do make accessories using their connectors. It's more than just two. There are speaker docks, there's desktop docks. Even high profile Apple accessory manufacturers like Griffin offer accessories customized for the Sansa and Zunes too. It's just that most of us don't consider that a success because there's simply so many more Apple accessories. If Apple wasn't in the picture, I'd consider this a success. And if we factor in Apple, then despite their tiny marketshare, I'd consider this pretty successful since there is external support for these manufacturers.
But yeah, that's not the complete picture either. I know the Sansa has a certification program as well. I can only assume that MS/Zune would too. The Sansa and the Zen use the same connector, but incompatible pinouts. Had they banded together on this, it would have worked out even better.
You're right that the dock connector can be an anti-feature. Buying accessories tied to a connector is an investment. You have to have confidence that you investment in accessories will continue to be there when you upgrade to the next model up. So if the manufacturer continues to support the same dock connector, they will in time encourage their customers to remain their customers by investment, and that the customers who have enjoyed their products in the past will continue to invest in their accessories as long as they enjoy the products in the future. An increase in commitment gives 3rd parties the confidence that making an accessory for the ecosystem is profitable as well, and then further contributes to its establishment.
It's not the same kind of lock in that we as programmers complain about, since accessories wear out. If a company makes a music player series and eventually starts putting out awful designs, they will lose their customers regardless of the lock in because disuse of the device doesn't hurt the user as much as it hurts the company. They're gadgets, it's not a vital part of the customer's life, but it's vital to the company. The company has a vested interest in making their customers happy because they need them to ensure other companies will support them.
Outside of the mp3 player space, there are a number of proprietary or defacto standardized cables. It's less noticable if you don't buy tons of stuff or get exposure to a ton of devices. But the mechanics are the same.
My Fuji F31fd digital camera uses a weird USB/AV connector... it's not an open standard as far as I know. But it just so happens to be compatible with Minolta, Nikon, Pentax, Vivitar, Panasonic, Olympus, a few Sonys, and a couple of Samsung devices as well.
See here: http://www.digitalpowerpro.com/catalog/avusb-cable-nikon-coolpix-s6000-s3000-l110-p100-s8000-s5100-s4000-p-564.html
Buying that cable, to me, makes a lot of sense despite it being proprietary, since it's supported by a reasonably large number of cameras. Sure, a $20 usb cable is expensive, but at the same time, if I don't need it anymore, it wouldn't be hard to ebay it off or find a friend who'd get a use out of it either.
Finally, one last example is Japanese cell phones. Having a controlling authority who dictates the use of a docking connector is best exemplified by the cell phone carriers in Japan. If you go into a convenience store or electronics shop, and look for a power adapter, or external battery supply, or a non-bluetooth headset, or even video/audio connectors, you'll find that the most important thing to know is who your carrier is and what is it that you want to do. Why? Because the carriers have managed to wrest
Android didn't start out as the phone you see now. In fact, the early SDK resulted in something that looked like a Blackberry/WinMo clone. Quickly after iPhone, Android was being redesigned to mimic the iPhone. Having Google execs cancel the Kogan Agora sealed the fate of the old form factor.
Manufacturers only started jumping on the Android bandwagon after seeing the iPhone's success, their own smartphone failures, and that Google bought Android to provide them a platform.
We'll never find out what would have happened without the iPhone, but I'm not sure that Android would have gained manufacturer support had Google not bought it. And I'm not sure Google would have bought it on their own.
Except it hasn't. When you see a 1/8" TRS jack, it's an audio output of some sort, but you have no guarantees whether it's amplified or line-level. This in important since feeding an amped signal into another amp can easily cause clipping.
Bluetooth isn't easy to implement either, and requires a lot more hardware in order to do simple things. A wireless remote is not what everybody wants. Nor do they all want to experience the lag that bluetooth normally introduces when you're using a mobile device to feed into some audio systems.
A standard connector that includes power, audio, usb, and video isn't enough. There has to be some way of negotiating what's available on both sides of the connection. And yes, dozens of proprietary standards is not good. It'd be great if somebody took the time to make a well-designed standard mobile docking connector, but from the looks of it, it's not going to be as simple as somebody's slashdot post.
Apple's dock connector is an example of the best solution so far. Not perfect, but obviously the most successful.
An entire ecosystem with rules that dictate how to interact between an unknown device and another unknown device using one connector. It has issues. And the latest devices do have DRM. But the result of having to abide by one central authority has resulted in many devices and accessories maintaining compatibility over longer periods of time. I'm fairly certain that the DRM resulted from the need to require standardized access for APIs and preserving expandability. (a free for all to the serial port would most likely result in some sort of protocol collision, and also remove the ability to automatically search and load applications that understand how to talk to the device)
(Yes, I did want to make hardware accessories for an iPhone. Yes, the auth requirement does annoy me. No, I didn't end up developing a device nor signing up for NDA and whatever in order to do so. But I totally understand why it is the way it is.)
As a person who recently joined a group working on both an iPad and iPhone app, I can say from experience that it's a quality control issues are real already with a fixed configuration. Moving the apps from two separate apps to a universal app (one app that switches based on form factor) would require us to rebuild the app once again despite half the app using the exactly same code already. The problem is that UI code isn't an insignificant amount, and some of it just doesn't make sense on one form factor versus the other. Making a single app that switches between the two would be doable, but significantly harder.
The problem with having the manufacturers and carriers sell Nexus-style (stock Android and unlocked bootloader) phones is that neither the manufacturers nor the carriers benefit from converting a chunk. They have no motivation to do so because they can't differentiate their offerings aside from hardware, and making more hardware models is expensive. If Google forced the manufacturers to all make some sort of Nexus-style device, I'd easily see many of them unhappy and considering leaving, especially since the diversity they provide is the only reason the Android platform is doing as well as it is.
The vast majority of Android users wouldn't understand why they'd buy it either. Installing somebody else's homemade OS? To the common user, "home made" versus "provided by Google" are equivalent to "shoddy" versus "backed by the company with tons of money and (hopefully) trustworthy." Given the problems with the Market and malware, I doubt many of them would be keen on installing a third party ROM especially when people are now worried of third party software containing malware.
I bought a Nexus S for dev. Even I don't want to install a third party ROM (well, partly since even Cyanogen doesn't support the Nexus S). I feel that I have to keep the stock ROM because it's closest to a common user's Android setup.
The sideloading, screen size, and Google Navigation reasons are fine with me. I was just thinking that official support for phones on the Android platform has been lackluster lately. Even Cyanogen is dropping support for the G1 and Ion. For me, it's starting to sound like I should look into the WP7 platform in more detail now.
Problem is micro USB can't be used for as much stuff as the iDevice Dock Connector.
The Dock Connector is better than what Nokia/Samsung/etc have done because for the most part, it's remained the same connector for a freakin long time.
Yes, there have been devices where support has gotten dropped, probably due to having to own up to past decisions not being viable in the future. But for the most part, most accessories work. The additional serial and video lines are useful.
Others are converging on microUSB, but it's not going to give you the ability to link in a standard line-out, audio remote, or video out. And everybody puts it in a different location. And the phone sizes are different, so there's no chance of an ecosystem of compatible docking stations.
In theory, yes, there's a continuous gradient from 3" phone to 12" tablet. And sure, you could scale a UI from one end to the other. But the fact is, somewhere in between the two physical sizes, people start interacting with it differently. It's not a set point either. It depends on the person.
Why this matters is that once you get to a certain size, it doesn't make sense to directly scale the UI up from where it is anymore. Take for example, a dictionary app. When you draw it on a phone, it's a simple table with entries. If you scaled that up to a 7" screen, you'll either have silly amounts of white space and tiny text, or huge text that fills it proportionately as it did on the phone, but largely useless. This is bad. It's a waste of space, and it's simply a bad user experience.
If left up to developers to decide where and when to take the leap to the larger screen, it'd be chaos. Every developer will think, "well, it works for me, so it must work for everybody" and even the fact that you're asking this question proves that we're going all going to have differing opinions. The result would be that anywhere in the no-mans-land between 3" and 12", we'd end up with apps that behave like a phone on a 5" screen but a tablet on a 5.5" screen. Or maybe somebody crosses the line at 4". Or 6.78". The end result is that people who disagree, will stare and think "wtf? I thought I bought a tablet? why is this app look like a badly scaled phone?" or vice versa.
Apple took the solution of providing 2 physical screen sizes. This way, it's easy to target. It's large or it's compact. (it's not by resolution, it's by form factor)
Android took the solution of providing a different platform, and therefore declaring the device to be a tablet instead of a phone. (it's called a tablet, therefore it is a tablet)
Google's pushed for Nexus phones in the past, but people don't seem to want to buy them. Having more won't help, it's simply that Google is bad at selling phones. And it makes no sense for Google to become a retailer or carrier.
By the way, if your primary reason for leaving iOS for Android is because Apple screwed you over your iPhone 3G, you're going to the wrong platform. The equivalent phone, the Google Ion/ADP2, got abandoned around Android 2.0, in 2009, less than a year after launch.
I suggest you find a different reason to switch.
Hmmm.... now i wonder, if apple gets to count the apple provided and or sponsored apps at launch time, why dont we do the same for google? Obviously, outside apps wont be ready as fast as the google apps. Also, correct me if i am wrong, but isnt honeycomb still in the final stages before official release, and most manufacturers are able to get it onto devices only because the development is happening out in the open?
1) Honeycomb has already been released, binary only. Get a Xoom.
2) Apple-provided apps for the iPad on launch? 3. Pages, Numbers, and Keynote.
3) Apple-sponsored apps for iPad on launch? Dunno. Most apps were developed quickly by independent developers as soon as the SDK was available, which was before the iPad itself was available. A few game developers might have contacted Apple for some assistance, but none that I know were actually sponsored.
The outlook for Honeycomb looks pretty bad.
Name some. I have both phones now and Romeozulu seems so much more correct.
TOY-level (iPad / Android) tablets are a fad.
LAPTOP-REPLACEMENT-level ($1200 / 4+GB ram / 2.5+ghz proc) tablets that run full OSs (Windows / OS X / Linux / etc) are the future.
I think Microsoft's past products have already proved that you've got it backwards.
Not an arbitrary artificial restriction. It's because not all versions of Amazon Cloud Player support those formats, as in doesn't include codecs for them.
Say, if you uploaded music as FLAC and it plays on your desktop, but not your Android phone, then you might be kinda pissed. You'd also be kinda pissed that your data plan ran your bank account out of funds for streaming FLAC, but that's a different problem.
Actually, it does kinda justify it. Because for every user who understands completely, many more won't really get it. Having a "don't show again" button would be much better for you and I, but maybe they decided it wasn't worth the time to implement. Or maybe they think that the common user would click it and not actually read the "hey, it's untested" message.
Some management guy probably decided this would help PR and/or support with handling problems with users who are not technical. For the non-techie, who's been handed an unsupported browser on an unsupported platform, it helps to remind them that any problems they experience can be fixed by using something that Yahoo has tested.
Keep in mind, you're taking their message as questioning your choice of OS. (and granted, I haven't read said message because I don't use said service) I expect them to simply state that you're running on an unsupported configuration, and that unexpected behavior might occur. It's the fine line between, "We didn't test it on your config" versus "We think your config sucks."
Now I kinda wonder what happens if I pull an old Mac LC475 out of the garage and try out Netscape 3...
Wow, a comment from a Linux fanboy who's prayers for an anti-not-Linux article has been heard. :P
You know why most people are giving him a hard time? Cuz he's a moron. We don't care if he's complaining about a Mac. Or about Windows. It doesn't matter.
What matters is that he has a laptop which has no problem installing and running Linux, which he obviously wants, AND DECIDES TO FUCKING WHINE INSTEAD OF INSTALLING LINUX.
Seriously? You want emacs? You already have emacs! Go to Terminal.app... it's a terminal. Got it? Now type "emacs". See? Happy now? No?
That's okay. You want Linux? Then why haven't you installed it yet? Are you too cheap to buy a blank CDR to burn insert-favorite-distro-here? And instead you want to buy a Lenovo laptop?
(And I kinda like Gentoo, dumbass.)
Have you seen the cheap iPod knockoffs? They're running some sort of ARM processor with a UI prototyping layer already.
Tack on a GSM modem or CDMA modem, and with some UI work, they can easily make dirt cheap phones easily.
If you don't believe that, then how about all those cheap touch screen iPhone/Android knockoffs? Yes, Android knockoffs.
One more time, Android. Knockoff.
The Chinese can whip up a feature phone in any shape or size, even going as far as making a completely fake Android UI clone.
Even when the fandroids think the Chinese should go and just use Android cuz it's open source and all that jazz, the Chinese know better. It's cheaper to fake the Android UI then to upgrade the processor by 10x clock speed and add 16x the SDRAM.
And this is a problem because?
Look, if he thinks Android sucks balls AND can make it better, why complain?
It's not like being an employee means you have to tow the company line.
Besides, the Castle and Moat scenario basically said to me that Google cares more about making money off me by selling my eyeballs than it does making a product that's well polished. It's the "we're done when it's good enough" condition that resulted in Windows being the primary computing OS.
The point I was making was that if the page is written properly it DOES NOT HAVE to be tested for any OS rendering about 80% of your argument moot.
Huh? If the page was written properly (and i'm not saying yahoo is or is not), and compliant to every open standard, it still does not mean you've tested it on every OS distribution.
From a corporate standpoint, you cannot and should not say some platform is supported, when you've not tested it. You can say "should probably work", but you shouldn't say "is supported" because your ass is on the line when somebody finds out something obscure that you never thought about doesn't work.
Cuz to imagine having the world end in a disaster in 2012 sounds interesting and entertaining, but having to imagine that people actually like Android tablets is more sad than anything else.
The problem with UMA is that it needs handset-side support. Was Google going to implement UMA for the G1? Probably not.
Likewise, all those other phones which didn't have it.
If all your phones use excess data that's completely out of the ordinary for a properly designed app, it's effectively DDOSing the network.
http://gizmodo.com/#!5668601/how-an-android-app-brought-down-t+mobile-for-an-entire-city
Nope. That's just wrong.
Phones need support chips to handle a frequency.
Just because the primary radio chip supports the frequency doesn't complete the whole story, as there are additional pieces of hardware necessary in most chipsets.
Something I'm curious about is the extent of the difference between the privileges given to MobileSafari compared to the normal iOS 3rd party apps. We know they're different, but by how much?
I have a feeling that jailbreakme.com might not have worked from a UIWebView in a 3rd party app. But nobody ever bothered to try it since it's easier to use MobileSafari.
In 2003, I was in a class where 30 students attempted to use IR transceivers to send an ID and an answer.
The system worked like shit for the reason spazmania said above in #3:
If a moderate number of students attempt to press the buttons on their remote, they all collide and attempt to transmit again.
If a fewer number of students are sitting too far back in the room, they're unable to get a reliable signal to the receiver.
The solution rigged up helped a bit, but keep in mind, it barely worked for 30 students. Basically, we had 4 receivers all wired to the same computer. Students were to try each reciever in the room in order until their ID showed up on the projector screen and then stop. This way, eventually answers get in and then those students filter themselves out of the noise.
All of this was using an actual commercial IR voting product. How crappy. We each had to pay $20 for our voting clickers; I still have mine.
In iOS, apps are sandboxed by the kernel. Look up "seatbelt."
The kernel is fed a permissions document which dictates what the app is allowed to do.
Basically, MobileSafari gets special privileges which other apps arn't given.
Attempts to use the Nitro engine result in success in MobileSafari.
Attempts to use the Nitro engine in other iOS apps is likely to just fail or get auto-killed by the kernel. (not sure which one)
Haha, I feel like perhaps we should call it Apache/Android to piss RMS off since nothing that interesting in Android is licensed GNU. (seriously, if it were based off FreeBSD instead of Linux, would any of its users actually give a damn?)
I dunno, I was just using Eclipse and found that it still feels weird to me. Not that Visual Studio is perfect. Nor Xcode.
They all have their own little quirks, but for starters, I just don't like the workspace model that Eclipse uses. I'm used to the project folder model that pretty much every other IDE since the beginning of my career has used. It makes sense that my project world is contained in a folder/document that moves like any other documents I carry around in other apps.
Compiling basic Android sample code even takes much longer than I expect. And the plugin model, while flexible, doesn't add in the features in a way that feels comprehensive. In short, I feel usability is poor.
WTF? Do you even know anything about the Nexus S?
There's industry standards for tag/card communication like Mifare. But there's nothing to use it with. In fact, only recently Google released the ability to write to some NFC cards. This ability was not there on launch of the Nexus S/
Now that you have the lower layers set up, there's no standard on top of it which to use for anything that a common user would want.
Think about it this way, if NFC were networking technology, then it's as if FeliCa was AUI, Mifare was Token Ring, ISO 18000-3 is 10BaseT and nobody invented an equivalent to UDP, TCPIP, IPX, AppleTalk, nor ArcNet yet.
The summary of Google's lead is this:
"We're selling a phone which could talk with cards if somebody would actually declare an application level protocol, implement it, and deploy it. Otherwise, it's a fun toy."