Android invested up front in more complex technology that would allow adaptation to future hardware devices. Most obviously, by using layout managers instead of pixel positioning like iOS did. That meant Android was able to adapt to a range of screen sizes way earlier than Apple could. Every time Apple tried to introduce a new screen size or resolution it resulted in major pain across their entire app ecosystem, something many Android apps avoided.
Phones are still memory constrained. Yes they have "shitloads" of RAM compared to previous devices but they still don't have a swap file of any kind. The activity model allows phones to have an apparently infinite number of apps open, without the UI ever stalling due to hitting a paging storm like desktop apps can. Simply increasing the amount of RAM doesn't solve the problems the activity model was designed to solve, and it's worth noting that when Apple introduced multi-tasking into iOS, they ended up with something quite similar to activities.
The choice of Java had complex effects on memory usage. Whilst Java heaps can be kind of piggy, a lot of memory usage comes from loaded code, and bytecode is a lot more compact than native code is. That's why they're reintroducing JIT compilation in Android N - having moved to fully AOT when ART was introduced they are now going back again to reduce memory pressure.
The decision to support SD cards made a lot of sense back in the days when internal storage was a lot more limited.
> The decision to support SD cards made a lot of sense back in the days when internal storage was a lot more limited.
And it still makes sense today. See: Android One (and most other handsets targeted at the developing world), manufacturers adding SD cards back after dropping them (most recently Samsung) and so on.
Personally speaking, despite loving my Nexus 7s in the past, I'm no longer interested in tablets without SD card slots. Even if it were good for nothing else, it's easy to fill up a 128 GB or larger SD card with video and music I want on hand.
> Android invested up front in more complex technology that would allow adaptation to future hardware devices. Most obviously, by using layout managers instead of pixel positioning like iOS did.
Layout managers are complex technology now ? The layout managers Android uses are pretty much identical to what Java used in AWT and Swing and is trivial to implement. I know because I implemented just such a thing for a UI toolkit I made for J2ME back in the day. Desktop apps have been doing it for decades. iOS by contrast uses a much more complicated system (not saying it's better, just more complex).
Also, I vastly prefer iOS's sytem with just a handful of resolutions so you can fine-tune your designs to the exact screen dimensions. In practice I've found it very hard to explain Android's layout mechanisms to designers and to get good designs from them that scale well. Most designers I know prefer being able to make a pixel-perfect design like you can on iOS. Sure it works fine for business-style apps but if you want to make something spiffy, you're fucked on Android.
> when Apple introduced multi-tasking into iOS, they ended up with something quite similar to activities.
iOS has nothing even remotely resembling activities. Background apps can be suspended and possibly killed, but that's as far as the parallelels go. Don't even get me started on the insane idea of Intents (sounds like a great concept but horrible in practice and badly implemented too).
> The activity model allows phones to have an apparently infinite number of apps open, without the UI ever stalling due to hitting a paging storm like desktop apps can.
Then why is this not an issue at all on iOS. In fact, my 6S pretty much never kills background apps and even when it does that does not affect foreground performance. And if they were so concerned about the UI stalling, they should have stayed away from Java. It has improved a little bit but especially in the early days the GC would regularly freeze the entire JVM for 100+ ms. Try hitting 60fps like that.
> The choice of Java had complex effects on memory usage. Whilst Java heaps can be kind of piggy, a lot of memory usage comes from loaded code, and bytecode is a lot more compact than native code is.
Wut ? Loaded code is a completely negligible part of an apps memory usage. And again, not an issue on iOS. In fact memory is far more constrained on Android than on iOS even when Android devices have more physical RAM. Android severely limits the amount of RAM an application can use (the heap size limit). I've never run into problems with RAM usage on iOS and regularly on Android. On a 1GB iPhone you can easily use 700-800MB RAM for your app if you wanted, while you're lucky if you can get 192MB on a 3GB Android phone.
Furthermore, garbage collected languages use about 3 times as much RAM as a non-GC language for similar performance (tradeoff between how often the GC runs vs performance) negating any and all gains of a smaller code size. There is also this thing called the ARM Thumb instruction set which results in smaller binaries if that really is an issue.
> The decision to support SD cards made a lot of sense back in the days when internal storage was a lot more limited.
And this goes to the heart of my criticism: yes internal storage was a lot more limited back then. Both Google and Apple knew this. They both also knew (or should have) that internal storage was going to improve a LOT and very quickly at that. This is the point I'm trying to make: Google develops for yesterdays and todays constraints while they should be developing for tomorrows. In fact, Google should look farther into the future than Apple does because it takes so long for their software to reach consumers, it's taking 2-3 years for any new Android release to gain any significant market share. Android N should be built with 2019's phone hardware in mind, instead it's being built for 2015 hardware.
Regarding GC, Windows Phone apps are garbage-collected, yet Windows Phones has a great reputation for smoothness and responsiveness on anemic hardware like the Nokia 520.
WP only runs one application at a time. When you switch away from an app, it's "tombstoned" so that the app in focus has all available resources. It is possible to run tasks in the background, but IIRC the OS reserves the right to tell your background task "GFY".
No it doesn't. One look at the Windows Phone reddit will tell you otherwise. Windows phone jank is masked by superfluous animations, capped scrolling speeds and other tricks to hide it. Unfortunately, those tricks don't do the job.
Intents don't work because they were designed to be too flexible.
Say I want to be able to share something on social media from my app, seems like the exact use-case Intents were made for. So I create an intent of type ACTION_SEND because that's the only one that sorta does what I need and now my user gets a HUGE list of options, half of which are irrelevant and/or don't work at all. I cannot limit the Intent to 'share on social media' because it has no such category. You cannot filter the list yourself because that would mean having to know the package name of every possible social media app.
Worse, even the well known social media apps do not work. No one agrees on what fields should mean what and how to interpret them. For example: you can create an intent that prefills the text and attaches a photo and it will work when you use it to open Twitter but not Facebook, facebook ignores the pre-filled text. Another app will ignore the photo, etc. you can't test every possible target app so the whole mechanism is unusable if you want to deliver a good UX. In the end you give up and just add the Facebook and Twitter SDK's to your app.
Another example: we have an app that deals with privacy-sensitive information. We want the user to be able to e-mail this to him/herself but nothing else. Or rather: we don't want our users to accidentally share this information on social media. You cannot create an Intent that will only open the users preferred email client and excludes everything else.
Intents are pretty much worthless if you care about a good UX at all.
From a user's perspective, I consider Intents the strongest feature of Android as it let the system make no assumptions about my preferred apps. If it is important to closely control the user's flow, as in your second example, then you're probably better off hardcoding a list of other apps that your app can interact with using explicit intents like how sharing works on iOS. General intents like ACTION_SEND are designed to be intercepted by any app that declares itself capable of servicing the request, regardless of how well the app can actually do so.
> From a user's perspective, I consider Intents the strongest feature of Android as it let the system make no assumptions about my preferred apps.
Half of the time the apps listed make no sense for an intent. There needs to be a mechanism for more fine-grained categories. For example, it should be possible to create a 'social media' intent for sharing on social media. It makes no sense to include Dropbox or Google Drive in that list.
And while it may be a nice feature for power-users, it's a horrible feature for the average user. Why would the user want to be presented options that don't even work ?
Just wanted to chime in as a former six year Android user that I miss intents the most.
I'm using my phone much less for certain activities. For instance, I share to instagram less because it's not in thr iOS share drawer for some reason.
I think the arguments leveled against Android elsewhere in this thread are solid...maybe even the UX one against intents. I certainly don't suggest an Android to anyone in my parents' generation, except my former-programmer uncle.
Android invested up front in more complex technology that would allow adaptation to future hardware devices. Most obviously, by using layout managers instead of pixel positioning like iOS did. That meant Android was able to adapt to a range of screen sizes way earlier than Apple could. Every time Apple tried to introduce a new screen size or resolution it resulted in major pain across their entire app ecosystem, something many Android apps avoided.
Phones are still memory constrained. Yes they have "shitloads" of RAM compared to previous devices but they still don't have a swap file of any kind. The activity model allows phones to have an apparently infinite number of apps open, without the UI ever stalling due to hitting a paging storm like desktop apps can. Simply increasing the amount of RAM doesn't solve the problems the activity model was designed to solve, and it's worth noting that when Apple introduced multi-tasking into iOS, they ended up with something quite similar to activities.
The choice of Java had complex effects on memory usage. Whilst Java heaps can be kind of piggy, a lot of memory usage comes from loaded code, and bytecode is a lot more compact than native code is. That's why they're reintroducing JIT compilation in Android N - having moved to fully AOT when ART was introduced they are now going back again to reduce memory pressure.
The decision to support SD cards made a lot of sense back in the days when internal storage was a lot more limited.