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.

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) and the Forcastie weather app (https://github.com/martykan/forecastie). They are great references!

I quickly looked up DuckDuckGo, and - unlike this one - boy is it spaghetti: 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.)

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.

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.

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.

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

That "glue" can be Android's Databinding library. I've used it to bind ViewModel data to views. Works really well.

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.

It is definitely production ready now.

> 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

It's impressive that it took almost 3 person years to ship a 1.0 of a basic app?

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.

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.

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.

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.

Yes Android is particularly complicated, but not to the point where 3 experienced developers building an app in 8 months is in any way remarkable.

I have never used this app myself, I don't know whether it's complex. I only peeked at the source code. And yes I was referring to the contrast between how neatly written it is, and their lack of experience with the platform, not how fast they did it.

Development on Android tends to be slow overall, owing to numerous intricacies of the platform, but I believe that in general taking some extra time to roll out a clean and polished version 1.0 will pay off when it comes to 2.0 and 3.0. It's always easy to move fast in the beginning, use lots of duct tape and snap something out rapidly, but it comes at a cost and then you get bogged down further down the line

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.

Speaking of MVP, check here too:

https://github.com/6thsolution/EasyMVP

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.

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.

I'm not a fan of Fragments when it comes to navigation either, but there are other solutions as well (see Conductor). But there are limitations to using a new Activity for each screen, which I mention in my other comment below. They really only make sense for specific features in an app that require a specific entry point. Things like external intents (other apps, push notifications, etc...) or deep linking, as another user mentioned. They may be useful for Google Instant Apps too depending on how it ends up working.

Fully agreed that there are limitations, but I still think calling it an out-dated approach is unfair.

I don't see a simple, low on boilerplate, one-size-fits-all solution for reusable and separated components on Android at the moment. I love that the community didn't settle with just Activities or just Fragments and is actively trying new stuff (after all, if you look at React or Vue or even freaking backbone.marionette, the web is in a much better spot right now regarding UI composition), but right now the right solutions always seems to take the path of least resistance and use whatever mix of pattern that gets you to your goal as easily as possible.

I agree with you as well. It makes deep linking easier since you don't need to recreate an entire fragment backstack.

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?

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.

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).