"Both iOS and Android" misses a whole decade of mobile computing, though! Before the iPhone was even announced, Symbian had already shipped 100 million smartphones.
For an in-depth look into how the original smartphone OS came about, I can recommend David Wood's Smartphones and beyond: Lessons from the remarkable rise and fall of Symbian:
David Wood was an R&D executive at Symbian. He's brutally honest about the company's failings... But he also paints a fascinating picture of how the vision for smartphones evolved in the late '90s, when nobody had a clear idea of what the form factor could be and what actual people might want to do with the devices.
(There's a widespread belief that Symbian wasn't a real smartphone OS... Yet it supported 3rd party apps, multitasking and background services, 3G data, touch and keypad UIs, had a mobile WebKit browser before anyone else, GPU-accelerated OpenGL in 2005, and so on. In many ways Android owes a lot to Symbian, IMO -- for example the Activity lifecycle is fairly similar to the base concepts in Symbian.)
Let's also not forget about Windows Mobile. The first smartphones powered by it (marketed as "Pocket PCs which also happen to be a phone") started coming out in ~2002, with touchscreen and everything. I own a collection of phones with this OS, including a HTC Wallaby (the phone that the XDA-developers community was originally about), and even that old thing supported true multitasking, mobile data (GPRS), the best Internet Explorer they could put on such things at the time (it was Microsoft, after all), media player, handwriting recognition (inspired by the Palm devices, I believe)... in many ways it allowed one to do "smartphone tasks" well before Android or the iPhone came out. In fact, UX aside, when the iPhone came out, the Windows Mobile users I knew weren't impressed, because in terms of "technological possibilities" there was no news.
I used another more recent HTC device (Blue Angel), second-hand, for a couple of years as my main phone, from 2011 to 2013 IIRC. With WiFi and Bluetooth, decent web browsers available (Opera Mini and Mobile, plus some WebKit forks/wrappers), Google syncing through ActiveSync, for a long time upgrading to a newer phone and OS was not a priority. I only stopped using it for a Android phone two years ago (with the "appification" trend, a web browser is sadly no longer enough).
Coincidentally, the Blue Angel was an early Android target[0], and people have made it run versions up to 2.3 (at which point it's too slow to be usable by today's standards).
I doubt that Android owes much to WM, after all it was a closed-source OS and certainly there wasn't any motivation to do things the "Windows way". It's important to point out that platforms like WM and Symbian existed well before iOS/iPhone OS and Android even had their names decided, and failures apart, the idea of "smart phone" was not the result of solely Apple or Android Inc./Google. Unfortunately, even in many tech circles this is not the idea that prevails.
I also own a Symbian-powered Nokia phone (without touchscreen, forgot the model), and I have no doubt it is a "real" smartphone OS. I can confirm it allows for all that you described and certainly even more in the newer devices with touchscreen.
I began developing apps for Windows CE 2.11 in 2001 (then, Windows CE 3.0, PocketPC, and Windows Mobile). Its name changed many times but it's still a mini Windows. I did like it at that time. I was not impressed by iPhone until I really put my hands on it. WM is good, but iPhone is revolutionary.
> the best Internet Explorer they could put on such things at the time (it was Microsoft, after all)
Say what you will, the IE on my HTC Windows CE-based phone (I forget the model) was actually better than its contemporary IE in supporting standards correctly.
To go further down the rabbit hole, there's also http://www.osnews.com/story/26838/Palm_I_m_ready_to_wallow_n...
Thom makes a point to dig up where a lot of the concepts of that era drew their inspiration from. I especially like the comparison with the speed and ease of pen and paper.
It is a great read, and I recommend studying the history of Palm in order to understand mobile device history until 2007.
Yep, sometimes it feels like a lost decade in terms of mobile technology.
I seem to have misplaced the url, but there used to be a video on Youtube from a mobile tech trade show where Nokia was showing off using one of their phones as a mobile office.
We are talking Symbian, bluetooth keyboard and mouse, and video out to a TV. And this was when Android barely had bluetooth keyboard support (and you needed to use special OSKs to get anything but an American layout), and they had been doing it for years already.
I had a Symbian UIQ phone years before the iPhone and it's remarkably similar in overall design. One big touch screen with no face buttons, rows of icons for launching apps, etc. All the pieces were really there.
But the Symbian OS itself was terrible; I coded for it and it was a mess. It was quite functional, didn't really crash, but it seemed like it achieved that through sheer effort and will rather than good design.
Android was influenced by all of these prior efforts, at least indirectly. I was at Orange prior to Android getting started (and before Miner left to join Rubin).
At Orange we had built apps for Symbian S60, UIQ, and windows mobile. We also had seen the limitation of these platforms, especially Symbian which was getting long in the tooth with its baroque memory management architecture. I personally had seen the limitations of trying to get something working on Series 60 working directly with Nokia Engineers and getting held up by the platform limitations (and Nokia's own internal issues).
Another player at that time was Savaje - they had built a completely java based phone OS and were trying to sell it to carriers. Unfortunately they were too early to the market (among other issues).
So Rich had seen all of these issues with early smart phone systems and the European smartphone ecosystem, and presumably applied some of the learnings to Android's development.
I'm not sure if the book covers this, but I'm more curious about technical details like why Java was chosen as the language and why Dalvik as the VM (I know, "it wasn't the JDK/JRE", but then why not a different language?), and other interesting choices (Linux for the kernel, for example).
I've read, though I can't remember where, that a number of languages were under consideration.
But the Android team mostly came from Danger, and Danger used Java. So the Android team had considerable experience designing a Java VM for a device with very limited resources. Although Android never shipped on such a device, the design target was 200Mhz CPU, no GPU, and, IIRC, 128 or 256MB RAM. That's luxurious compared to a Danger Hiptop, which IIRC had only 32MB.
If you look at how many VM instances get started when an Android boots, it's pretty amazing that it doesn't take 15 minutes.
Also it enabled them to piggyback on a very mature toolchain by translating from Java bytecode to Dalvik bytecode as the last thing before packaging an app. At the time, XCode had nothing like the linting and refactoring Eclipse had. If they had a similar toolchain for Danger, that would be another reason to stick to Java.
I'm sure Java was chosen because it was the dominant smartphone programming language at a time.
And not for any actual good reasons.
And we (Android developers) still need to suffer through their poor initial choice of platform; things would be so much better if they exposed a C API as a first-class citizen of the OS, rather than making Java the only first-class way to access Android.
The original Danger Hip-Top also used Java. Rubin had already experience with that. They removed the part that sucked hard (MIDP) and replaced with their own implementation (Dalvik).
In 2009, I thought the same way as you do - that C API would be better. However, I was wrong - the Java/Dalvik as a first class is actually better, Google got the possibility to be CPU-architecture independent. Today, we have ARM, Intel, MIPS implementations, that are all first class citizens. Compare that to the failure of Windows-on-ARM.
Yes, the Java language is nothing to write home about - but there is a lot of existing code written in it, so replacing that would be difficult. Designing another language that could use the same standard library, API semantics AND be effective on small devices is not that easy (for example, Scala and Clojure both bring their own large standard libraries, Clojure also runtime overhead, making them both unusable on small devices).
>However, I was wrong - the Java/Dalvik as a first class is actually better, Google got the possibility to be CPU-architecture independent.
Just about anything would have been better than Java. I'm not a big fan of C#, but CLR would have been better. Even JavaScript would have been better. But an intermediate VM language (like the LLVM intermediate representation) would have been the best option, if CPU architecture targeting were the concern.
I do games, primarily. And writing games in Java (which is what Google tells you to do -- though they finally gave in to pressure and added the NDK) just sucks, because you have to ship the JDK when shipping on every other platform -- or you need to write your game twice.
So pretty much every major game uses C/C++ despite it being the ugly stepchild of Android. Google set up the dev environment so that you can add as many target architectures as you want, making your APK "fat", or alternately shipping various APKs with different architectures in them and letting the store pick the appropriate version. Which works, but is ugly.
C and C++ have been CPU-architecture-independent for a long time, and if they DIDN'T want to force the multi-binary approach, using LLVM to build to an intermediate language and compiling for each platform would have been an even better fix.
Intel and MIPS are not first-class citizens, by the way, because the NDK exists, and many developers still only ship ARM binaries. And while other platforms ship with ARM emulators, they're buggy: An app I'm currently working on just fails on MIPS, and there are few enough people with MIPS devices that the client decided to just not support MIPS (our build process uses libraries that aren't build using the Android.mk system, so I can't just add "mips" to the platform list).
I don't think that failure occurred due to anything other than mismanagement.
The Win8 cycle produced many things:
* An OS for desktop PCs
* Under the hood improvements vs. Win7, like faster boot
* A tablet UI
* A tablet
* A port of NT to ARM
* A tablet based on the above which could only run code signed by Microsoft
* An app store with a new set of APIs that nobody cares about
In a weird attempt to distinguish all of these bullet points they muddied the message. What was Windows 8 exactly? They produced oddities like a Windows tablet that won't run Windows programs (not even after a recompile), and a tablet UI that ran on desktops.
Imagine a world where they shipped some other combination of these bullet points. Example: A laptop running ARM and recompiled Win32 apps, with a UI that more resembles Windows 7. I'd argue (and argued at the time) that would be more successful than Windows RT.
> the Java language is nothing to write home about.
Sure, but it is also not as bad as its reputation in hackerNews circles.
With the right libraries (Dagger 2, Volley, GreenRobot/EventBus, ...) Java for Android can be quite productive (not to mention that IntelliJ also helps a lot).
Kotlin could allow us to go even further and remove most of Java biggest weaknesses.
write-once-run-everywhere does not work for high quality apps.
You can share some of the model code with something like J2objc, but I have yet to see a non trivial app fitting in 2 platforms UX principles written by some sort of write once framework.
I am talking about apps, not games :) .
Of course for games you want to use a cross platform approach, for example with unity.
They are a very specific case though. For games :
-you probably don't want to use the platform's UI framework (unless you game is extremely simple and even in that case it is probably not the best choice for crossplatform).
-the platform specific layer is pretty thin. Google Play Games/Apple Game Center. Share achievements, tweet game events and that's it.
It's funny that they don't talk about Danger a bit more. Anybody who ever worked in that environment can tell you that Android is pretty much just Danger v2, even the APIs were similar upon launch. (they have evolved quite a bit since then and veered off, but the first Android SDK was mighty familiar to anybody working on Danger stuff)
It really seems like it was the blueprint of what Android became.
Did you work with sidekick devices? I've just learned about them. I find interesting that they were manufactured by Sharp which back then was manufacturing also the Sharp Zaurus SL series (able to run several Linux flavours)
I used to play a lot with those devices, we were an small but passionate community wanting to get a full Linux on mobile. I remember people running a full debian desktop distro in a Zaurus... crazy stuff for 2004.
I've always wondered if Android had the same roots as OpenZaurus or similar mobile distros. It looks like Sharp is at least a common denominator...
The Zaurus devices are an odd duck. Sharp had their own OS that the devices shipped with in Japan, iirc. But for some reason they opted for putting a home grown Linux distro on them when offering them abroad. Not that they were easy to get in the first place...
It is sad that with recent updates, my Android has become slower and slower. With great products comes great responsibility, and I hope that they can set some higher standards for the future.
