3 ms·

One of the biggest challenges for building on Android is its complexity, and the team must successfully integrate with a lot of surface area conceptually (the f

One of the biggest challenges for building on Android is its complexity, and the team must successfully integrate with a lot of surface area conceptually (the fundamental building blocks Dianne explains is just the start). This unusually negative comment thread (for HN, I think) is probably illustrative of how frustrating Android development can be. On the other hand, it's been clear to me that Google is investing heavily in making Android an easier platform to develop for. First, the tooling: Moving to Gradle for the build system was a huge improvement. Making a repeatable, extensible build is the vital with teams moving towards the DevOps world with CI/CD. Android Studio has also been a welcome change; all of the separate components of the build being integrated together makes for a much better development experience. The best example of this is Instant Run, which is a great accomplishment for the tooling team. The Support Libraries are also a solid investment for implementing good patterns - particularly patterns that can be tricky to implement yourself like the separately sliding appbars. Getting more developers to adopt the support libraries also allows more compatibility, since Google can release the fixes independently from platforms. YouTube has also been a great resource for Android developers as Google has been constantly releasing content about how to build better apps. Jo and Ian are really great. Anyway, I would watch this space. It might be a coincidence that Dianne made this post, or the most recent videos ("concurrent tasks with multiple documents" and "tasks and back stack", respectively) were also about basic Android features. Maybe Googlers are reflecting on what Android is due to the current news of Oracle v Google. Or maybe it's because IO is this week. I'll be watching!

HillaryBriss 10y ago
I agree that moving to AS+Gradle was a net improvement (even though Gradle is not always so quick) because it let us exactly reproduce the individual developer's build on the CI server, as you say. OTOH, I wonder how many devs really grok the Android gradle plugin and feel comfortable just writing tasks themselves without carefully copying/pasting/modifying some magical incantation from somewhere. I feel like the verdict on Instant Run is still out though. We need to get used to the complexity of IR's choices to restart the Activity or stop the entire app and reinstall the apk etc and gain solid confidence that we can just trust IR to truly reproduce our code changes in its special, optimized way.
- vorg 10y ago
  > how many devs really grok the Android gradle plugin and feel comfortable just writing tasks themselves without carefully copying/pasting That plugin uses Apache Groovy for its syntax, though in reality only a tiny non-Turing Complete portion of Groovy's syntax is used in virtually every build script out there. The main difficulty with Gradle is really the complex API it exposes to Groovy, e.g. not knowing whether to use an = like in depos = { //stuff } or depos { //stuff }

HillaryBriss 10y ago

I agree that moving to AS+Gradle was a net improvement (even though Gradle is not always so quick) because it let us exactly reproduce the individual developer's build on the CI server, as you say. OTOH, I wonder how many devs really grok the Android gradle plugin and feel comfortable just writing tasks themselves without carefully copying/pasting/modifying some magical incantation from somewhere. I feel like the verdict on Instant Run is still out though. We need to get used to the complexity of IR's choices to restart the Activity or stop the entire app and reinstall the apk etc and gain solid confidence that we can just trust IR to truly reproduce our code changes in its special, optimized way.

vorg 10y ago
> how many devs really grok the Android gradle plugin and feel comfortable just writing tasks themselves without carefully copying/pasting That plugin uses Apache Groovy for its syntax, though in reality only a tiny non-Turing Complete portion of Groovy's syntax is used in virtually every build script out there. The main difficulty with Gradle is really the complex API it exposes to Groovy, e.g. not knowing whether to use an = like in depos = { //stuff } or depos { //stuff }