My typical Android/iOS apps are now done using a Clean (or mostly Clean) architecture, with an MVVM app layer (as I think MVVM is superior to both MVC or MVP).
If you’ve never read Five’s Clean architecture explanation – do yourself a favour and read all 4 parts now… And then re-read them all.
In my setup, the View and ViewModel are in the “app” (or “ui”) module, while the Model is the rest of the system – for example, the use case interactors which communicate with the domain/data/device modules of my apps.
Android “Architecture” Components
Let’s ignore the fact that AA Components are actually just libraries/wrappers – and are an aside to “architecture” itself.
One of the components is a pretty cool ViewModel – which is inherently lifecycle aware (not that this is a huge issue in practice – but it’s a nice convenience). Unfortunately, it does not natively play well with the Data Binding library.
Similar for LiveData, which listens to underlying data and updates the UI reactively. LiveData allows for kinda reactive UIs, but doesn’t play well with the Data Binding library? WTF? Admittedly, the Data Binding library operate imperatively, but if you use RxJava to pull data reactively from your use cases and databases, which then update the bindings – you’ve got a pretty reactive solution.
The reason I love the DB libraries, is that once you get the hang of them, they’re brain dead to use, they’re unit testable (no emulators/hardware), and they play pretty well with RxJava – which litters the rest of my apps.
I should say, LiveData and Data Binding don’t play well… until now…
From Android Studio 3.1 Canary 6’s release notes
Updates to Data Binding:
* You can now use a LiveData object as an observable field in data binding expressions. The ViewDataBinding class now includes a new setLifecycle method that you need to use to use to observe LiveData objects.
* New compiler: You can preview a new incremental compiler for your data binding classes. To enable this compiler, add android.databinding.enableV2=true to your gradle.properties file, or include the following command line argument: -Pandroid.databinding.enableV2=true. Keep in mind, this compiler is not backwards compatible, so you need to recompile all of your data binding classes with this feature enabled to take advantage of incremental compilation. Note the following behavior changes when using the new compiler:
* The Android plugin for Gradle now generates Binding classes for your layouts before compiling your Java code.
3 main takeaways here:
- They’re still updating the Data Binding libraries!
- They are working on LiveData + Data Binding integration
- The binding code compilation is being optimized (currently, my only qualm with DB is that it’s just a bit slow to compile, and you can run into strange compilation bugs solved by re-compiling)
I still haven’t tried out using the new ViewModel with the Data Binding library – but since ViewModel was built to play with LiveData – it looks like there might be a go-forward path here somewhere…
iOS Data Binding still sucks
Aside: iOS still sucks huge due to their lack of binding libraries. They’ve got Bond, which is now a part of ReactiveKit – which means pulling in a whole reactive library for data binding. Which is technically what I do right now, with RxSwift acting as my data binding tool (but I use RxSwift everywhere anyways).
I’ve seen a few “roll your own” ideas, but I think until iOS/Swift come out with something native, I’m kinda screwed here.