6 ms·

What about the underlying architecture of the OS though? Linux with a Java runtime and a new windowing layer that stops "normal" Linux apps running? Running eac

What about the underlying architecture of the OS though? Linux with a Java runtime and a new windowing layer that stops "normal" Linux apps running? Running each dalvik process in its own confined user process? What about the design for background services and foreground activities that can be switched to/from (multitasking) right from the beginning, with AIDL for implementing service definitions? What about Intents and the ability to pass messages between processes? What about access to the filesystem in a "normal" way? What about the "desktop" on Android? Where did they copy that from? iOS didn't have multitasking until a lot later, and the concept of background services is more aggressively policed (that is, processes killed often) on iOS, as far as I know? Sure, the superficial layer on top (look! icons! rows of icons!) that children in a sweet shop would notice may look familiar, but underneath it is not anything alike is it? Or are you saying it is?

rimantas 12y ago
> iOS didn't have multitasking until a lot later, and the > concept of background services is more aggressively > policed (that is, processes killed often) on iOS, as far > as I know? Ugh, of course iOS had multitasking from the very beginning as you would expect from unix kernel. The access to it from third party apps is entirely different question.
- nailer 12y ago
  Well yes, without UX it may as well not exist.
- socrates2014 12y ago
  iOS had restricted multitasking exposed to apps for awhile (definitely by iOS 5) but it was restricted to certain kinds of apps: VOIP, background audio, newsstand, location awareness, or to a restricted period of time after the app is backgrounded. They expanded it quite a bit in iOS 7? to all apps with background fetch, background url upload and download tasks, silent push notifications, and background tasks. All of these approaches do not work if a user forcibly shuts down the app (I am not quite sure of every case). All these mechanisms are controlled by the OS: we'll call you, don't call us sort of thing and if you don't return in a certain period of time or if we need to, we will shut you down. In iOS 8 you have extension support which launches mini apps. Extensions are somewhat equivalent to services but they are about integration with multitasking an implementation detail for security purposes.
- 72deluxe 12y ago
  Yes I meant that it wasn't available to common app developers; of course the system did multitasking and time-sharing!
coldtea 12y ago
>What about the underlying architecture of the OS though? Linux with a Java runtime and a new windowing layer that stops "normal" Linux apps running? What's impressive about that? Tons of companies did something similar. Heck, OS X/iOS is Mach+BSD based hybrid kernel with a UNIX (FreeBSD/GNU) userland and a new windowing layer that "stops normal UNIX apps running". >iOS didn't have multitasking until a lot later Actually it did. It just wasn't enabled for third party apps because Apple is not the company to give users some non-essential feature by sacrificing something more precious at the time (battery life). Android just went for the "whatever" option, and let users deal with that. >What about access to the filesystem in a "normal" way? What about it? If anything its worse that it being something copied from iOS: it is the standard way of doing things carried over from 40+ years of computing. >Sure, the superficial layer on top (look! icons! rows of icons!) that children in a sweet shop would notice may look familiar, but underneath it is not anything alike is it? No, underneeth it's worse. More battery draining, worse responsiveness, a Java runtime they had to axe, audio latency issues, 2-3 releases to get a anywhere near decent UI, bad malware issues, etc.
- 72deluxe 12y ago
  All of the points you make are correct! But I was mainly pointing out the comment that stated that Android was a rip-off entirely of iOS at the time; it wasn't - the ability to have (battery-draining) multitasking for 'common' apps was missing on iOS. Android also introduced features not found on iOS (intents, notifications at the top, stuttering scrolling haha etc.) so it wasn't a "coat-tail-riding" exercise entirely. I do recall the bad UI from early on; even 2.3 was pretty ugly, and every release said "now with smooth scrolling!" which sadly was lacking. The Java runtime axing is the funny one. One day Java will be as fast as C, right? I am aware that many of the features could probably be found on Windows Mobile 6.3 or 5.0 or whatever was available at the time, but Android appears to have displaced the Windows phone market to a large extent.
- lern_too_spel 12y ago
  This is coming from a hobbyist mobile developer, so take the following responses with the appropriate perspective: "Actually it did. It just wasn't enabled for third party apps...." This is, to my mind, the worst continuing failing of iOS, so bad that we see a front page HN post related to it at least once per month. Apple builds its apps on private APIs, while third parties must build their apps on inferior public APIs. Apple gets to create and use new UX, while third parties must wait until Apple uses it first. On Android, Google's apps use the same APIs my own apps use. "Android just went for the "whatever" option, and let users deal with that." That's funny. Apple copied wholesale the Android save and restore data bundles model that was in Android from the beginning, and said, "Look at our battery-saving multitasking." "What about [normal filesystem access]?" It simplifies porting. What does Apple's system gain that you can't get by alternate APIs on top of the filesystem? Nothing, as far as I can tell. "Worse responsiveness" https://www.youtube.com/watch?v=hPhkPXVxISY https://www.youtube.com/watch?v=hPhkPXVxISY The Android apps are running on Dalvik on year-old budget hardware pushing more pixels. In a same-generation test, I would expect the outcome to be even more lopsided. "A Java runtime that they had to axe" How does this matter? It's as transparent to the developer as switching from Sun's client JVM to server JVM. It doesn't require so much as a recompile, unlike on iOS. "Audio latency issues" This is true, but it doesn't affect 99.9% of apps, unlike the first issue I pointed out. If you're developing an app for DJs, you already know about it. "2-3 releases to get a [sic] anywhere decent UI" It was many more releases than that. "Bad malware issues" Not by default -- only if you install apps from websites (requires users to click through a dialog that tellls them it's dangerous) or use a phone with a Chinese app store. You're buying Tim Cook's lazy marketing. None of the manual testing that Apple does before allowing an app on the App Store stops malware any better than the automated testing that gates publishing on the Play Store. Looking at allowing installation of apps from unknown sources from the other side, this lets me develop apps for my own phone for free, without paying a $99 / year tax. Even more than the private APIs issue, this is what made me jump on the Android bandwagon early on and makes it hard for me to understand why a person who enjoys software development would choose the iOS ecosystem.

