6 ms·

Google should do this for regular Android APIs. The frequency you have to look up special-android-things is stunning –> disrupts your flow = very bad There are

Google should do this for regular Android APIs. The frequency you have to look up special-android-things is stunning –> disrupts your flow = very bad There are way too many things you have to keep in your head on Android to get things right (https://developer.android.com/guide/components/images/activity_lifecycle.png https://developer.android.com/guide/components/images/activi...). The approach Google took here - do what ever you want, we won't tell/force you, is pure wrong (I'm a bit exaggerating, but still). Developers wasted millions of hours of dev-time and therefor money to figuring out how to do basic things, like saving application state when the device is rotated or another app comes to foreground (testing state-changes is also complicated). There were complains about how state-saving is handled, but Google ignored them for many many years. Every platform has good and bad points, acknowledged, but not having a clear-line, a way how things should be done, is to me indecisive leadership and a very big mistake I would not have expected from Google. Last AndroidIO things got better with the introduction of so called "Architecture Components" (among other things a SQLite ORM and guide how basic things should be done, finally). I wonder what took them so long.

ashark 9y ago
Going back and forth between Android's SDK and docs and Apple's for iOS is like alternating between navigating a labyrinth with a floor of hot coals and, somewhere, the howls of wolves, and relaxing in a nice warm bath with a glass of wine and a good book.
- mercer 9y ago
  As someone about to take the plunge into mobile development (and slightly leaning towards iOS over Android), I'd love to hear some elaboration on your experiences.
  - ashark 9y ago
    iOS: docs are so good you'll find yourself reading way past what you actually need, just for fun. They're great. APIs generally well thought out. Examples current. Xcode's sometimes frustrating, but not that bad. Worst part's the signing process which remains prone to breaking for mysterious reasons (this is probably less true if you have just one project that's always current, but if you have historical projects that need upkeep and you bounce between different apps it's bad) and I still have to look up again how to get all the parts working if I go more than a few months without messing with it, because I can't seem to keep it in my head. Android: most docs amount to half-assed Javadoc output. Longer-form sections frequently contain bad advice and outdated examples. When the examples aren't outdated they always seem to avoid demonstrating the particular use you need them to, as if by magic. APIs themselves sometimes weirdly bad (see, at least as of ~6 months ago, the Android google maps address search API being significantly worse than the Javascript one). New UI elements are frequently a duct-tape-heavy veneer over existing UI elements that lacks customization you'd expect to exist, unless you resort to reflection, and generally feel like something the summer interns threw together. Support for all that pretty Material UI stuff is laughable. And while I know there isn't an iOS public bugtracker to compare it to and that that's also kind of a bad situation, the Android bugtracker is mostly useful as a source of either comedy or suicidal ideation, depending on your demeanor. You'll learn what I mean if you spend much time with Android. For Android your best bet is to read everything Square (yes, that Square) has written about it, and follow their patterns and use their libraries wherever possible. See: https://github.com/square/flow https://github.com/square/flow https://github.com/square/retrofit https://github.com/square/retrofit https://medium.com/square-corner-blog/simpler-android-apps-with-flow-and-mortar-5beafcd83761 https://medium.com/square-corner-blog/simpler-android-apps-w... and so on.
- esrauch 9y ago
  The converse side of this is when you do hit something that isn't covered by the iOS documentation (and also can't find some random WWDC talk) you are completely stuck with no avenue to find out the answer, whereas with Android you can pull up the AOSP source and often find the answer to the question yourself.
- izacus 9y ago
  Really? Because as an Android developer I have the exact opposite experience - navigating around Apple's iOS documentation feels like digging through obsolete webpages where bunch of parameters and methods aren't documented at all (especially around bitmap processing and some other older APIs).
