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

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>