Let's create playback control view for a music player app. Our view will show playback progress of current song, and provide user with basic actions to control playback and switch songs in an album. Assuming that we already have ui layout properly done in xml, and playback service gives us nice api based on Signals, we are going to implement view controller layer in reactive way.
To create reactive applications we need proper mechanisms, idea for Signal
is borrowed from FRP (Functional Reactive Programming). With couple additions to better support Android app lifecycle, signals become very powerful, yet simple,
building blocks for our apps. They are especially useful in UI development.
Slides for Reactive UI talk.
There is a reason why standard Future,
as well as many other implementations, don't provide cancel() method. It's very hard, or impossible, to create general purpose solution,
providing reliable cancellation handling for everyone. But we can create
CancellableFuture
for code following some specific constraints (see previous post).
Multiple running threads can easily become very expensive, especially on slower Android devices.
Once non-blocking software threads outnumber cpu cores, context switching starts consuming huge part of total run time.
Common solution to that problem is using some type of fixed thread pool. I propose going one step further, to achieve even more,
through the use of specialized ExecutionContext.
I've been using Scala to create Android applications for some time now, and I've always been using ScalaTest for testing my Scala code. It felt perfectly natural that I wanted to test Android application the same way. When it comes to testing of Android applications, Robolectric is the main library for the job. Unfortunately it only comes with JUnit support, and using it from ScalaTest is only possible with some serious plumbing. Some time ago I decided to extract all this plumbing, update it to latest Robolectric release, and publish it as separate project: RoboTest.