lukasb 9y ago
Hi, I work for Google on Android developer UX, including Architecture Components and the Support Library. Looking to collect as much feedback as I can. Requirements+approach+pain points preferred, but if you prefer to just vent I'll also take it as data. Thanks, and sorry to spam the thread.
- mjw1007 9y ago
  For a start, the image that thibran posted could be fixed. It isn't consistent about whether the bordered rectangles represent represent onFoo() calls or the state after their calls. The page it comes from says « the colored ovals are major states the Activity can be in ». There should be a coloured oval for the (rather common) state where the Activity is the background after onStop(), and the two arrows coming out of onStop() should come out of that oval.
  - lukasb 9y ago
    What do you think of this diagram? https://developer.android.com/images/topic/libraries/architecture/lifecycle-states.png https://developer.android.com/images/topic/libraries/archite... From this page we launched in May: https://developer.android.com/topic/libraries/architecture/lifecycle.html https://developer.android.com/topic/libraries/architecture/l...
    - mjw1007 9y ago
      I think representing each state by two separate boxes containing the same text is strange and confusing. If it didn't do that, it would be able to avoid having the 'on create' line appear to pass through the 'destroyed' state.
- thibran 9y ago
  Hi lukasb, my last Android dev job was two years ago, I try my best to give you some feedback. Lets start with expectations. I expect that tasks performed by the majority of Android developers are actively supported by Google and are as easy as possible, with as few code lines as possible. # REST - A lot of apps consume REST APIs. REST is almost the standard way to communicate with the outside world. Therefor the Android framework should include APIs to consume and send REST-requests and parse JSON easily (a support-rest lib would be nice, too). Depending for one of the main use-cases on third-party software is not okay. # SQLite - Android really needs a support-sqlite library. Right now you have to use SQL features of the lowest supported api level, which means you are stuck in the past (if you want to stick with the default). # Permissions - https://developer.android.com/training/permissions/requesting.html#handle-response https://developer.android.com/training/permissions/requestin... - Handling permissions for older and new devices is a nightmare. I would expect to be able to declare the need for a certain permissions in – lets say 10 seconds – but figuring out how to get the permission bits right took fare longer (maybe 1 hour) and if I had to do it again, it would probably need again one hour. Instead of half a screen of boilerplate code and an activity-callback like onRequestPermissionsResult(), it would be nice if there where a PremissionBuilder, which would allow to easily setup permissions (spreading code all over the activity to do a basic thing is not that great). # Cache - https://developer.android.com/topic/performance/graphics/cache-bitmap.html https://developer.android.com/topic/performance/graphics/cac... - Almost every dev needs & should cache data to improve app responsiveness and use the network less... To my knowledge there is no easy >>general<< caching mechanism in Android (maybe support-cache in the future ??). There is LruCache, but using it means almost writing all caching stuff yourself. Okay, there is Glide for images, which should probably be part of Android, but beside of that, void :). What would I expect? An API which lets you declare how something should be fetched, how many bytes/how long it should be in memory and if and how it should be saved to disk. Caching is such a general problem, I wonder why it hasn't been solved long time ago (we don't need the perfect solution, we need a solution – since it's such a common problem I don't feel like its my job as app-dev to solve it, I can, but I shouldn't do it). # Effects/Transitions - During my Android years creating custom effects was very complicated and frustrating. Opening Qt Quick Designer for the first time and seeing how easy it is there, I was kind of shocked. # Outdated information/blog posts - When researching a topic it is very easy to come along outdated knowledge. This is a real problem, since you don't know what you don't know. Sometimes I did things, just to learn later that there is a newer/better Android API. Since Google has not much control over it, I would suggest that Google keeps track of their own blog posts/articles and move them after some time into an archive or put a big (orange) banner on top of them, telling the reader that the content is outdated. Managing the produced textual output might be boring, but it seems to be necessary. I don't know if any company has ever done something like this... but, it would be great. # Android takes up too much time & attention - Its difficult to describe the cause, but overall I felt like I did fight way too much with the framework, even after years of experience with it. I never had the time to care about things like battery saving APIs and such. It's sad and I wish I could have spend some more time following best-practices. Overall I think Android has to become simpler, I assume most people don't spend a huge amount of time learning all the bits of a given topic, they just want to get things done. Fare too often you have to know hell of a lot of things in Android, write a lot of code, like for RecyclerView with a custom Adapter (most people probably need a custom adapter, even the example is already cluttered) https://developer.android.com/training/material/lists-cards.html#RVExamples https://developer.android.com/training/material/lists-cards.... ... it's just too much code for such basic functionality. # Android Studio UI ... has too many buttons, even for things like copy & paste, back & forward and may other buttons, I doubt those are use that often (we are experts, not computer novices). I know I can customize the UI, but still I wish the default was less overloaded :) I acknowledge the huge amount of work Google did to make Android better over the years and things got really better. The introduction of the support library was stellar, thanks! </brain-dump>

