5 ms·

Kudos to them. Compared to the web it's rather cumbersome to poke into packaged and released mobile apps, so I really appreciate access to the source of a real

Kudos to them. Compared to the web it's rather cumbersome to poke into packaged and released mobile apps, so I really appreciate access to the source of a real world app for learning and comparison. The Android codebase looks very modern and well structured. I think it makes great use of many of the goodies (gradle, rxjava, retrofit, dagger, android support lib, ...) and learnings (bring your own MV*; use Fragments when you need them, stick to Activities if you can) that is state of the art in Android development. I think it's a great thing to skim through if you are interested in developing for Android or to compare it to you own app. I can only assume that the same is true for I iOS. I'll certainly check it out should I start developing for that platform.

fareesh 10y ago
Was thinking about this the other day, now in the context of this release it comes to mind again - it would be kinda cool if it was a common practice for tutorial folks to make a repo where they forked the entire thing and placed comments all over which were links to videos that broke down those sections in an easy to understand way.
V-2 10y ago
Yeah, they sort of rolled out their own MVVM implementation, based on RxJava and RxLifecycle. On Android MVVM is more difficult than MVP in my opinion (the most popular choice, not counting spaghetti projects), mostly because the platform doesn't provide the "glue" needed to bind viewmodels to the UI layer. At first glance it looks like they did it without overengineering, which is another trap as far as these matters go. Clearly a work of very good experts
- Plaastix 10y ago
  That "glue" can be Android's Databinding library. I've used it to bind ViewModel data to views. Works really well.
  - V-2 10y ago
    I'm aware of it, but last I checked it didn't seem production-ready and lacked features. I believe they updated it at some point, but other than some talk at Google IO not much came out of it - even the docs didn't reflect it back then. Perhaps it's up to the task now, I admit I'm not looking it up regularly.
    - Plaastix 10y ago
      It is definitely production ready now.
- V-2 10y ago
  > In less than eight months, four engineers who had never written production Java code, let alone production Android code, shipped a 1.0. Wow. That's pretty impressive
  - brianwawok 10y ago
    It's impressive that it took almost 3 person years to ship a 1.0 of a basic app?
    - rtpg 10y ago
      it's impressive that 3 person years from _no Java experience_ was all it took. Java and Android are complex ecosystems. Not to say they couldn't have shipped it in less time. Of course they could have. But it sounds like they shipped something very well built.
      - flukus 10y ago
        But what other languages did the have experience with? If it was something similar like c#/c++/ruby/python then the time to learn java should not be significant.
        V-2 10y ago
        When it comes to Android, Java by itself is the least of problems. It's the SDK and framework that are tricky, ridden with technical debt and often far from developer-friendly.
        matwood 10y ago
        I was about to say this. In fact, you have to unlearn a lot of what works and is accepted in server side java when you move to Android. Learning the SDK and Android gotchas was by far the hardest part of my first Android app.
        flukus 10y ago
- joblack33 10y ago
  Speaking of MVP, check here too: https://github.com/6thsolution/EasyMVP https://github.com/6thsolution/EasyMVP
- polarisrising 10y ago
  When dealing with MVP on Android, how did you deal with dynamic view creation? Right now we are working on a rearchitecture and are finding that creating dynamic views in the Activity/View requires business rules we are putting in Presenter. But the Presenter doesn't have context.
