4 ms·

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 t

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>

lukasb 9y ago
REST - we recommend Retrofit, and don't have plans to do anything else here. sqlite - please check out Room from Architecture Components (soon to exit alpha, already pretty stable) permissions, transitions - haven't done work here but will look into, ask people who do cache - we're aware there's a gap here. if there's a library here you think i should look at, let me know. outdated info / blog posts - we're looking at how to improve developer.android.com to make sure people get the latest guidance. i'll see if we can expand scope to include blog posts. btw, if anyone has recommendations for how to address people finding outdated answers on StackOverflow ... i'm all ears. too much time & attention - definitely agree with the general point, and for RecyclerView specifically yes, I think we can make this simpler. Android Studio UI - we have some very good UX people now, but (1) it will take time for their work to launch and (2) there's only so far we can move from IntelliJ's approach, which is very much "we'll give you lots of options and you can customize to simplify" thanks for the brain dump! very helpful.
- lukasb 9y ago
  btw, we don't have a problem with recommending good, well-maintained third-party libraries. no reason to reinvent the wheel. (although lawyercat wants me to note that a recommendation is not a guarantee of fitness, if it causes your machine to blow up we're absolved of all blame, etc.)
- thibran 9y ago
  brain dump part 2 Now that I spend some time thinking about Android, other things popped back to my mind. # back-stack - For all the time I spend in Android I wished there where a tool to log/see the current state of the back-stack. I tried hard to have a correct mind-model of it, but too often the app behaved differently, so I did fallback to try-and-error which consumed a lot of time and was very frustrating. App navigation is too hard, there are too many places where you specify navigation bits and too many tools/code paths to implement it. I would suggest to move all navigation/back-stack settings from the activity/manifest into >>one<< separate file for all screens of the app where all navigation settings are displayed and all possible navigation flows are modeled – with the possibility for Google to later add a graphical representation, like done for the xml layout preview. As a plus, transition effects could be specified in that file too. I assume this would be a looooooot of work :) # A code coverage tool like it exists for Go is super helpful. It highlights lines that are tested and which are not, take a look at Visual Studio Code, with the Go extension installed: http://i.imgur.com/7mvRjLC.png http://i.imgur.com/7mvRjLC.png # Bundle/Intent data - Passing data to another activity is too cumbersome. Maybe this is something that could be solve by annotations. I always wrote factory methods like newMyActivity(...) to have the code all in one place, but writing such code always felt like a wast of time. Implementing Parcelable (the auto-generation function was god send), is jet another boilaplate code piece you have to update as soon as something changes, so it helps not that much. # Resource folder - This is an old complain but it holds. If you have a medium to big size app your layout resource folder grows way too big. Because it is not possible to create sub-folders you have to invent ugly long names. Maybe a per-activity layout folder would help here, without introducing too many folder-layers (those could later be auto-merged into a single folder by a tool). # App resources - It is difficult to know if your app uses too much resources. There are resource-viewers hidden somewhere in Android-Studio UI (you have to know that they exist). I would wish if I would get automatically a warning, if something exceeds a common threshold, so that I can try to be a better citizen without spending too much time there. Optimizing resources is something to do later, if there is ever time for it (depends on your boss). As dev it would be easy for me to tell a tool (maybe in the manifest.xml) that my app should have low/medium/high disk/network/memory usage, but observing if that assumption holds is time consuming. If e.g. I would classify the app as low disk usage, but for some reason the disk is accessed all time, there is probably something wrong. Telling devs that they consume to many resources might be an easy way to improve battery-duration for all of us -> it's hard to do something right, when you don't know that you do it wrong. # The Context object - I struggled for quite some time to learn all the wrapper-objects that contain a Context and should therefor not be kept in memory. I don't know what kind of advice I would give a new dev to circumvent the context pitfall, this is unexpectedly a hard one. # Image zoom - When working with images I was surprised to find out that there is no flag which allows the user to pinch-zoom into it. Implementing image pinch-zoom took way too many lines of code and was way more complicated than it should have been (I don't know what the current state of this problem is, maybe it got solved in the meantime). If not, there should be really a simple way to get this feature, maybe it would need a new image tag, like zoomable-image or so, but it should exist. # Image-to-full-size - There is the common pattern, that you have an image and when touched, it should be displayed fullscreen. As far as I know you have to hand-write that code. Attached to this use-case is effective image loading, like loading only the pixels into ram you know can be displayed, or ignoring the alpha channel... This image handling util could be extended by having the possibility to load the next image by fling-pushing the current image to the left/right. Right now you write a lot of boilerplate code and maybe miss quite a lot of optimizations if you don't read enough about the topic. # LayoutInflater - The inflate() method was for a long time confusing to me, because of the attachToRoot param. It should be easy, for some reason it is not. Do a google search about the topic, people are confused :) # Custom views - For years there was not much information on how to create custom views. Than there appeared an official tutorials about how to extend the View class. I feel like the docs miss here something. When I was in the need of a custom view I always extended a view-group container, not the View class itself, because it's much simpler and gets the job done. There should probably be more information about that kind of custom view, the we-extend-the-view-class is the most complicated and maybe also a very rarely needed use-case (btw, I never used canvas to do anything). https://developer.android.com/training/custom-views/create-view.html https://developer.android.com/training/custom-views/create-v... # Menu items - Should probably be handled by a builder too, instead of a couple of callbacks (there are too many activity-callbacks, leading overall to spaghetti-code). # Multi-layout - I wonder if Google ever thought about having a multi-layout-container, which would depending on your display size, displaying/hiding different views automatically. On the left a nav-pannel, mid the content and on the right, optional content pages. Such a setup feels like a classic setup. You can code it yourself, which would take ~3-6 classes and a lot of glue code (and documentation look-ups therefor). I wonder why there is not something like this already (maybe there is, and I have just missed it). # Video-cast for experienced Android developers - For Go there is JustForFunc https://www.youtube.com/channel/UC_BzFbxG2za3bp5NRRRXJSw https://www.youtube.com/channel/UC_BzFbxG2za3bp5NRRRXJSw which hits a lot of nails. Watching a grand master Go dev doing a code-review or implement a little gem gives you more insights into his thoughts and tooling than 10 blog posts ever could. JustForFunc is pure awesome, entertaining and has a really good time-to-value rate. Even after years of experience with Go, I learned quite a lot watching Francesc Campoy code. I should probably also let you know that I loved the code inspection features of Android Studio. They really did make a big difference and helped me to keep my code clean (especially the resource files). For the value that inspections give you, they are IMHO a bit to hidden in the UI. Also Dagger2 did help a lot. The difference between code without and with Dagger2 is like day and night. Maybe Dagger2 should be pushed more. Ah, and Kotlin is awesome, sooo much better than Java. </brain-dump>

