To read all comments associated with this story, please click here.
Any reason in particular for not using then, as a base (at least for early development phones, not necessarily the launched one), the existing Windows Mobile HTC touch handsets?
I think I remember some of them even getting community created Android builds...
This is still an issue on Android? It was my understanding that this kind of thing was fixed for good in Froyo or Gingerbread (I don't remember which specifically). I know that every device I've used with Gingerbread or higher, including my lowly Moto Cliq with CM7 that I just gave to my best friend's sister, has no scrolling issues.
Oh wait, I forgot you are a huge Apple fan. My apologies, troll on my friend.
http://www.usatoday.com/money/industries/technology/2008-01-13-andr...
http://news.soft32.com/a-la-mobile-demonstrates-android-platform-on...
http://www.a-la-mobile.com/news/press/pr080114.html
strange photo:
http://openhandsetmagazine.com/2008/01/a-la-mobile-demonstrates-the...
Edited 2012-05-07 13:39 UTC
Would just like to clarify that I am most certainly a programmer (you can Google me if you like) ;-) And even running the M3 SDK version of Android on the touchscreen emulator has the OS looking and acting exactly the same as non-touch - there is no completely different UI for touch, so it's misleading to suggest that what you see here isn't representative of Android at the time. Just my 2ยข
The early emulator was released with the goal to get feedback on APIs and developers starting on basic application development. A lot of the real UI stuff was not visible in order to avoid it being leaked in an incomplete state.
If you look at the schedule, it would be pretty hard to believe that in the less than a year from the first emulator release until devices are being sold, the entire platform was stabilized *and* the entire UI was changed from being DPAD-based to touch-based. The same people stabilizing the different parts of the platform would also often need to be doing any work on touch -- for example the view hierarchy was a big new piece of code that had never been shipped, and would have significant disruptive work to add touch support later on. Even if you had a large number of engineers working on it (which there were not) you couldn't stabilize it at the same time you were making such changes.
The tail end of this comment reminds me of many moons ago where an overzealous and underdeveloped Director used to come around my dev team office every day to see "progress".
I'd make sure we stuck a few meaningless buttons on forms or changed a layout a bit before he came around and then we'd carry on as per usual.
The new pretty buttons was the only sign of change he understood. A UI that never changed for weeks was obviously a sign of developers doing nothing in his eyes.




.
Member since:
2006-02-15
I think this gives a somewhat misleading impressions of what happened.
That was one of the lagging implementations in Android, which was increasingly making the hardware schedule for Sooner not match the software schedule for Android. I think almost everyone on the team was relieved when Sooner was dropped, just because it gave some relieve on the core software schedule.

From a software perspective, Sooner and Dream were basically the same -- different form-factors, one without a touch screen -- but they were not so different as this article indicates and the switch between them was not such a huge upheaval.
The main reason for the differences in schedule was hardware: Sooner was a variation of an existing device that HTC was shipping, while Dream was a completely new device with a lot of things that had never been shipped before, at least by HTC (new Qualcomm chipset, sensors, touch screen, the hinge design, etc). So Sooner was the safe/fast device, and Dream was the risky/long-term device.
However the other factor in this was the software. Work on the Android we know today (which is what is running in that Sooner) basically started around late 2005 / early 2006. I got to Google at the beginning of 2006, and it was around that time we started work on everything from the resource system through the view hierarchy, to the window manager and activity manager that you know today. Some work on stuff we have today (like SurfaceFlinger) was started a bit earlier, but also after Google acquired Android.
Even if there was no iPhone, there is a good chance that Sooner would have been dropped, since while it was a good idea to get Android out quickly from a hardware perspective, the software schedule was much longer. I don't recall the exact dates, but I believe the decision to drop Sooner was well before the iPhone announcement... though we continued to use it for quite a while internally for development, since it was the only semi-stable hardware platform we had. If nothing else, it helped remove significant risk from the schedule since software development could be done on a relatively stable device while the systems team brought up the new hardware in parallel.
So what you see running on that Sooner is the same Android that would run on Dream. This is one of the reasons we have the -notouch resource qualifier, for the UI select a touch-based or non-touch interface depending on the device. Also at that point most of the widgets you see in the UI (lists and such) are the ListView and GalleryView we have today, and would already be able to react to touch input if they received it. And the software on there was using our layout managers to resize the UI elements to match the screen size.
However that build may not have things in it like actually running apps in multiple processes.
Imagine if Sooner had gone out at a reasonable time before Dream, say a year before. This was when we released the preview SDK. We had a mad dash to get the SDK somewhat cleaned up for that, but did lots of iterations on it in the following months. We had barely gotten multiple processes working (it was so close you still see remnants of our single process environment in the SDK with Application.onTerminate).
During the time from when the SDK came out to when the G1 shipped, we spent many many months working on stabilizing, optimizing, and productizing the platform. This was a platform that had never been shipped before, with a lot of pretty unusual designs -- up until near the end, you had to wonder "is this actually going to work?"
We also had a long lead time required in stabilizing the platform before shipping the device. Partly because of uncertainty of how everything would work together, partly because the team hadn't shipped a device before and didn't know the tricks we do now for tuning the release schedule. At the time we shipped the device, we even felt like we had to assume that what we shipped on the ROM was it, and we would never be able to deliver an update to it!
So be careful when you look at screen shots. People who aren't programmers, understandably, see a UI and take that to be all there is to know. We should know however that what is behind the part you can see is actually a lot more complicated, stuff you could never realize just from what you see with your eyes. People throwing up pictures of a UI they have played with and coming to conclusion that explain what is going on behind the scenes may get some things wrong.