Linked by Thom Holwerda on Thu 26th Apr 2012 22:09 UTC
PDAs, Cellphones, Wireless As I already said yesterday - a bit colourful to get me point across - this older article of mine has proven not to be as accurate as I thought it was, in light of a heap of new information. I want to offer some more background to all this.
Thread beginning with comment 515859
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Android's pivot
by mrstep on Fri 27th Apr 2012 01:32 UTC in reply to "Android's pivot"
Member since:

The fact that Android essentially had no legacy code base to try to move to a touch platform made it much easier. Microsoft was worried about keeping the PocketPC / CE apps going, RIM had their Blackberry users, and Nokia had their base. Adding fundamental touch support without screwing over existing apps where UI interactions were designed totally differently (interface elements too small to touch effectively) because of the working assumption of a keyboard, buttons or stylus - not as easy to respond to. Look at Microsoft's final answer: drop the old mobile OS entirely.

From Thom's original article: "In other words, unlike iOS, Android was built to be flexible, and run on many sorts of devices, with different screen sizes and form factors."

The fact that Apple optimized their specific UI for a more controlled set of sizes and touch input certainly doesn't mean the OS is somehow less flexible. If you mean the UIKit framework, sure, that assumes a touch interface - but the core of the OS has made it from NeXT workstations to current desktop machines, laptops, and phones and across quite a few CPU types to boot, and the lack of multitude of screen sizes had more to do with Apple not making 15 product variants because they didn't think it made sense.

Reply Parent Score: 4

RE[2]: Android's pivot
by akrosdbay on Fri 27th Apr 2012 02:01 in reply to "RE: Android's pivot"
akrosdbay Member since:

Apple TV runs iOS. iOS handles non-touch input just fine.

Reply Parent Score: 4

RE[3]: Android's pivot
by mrstep on Sat 28th Apr 2012 07:07 in reply to "RE[2]: Android's pivot"
mrstep Member since:

iOS - UIKit specifically - doesn't have event processing at the SDK level for mouse or key events, which makes perfect sense since it's designed for a touch interface - mouse movement/clicking and key handling isn't the same as multi-touch.

I'd encourage you to take a look at how the iCade SDK has to work around the missing key events to get joystick and button events into games that support it. (Start with a hidden text field's delegate and go a bit downhill from there since that delegate doesn't know about 'key down' or 'key up' either...)

Again, that in no way makes iOS less flexible since it's a UIKit design question, and having mouse events - or in 99.9% of the time keyboard events - in UIKit would needlessly complicate event handling, but it's a stretch to claim it handles all kinds of input equally well.

Reply Parent Score: 3