7 ms·

> After all these years, I still find the most difficult and un-natural thing is mixing concurrency / background tasks that must outlive the UI with complex UI

> After all these years, I still find the most difficult and un-natural thing is mixing concurrency / background tasks that must outlive the UI with complex UI component lifecycles. Completely agree. I've been developing for Android since 1.0 and the complex interaction between background tasks and activity lifecycle is the worst part of Android that a significant majority of devs get wrong, introducing subtle bugs. (And the worst thing is that the documentation pretends like this issue doesn't exist last time I checked. Newbie developers have no chance getting this right, even experienced dev often ignore it.) Overall, I wouldn't say Android is poorly designed, it's just mediocre, I would expect more from Google. In general, I'd say the design lacks simplicity and elegance. Some examples: - Fragments. Activities were already overly complicated and for some mysterious reason they took it to the next level with fragments. (They should get rid of or redesigned activities too.) - Older version of Google Cloud Messaging library - hundreds of lines of source code to implement a basic hello world example (wth)? - Documentation is unclear in some cases, promoting some cargo cult patterns such view holders (zero effect on performence these days). Also, services, if you don't need IPC, the only "feature" of a service is that it lowers the probability that the app gets killed. I usually just create a simple service and start / stop it as a way to telling the system "don't kill the app".

chinhodado 10y ago
I used to think Activity lifecycle management is complex. Then I learned about Fragments and I started to loathe every moment I have to work with them. What a bloated mess: http://staticfree.info/~steve/complete_android_fragment_lifecycle.png http://staticfree.info/~steve/complete_android_fragment_life...
- sgc 10y ago
  I started making a semi-complex android app as my first project. Saw the recommendation to use fragments, and I have never looked back because I am way, way too far down the rabbit whole. It's main advantage to me is perhaps nothing. I have no idea and no real way of knowing. But is has tripled my code base, so that is a good thing!
- m_fayer 10y ago
  Otherwise known as the "lolcycle".
- tigershark 10y ago
  They must have been using some seriously good drug when "designing" this mess..
- V-2 10y ago
  And then there are nested fragments and all the caveats associated with them, but it's all good, it just requires some simple fixes everyone could come up off the top of their head, like http://stackoverflow.com/a/23276145/168719 http://stackoverflow.com/a/23276145/168719 (the top voted answer) It's good, because it doesn't require you to use the workaround of deluding the user with a SCREENSHOT of your layout (sic; see the accepted answer above).
  - nodamage 10y ago
    Good lord. How absurd that this is even necessary in the first place.
  - BoorishBears 10y ago
    Support fragments "fixed" nested fragments a little while back, or so they claimed in a change log.
    - V-2 10y ago
      I don't even know; I imagine at that point there wasn't many developers left around still willing to go down that route. As an Android dev I'm in the camp that steers clear of Fragments out of principle, if only possible.
      - BoorishBears 10y ago
        I'm pragmatic about them and they work out. It takes some discipline, but in exchange you get to use a standard back stack manager with more mindshare than any 3rd party replacement like Flow will have. My personal guidelines are: Only use them in a single form. FragmentTransaction add/remove/replace, no fragment tags in xml to cause inconsistent behavior Represent state with single AutoValue + Auto Parcel object and save it with Icepick so they work with process death automatically Implement all interactions with other threads via RxJava so I can unsubscribe and avoid "after onInstanceState exceptions" Use custom view groups instead of nested fragments since nested fragments tend to not be using the backstack anyways
yincrash 10y ago
Some historical context, fragments came out with Honeycomb which was the first version of Android specifically for tablets. As such Fragments were meant to be a way write UI in something both tablet and phone layouts could use. So, that's the mysterious reason for the extra layer of complexity. I think at this point, many people don't even use them unless they specifically need to for tablet/phone/tv shared layouts. There are also other alternative patterns that have emerged that are less complicated
- digi_owl 10y ago
  Also, they envisioned tablets to be used mostly in landscape. That's why we got everything on a single bar at the bottom. The basic concept behind Fragments was pretty much the same as WebOS' Enyo framework. I recall one of the big Enyo demo moments was when a browser window was resized, and the email app ui went from multiple columns to a single column, and back, without missing a beat. Then again i wonder if Android was partially designed, before Fragments, to rekindle the experience of using Apple's Newton tablet. This in that one app would extend the functionality of another app in a virtually seamless manner via intents. But as best i can tell, Android left too much of the plumbing in the hands of the app devs. Thus for every app that handled cross-app intents properly, you got 100+ that would jump back through the in-app activity history rather than roll back the intent chain. And with fragments you got a in-app way to do the activity history backtracking, while still having the intent focused back button of the Android UI.