ashark 9y ago

Going back and forth between Android's SDK and docs and Apple's for iOS is like alternating between navigating a labyrinth with a floor of hot coals and, somewhere, the howls of wolves, and relaxing in a nice warm bath with a glass of wine and a good book.

mercer 9y ago
As someone about to take the plunge into mobile development (and slightly leaning towards iOS over Android), I'd love to hear some elaboration on your experiences.
- ashark 9y ago
  iOS: docs are so good you'll find yourself reading way past what you actually need, just for fun. They're great. APIs generally well thought out. Examples current. Xcode's sometimes frustrating, but not that bad. Worst part's the signing process which remains prone to breaking for mysterious reasons (this is probably less true if you have just one project that's always current, but if you have historical projects that need upkeep and you bounce between different apps it's bad) and I still have to look up again how to get all the parts working if I go more than a few months without messing with it, because I can't seem to keep it in my head. Android: most docs amount to half-assed Javadoc output. Longer-form sections frequently contain bad advice and outdated examples. When the examples aren't outdated they always seem to avoid demonstrating the particular use you need them to, as if by magic. APIs themselves sometimes weirdly bad (see, at least as of ~6 months ago, the Android google maps address search API being significantly worse than the Javascript one). New UI elements are frequently a duct-tape-heavy veneer over existing UI elements that lacks customization you'd expect to exist, unless you resort to reflection, and generally feel like something the summer interns threw together. Support for all that pretty Material UI stuff is laughable. And while I know there isn't an iOS public bugtracker to compare it to and that that's also kind of a bad situation, the Android bugtracker is mostly useful as a source of either comedy or suicidal ideation, depending on your demeanor. You'll learn what I mean if you spend much time with Android. For Android your best bet is to read everything Square (yes, that Square) has written about it, and follow their patterns and use their libraries wherever possible. See: https://github.com/square/flow https://github.com/square/flow https://github.com/square/retrofit https://github.com/square/retrofit https://medium.com/square-corner-blog/simpler-android-apps-with-flow-and-mortar-5beafcd83761 https://medium.com/square-corner-blog/simpler-android-apps-w... and so on.
esrauch 9y ago
The converse side of this is when you do hit something that isn't covered by the iOS documentation (and also can't find some random WWDC talk) you are completely stuck with no avenue to find out the answer, whereas with Android you can pull up the AOSP source and often find the answer to the question yourself.
izacus 9y ago
Really? Because as an Android developer I have the exact opposite experience - navigating around Apple's iOS documentation feels like digging through obsolete webpages where bunch of parameters and methods aren't documented at all (especially around bitmap processing and some other older APIs).

lukasb 9y ago

Hi, I work for Google on Android developer UX, including Architecture Components and the Support Library. Looking to collect as much feedback as I can. Requirements+approach+pain points preferred, but if you prefer to just vent I'll also take it as data. Thanks, and sorry to spam the thread.

mjw1007 9y ago
For a start, the image that thibran posted could be fixed. It isn't consistent about whether the bordered rectangles represent represent onFoo() calls or the state after their calls. The page it comes from says « the colored ovals are major states the Activity can be in ». There should be a coloured oval for the (rather common) state where the Activity is the background after onStop(), and the two arrows coming out of onStop() should come out of that oval.
- lukasb 9y ago
  What do you think of this diagram? https://developer.android.com/images/topic/libraries/architecture/lifecycle-states.png https://developer.android.com/images/topic/libraries/archite... From this page we launched in May: https://developer.android.com/topic/libraries/architecture/lifecycle.html https://developer.android.com/topic/libraries/architecture/l...
  - mjw1007 9y ago
    I think representing each state by two separate boxes containing the same text is strange and confusing. If it didn't do that, it would be able to avoid having the 'on create' line appear to pass through the 'destroyed' state.
