gruber adds on android's open hardware approach.

Gruber quotes what I wrote about android, cool.

I agree with the addition of the CPU and GPU as another hardware permutation factor. I didn't write about that in the original post because I wanted to keep the post focused on the physical UI aspect of the totally-open hardware specification of android and what I think are the consequences for mobile app development.

there are some cool comments about this on my original blog post too. I particularly like the comparison of the iphone platform to a console gaming platform - which are even MORE rigid as a platform the the iphone is.. as there is only ONE hardware profile to develop for - the iphone has 3 three sets hardware permutation thus far (iphone, ipd touch and the 3g iphone).

android's main disadvantage against the iphone (and blackberry, openmoko, others)

Gruber at daringfireball writes, in a post about android vs iphone as a platform:

"The big advantage Apple has with the iPhone is that they control the entire product, top to bottom. The case, the chipsets, the OS, the user interface.".... "Google’s dependence on hardware and carrier partners puts the final product out of their control — and into the control of companies whose histories have shown them to be incompetent at design and hostile to users."

I Agree.

Moreover, it's not just a big problem from a user perspective, or the quality of the end product from Googles point of view. It presents an even bigger problem from a development point of view too.

Developers working on android apps are put in a position where they need to guess and program for different physical UI scenarios (none of which actually exist in the wild, yet):

Does the target phone have physical buttons?
What is the button configuration?
Does it have a touch screen?
What about different resolutions?
What sensors do you code for? camera? accelerometer? proximity? touchpad?

It's hard enough to code effective UIs for a unified platform - coding for different hardware UI configuration adds complexity which is an order of magnitude harder to do effectively. and it presents a problem for the end user market too - in disseminating the platform (educating: how to use the platform, what does the user expect from the platform, what is the BRAND experience from an android phone? is there one at all?)

Google's approach, as determined by Google's GOAL (proliferation of an OPEN platform so there is no way for one company to lock access to the web) is to let the market decide. this is great, and very democratic, but when you look at the way major platform evolve - you see that standardisation takes TIME.

If you look at platforms that have a differing hardware UI footprint to them you see the problem with this approach pretty clearly - the web is the classic example for resolution based problems - even now, many websites don't scale well on differing resolution screens - and most sites are coded to a standard resolution (around 800 pix wide or so) - which took time, around 10 years to get too.
In the PC world the market standardised itself over the course of ten years on keyboard+mouse.
If you look at Linux (and earlier on the fragmentation of UNIX which allowed Microsoft access to the enterprise market through "divide and rule") you'll see why many standards (UI toolkits, package management, dependencies on different libraries, different shells) = no homogenised platform which allows for the more perceived cohesive platform to win in the market place.

no homogenised platform = no advantage to android as a recognised platform.

this is not to say that android won't be a huge success, I think it will, but it's going to be a different kind of success then the kind of success that the iphone will have (and has) as a development platform - it will probably kill the OS licensing to cellphone makers market, kill data access crippling by the carriers and this way will remove a big threat to Google's core business model. but I doubt that android will sustain a long term development community and hardware platform in the way that apple's iphone is likely to achieve.

Apple dropped the other shoe.

SDK announced. If you're a programmer and you are reading this. well.. I advise you to download the thing and play with it.

they announced a lot of buisness oriented features that are boring (exchange support, push mail, blah).

they demoed games working on the thing (including a mobile version of spore and some sega stuff).

But there were to things that really amased me. both happened at the Q&A session:

amazing moment number 1:

Q: What will happen if someone does a VOIP app?
A: We will only stop VOIP over cell networks, but not WiFi.

well people, it looks like Ebay might not have been stupid buying skype, after all. they could make a killing if they port it to iphone. question is... well... are they?

if they do - there might not be any reason to unlock the sim in the iphone in the first place, just use it as a skype phone where you have wifi. which, by the time this goes on-line - is likely to be anywhere. welcome to the 21st century.

amazing moment number 2:

there always has to be a village idiot, in this case it's Ryan Block from engadget:

Q: Will SIM unlock software be considered software not allowed in the app store?
A: (pause) "... yes.".

Android's BIG problem.

hardware control of a pro-tool system using an iphone/ipod touch. (via cdm)

a good example of why Google's android is going to fight an uphill battle against a platform which is more unified - one standardized hardware interface rather then many different ones, one software GUI - and MANY MORE users (specificly when putting the ipod touch into the equation). if I was a developer I would concentrate on understanding apple's platform now, specifically - since the official API will be out on February.

ahh yeah.. and right now there is a user base of 2-5 million users of apple's Multi touch platform. android has a user base which is considerably lower then that.

as this example shows - developers in vertical markets are already making some really cool stuff for a platform that exists now, without an official API - I'm not sure what interest do developers have to code stuff for an API that has no product in the market - and in it's own echo system the input devices and UI's are probably going to be non-homogeneous.

revenge will be mine.

herenot: yo.

adistav: hey

herenot: how was the cultura eve?

adistav: very nice. people like it, especially the non-technical people (which was the idea)

herenot: cool. am I right in assuming that moshe will be the next one?

adistav: yes. on a subject closer to you

herenot: yah, I read as much on his blog. you know what that means?

adistav: what?

herenot: I will have to kill both of you when I come back. I could accept one of you giving a talk in my absence about a subject I'm interested in. but not two. ok. that's it, need to find new friends when I return. (that is after I dispose of the bodies)

adistav: ah. when are you back?

herenot: 15th of october

adistav: i felt a little funny to tell noa "let me give a lecture in 4 months"
adistav: moshez has less of an excuse...

herenot: doesn't matter.

adistav: actually i think you would not find much new with my own lecture, dax would've enjoyed it more

herenot: work out your wills. you have a month and a half.

adistav: okay :)

herenot: I'm serious.

adistav: okay.

herenot: I'll shop for the knifes today after work. ze germans have great knifes.

skype's lame excuse

skype's outage this weekend has been resolved, and all is well now. Skype issued an explanation which I find hard to believe: according to thier blog - a microsoft software patch which requered rebooting flooded thier netword with log-on requests and a software but caused thier servers to crash.

If this is true can anyone tell me: why now?

why did this never happen before. I mean, it's not like this was the first software update microsoft has issued which initiated a computer restart...

why did the skype network crash now, and not before?

any ideas?