rimantas 12y ago

> iOS didn't have multitasking until a lot later, and the > concept of background services is more aggressively > policed (that is, processes killed often) on iOS, as far > as I know? Ugh, of course iOS had multitasking from the very beginning as you would expect from unix kernel. The access to it from third party apps is entirely different question.

nailer 12y ago
Well yes, without UX it may as well not exist.
socrates2014 12y ago
iOS had restricted multitasking exposed to apps for awhile (definitely by iOS 5) but it was restricted to certain kinds of apps: VOIP, background audio, newsstand, location awareness, or to a restricted period of time after the app is backgrounded. They expanded it quite a bit in iOS 7? to all apps with background fetch, background url upload and download tasks, silent push notifications, and background tasks. All of these approaches do not work if a user forcibly shuts down the app (I am not quite sure of every case). All these mechanisms are controlled by the OS: we'll call you, don't call us sort of thing and if you don't return in a certain period of time or if we need to, we will shut you down. In iOS 8 you have extension support which launches mini apps. Extensions are somewhat equivalent to services but they are about integration with multitasking an implementation detail for security purposes.
72deluxe 12y ago
Yes I meant that it wasn't available to common app developers; of course the system did multitasking and time-sharing!

coldtea 12y ago

>What about the underlying architecture of the OS though? Linux with a Java runtime and a new windowing layer that stops "normal" Linux apps running? What's impressive about that? Tons of companies did something similar. Heck, OS X/iOS is Mach+BSD based hybrid kernel with a UNIX (FreeBSD/GNU) userland and a new windowing layer that "stops normal UNIX apps running". >iOS didn't have multitasking until a lot later Actually it did. It just wasn't enabled for third party apps because Apple is not the company to give users some non-essential feature by sacrificing something more precious at the time (battery life). Android just went for the "whatever" option, and let users deal with that. >What about access to the filesystem in a "normal" way? What about it? If anything its worse that it being something copied from iOS: it is the standard way of doing things carried over from 40+ years of computing. >Sure, the superficial layer on top (look! icons! rows of icons!) that children in a sweet shop would notice may look familiar, but underneath it is not anything alike is it? No, underneeth it's worse. More battery draining, worse responsiveness, a Java runtime they had to axe, audio latency issues, 2-3 releases to get a anywhere near decent UI, bad malware issues, etc.

72deluxe 12y ago
All of the points you make are correct! But I was mainly pointing out the comment that stated that Android was a rip-off entirely of iOS at the time; it wasn't - the ability to have (battery-draining) multitasking for 'common' apps was missing on iOS. Android also introduced features not found on iOS (intents, notifications at the top, stuttering scrolling haha etc.) so it wasn't a "coat-tail-riding" exercise entirely. I do recall the bad UI from early on; even 2.3 was pretty ugly, and every release said "now with smooth scrolling!" which sadly was lacking. The Java runtime axing is the funny one. One day Java will be as fast as C, right? I am aware that many of the features could probably be found on Windows Mobile 6.3 or 5.0 or whatever was available at the time, but Android appears to have displaced the Windows phone market to a large extent.
lern_too_spel 12y ago
This is coming from a hobbyist mobile developer, so take the following responses with the appropriate perspective: "Actually it did. It just wasn't enabled for third party apps...." This is, to my mind, the worst continuing failing of iOS, so bad that we see a front page HN post related to it at least once per month. Apple builds its apps on private APIs, while third parties must build their apps on inferior public APIs. Apple gets to create and use new UX, while third parties must wait until Apple uses it first. On Android, Google's apps use the same APIs my own apps use. "Android just went for the "whatever" option, and let users deal with that." That's funny. Apple copied wholesale the Android save and restore data bundles model that was in Android from the beginning, and said, "Look at our battery-saving multitasking." "What about [normal filesystem access]?" It simplifies porting. What does Apple's system gain that you can't get by alternate APIs on top of the filesystem? Nothing, as far as I can tell. "Worse responsiveness" https://www.youtube.com/watch?v=hPhkPXVxISY https://www.youtube.com/watch?v=hPhkPXVxISY The Android apps are running on Dalvik on year-old budget hardware pushing more pixels. In a same-generation test, I would expect the outcome to be even more lopsided. "A Java runtime that they had to axe" How does this matter? It's as transparent to the developer as switching from Sun's client JVM to server JVM. It doesn't require so much as a recompile, unlike on iOS. "Audio latency issues" This is true, but it doesn't affect 99.9% of apps, unlike the first issue I pointed out. If you're developing an app for DJs, you already know about it. "2-3 releases to get a [sic] anywhere decent UI" It was many more releases than that. "Bad malware issues" Not by default -- only if you install apps from websites (requires users to click through a dialog that tellls them it's dangerous) or use a phone with a Chinese app store. You're buying Tim Cook's lazy marketing. None of the manual testing that Apple does before allowing an app on the App Store stops malware any better than the automated testing that gates publishing on the Play Store. Looking at allowing installation of apps from unknown sources from the other side, this lets me develop apps for my own phone for free, without paying a $99 / year tax. Even more than the private APIs issue, this is what made me jump on the Android bandwagon early on and makes it hard for me to understand why a person who enjoys software development would choose the iOS ecosystem.