lukasb 9y ago

REST - we recommend Retrofit, and don't have plans to do anything else here. sqlite - please check out Room from Architecture Components (soon to exit alpha, already pretty stable) permissions, transitions - haven't done work here but will look into, ask people who do cache - we're aware there's a gap here. if there's a library here you think i should look at, let me know. outdated info / blog posts - we're looking at how to improve developer.android.com to make sure people get the latest guidance. i'll see if we can expand scope to include blog posts. btw, if anyone has recommendations for how to address people finding outdated answers on StackOverflow ... i'm all ears. too much time & attention - definitely agree with the general point, and for RecyclerView specifically yes, I think we can make this simpler. Android Studio UI - we have some very good UX people now, but (1) it will take time for their work to launch and (2) there's only so far we can move from IntelliJ's approach, which is very much "we'll give you lots of options and you can customize to simplify" thanks for the brain dump! very helpful.

lukasb 9y ago
btw, we don't have a problem with recommending good, well-maintained third-party libraries. no reason to reinvent the wheel. (although lawyercat wants me to note that a recommendation is not a guarantee of fitness, if it causes your machine to blow up we're absolved of all blame, etc.)
thibran 9y ago
brain dump part 2 Now that I spend some time thinking about Android, other things popped back to my mind. # back-stack - For all the time I spend in Android I wished there where a tool to log/see the current state of the back-stack. I tried hard to have a correct mind-model of it, but too often the app behaved differently, so I did fallback to try-and-error which consumed a lot of time and was very frustrating. App navigation is too hard, there are too many places where you specify navigation bits and too many tools/code paths to implement it. I would suggest to move all navigation/back-stack settings from the activity/manifest into >>one<< separate file for all screens of the app where all navigation settings are displayed and all possible navigation flows are modeled – with the possibility for Google to later add a graphical representation, like done for the xml layout preview. As a plus, transition effects could be specified in that file too. I assume this would be a looooooot of work :) # A code coverage tool like it exists for Go is super helpful. It highlights lines that are tested and which are not, take a look at Visual Studio Code, with the Go extension installed: http://i.imgur.com/7mvRjLC.png http://i.imgur.com/7mvRjLC.png # Bundle/Intent data - Passing data to another activity is too cumbersome. Maybe this is something that could be solve by annotations. I always wrote factory methods like newMyActivity(...) to have the code all in one place, but writing such code always felt like a wast of time. Implementing Parcelable (the auto-generation function was god send), is jet another boilaplate code piece you have to update as soon as something changes, so it helps not that much. # Resource folder - This is an old complain but it holds. If you have a medium to big size app your layout resource folder grows way too big. Because it is not possible to create sub-folders you have to invent ugly long names. Maybe a per-activity layout folder would help here, without introducing too many folder-layers (those could later be auto-merged into a single folder by a tool). # App resources - It is difficult to know if your app uses too much resources. There are resource-viewers hidden somewhere in Android-Studio UI (you have to know that they exist). I would wish if I would get automatically a warning, if something exceeds a common threshold, so that I can try to be a better citizen without spending too much time there. Optimizing resources is something to do later, if there is ever time for it (depends on your boss). As dev it would be easy for me to tell a tool (maybe in the manifest.xml) that my app should have low/medium/high disk/network/memory usage, but observing if that assumption holds is time consuming. If e.g. I would classify the app as low disk usage, but for some reason the disk is accessed all time, there is probably something wrong. Telling devs that they consume to many resources might be an easy way to improve battery-duration for all of us -> it's hard to do something right, when you don't know that you do it wrong. # The Context object - I struggled for quite some time to learn all the wrapper-objects that contain a Context and should therefor not be kept in memory. I don't know what kind of advice I would give a new dev to circumvent the context pitfall, this is unexpectedly a hard one. # Image zoom - When working with images I was surprised to find out that there is no flag which allows the user to pinch-zoom into it. Implementing image pinch-zoom took way too many lines of code and was way more complicated than it should have been (I don't know what the current state of this problem is, maybe it got solved in the meantime). If not, there should be really a simple way to get this feature, maybe it would need a new image tag, like zoomable-image or so, but it should exist. # Image-to-full-size - There is the common pattern, that you have an image and when touched, it should be displayed fullscreen. As far as I know you have to hand-write that code. Attached to this use-case is effective image loading, like loading only the pixels into ram you know can be displayed, or ignoring the alpha channel... This image handling util could be extended by having the possibility to load the next image by fling-pushing the current image to the left/right. Right now you write a lot of boilerplate code and maybe miss quite a lot of optimizations if you don't read enough about the topic. # LayoutInflater - The inflate() method was for a long time confusing to me, because of the attachToRoot param. It should be easy, for some reason it is not. Do a google search about the topic, people are confused :) # Custom views - For years there was not much information on how to create custom views. Than there appeared an official tutorials about how to extend the View class. I feel like the docs miss here something. When I was in the need of a custom view I always extended a view-group container, not the View class itself, because it's much simpler and gets the job done. There should probably be more information about that kind of custom view, the we-extend-the-view-class is the most complicated and maybe also a very rarely needed use-case (btw, I never used canvas to do anything). https://developer.android.com/training/custom-views/create-view.html https://developer.android.com/training/custom-views/create-v... # Menu items - Should probably be handled by a builder too, instead of a couple of callbacks (there are too many activity-callbacks, leading overall to spaghetti-code). # Multi-layout - I wonder if Google ever thought about having a multi-layout-container, which would depending on your display size, displaying/hiding different views automatically. On the left a nav-pannel, mid the content and on the right, optional content pages. Such a setup feels like a classic setup. You can code it yourself, which would take ~3-6 classes and a lot of glue code (and documentation look-ups therefor). I wonder why there is not something like this already (maybe there is, and I have just missed it). # Video-cast for experienced Android developers - For Go there is JustForFunc https://www.youtube.com/channel/UC_BzFbxG2za3bp5NRRRXJSw https://www.youtube.com/channel/UC_BzFbxG2za3bp5NRRRXJSw which hits a lot of nails. Watching a grand master Go dev doing a code-review or implement a little gem gives you more insights into his thoughts and tooling than 10 blog posts ever could. JustForFunc is pure awesome, entertaining and has a really good time-to-value rate. Even after years of experience with Go, I learned quite a lot watching Francesc Campoy code. I should probably also let you know that I loved the code inspection features of Android Studio. They really did make a big difference and helped me to keep my code clean (especially the resource files). For the value that inspections give you, they are IMHO a bit to hidden in the UI. Also Dagger2 did help a lot. The difference between code without and with Dagger2 is like day and night. Maybe Dagger2 should be pushed more. Ah, and Kotlin is awesome, sooo much better than Java. </brain-dump>