- dimillian 10y ago
  I use Fragments as "Content View Controller", phone / tablet whatever, it's just a reusable piece of UI / Logic for me.
- HNSucksAss 10y ago
  The failure to envision future devices of unpredictable resolution was an insufferable failure of both Google and Apple. It's worse in Google's case because Android is more recent. I've been an iOS developer; but with Apple's continuing war on usefulness (the headphone jack being the last straw), I'm thinking of moving to Android. But everything I read and observe in the marketplace indicates that Android is a pathetically designed pile of shit.
0xFFC 10y ago
>Overall, I wouldn't say Android is poorly designed, it's just mediocre I think it is mostly have to do with company's talent pool and focus. As far as I can see (I may be wrong, this is my estimate) Google tries hard to devote best talents to 1) ads and Search and it's maintaining 2) Chrome team 3) Google apps and services online and on iPhones. After these option they try to develop Android as kinda (I don't know what is they correct word, so I am going with kinda) side project because they know the world needs an open platform for competing with apples devices. The reason because why Android is unacceptable from Google is we all used Google's best products. Chrome and search and we kinda (by default) think about Google as non fallible. But that's nowhere near the reality, they have limited number of super smart guys, and they try their best to keep core products (search and browser) much better than competitors. Most of the time when Google does release a new app their iOS apps is better than Android's ones. We would be okay if Android was from mediocre company. But it is not, it is from Google , which is the best in some areas. But they don't have unlimited talent. They are trying their best to balance. I am not saying people who worked on Android are not that bright. No I am talking about more broader picture. Of course there some excellent people who work on Android. But I am not talking about 1,2 or three. I am talking about management perspective in broader sense. This is my personal understanding, I may be completely wrong.
- yincrash 10y ago
  What are examples of the iOS app of a Google product being better than the Android one? Also, can I ask which OS you primarily use for mobile?
  - 0xFFC 10y ago
    Just Google it. http://www.theverge.com/2016/7/8/12109832/google-apps-iphone-android-motion-stills-gboard-search-hangouts http://www.theverge.com/2016/7/8/12109832/google-apps-iphone... There is so much articles and news about it. It is completely rational decision. Google like any other company at the end wants to maximize its profit, and iPhone is where the money is (Google it, 84% of profit of whole market goes to apples pocket_ I don't remember exact number). I have used HTC desire around 2011 (I don't remember the exact model name) and my gf was using Samsung note (around the same time) the experience was disaster, no updates, bloated software, no bug fix, nos security fixes. Nothing,pure marketing and pure rip off. After a year I switched to Nexus line and my gf using iPhone. We haven't thought about buying anything else since then. And right now , with this update problem Google imposing on Nexus line, my last hope for Android is dieing and I am considering buying iPhone. I switched from Nexus 4 to Nexus 5. It is unacceptable to me, device as capable as Nexus 5 doesnt get N update. Why would I use Android when I have better support, long term update with iPhone almost for same price (I could have bought iPhone 5 for 100$ 150$ more when I bought Nexus 5. Which was total mistake) And remember developing for Android is what I do for living. So I am so enthusiastic about androids future. I have really high hopes for Windows 10 phone. Their continum can be game changer. And don't forget Google is not software company, they are IT company. But Microsoft is different, they are biggest most successful software company in humankind history. They know how to develop software. The problem with their failure was stupid manager (Steve ballmer). Which is now solved. I hope they can compete with iPhone with their surface phone line. We will see how it is going to pan out.
pjmlp 10y ago
> Overall, I wouldn't say Android is poorly designed, it's just mediocre, I would expect more from Google. I completely agree and although I only do it as a hobby, there are lots of points that many in the community feel as pain. - They never managed to write a proper working emulator, while other companies had no problem doing so; - The whole debacle of C++ support, had JetBrains not decided to create CLion, to this day Eclipse CDT would be deprecated without any official path for NDK users - Speaking of NDK, the four parallel paths to build applications (old ndk-buld, experimental Gradle plugin, stable plugin with ndk-build, stable plugin with cmake), each with its own set of issues - Dalvik JIT/GC were always worse than the average J2ME /J2Embedded commercial offerings, regardless of how they used to sell the story of having to fork Java for performance - Choosing to AOT on device instead of doing at the store like everyone else, thus leading to the half-backed solution in Android 7 that everything goes (interpreter in Assembly, JIT with PGO, AOT when docked). - Android Studio just puts my computer fans in full throttle bringing back memories from Webpshere RAD, something that Eclipse CDT never did. And I am not a big Eclipse fan. - Gradle needs a background daemon with 2GB of allocated memory to match Ant or Maven performance - The SupportLibrary releases that are so well tested that always required a minor updated, because they always break something - I do approve that the NDK is constrained due to security concerns, but being forced to use JNI to call libraries that are implemented in C++ like Skia? - Forking Java community with cherry picked features from Java 6, 7 and 8. Which will only get worse now that Java 9 and 10 will bring features that will drastically change how the language is used (modules, linker, graal, value types, type inference,....). There are plenty of other issues to rant about, these are just some of them. They seem to just keep Android on some kind of "just good enough" for the masses. Literally the MS-DOS of mobile world.
- kuschku 10y ago
  Regarding ndk build, you forgot the tooling Google themselves uses for everything: Bazel That can also build NDK and Android.
  - pjmlp 10y ago
    You are right, and also reminded me that if you check the AOSP commits, they are in the process of adding a new one built with Go.
ensiferum 10y ago
> Overall, I wouldn't say Android is poorly designed, it's just mediocre, I would expect more from Google. In general, I'd say the design lacks simplicity and elegance. Some examples: Android is just one of those Big Corp projects were you hastily throw enough shit at the wall and see what sticks. It wasn't "designed", it's just the way it came out.
72deluxe 10y ago
Are you talking about Services and Activities or something else? I never had any problems with Services and Activities using them and connecting to them, using them etc. but I can see how an inexperienced dev could get this wrong. Same problem goes for not understanding detachable threads in other languages (eg. keeping a reference/pointer to them and attempting to use them when you have no idea when they've finished) but that's a newbie problem. I wouldn't say that the language or design of threads was at fault if I was using it wrong.

chinhodado 10y ago

I used to think Activity lifecycle management is complex. Then I learned about Fragments and I started to loathe every moment I have to work with them. What a bloated mess: http://staticfree.info/~steve/complete_android_fragment_lifecycle.png http://staticfree.info/~steve/complete_android_fragment_life...

sgc 10y ago
I started making a semi-complex android app as my first project. Saw the recommendation to use fragments, and I have never looked back because I am way, way too far down the rabbit whole. It's main advantage to me is perhaps nothing. I have no idea and no real way of knowing. But is has tripled my code base, so that is a good thing!
m_fayer 10y ago
Otherwise known as the "lolcycle".
tigershark 10y ago
They must have been using some seriously good drug when "designing" this mess..
V-2 10y ago
And then there are nested fragments and all the caveats associated with them, but it's all good, it just requires some simple fixes everyone could come up off the top of their head, like http://stackoverflow.com/a/23276145/168719 http://stackoverflow.com/a/23276145/168719 (the top voted answer) It's good, because it doesn't require you to use the workaround of deluding the user with a SCREENSHOT of your layout (sic; see the accepted answer above).
- nodamage 10y ago
  Good lord. How absurd that this is even necessary in the first place.
- BoorishBears 10y ago
  Support fragments "fixed" nested fragments a little while back, or so they claimed in a change log.
  - V-2 10y ago
    I don't even know; I imagine at that point there wasn't many developers left around still willing to go down that route. As an Android dev I'm in the camp that steers clear of Fragments out of principle, if only possible.
    - BoorishBears 10y ago
      I'm pragmatic about them and they work out. It takes some discipline, but in exchange you get to use a standard back stack manager with more mindshare than any 3rd party replacement like Flow will have. My personal guidelines are: Only use them in a single form. FragmentTransaction add/remove/replace, no fragment tags in xml to cause inconsistent behavior Represent state with single AutoValue + Auto Parcel object and save it with Icepick so they work with process death automatically Implement all interactions with other threads via RxJava so I can unsubscribe and avoid "after onInstanceState exceptions" Use custom view groups instead of nested fragments since nested fragments tend to not be using the backstack anyways

yincrash 10y ago

Some historical context, fragments came out with Honeycomb which was the first version of Android specifically for tablets. As such Fragments were meant to be a way write UI in something both tablet and phone layouts could use. So, that's the mysterious reason for the extra layer of complexity. I think at this point, many people don't even use them unless they specifically need to for tablet/phone/tv shared layouts. There are also other alternative patterns that have emerged that are less complicated

digi_owl 10y ago
Also, they envisioned tablets to be used mostly in landscape. That's why we got everything on a single bar at the bottom. The basic concept behind Fragments was pretty much the same as WebOS' Enyo framework. I recall one of the big Enyo demo moments was when a browser window was resized, and the email app ui went from multiple columns to a single column, and back, without missing a beat. Then again i wonder if Android was partially designed, before Fragments, to rekindle the experience of using Apple's Newton tablet. This in that one app would extend the functionality of another app in a virtually seamless manner via intents. But as best i can tell, Android left too much of the plumbing in the hands of the app devs. Thus for every app that handled cross-app intents properly, you got 100+ that would jump back through the in-app activity history rather than roll back the intent chain. And with fragments you got a in-app way to do the activity history backtracking, while still having the intent focused back button of the Android UI.
dimillian 10y ago
I use Fragments as "Content View Controller", phone / tablet whatever, it's just a reusable piece of UI / Logic for me.
HNSucksAss 10y ago
The failure to envision future devices of unpredictable resolution was an insufferable failure of both Google and Apple. It's worse in Google's case because Android is more recent. I've been an iOS developer; but with Apple's continuing war on usefulness (the headphone jack being the last straw), I'm thinking of moving to Android. But everything I read and observe in the marketplace indicates that Android is a pathetically designed pile of shit.

0xFFC 10y ago

>Overall, I wouldn't say Android is poorly designed, it's just mediocre I think it is mostly have to do with company's talent pool and focus. As far as I can see (I may be wrong, this is my estimate) Google tries hard to devote best talents to 1) ads and Search and it's maintaining 2) Chrome team 3) Google apps and services online and on iPhones. After these option they try to develop Android as kinda (I don't know what is they correct word, so I am going with kinda) side project because they know the world needs an open platform for competing with apples devices. The reason because why Android is unacceptable from Google is we all used Google's best products. Chrome and search and we kinda (by default) think about Google as non fallible. But that's nowhere near the reality, they have limited number of super smart guys, and they try their best to keep core products (search and browser) much better than competitors. Most of the time when Google does release a new app their iOS apps is better than Android's ones. We would be okay if Android was from mediocre company. But it is not, it is from Google , which is the best in some areas. But they don't have unlimited talent. They are trying their best to balance. I am not saying people who worked on Android are not that bright. No I am talking about more broader picture. Of course there some excellent people who work on Android. But I am not talking about 1,2 or three. I am talking about management perspective in broader sense. This is my personal understanding, I may be completely wrong.

yincrash 10y ago
What are examples of the iOS app of a Google product being better than the Android one? Also, can I ask which OS you primarily use for mobile?
- 0xFFC 10y ago
  Just Google it. http://www.theverge.com/2016/7/8/12109832/google-apps-iphone-android-motion-stills-gboard-search-hangouts http://www.theverge.com/2016/7/8/12109832/google-apps-iphone... There is so much articles and news about it. It is completely rational decision. Google like any other company at the end wants to maximize its profit, and iPhone is where the money is (Google it, 84% of profit of whole market goes to apples pocket_ I don't remember exact number). I have used HTC desire around 2011 (I don't remember the exact model name) and my gf was using Samsung note (around the same time) the experience was disaster, no updates, bloated software, no bug fix, nos security fixes. Nothing,pure marketing and pure rip off. After a year I switched to Nexus line and my gf using iPhone. We haven't thought about buying anything else since then. And right now , with this update problem Google imposing on Nexus line, my last hope for Android is dieing and I am considering buying iPhone. I switched from Nexus 4 to Nexus 5. It is unacceptable to me, device as capable as Nexus 5 doesnt get N update. Why would I use Android when I have better support, long term update with iPhone almost for same price (I could have bought iPhone 5 for 100$ 150$ more when I bought Nexus 5. Which was total mistake) And remember developing for Android is what I do for living. So I am so enthusiastic about androids future. I have really high hopes for Windows 10 phone. Their continum can be game changer. And don't forget Google is not software company, they are IT company. But Microsoft is different, they are biggest most successful software company in humankind history. They know how to develop software. The problem with their failure was stupid manager (Steve ballmer). Which is now solved. I hope they can compete with iPhone with their surface phone line. We will see how it is going to pan out.

pjmlp 10y ago

> Overall, I wouldn't say Android is poorly designed, it's just mediocre, I would expect more from Google. I completely agree and although I only do it as a hobby, there are lots of points that many in the community feel as pain. - They never managed to write a proper working emulator, while other companies had no problem doing so; - The whole debacle of C++ support, had JetBrains not decided to create CLion, to this day Eclipse CDT would be deprecated without any official path for NDK users - Speaking of NDK, the four parallel paths to build applications (old ndk-buld, experimental Gradle plugin, stable plugin with ndk-build, stable plugin with cmake), each with its own set of issues - Dalvik JIT/GC were always worse than the average J2ME /J2Embedded commercial offerings, regardless of how they used to sell the story of having to fork Java for performance - Choosing to AOT on device instead of doing at the store like everyone else, thus leading to the half-backed solution in Android 7 that everything goes (interpreter in Assembly, JIT with PGO, AOT when docked). - Android Studio just puts my computer fans in full throttle bringing back memories from Webpshere RAD, something that Eclipse CDT never did. And I am not a big Eclipse fan. - Gradle needs a background daemon with 2GB of allocated memory to match Ant or Maven performance - The SupportLibrary releases that are so well tested that always required a minor updated, because they always break something - I do approve that the NDK is constrained due to security concerns, but being forced to use JNI to call libraries that are implemented in C++ like Skia? - Forking Java community with cherry picked features from Java 6, 7 and 8. Which will only get worse now that Java 9 and 10 will bring features that will drastically change how the language is used (modules, linker, graal, value types, type inference,....). There are plenty of other issues to rant about, these are just some of them. They seem to just keep Android on some kind of "just good enough" for the masses. Literally the MS-DOS of mobile world.

kuschku 10y ago
Regarding ndk build, you forgot the tooling Google themselves uses for everything: Bazel That can also build NDK and Android.
- pjmlp 10y ago
  You are right, and also reminded me that if you check the AOSP commits, they are in the process of adding a new one built with Go.

ensiferum 10y ago

> Overall, I wouldn't say Android is poorly designed, it's just mediocre, I would expect more from Google. In general, I'd say the design lacks simplicity and elegance. Some examples: Android is just one of those Big Corp projects were you hastily throw enough shit at the wall and see what sticks. It wasn't "designed", it's just the way it came out.

72deluxe 10y ago

Are you talking about Services and Activities or something else? I never had any problems with Services and Activities using them and connecting to them, using them etc. but I can see how an inexperienced dev could get this wrong. Same problem goes for not understanding detachable threads in other languages (eg. keeping a reference/pointer to them and attempting to use them when you have no idea when they've finished) but that's a newbie problem. I wouldn't say that the language or design of threads was at fault if I was using it wrong.