thibran 9y ago
Hi lukasb, my last Android dev job was two years ago, I try my best to give you some feedback. Lets start with expectations. I expect that tasks performed by the majority of Android developers are actively supported by Google and are as easy as possible, with as few code lines as possible. # REST - A lot of apps consume REST APIs. REST is almost the standard way to communicate with the outside world. Therefor the Android framework should include APIs to consume and send REST-requests and parse JSON easily (a support-rest lib would be nice, too). Depending for one of the main use-cases on third-party software is not okay. # SQLite - Android really needs a support-sqlite library. Right now you have to use SQL features of the lowest supported api level, which means you are stuck in the past (if you want to stick with the default). # Permissions - https://developer.android.com/training/permissions/requesting.html#handle-response https://developer.android.com/training/permissions/requestin... - Handling permissions for older and new devices is a nightmare. I would expect to be able to declare the need for a certain permissions in – lets say 10 seconds – but figuring out how to get the permission bits right took fare longer (maybe 1 hour) and if I had to do it again, it would probably need again one hour. Instead of half a screen of boilerplate code and an activity-callback like onRequestPermissionsResult(), it would be nice if there where a PremissionBuilder, which would allow to easily setup permissions (spreading code all over the activity to do a basic thing is not that great). # Cache - https://developer.android.com/topic/performance/graphics/cache-bitmap.html https://developer.android.com/topic/performance/graphics/cac... - Almost every dev needs & should cache data to improve app responsiveness and use the network less... To my knowledge there is no easy >>general<< caching mechanism in Android (maybe support-cache in the future ??). There is LruCache, but using it means almost writing all caching stuff yourself. Okay, there is Glide for images, which should probably be part of Android, but beside of that, void :). What would I expect? An API which lets you declare how something should be fetched, how many bytes/how long it should be in memory and if and how it should be saved to disk. Caching is such a general problem, I wonder why it hasn't been solved long time ago (we don't need the perfect solution, we need a solution – since it's such a common problem I don't feel like its my job as app-dev to solve it, I can, but I shouldn't do it). # Effects/Transitions - During my Android years creating custom effects was very complicated and frustrating. Opening Qt Quick Designer for the first time and seeing how easy it is there, I was kind of shocked. # Outdated information/blog posts - When researching a topic it is very easy to come along outdated knowledge. This is a real problem, since you don't know what you don't know. Sometimes I did things, just to learn later that there is a newer/better Android API. Since Google has not much control over it, I would suggest that Google keeps track of their own blog posts/articles and move them after some time into an archive or put a big (orange) banner on top of them, telling the reader that the content is outdated. Managing the produced textual output might be boring, but it seems to be necessary. I don't know if any company has ever done something like this... but, it would be great. # Android takes up too much time & attention - Its difficult to describe the cause, but overall I felt like I did fight way too much with the framework, even after years of experience with it. I never had the time to care about things like battery saving APIs and such. It's sad and I wish I could have spend some more time following best-practices. Overall I think Android has to become simpler, I assume most people don't spend a huge amount of time learning all the bits of a given topic, they just want to get things done. Fare too often you have to know hell of a lot of things in Android, write a lot of code, like for RecyclerView with a custom Adapter (most people probably need a custom adapter, even the example is already cluttered) https://developer.android.com/training/material/lists-cards.html#RVExamples https://developer.android.com/training/material/lists-cards.... ... it's just too much code for such basic functionality. # Android Studio UI ... has too many buttons, even for things like copy & paste, back & forward and may other buttons, I doubt those are use that often (we are experts, not computer novices). I know I can customize the UI, but still I wish the default was less overloaded :) I acknowledge the huge amount of work Google did to make Android better over the years and things got really better. The introduction of the support library was stellar, thanks! </brain-dump>