swanson 10y ago
And actual tests for the Android app! It's a rarity, and especially annoying since the "sample" apps that Google provides pretends that testing doesn't exist.
- mathiasjakobsen 10y ago
  Agreed! But some great companies has been Open Source'ing their Android applications for a while. I.e. DuckDuckGo's app (https://github.com/duckduckgo/android https://github.com/duckduckgo/android) and the Forcastie weather app (https://github.com/martykan/forecastie https://github.com/martykan/forecastie). They are great references!
  - V-2 10y ago
    I quickly looked up DuckDuckGo, and - unlike this one - boy is it spaghetti: https://github.com/duckduckgo/android/blob/master/src/com/duckduckgo/mobile/android/activity/DuckDuckGo.java https://github.com/duckduckgo/android/blob/master/src/com/du... Yes I've seen worse, but this most certainly isn't a great example of how to structure an Android app, not to mention the overall untidiness (commented out lines, messed up indentations etc.)
- flukus 10y ago
  Unit tests or integration tests? It may be better now, but android used to be a real pain to unit test, so much important functionality was baked into the Activity base class that was hard to substitute.
  - V-2 10y ago
    They seem to favour unit tests over integration tests, which is achieved by abstracting the layout logic away from Activities and into view models that can be unit tested with no fuss.
jpetitto 10y ago
I'm actually surprised they're relying on Activities for the views in the app. I'm not familiar with how the app works, but this is typically an out-dated approach. Activities should really only be treated as entry points into your app. Also, not a huge deal for an app, but the package structure is organized by layers, not features. Makes Java's non-private access modifiers essentially useless. The general style of the source code is solid though. I wouldn't be upset if I had to work in this code base on a daily basis.
- skewart 10y ago
  Just curious, why should activities only be treated as entry points to the app? What are the downsides of the only-use-fragments-if-you-need-to approach?
  - BoorishBears 10y ago
    For one, the backstack story for Fragments is a lot more sane than whole "Task" concept for activities (The backstack for fragments is a list of fragments you can manipulate and debug very easily).
  - jpetitto 10y ago
    Fragments are one option. Another is just to use regular Views. There are libraries to help you with this such as Conductor. As for Activities, they are usually overkill for most screens. They don't allow for seamless transitions between screens and prevent sharing UI components across screens (e.g. a Toolbar). Fragments and/or regular views have the added flexibility of being able to use more than one at a time and allows for easy re-use and view composition. Like I said in my previous comment, the only really good reason to create additional Activities is to provide additional entry points into your app. Otherwise Fragments or Views will suffice and provide greater flexibility and improve the UX in many cases.
- unsoundInput 10y ago
  I disagree with you regarding Activities. For apps they do most of the screen management the developer needs just fine, especially if they are backed by a strong view and data model. If you download the App you can actually really quickly make out where they leverage the single Fragment (switch the project category via the drawer) and it makes sense there; but I think the same App build with a single Activity and Fragments would be much messier (especially regarding animations and back-navigation) and they'd gain (next to) nothing.

fareesh 10y ago

Was thinking about this the other day, now in the context of this release it comes to mind again - it would be kinda cool if it was a common practice for tutorial folks to make a repo where they forked the entire thing and placed comments all over which were links to videos that broke down those sections in an easy to understand way.

V-2 10y ago

Yeah, they sort of rolled out their own MVVM implementation, based on RxJava and RxLifecycle. On Android MVVM is more difficult than MVP in my opinion (the most popular choice, not counting spaghetti projects), mostly because the platform doesn't provide the "glue" needed to bind viewmodels to the UI layer. At first glance it looks like they did it without overengineering, which is another trap as far as these matters go. Clearly a work of very good experts

Plaastix 10y ago
That "glue" can be Android's Databinding library. I've used it to bind ViewModel data to views. Works really well.
- V-2 10y ago
  I'm aware of it, but last I checked it didn't seem production-ready and lacked features. I believe they updated it at some point, but other than some talk at Google IO not much came out of it - even the docs didn't reflect it back then. Perhaps it's up to the task now, I admit I'm not looking it up regularly.
  - Plaastix 10y ago
    It is definitely production ready now.
V-2 10y ago
> In less than eight months, four engineers who had never written production Java code, let alone production Android code, shipped a 1.0. Wow. That's pretty impressive
- brianwawok 10y ago
  It's impressive that it took almost 3 person years to ship a 1.0 of a basic app?
  - rtpg 10y ago
    it's impressive that 3 person years from _no Java experience_ was all it took. Java and Android are complex ecosystems. Not to say they couldn't have shipped it in less time. Of course they could have. But it sounds like they shipped something very well built.
    - flukus 10y ago
      But what other languages did the have experience with? If it was something similar like c#/c++/ruby/python then the time to learn java should not be significant.
      - V-2 10y ago
        When it comes to Android, Java by itself is the least of problems. It's the SDK and framework that are tricky, ridden with technical debt and often far from developer-friendly.
        matwood 10y ago
        I was about to say this. In fact, you have to unlearn a lot of what works and is accepted in server side java when you move to Android. Learning the SDK and Android gotchas was by far the hardest part of my first Android app.
        flukus 10y ago
joblack33 10y ago
Speaking of MVP, check here too: https://github.com/6thsolution/EasyMVP https://github.com/6thsolution/EasyMVP
polarisrising 10y ago
When dealing with MVP on Android, how did you deal with dynamic view creation? Right now we are working on a rearchitecture and are finding that creating dynamic views in the Activity/View requires business rules we are putting in Presenter. But the Presenter doesn't have context.

swanson 10y ago

And actual tests for the Android app! It's a rarity, and especially annoying since the "sample" apps that Google provides pretends that testing doesn't exist.

mathiasjakobsen 10y ago
Agreed! But some great companies has been Open Source'ing their Android applications for a while. I.e. DuckDuckGo's app (https://github.com/duckduckgo/android https://github.com/duckduckgo/android) and the Forcastie weather app (https://github.com/martykan/forecastie https://github.com/martykan/forecastie). They are great references!
- V-2 10y ago
  I quickly looked up DuckDuckGo, and - unlike this one - boy is it spaghetti: https://github.com/duckduckgo/android/blob/master/src/com/duckduckgo/mobile/android/activity/DuckDuckGo.java https://github.com/duckduckgo/android/blob/master/src/com/du... Yes I've seen worse, but this most certainly isn't a great example of how to structure an Android app, not to mention the overall untidiness (commented out lines, messed up indentations etc.)
flukus 10y ago
Unit tests or integration tests? It may be better now, but android used to be a real pain to unit test, so much important functionality was baked into the Activity base class that was hard to substitute.
- V-2 10y ago
  They seem to favour unit tests over integration tests, which is achieved by abstracting the layout logic away from Activities and into view models that can be unit tested with no fuss.

jpetitto 10y ago

I'm actually surprised they're relying on Activities for the views in the app. I'm not familiar with how the app works, but this is typically an out-dated approach. Activities should really only be treated as entry points into your app. Also, not a huge deal for an app, but the package structure is organized by layers, not features. Makes Java's non-private access modifiers essentially useless. The general style of the source code is solid though. I wouldn't be upset if I had to work in this code base on a daily basis.

skewart 10y ago
Just curious, why should activities only be treated as entry points to the app? What are the downsides of the only-use-fragments-if-you-need-to approach?
- BoorishBears 10y ago
  For one, the backstack story for Fragments is a lot more sane than whole "Task" concept for activities (The backstack for fragments is a list of fragments you can manipulate and debug very easily).
- jpetitto 10y ago
  Fragments are one option. Another is just to use regular Views. There are libraries to help you with this such as Conductor. As for Activities, they are usually overkill for most screens. They don't allow for seamless transitions between screens and prevent sharing UI components across screens (e.g. a Toolbar). Fragments and/or regular views have the added flexibility of being able to use more than one at a time and allows for easy re-use and view composition. Like I said in my previous comment, the only really good reason to create additional Activities is to provide additional entry points into your app. Otherwise Fragments or Views will suffice and provide greater flexibility and improve the UX in many cases.
unsoundInput 10y ago
I disagree with you regarding Activities. For apps they do most of the screen management the developer needs just fine, especially if they are backed by a strong view and data model. If you download the App you can actually really quickly make out where they leverage the single Fragment (switch the project category via the drawer) and it makes sense there; but I think the same App build with a single Activity and Fragments would be much messier (especially regarding animations and back-navigation) and they'd gain (next to) nothing.