Seven years ago, I was working at the New York Times and helped create a library called Store. It was a small library that fit the use case of reactively loading data from network and local storage. Originally, we built Store using RxJava and patterns adopted from Guava’s Cache implementation. A few year’s later I was working at Dropbox and (with the help of some community members including Yigit Boyar & Fabio Collini ) created a new fork of Store which was rebuilt from the ground up using Coroutines. Eventually this became the main Store repo and New York Times archived their copy. Store has continued to grow (74 contributors and counting!) and so has my career. As of a few months ago I am no longer working at Dropbox and wanted to once again re-evaluate where Store should live. My first goal was to find a new home for the project that would be permanent. My second goal was for that new home to allow the project to grow in size and contributors.

Today I am happy to announce that Dropbox has agreed to donate Store to the Mobile Native Foundation making it MNF’s first Android library project (The incredible Flank beat me to it for first project). Store will now have a permanent home that is decoupled from my career choices.

This decision was driven by a few factors.

• Mostly importantly, I believe in the MNF mission, I love the ability for many companies to come together and iterate on a solution. I want to walk the walk and take the most popular project I have and move it to MNF. I hope this sets a precident for others to follow. I believe dropping corporate ownership from Android open source projects is important for the health of the community.
• I’m tired of convincing my employers that open source is important. Store can live on whether my day job wants to contribute to it or not.
• I am hoping to broaden the reach of this project to users that only add libraries from completely FOSS orgs.
• I am getting little long in the tooth and my clan has expanded, over time I’d love to find others that would want to shepherd this project.

Over the next few months, I will be cleaning up older issues/prs and giving the project a fresh coat of paint, no major changes are planned as I’ll also be juggling a day job and a one year old.

If you are a contributor/user that wants to get more involved please reach out to me on twitter:@FriendlyMikhail. I would love more help with this project.

If you are a maintainer of an open source repo, consider joining me in moving your code under the Mobile Native Foundation.

Normally my apps have an app component, an activity subcomponent and a view/screen subcomponent. Each subcomponent has access to all the dependencies of its parent component.

Unfortunately, that setup breaks down if, for example, activities live anywhere except inside the app module because there is a coupling between the parent and its subcomponents (Dagger-Android has a solution for this that we will not be covering in this article). Instead, using the concept of component dependencies, I settled on the following workflow that allows any host app to pass dependencies into libraries, regardless of whether they use Dagger or not.

Let’s pretend we are all working at Kittn, an up-and-coming cat photo app. Our app started as a single feed of cat photos, but Kittn has been growing by 20% monthly (take that, Zuch!). All the Kittn code was previously in a single module, but now that we have funding, and a team of 100+ devs, we can’t realistically have everyone work in the same Gradle module.

My team in particular was tasked with creating a comments module that can be integrated into the app. (For consistency, we’ll call this module Commentr, in case we decide to spin it off and sell it as its own service in the future). The host app would call a function that is exposed from my library

CommentNavigator.goTo(CommentWithId(5), this)

which will launch a Comment Activity. So far, so good. The app module has a module dependency on comment module and we are off and running.

Next, product comes back to our team and says that they have no idea how well comments are doing because we don’t have any analytics. Well…that’s not the full story. The Kittn app is using Firebase Analytics but that implementation lives inside the app and not inside the comments module.

Additionally, the company is spiraling up a new app Puppr which, as you guessed, will also want to use my team’s Commentr library. Puppr, however, is using another analytics provider.

Luckily for both apps, our module was already using Dagger and will have no problem working with many implementations of a common interface. Let’s get down to it.

Within Commentr we have a comment activity which contains a presenter CommentPresenter

We also define within Commentr the following interfaces to allow us to log analytics:

RealCommentPresenter is our implementation and will be provided by a DaggerCommentComponent along with any dependencies that it has:

Notice that RealCommentPresenter depends on the interface not the implementation of HostAnalytics. So how do we actually get the implementation? Component dependencies, that’s how!

First we create our CommentComponent

This is the component that will know how to provide dependencies that live within our Commentr module — things like our database or API. Normally, we would create an instance of this component, retain it somewhere and then perform injection with it. But we still have the issue of a circular dependency — somehow needing to depend on the host’s analytics implementation without creating a circular dependency between the comment and app module. The Kittn app module depends on the Commentr module; we can’t also set the Commentr module to depend on the app module. Instead we will set up a component dependency and only have a dependency on an interface. Per the Dagger javadoc:

While subcomponents are the simplest way to compose subgraphs of bindings, subcomponents are tightly coupled with the parents; they may use any binding defined by their ancestor component and subcomponents. As an alternative, components can use bindings only from another component interface by declaring a component dependency.

Our Kittn app module already has an implementation for Analytics that looks to be really perfect for what we need within Commentr:

How about we add our Comments HostAnalytics interface here

Now KittnFirebaseAnalytics will be an implementation of HostAnalytics. Unfortunately, it’s still in the wrong module (Commr can’t depend on the Kittn app module because the app module depends on Commentr). Wouldn’t it be nice if we can somehow pass this implementation directly into CommentComponent during its construction?

First, we are going to add a component dependency on the interface HostComponent. Remember that HostComponent is nothing more than an interface that can provide an implementation of HostAnalytics:

When we run our build, Dagger will generate an additional builder method hostComponent that will allow us to pass and set an instance of the HostComponent:

Within Commentr:

Within Kittn Application Class or wherever you inititialize the Commentr library:

Let’s unpack the above a bit… by passing in an implementation of HostComponent into our CommentComponent builder, CommentComponent’s object graph will now contain every object that was provided from the HostComponent’s implementation. Provided just means that some function within the passed in implementation returns a certain type. In our case the type that HostComponent provides is HostAnalytics. Since we have a function that was returning HostAnalytics, CommentComponent’s graph will now be able to provide HostAnalytics in the same way that it can provide anything that lives in a dagger CommentModule.

One of the things I absolutely love about this setup is that I can test my Commentr module in isolation by just passing fakes/stubs through the HostComponent interface. Another advantage is that CommentComponent does not care what implements HostComponent. This means that if I have an app with the following app component:

As long as AppComponent has an instance of HostAnalytics in its object graph, We can have AppComponent extend HostComponent and, it will fulfill our interface’s requirement.

If I get a new requirement and now need to pass an Image Loader from our app to our library we can add an additional providesMethod within our HostComponent interface like

Now my AppComponent will need to also satisfy providing an ImageLoader implementation. If it doesn’t dagger will not let me compile. Yay for failing fast

Wrapping up:

While subcomponents work well when you have a single module or want to have every subcomponent to have every dependency from the parent component, component dependencies work well if you want to set a relationship that defines exactly what a parent component exposes to the child. I have used the above pattern to solve challenges like saving data to the app’s db, delegating click handling back to a host, pulling configuration from the host app & even passing a view container to a library module within a SingleActivityApplication.

Happy Daggering

Dagger Component Dependencies for Library Development was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Recently, our Android team started going through tech debt and spiking on how we can continue to have a best in class SNKRS experience for our users. While the app is beloved, as evident by our 4.5 rating on Play Store, we still felt that it was necessary to update our architecture to the latest and greatest that Android has to offer. In this post I’ll be going over the work we are doing to take the old persistence model, which stored flattened feed objects into Sqlite directly, and convert it to a relation schema using Google’s fantastic Room ORM. I’ll be going over the good, the bad, and the ugly of using Room.

The Good

Kotlin Support

Room works with Kotlin out of the box, you never have to write a line of java to work with Room. Your data models, DAOs, & database can all be written in Kotlin.

API Done Right

It takes all of ten minutes to be up and running with Room:

First, create Kotlin data class and annotate them as room entities

@Entity
data class Sneaker(
        @PrimaryKey val id: String,
        ...
)

Next, create a BaseDAO (Thanks Florina for the tip!)

interface BaseDao<T> {
    @Insert(onConflict = OnConflictStrategy.REPLACE)
    fun insert(vararg obj: T)

    @Delete
    fun delete(vararg obj: T)
}

Now, you can create abstract DAOs like the one below. You will only have to define query functions. Insert/Delete functionality will be inherited from your base DAO. Overall, find the syntax to feel familiar for those that use retrofit

@Dao
abstract class SneakerDAO : BaseDao<Sneaker> {
    @Query("Select * from Sneaker where id like :id")
    abstract fun getSneakerById(id: String): Sneaker
}

Once you have your DAOs, you create an abstract class with your DAOs and entities:

@Database(
        entities = [Sneaker::class, ...],
        version = 1)
abstract class SnkrsDB : RoomDatabase() {
    abstract fun sneakerDAO(): SneakerDAO
    ...
}

Finally, you create an instance of your DB:

@Singleton fun provideRoomDB(context: Context): SnkrsDB =
 Room.databaseBuilder(context, SnkrsDB::class.java, "coredb")
            .build()

Anytime you want to access your data you only need to call the function made above:

val sneaker = snkrsDB
.sneakersDAO
.getSneakerById(5)

Code Generation

Room is great because it allows you to access your DAOs which will have auto-generated implementations of all your db operations (no more cursors/content values necessary). Developers can now focus on writing beautiful features rather than binding parameters to sql statements or handwriting all the content values boilerplate that was previously required.

Native RxJava Support (It’s Reactive!)

Let’s go back to our query. The way we currently have it written we would only be able to access the data on a background thread (in a blocking fashion). Rarely would you want data on a background thread. Instead, it would be nice to have all database calls be observables similar to how retrofit allows observable call adapters.

The function can now be changed to return a Flowable<Sneakers> rather than just a Sneaker scalar value

    @Query("Select * from Sneaker where id like :id")
    abstract fun getSneakerById(id: String): Flowable<Sneaker>

Now the data can be accessed with all the power of RxJava

snkrsDB
.sneakersDAO
.getSneakerById(5)
.toObservable
.observeOn(Schedulers.io())
.subscribeOn(AndroidSchedulers.mainThread())
.subscribe({updateScreen(it)},{logError{it})

The biggest advantage of exposing queries as “endless streams” is that an update to the database will trigger a new emission to the emission above.

Anytime another insert/delete/update is run that will update the Sneaker color, my getSneakerByID backed observable will emit a new value. Additionally, schedulers can be used to allow database access on a background thread and responses to be delivered on the main thread.

Paging Support

So far there has been only a single record from the Sneaker table. What if instead all Sneakers need to be shown in a feed? Room allows writing a query like the one below to return all Sneakers:

@Query("Select * from Sneaker")
    abstract fun getSneakerById(id: String): Flowable<List<Sneaker>>

This doesn’t scale very well since the table could have thousands of records in it. Luckily the architecture components team integrated the Paging Library with Room.

Now a pagedList can be built that will bind to a RecyclerView rather than returning all records:

First, return a DataSource.Factory:

@Query("Select * from Sneaker")
    abstract fun getSneakerById(id: String): DataSource.Factory<Int, Sneaker>

Then build up your PagedList, in our case we return 10 items per page:

 val config = PagedList
        .Config.Builder()
        .setPageSize(10)
        .setInitialLoadSizeHint(20)
        .build()
 
val dataSourceFactory = snkrsDB
        .sneakerDAO()
        .getPage()
       
val pages = RxPagedListBuilder(
        dataSourceFactory, config)
        .buildObservable()

Testing Support(!!!!)

One of the most exciting features of room is that it provides a straightforward API for writing connected JUnit tests. While you can’t do unit testing due to differences in sqlite on android/jvm, you can write connected junit tests that work flawlessly with Room. Here’s an example:

First you create an instance of your DB as an in memory database:

val snkrsDB = Room.inMemoryDatabaseBuilder(InstrumentationRegistry.getTargetContext(), SnkrsDB::class.java).build()

Next, you work with your DB same as you would in your production app

val model=testSneaker(id=5,...)
snkrsDB.sneakerDAO.insert(model)
asssertThat(snkrsDB.sneakerDAO.getByID(5)).isEqualTo(model)

TDD with SQL is now a reality and dramatically sped up my development time.

Type Converters:

Want to save a date to the db as a long? You can write a type converter for how that works:

object MyConverters {
    
    @TypeConverter
    @JvmStatic
    fun toDate(value: Long?): Date? {
        return if (value == null) null else Date(value)
    }

    @TypeConverter
    @JvmStatic
    fun toLong(value: Date?): Long? {
        return value?.time
    }

}

Similar you can have type converters for saving a list of strings to a single column:

fun stringAdapter(): JsonAdapter<List<String>> {
    val listOfStringsType = Types.newParameterizedType(List::class.java, String::class.java)
    val adapter: JsonAdapter<List<String>> = moshi.adapter(listOfStringsType)
    return adapter
}

@TypeConverter
@JvmStatic
fun toJSON(list: List<String>?): String? = stringAdapter().toJson(list)

@TypeConverter
@JvmStatic
fun fromJson(list: String): List<String>? = stringAdapter().fromJson(list)

Notice that we used Moshi to marshal/unmarshal the String

We can now add the Type Converter to our data class which will tell Room how to save/read the field from db

@Entity
@TypeConverters(value = [MyConverters::class])
data class Sneaker(
        @PrimaryKey val id: String,
        val sizes: List<String>
)

It’s really nice to be able to encode the type converter logic and never have to worry about it again.

1:1 relationships with Embedded

Let’s say our Sneaker needs has a 1:1 relationship with a barcode, we can leverage an Embedded annotation which will save the barcode to the same table as the Sneaker:

data class Sneaker(
        @PrimaryKey val id: String,
        @Embedded val barcode:Barcode
)

Anytime we insert or query a Sneaker from Room, it will properly set the Barcode field with any scalar values the Barcode contains. Think of it as flattening and unflattening the two objects. The only caveat is that Barcode & Sneaker cannot have any fields that are named the same (more on that in the Bad/Ugly part)

The Bad

No support for saving nested objects

Most annoyingly, there is no support for saving nested objects. Even if we define the relations and embedded objects above, we still will need to iterate through our network models and save each object separately. Hopefully, the arch component team can improve on this process.

Embedded fields need unique names

Back to our embedded example above. If Barcode contains a field called name and Sneakers contains a field called name you will get an error on compile. Since Embedded fields are saved to the same table you need to have unique names for each field. One workaround is to manually rename the column in one object or another like the following:

@ColumnInfo(name = "barcodeName") val name: String?,

Another way is:

@Embedded(prefix = barcode)

which will then prefix all columns pertaining to barcode to barcode*FIELDNAME*

No support for recursive relations

Even if we go through the trouble of creating the above “view” of data, we still cannot load recursive relationships. For example, if a FeedItem contains images and barcodes, Room’s compilation will fail if each barcode contains an image as well.. This lead us to have to lazy load a Barcode’s images on our own.

The Ugly

1 to many relations are pretty messy

As mentioned at the top of the post, we are migrated from a data schema where we saved each Feed Item in a single table where all nested objects are serialized to json strings. Unless we rewrote every caller of the old sqlite db, we need to support callers that expect to get “fat models” back from room. Unfortunately this is not easy. Below are steps we needed to take to return a FeedItem which contained 1:1 & 1:many relationships 4 levels deep:

Need to make views

1. views should contain all 1:1 as embedded & all 1:many as relations
2. all relations need to be nullable since they get selected after embeddeds
3. entities need to have a second constructor for nullable fields
4. relation fields need to be marked as @ignore and nullable

Below is an example of a data schema that is similar to what we have in our app. Below are the additional objects and annotations you’d need to create if you wanted to load the following FeedItem with:

• 1:1 relationship with a Barcode
• 1:many relationship with Other linked items
• 1:many relationship with properties
• Properties that have a 1:many relationship with Images

data class FeedItemFull(
        @Embedded var thread: FeedItem,
        @Embedded var barcode: BarcodeFull?
) {
    @Relation(entity = LinkedItem::class, parentColumn = "itemId", entityColumn = "itemId")
    lateinit var relations: List<LinkedItem>
    @Relation(entity = Property::class, parentColumn = "itemId", entityColumn = "itemId")
    lateinit var properties: List<PropertFull>
}

class BarcodeFull(@Embedded
                  var barcode: Barcode? = null) {

    @Relation(entity = Barcode::class, parentColumn = "ItemId", entityColumn = "itemId")
    var barcode: List<Barcode>? = null
}

data class PropertyFull(@Embedded val property: Property) {

    @Relation(parentColumn = "propertyId", entityColumn = "propertyId")
    var images: List<Image>? = null
}

We were hoping that Room would “just work” when it comes to relationships and be able to save/load nested objects without all the ceremony above. Hopefully someday we can get to a better place with this. We considered writing an annotation processor to save FeedItems which would, in turn, save all nested complex objects to their own table.

Conclusion

After using Room for the first time we can definitely say that the good far outweigh the bad. The biggest pain point is how relationships are handled, otherwise doing sql on android is dramatically easier than its ever been. We will continue to migrate more and more of our data layer to Room and hope that the always amazing Architecture Component team will continue to make improvements

Room with a View was originally published in S23NYC: Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

One of the first libraries I open sourced was Store which was an implementation of the Repository pattern wrapped in RxJava. Store abstracted away the common pattern of load from memory, if not present load from disk parse the data, if not present load from network. This was all done with minimal setup by a user:

Initially Store was something I developed based on my use cases. While everything was interface based, I shipped a few implementations of parsers for Gson, Moshi, Jackson) and a FilePersister which eased in streaming data from a network to disk.

Fast forward 18 months and Store is up to 3000+ stars & 37 contributors mostly from folks I’ve never met (Thank you all!). In that time the community has helped implement:

• Memory & disk caching policies
• Wrappers for fetchers that return full objects rather than streams
• Result abstractions to determine which source data is coming from
• New API for refreshing get calls on clearing data
• A fluent Kotlin DSL
• Documentation including translations to Russian & Spanish
• An update to RxJava2
• Many other PRs full of performance improvements and bug fixes.

Store as it stands today is a full fledged data solution that both helps prevent extraneous data calls to your network and helps write apps that exhibit proper separation of concerns. Since moving on from the New York Times, I’ve had a chance to rethink how Store can better suit the needs of users in the modern Android ecosystem. I’m not just the primary maintainer of Store, I also use it in every project I have built since.

Time to get a Room

One of the most popular open source requests Store had was integration with Room. I was hesitant to integrate Room because I had never used it before and I wasn’t really sure how the integration would work. Now that I’m working at Nike’s s23NYC studio, we explored what data solution best fits into our re-architecting of the SNKRS Android app that we maintain. After exploring various solutions we decided that Room was by far the most robust and easy to use persistence solution. While Room was great at working with a database, it was still missing key features like request de-duping, memory caching, stale/refresh policies and all the other great features mentioned above. We still needed a repository abstraction that would wrap Room to implement these features. So, my team set out to fuse all the great features of Room with all the things we loved from Store.

Since most of Store was based on interfaces, we were able to integrate Room into Store by building a RoomPersister and StoreRoom, which is a specialized type of store. The StoreRoom includes the familiar features from Store while taking advantage of the reactive nature of Room & Flowables.

Room: Remind me what that is?

Room is a persistence library that is part of Google’s Architecture Components. Room is an ORM and does a fantastic job of giving you all the power of working with a database without any of the messiness of cursors, database connectors or having to map data yourself. Room is built on top of SQLite and takes care of a lot of the boilerplate associated with saving to or reading from a database.

Additionally, Room’s reactive API through its first class RxJava support transforms simple SQL queries into auto updating Flowables. Room queries exposed as RxJava Flowables is what I’ve always imagined as the perfect persistence layer to Store. It helped me get rid of messy code like the old stream & getRefreshing functions we previously used to fake endless streams. Using a Room backed persister allows Store subscriptions to update anytime the underlying data changes.

Store+Room a match made in Android heaven

Using the new StoreRoom is every bit as easy as using a regular Store.

First, create a Room DAO as you always do with Room. Within your DAO, expose an Insert & a Query function. The types do not need to be the same.

Next, implement Store’s Fetcher to tell StoreRoom how to get new network data. Below is an example that would use an API (Retrofit is recommended) to return a Single<User> based on a passed in user id.

Since both Retrofit & Room work with objects, there’s no reason to implement a parser anymore. We will let Retrofit take care of the parsing when a new network request comes in.

Next, we need to make an implementation of our RoomPersister. Notice how the read function returns a List<User> while the write function is only writing a single user each time.

You can of course change what the read and write functions return. As another example, you might want to write a collection or return a single item — the choice is up to you.

Now that we have our Fetcher & Persister, we can create an implementation of a StoreRoom:

Voila! All the functionality we always had with Stores but rather than being backed by a file persister we are now backed by a Room DAO.

Want to get data but don’t care about the source? Call store.get(). Need to bust through your cache and call network only? Call store.fresh()

So far this feels just like a normal Store. What do we gain by using Room besides ability to query & have different read/write types? Reactive reads, that’s what!

Since Room can expose data as Flowables, StoreRoom will expose endless reactive streams from your get and fetch calls. For example, if you call store.get() and subscribe to the results, anytime another call is made to your stores’ get or fetch method, your subscriber receive an updated value.

With StoreRoom we not only have disk and memory caching but we now have endless observables that will auto update subscribers if the underlying data we are querying for changes. Particularly in the above example every new user that gets fetched from the network and saved to the DB will cause an emission of all the users to any current subscribers.

Store and Room are a match made in heaven, Room is inherently reactive as the use case above demonstrates while Store gives you memory that sits on top of those DB requests and missing features like request throttling when you request the same data in parallel from various parts of your app (Think of reading the same config value N times on app start without having to hit your network or db more than once). As always with Store, new subscribers to Store.get() don’t need to go all the way to your DB if your memory cache has not expired. This leads to my ideal data workflow of fast reads from memory and reactive reads from disk all backed by a network source.

What’s next

I hope you enjoy using our new StoreRoom and RoomPersisterthat our s23NYC team is contributing back to Store. Next, we hope to work towards an annotation processor that would auto generate the above Store code from a Room DAO. As always community help is appreciated!

Resources:

NYTimes/Store

• 7 Steps To Room
• Room 🔗 RxJava

Store+Room — A Reactive Repository was originally published in S23NYC: Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

At a high level, the task was to create a flow that a user can navigate through. We chose to go with a single Activity architecture backed by MVP with lifecycle-aware presenters and a reactive dispatcher of state changes. We wrote our library completely in Kotlin. In this article we will explain how we did it.

Like all architectures, this one is still a work in progress but nonetheless we wanted to share our thought process. This architecture allowed us to build an augmented reality flow encapsulated in a single activity with six screens and presenters . In the past we have always ended up with a tightly coupled mess with presenters injected into each other or views nested in an unscalable way. This time we were able to build a reactive architecture where each presenter and view reacts to new state from a centralized dispatcher. As a result, we achieved our goal by decoupling our views and presenters.

We have always been big fans of MVP. It is the architecture that always seemed easiest to explain to a new dev:

• When a view inflates, it creates an instance of a presenter and attaches to it.
• Whenever the view needs to interact with anything but its own layout it calls a function on the presenter and then waits for a response through a view interface.
• Presenters don’t have any Android framework code in them and can be easily tested in the JVM using a test implementation of the view interface.

Here’s an example of a non lifecycle-aware view and presenter:

View Interface

View implements our interface and attaches to our presenter

Presenter

Since presenters are in non Android land, we need to call presenter.attachView and presenter.detachView as the presenter has no idea when the view is inflated or deflated. If we do not call detach we risk leaking memory when a presenter is bound to a long running operation.

Our mvpView can be an activity, fragment or view. Its main purpose is to implement an interface that the presenter will use to tell the view what to render. If I were writing this a year ago, I’d say, “We have a nice presenter here!” but this is the year 2017 (almost 2018!) and we now live in a world where lifecycle-aware components are a thing, most importantly SupportActivity implementing LifeCycleOwner. Since Activities are a LifecycleOwner and views are able to get a reference to their containing activity, we made the decision to have our presenter attachView function take in a lifecycle and register with it.

This was made possible by having our Presenter implement LifecycleObserver.

Now that our Presenter is listening to the activity’s lifecycle, we can have our detachView listen for our activity’s ON_PAUSE lifecycle which means we never have to call it explicitly. It is nice to have this auto detachthat we won’t need to remember to call from a view.

Now, our views no longer need onDetachFromWindow as our presenter can detach the view from themselves. The general flow of our UI will be:

• Activity is created
• Activity inflates its views
• Each view creates a presenter and attaches itself.
• The presenter requests any necessary data and passes it to the view.
• When our activity is paused our presenter will detach the view from itself preventing memory leaks.

We now have a NoNetworkView that — you guessed it! — we want to show anytime we have problems with network connectivity. We will need to show our NoNetworkView anytime someone loses connectivity, regardless of which screen they are on. What we did NOT want to do is inject the NoNetworkPresenter into any other view/presenter that can show noNetwork since we felt that this will eventually lead to a circular dependency if, for example, the SuccessPresenter needs to be able to call the NoNetworkPresenter, which in turn needs to be able to call something on the SuccessPresenter. Instead, we want to leverage RxJava and have each of our presenters react to a state change that will tell them whether to render or hide their UI. What we did was make a reactive dispatcher for our presenters to listen to. Here’s what the API from our presenter looks like:

In the example above, our presenter is listening to a stream called noNetwork . When an event is emitted, it tells its view to render itself.

Similarly, the presenter listens for the inverse of our event, which is really any other showing event, and hides its view.

Let’s take a look at our dispatcher next.

Our dispatcher has a few functionalities:

• We can use it to dispatch a new state which tells a screen to do something. For example, dispatcher.dispatch(State.ArTargetFound) will tell our AR presenter to display a found button.
• We can use it to dispatch a new state that needs to show a new Screen. dispatcher.dispatchShowing(Showing.NoNetwork) sends a new showing state to anyone observing the dispatcher. This state change is also added to our showEvents stack. (We’ll come back to this in a minute).
• Presenters can then listen for a particular state change (with an associated payload) and react accordingly. For example the no network view can be listening to dispatcher.noNetwork()

The landing view can be listening to dispatcher.showingLanding.subscribe()

We used Kotlin sealed classes to represent the different states that we can dispatch. Using sealed classes allowed us to represent some states as objects while others can be data classes that carry a payload.

Using a state dispatcher allowed us to decouple our presenters from each other, which meant we did not need to nest presenters into each other or have complicated logic that defines when views should be shown or hidden. Each presenter will listen for events that they need and also listen for the ones that they should be closing on. Take a look at what happens when our ARCamera attaches to its presenter:

At the same time that the ARView is visible, we might want to show an overlay or some additional controls. We can accomplish this with an OverlayPresenter that listens for similar events:

The overlay presenter might also care about other states, so it can react to those as well:

The last part of our architecture is to add all our various views to a single layout with visibility:invisible so that they can all be inflated when our activity starts. This in turn calls each presenter’s attachView function which will then subscribe to any events that the view needs to react to. As a user flows through our AR Activity we show and hide views based on states changes that are dispatched. When one of our lucky users finds an AR target in the wild, we can resolve their location and then dispatch a State change that will drive which screen is shown next:

https://gist.github.com/digitalbuddha/48a7758f68ef4b4a323d18f1d03dfe2d

Check out how simple our Success and Failure Presenters are:

The only remaining piece is dealing with backstack. Any view/activity/presenter can call dispatcher.goBack() which will dispatch the last showingState prior to the current one, which should both make your view disappear and another view appear. If there are no more showing states on our backstack we dispatch a State.BackStackEmpty which our activity listens for:

https://gist.github.com/digitalbuddha/973cfe4edd5052e76cfc9572b36b201b

ContainingActivity:

Just like the regular Android backstack, our dispatcher backstack is abstracted away from our views. No view should know what happens when it is finished — all it knows is that it gets shown or hidden. What’s nice about this is that we record each state change along with its payload into a single Stack structure called showEvents. A view doesn’t need to know if it’s being displayed for the first time, or being resumed by a backstack traversal. Incidentally, our state changes are Kotlin data classes with payloads that will be pushed with each state when you go back in reverse.

So that’s our new Friendly MVP! It works for us and we hope it works for you as well. Next post we will dive into how we implemented Augmented Reality with targeting and 3D models in under a month with the help of….a JavaScript library (gasp!)

Here’s a gist of some base classes to get you started. We hope to roll this into a library once it is more ironed out.

Like solving interesting problems in novel ways? We’re hiring at Nike’s Digital Innovation Lab located in the heart of the flatiron district. contact me at mike.nakhimovich@nike.com

MVP & Lifecycles & Dispatchers Oh My! was originally published in S23NYC: Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

• Give developers with little hardware experience a chance to check out the new Android Things platform, including Android engineers with little hardware experience (i.e. the organizers) and hardware engineers new to Android
• Get creators thinking about some of the possibilities offered by IoT for less able bodied individuals
• Contribute to building the NYC developer community

The event brought people with a range of experience levels together to experiment with the Android Things platform. Participants included professionals with 20 years of experience as well as current bootcamp students and recent grads. Several teams came from the Android program at Coalition for Queens.

Teams were tasked with coming up with an IoT product that would address a real-world accessibility problem and were given two days to code a solution. Teams each received a Raspberry Pi with Android Things, a Rainbow HAT, and an accessory kit with a breadboard. Having both the Rainbow HAT and the accessory kit was great because it gave hardware newbies a chance to build something impressive with the HAT, and the more seasoned techies could tackle more custom projects with the breadboard. Thank you Dave Smith and the rest of the IoT team for the generous donations of 15 kits!

Preparation

Because the teams would have a limited amount of time to get familiar with the platform and then code something, we wanted to get some setup done in advance. Two days before the event, we flashed the Android Things OS onto the SD cards of all the Raspberry Pis following these instructions: https://developer.android.com/things/preview/index.html.

We used a program called Etcher, which gave us a drag and drop interface for moving the ROM onto the device. We also deployed a sample app to make sure we’d be able to help the teams. We deployed Mike Wolfson’s sample app which was great because it hit all of the lights on the HAT, so it also confirmed that all the peripherals were working. Word of warning if you’re doing this yourself: When deploying a sample make sure you change the version number of anything Android Things related to the version of the things SDK you are using. So in our case we needed to change lines like following to use version 0.4

Kickoff

The event kicked off with a keynote presentation from Mark Murphy, author of the Busy Coder’s Guide to Android Development, who served up some sage advice on how to think about a good project idea.

We divided teams into groups of 4 and gave an hour for brainstorming then teams got down to business for a 2 day hackathon.

Take Aways:

What Went Great:

The Rainbow HAT is a really fantastic addition to the Pi. We had developers who had never coded before up and running in under an hour.

Raspberry Pi kit cases were also amazing. They were easy to put together the right way, forgiving if put together the “wrong” way, and good to put together as a team building exercise.

The available sample apps in Google’s documentation were easy to follow and gave a great starting point.

Lessons Learned:

Setting up WiFi on-site was a bust. We’re not sure if it was the network type or that the network was public, but we could not get any Pi’s connected to the WiFi. Fortunately we had backup ethernet cables to connect the Pi’s directly to computers and were able to share WiFi over ethernet. For future events we’ll plan to do a test run on-site to confirm everything works as expected.

While fine for prototyping the temperature sensor does not give an accurate reading due to being located on top of the Pi (which gives off heat).

Apps needed to be uninstalled or crashes happened. We noticed that if you install sample A and then install sample B without stopping sample A, the Pi will crash with a “sensor already in use” error. This meant we needed to make sure to press the stop button or kill each running app from ADB prior to installing a different one.

The Results

By 4pm on Sunday we had 8 teams ready to present their projects to our panel of 4 judges:

And the winners were:

First places — Emotionalize:

Emotionalize aims to make it easier for nonverbal individuals to communicate how they’re feeling to others. It consists of an emoji-based Android app that the nonverbal person can use to identify their current emotional state, plus a wearable Pi that displays their current emotion on their person using associated colored lights or text. There are currently tools that facilitate communication between nonverbal individuals and others, but they rely on talkback or both individuals looking at the same screen. Emotionalize improves this process by providing an instant visual indicator of how the person is feeling that is wearable and easy to see.

Second place — Smart MTA Elevator

Based on the recent NYTimes op-ed, “New York Has a Great Subway, if You’re Not in a Wheelchair” by Sasha Blair-Goldensohn, the team worked on building a system to collect the real-time status of station elevators. The solution consisted of an Android Things device to retrofit the MTA’s existing elevators with “smart” capabilities, a real-time monitoring dashboard for the MTA, and an elevator status API for transit apps. The Android Things device detects every time the elevator travels between different levels and sends a notification of that event to a Firebase database. Using the dashboard, the MTA could spot lower than normal usage of an elevator, which could indicate a problem, and send a technician to investigate before the elevator completely breaks down. The team chose to provide an API so transit apps could include up-to-date elevator status information in their trip planner results, because this information is very much a part of trip planning and shouldn’t require a separate app to find it.

The winners and runners-up each took home a digital copy of the Busy Coder’s Guide to Android Development. Two lucky raffle winners also each took home a copy of the Big Nerd Ranch Guide to Android Development.

Thank Yous

Thank you to our sponsors Google, NY Times, Friendly Robot, Commonsware & Big Nerd Ranch and co-host the Google Developer Group, NYC.

And to our wonderful volunteers (not all pictured)

Check out the rest of the photos of a wonderful weekend! https://goo.gl/photos/9re98sgCckSxQ2Mx7

The entirety of my Android career has been spent hitting RESTful APIs. No matter the app, the general setup was the same: Using get/post/delete with a predefined set of endpoints in a RESTful api. Recently, The New York Times started looking at other ways to transfer data between our servers and clients. One of our current problems is that we have a team dedicated to creating templates and endpoints for all of our mobile clients on Android and iOS. As a result, we had quite a few permutations of data feeds to manage, including: Android tablet, Android phone, iOS phone, etc. This meant that any time we wanted to request a different set of data, like new language for an article, we had to wait for one of our teams to make another template and endpoint. As you can imagine, this became inefficient.

Ideally, we needed a way for each client to request or query the data that they need without having to change anything on the server. If one Android phone needs small crops of images while another Android phone needs large crops, we should be able to use the same article API to fulfill the request. Of course, a single variation between different requests can be accomplished with request params but that didn’t quite fit our use case. We request up to 200 fields for any given article. 90% of the fields are not required for all articles, and a third of them have some special configuration. It would be nice to get only the necessary fields on a per request basis.

Choosing GraphQL

It became clear that REST is not the right tool for the job. We dug around for other options and landed on the GraphQL spec created by Facebook. For those that are unfamiliar, GraphQL is a query language for domain driven requests from a client to a server. Here’s a simple example from the front page of graphql.org:

Describe your data by making a schema:

type Project {
  name: String
  tagline: String
  contributors: [User]
}

Ask for what you want by writing a query:

{
  project(name: "GraphQL") {
    tagline
  }
}

Get predictable results:

{
  "project": {
    "tagline": "A query language for APIs"
  }
}

The way that GraphQL works is that you have a pre-defined schema of all the things a client can request. Then, clients can make a query which asks for only the fields that they need. The query is posted to a server which executes that query, pulling from any backends or databases to retrieve exactly the data the client asked for.

So a query like {a, b, c} returns {a: 1, b: 2, c: 3}. Or, you can query {a, c} and get back only {a: 1, c: 3}. This seemed perfect for us, and there was only one problem - there didn’t seem to be any clients for Android. After trying to create our own implementation internally, we realized why one didn’t exist yet: The GraphQL specification has a lot of things to implement, including fragments, union types, mutations, custom fields, nullable types, etc. Working in a statically typed language where reflection is expensive did not make anything easier.

Working with the community

Rather than creating something internally, we felt that the community as a whole would benefit from an open source GraphQL client. So we looked around for anyone else that might have the same needs. Through an Android Slack, I was connected with Felipe Lima from Airbnb who told me about Apollo GraphQL, a rather robust client implementation, first in JavaScript and recently also in Swift for iOS. He said that he had worked a bit with them trying to bootstrap an Android version together. We ended up taking a call, and tried to figure out what direction to go to start working on a GraphQL client for Android. After looking around a bit more we found another partner, Shopify, who had a developer also interested in creating an Apollo Android client. The base contributor team had been formed.

Five months, 200+ commits, and 13 contributors later, we have released version 0.30, which is the first version ready for public consumption. While there might be a few minor API changes we are feature complete for 1.0.

What is Apollo Android?

Apollo Android is a GraphQL compliant client library that generates Java models from standard GraphQL queries. These models give you a typesafe API to work with GraphQL servers. Apollo will help you keep your GraphQL query statements together, organized, and easy to access from Java. Here are some of the features you get:

Code generation: You can just change a query and recompile your project, and Apollo codegen will rebuild your data model. Code generation also allows Apollo to read and unmarshal responses from the network without the need of any reflection (see the README for an example).

Network calls and caching: Apollo-Android also includes a runtime to execute queries and cache the results. The client can be configured with three levels of caching:

1. HTTP response cache: This stores raw HTTP responses.
2. Normalized disk cache: This does per-node caching of results in SQL.
3. Normalized in memory: This is an optimized Guava in-memory cache.

RxJava: We have included RxJava wrappers to work with RxJava 1 and RxJava 2.

Optionals: Optional support is here as well. We work with Guava Optionals, Java optionals or our own shaded version. We are 100% ProGuard compatible with no configuration.

Trying Apollo Android in your app

Check out the example in the README. The majority of your interactions will look something like:

Step 1: Add a query to your project:

query FeedQuery($type: FeedType!, $limit: Int!) {
  feed(type: $type, limit: $limit) {
    comments {
      id
    }
    postedBy {
      login
    }
  }
}

Step 2: Compile your project to get generated code for the query.

Step 3: Interact with the generated type safe QueryBuilder and response:

apolloClient.newCall(FeedQuery.builder()
    .limit(10)
    .type(FeedType.HOT)
    .build())
    .enqueue(new ApolloCall.Callback<FeedQuery.Data>(){
        public void onResponse(Response<FeedQuery.Data> response) {}
        public void onFailure(@Nonnull Throwable t) {}
     });

or the RxJava version

Rx2Apollo.from(apolloClient
                  .newCall(FeedQuery
                  .builder()
                  .limit(10)
                  .type(FeedType.HOT)                 
                  .build()))
         .subscribe()

You can also find a sample project in the repository on GitHub.

Conclusion and thanks

We believe we made this library simple yet powerful. A developer can go from writing a GraphQL query to being up and running in a manner of minutes. We’d love to hear from you on how to make Apollo-Android better, and we’re currently working on a roadmap of features for the coming months.

It was incredible to work with talented developers from various companies to create an open source project. I’d like to recognize the main contributors on the project:

• Ivan Savytskyi, who was by far the top contributor, main developer of the code generation through a few rewrites, and generally an awesome guy. This project would not be a reality without the insane amounts of time he put in.
• Felipe Lima for getting the project off the ground.
• Ben Schwab for implementing the caching layer and countless other things.
• Martijn Walraven from the Apollo team for offering us guidance, check out his iOS library here.
• Marwan Ahmed for creating the Gradle plugin to run our code generation.
• Vishesh Vadhera for giving a big helping hand in documentation.

Learn more about the project and contribute on our GitHub repository!

Introducing the Apollo Android GraphQL client was originally published in Apollo GraphQL on Medium, where people are continuing the conversation by highlighting and responding to this story.

100 replies later ranging from questions to anger and I figured I owe a blog post. The statement above came out of an ASG discussion about how everyone seems to use Presenters differently, particularly when it comes to configuration changes during or after a data fetch. It seems like we all are trying to solve the same problems but in different ways:

• Activity/Fragment/View needs to be able to request data
• There needs to be a mechanism to cache the data so that on rotation you do not need to hit the network again
• Similarly, you should be able to maintain your state after rotation, such as scroll position.

In this article I’ll be going over my preferred way to structure a data driven application.

Some shocking points I’ll be making and explaining along the way:

• Presenters should be owned by the Activity/Fragment/View and destroyed/recreated on rotate
• Singleton data providers request and own your data
• State should be kept minimal and saved/restored on rotation

Let’s setup a common use case that something like a Reddit client would have: MainActivity allows a user to enter a subreddit name. It then calls the Reddit API and shows a list of posts for the particular subreddit. If a particular post in the results is selected, you will go to a CommentActivity which will hit another endpoint and show the comments for the post. To make the example a little more complicated we will have the CommentActivity contain a fragment that shows comments. Some pain points that we should all be aware of:

• If a user submits a request for a subreddit and then rotates mid request, you need to be able to keep the request going rather than making a new one, especially if it is an expensive network call like getting 100 posts.
• We need to be able to pass data between the 2 Activities. Because our CommentsActivity contains a CommentsFragment, we need to be able to pass data between the activity and fragment or allow the fragment to request its own data.
• If we are on the CommentActivity and rotate, we need to be able to restore the proper comments (and maybe the scroll position as well)

Here’s how I would approach the above (with explanations of design decisions)

User enters a subreddit name and then clicks on search:

Activity has an injected Presenter and will call

presenter.getPostsFor(subredditName)

The Presenter has 2 jobs: requesting new data from a data provider/repository/store and then passing that data back to the View (an Activity in this case). Using the simplest approach possible we can inject a network client like Retrofit to our presenter which will act as a data provider and request data from it.

public void getPostsFor(String subredditName) { 
subscription = redditApi.getPosts(subredditName)
.subscribe(posts -> getMvpView().showPosts(posts), 
           throwable -> getMvpView().showError()); }

The activity then implements these:

void showError();    
void showPosts(List<Post> posts);

Something that I do that may be different from others is that I make my View own my Presenter. By that I mean the Presenter dies any time an Activity dies. New Activity after rotation means we will have a new Presenter for that instance of the Activity. Think of the Presenter as having the same scope as an instance of an Activity.

What we currently have is a Presenter that acts as the go between our View and our data, the View doesn’t know or care where the posts come from. All it knows is that it needs to request Posts and have callbacks to properly handle when those posts (or an error) are returned. Views (Activity in our case) only care about requesting or showing data while request and subscription implementations live in a Presenter.

Next we need to discuss how we can have a request survive a configuration change. To recap: when a user rotates their device while fetching a new subreddit, we want to show the response after rotation without having to make a second request to the network. There seem to be two schools of thought about how this should work.

1. The first approach is that we can make our Presenter a singleton which will make it live on a higher scope; or
2. We make a singleton data provider that lives on a higher scope and caches our data

Let’s start by examining the first option. Some suggest that you should make your Presenters singleton or app scoped. This way when you rotate and have a new instance of an activity, you rebind to the same singleton Presenter. The presenter can then own the data and pass it back to the view rather than going to the network a second time.

This adds a bit of complexity, as the Presenter now needs logic for checking if “a request is in flight” before making another request. To me this feels like too much responsibility for a Presenter. In my opinion, Presenters are the middlemen. They request data, they hand it of,f but they shouldn’t be fat or keep data. Another disadvantage to this approach is that many presenters can be holding/retaining the same exact data. What if the MainPresenter and CommentPresenter both want to request a list of Posts, will there be duplicated data within their Singleton Presenters?

I think we can do better. It sounds like all we need to do is cache our data and in-flight requests somewhere that is not scoped to a single Activity. If we can have an abstraction that survives configuration changes, we can recreate our Presenter and then request the same data a second time.

Instead, I’d propose using data stores which abstract away data loading. Rather than the presenter needing to cache the data, we can leverage the Repository pattern and create Data Providers/Stores that can get data from the network and cache it for when we need it. For one thing, this approach makes it easier to persist your data. Another advantage is that we have a single source of truth for our data. Finally, wew can eliminate things like Interactors and just have your Presenter subscribe to your Stores whenever they need something for a view.

so

redditApi.get(subredditName)

becomes

redditStore.get(subredditName)

where the store is a singleton (preferably managed by Dagger) and takes care of requesting new data, caching that data and dealing with in flight request management.

Now when you rotate, the Presenter can simply inject the same singleton Store and re-request data which can piggyback on an inflight request or get the cached data from the Store. From the Views/Presenters perspective it shouldn’t matter if the data is being requested for the first time or coming from a cache; all it needs is the data to pass to the view.

As for an implementation of this pattern, I suggest wrapping your network calls in Stores that take care of caching and in flight logic. We just open sourced our implementation of a library using this pattern at NY Times https://github.com/NYTimes/Store.

Let’s examine this a bit more. Views get recreated, Presenters get recreated too. The only reason I’ve seen to not recreate Presenters is because they contain data that need to survive rotation. I believe that as long as you have an identifier for your data you only need to persist/retain/maintain a singleton provider of your data rather than the entire Presenter. Having a singleton Store that can provide pre and post rotation data gives you all of the advantages of a singleton Presenter without the added weight. Thin views and presenters which talk to single responsibility stores is my preferred setup for MVP. As mentioned above, Presenters now can worry about what the View needs and getting access to it rather than worrying about things like caching and request management (let your store do that).

Rotation logic works like this:

• OnSaveInstanceState will save the request params if there are any.
• OnCreate will inflate a layout, create a presenter and checks if there are any request params in the saved bundle. If there are, it will request data from the Presenter which will request from the Store. Since data has already been cached by the Store, you should be receiving a cached representation.

If an Application gets backgrounded for a long time and needs to recreate, it will work exactly the same as in a rotation. There’s no need to save your entire presenter or data model in save/restore instance state eliminating parcel too large exceptions. Since the Store owns the data, you can use much better persistence techniques like flat files or sql lite which are not available at the UI level. Both of these storage techniques have less size constraints than an activities save restore bundle mechanism.

OK, back to our example which is now powered by a Presenter and a Store. The user enters a subreddit name, clicks on search which delegates the call to the Presenter who made a Subscription to the Store and passed back the results to the Activity. Now that the user sees posts, he clicks on one to see the comments.

We then open CommentActivity and pass it a postID within an Intent. Activity B creates a Fragment and passes the Intent Extra to it. Fragment inflates a Layout, creates/injects a CommentsPresenter and asks the Presenter for the comments for a particular post. Similar to our last Activity/Presenter, the CommentPresenter will get a reference to a singleton CommentStore which it will pass the postID to and ask for a list of comments. As in our MainActivity example if a rotation occurs the fragment will save the current PostID and restore it when the fragment gets recreated.

The CommentFragment has 2 starting states: frag args containing postID or saved state contains postID, in either case the Fragment creates a Presenter and passes the postID to it for retrieval of a list of comments. As you can see by having a Store abstraction we can keep our logic for fetching pre or post rotation exactly the same. If any other state needs to be maintained it should be minimal and saved/restored same as the request params. Since you are only ever saving/restoring states that should be just a few flags.

In conclusion I feel that the simplest way to work with data is to have an Activity/Fragment/View which owns a Presenter. That Presenter can request data from an app scoped Store which can either fetch new data or return cached data. This setup works for me and I hope it will work for you too.

Feedback is loved and appreciated.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMI family. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!

activityComponent = application.getAppComponent()
        .plusActivityComponent(new ActivityModule(this));

Additionally I like to expose the activity component in a getter so that views can have access to the activity scoped objects:

public interface ActivityComponentProvider {
    Activitycomponent getActivityComponent();
}

within views I can then do:

public VrView(Context context, AttributeSet attrs, int defStyleAttr) {
    super(context, attrs, defStyleAttr);
    inflate(getContext(), R.layout.vr_view_contents, this);
    ((ActivityComponentProvider) context).getActivityComponent().inject(this);

In most cases this works but yesterday was not most case. The story started with me creating an xml layout that contains a <android.support.design.widget.AppBarLayout> tag. Inside of that I put a custom view <com.sample.myview>. Similar to the above example I added the injection code to the views constructor and ran my code and Crash. To my surprise I started getting “java.lang.ClassCastException: android.view.ContextThemeWrapper cannot be cast to android.app.Activity” errors. After a bit of digging, I was able to deduce that the problem is due to how AppCompat inflates views. Unlike regular widgets/layout groups, <AppBarLayout> children use a ContextWrapper to inflate child views rather than the containing Activity’s context.

The brute force solution was to call getBaseContext() on the view’s context over and over again until you get to the activity but this seemed hacky and strange. Instead I was pointed to an interesting solution on how to pass a Dagger Component from an activity to a view (Thanks Jake Wharton!)

The novel approach was to leverage an activity’s getSystemService override. Let’s go through a example.

The first thing you’ll want to do is override getSystemService in your activity.

@Override
public Object getSystemService(String name) {
    return super.getSystemService(name);
}

The context.getSystemService call normally is used to get a reference to things like the LayoutInflator. By overriding the method in your activity, you’ll now be able to return an instance of anything you want for a particular key. In our case we’d like to return the Activity component

@Override
public Object getSystemService(String name) {
    if("Dagger".equals(name)){
        return activityComponent;
    }
    return super.getSystemService(name);
}

Notice that we still want to call through to super if it is not the key that we are interested it.

Now within our view’s constructor we can access the activity component by calling getContext().getSystemService(key). The nice thing about this setup is that you don’t have to unwrap the context to find the activity, the system service call will do that for you.

public VrView(Context context, AttributeSet attrs, int defStyleAttr) {
    super(context, attrs, defStyleAttr);
    inflate(getContext(), R.layout.vr_view_contents, this);
    ActivityComponent activityComponent = (ActivityComponent) getContext().getSystemService("Dagger");
activitycomponent.inject(this);

Rather than making the dangerous cast from getContext to your activity, we can leverage androids system service architecture.

Finally to make Android Studio lint checker happy, add

//noinspection ResourceType

above

ActivityComponent activityComponent = (ActivityComponent) getContext().getSystemService("Dagger");

And thats it! You can now get a reference to your activity component from a view. Bonus: In a similar manner you can override getSystemService in your Application class and pass the app component from there. This would allow you to do something like

AppComponent component = (AppComponent) getAppplicationContext().getSystemService("AppComponent");

from your activities.

Thanks again to those that helped me grok this yesterday.

New Dependency

Before going into the API differences, I want to make a note about RxJava2 having a dependency on ReactiveStreams which is a standard for asynchronous stream processing with non-blocking backpressure. Think of ReactiveStreams as a spec for Reactive libraries to build on top of. Adhering to this standard adds the ability for interpolation with other Reactive Libraries.

Imports

RxJava2 is available in a different package than RxJava1:

RxJava1:

compile ‘io.reactivex:rxjava:1.0.y-SNAPSHOT’

RxJava2:

compile ‘io.reactivex.rxjava2:rxjava:x.y.z’

This means that you can start using RxJava2 while still using RxJava1 rather than having to fix your code to work with the breaking changes between versions. This style of packaging is similar to the versioning strategy used by Square Libraries (Retrofit2, OKHTTP3, etc.) and is great if you’re trying to run both versions. That said, if you’re instead migrating at once, this means that you will now need to change all your imports to the new package. Android Studio find/replace should mitigate most of the pain.

Null Emissions No Longer Permitted

RxJava2 no longer permits emitting a null value from a producer. Emitting a null value from an observable, flowable, or subject will throw a NullPointerException:

Observable.just(null); //don’t do this

subject.onNext(null); //don’t do this either

I’m personally a big fan of this change and believe that null should not exist in an API. I’ve always appreciated that Dagger throws exceptions if returning a null from a provides and am glad that RxJava is now enforcing clean code practices. There are plenty of alternatives to passing null through a stream such as: Enums, Constants, and Guava/Java8 Optional types (my favorite).

Under (Back) Pressure

RxJava 2 introduces a new base type called Flowable which is an Observable with backpressure support. Backpressure is when an Observable emits values faster than an Observer is able to handle. With RxJava2, Observables do not support backpressure while Flowables will support backpressure (with different strategies).

Flowables seem to have the same operators as Observables plus hooks for defining/handling backpressure. The good news is that you’ll still have all your favorite operators like map/filter, etc. The bad news is that organizing imports might now grab the wrong one. Here’s an example of creating a Flowable from the wiki:

Flowable.create((FlowableEmitter<Integer> emitter) -> {
emitter.onNext(1);
emitter.onNext(2);
emitter.onComplete();
}, BackpressureStrategy.BUFFER);

This looks very similar to the current Observable.create but with the added param of how to handle Backpressure. Hopefully, making Flowable its own type will help developers consider Backpressure when designing reactive flows rather than learning about it for the first time they see it in crash logs.

The Reactive-Streams spec also mandates that all operators support backpressure (within Flowable in our case). What this means is that Operators can’t emit faster than a downstream Consumer can consume. It’s important to note that this does not mean that operators can’t have backpressure problems — it just means that they will now throw the MissingBackpressureException exception themselves rather than pushing too much through onNext. The exception will be thrown from the Operator rather than the Consumer/Subscriber.

Single Old and New

Single has been reengineered from the ground up and is now built on the ReactiveStreams spec. Subscribing to a Single is now done with a SingleObserver<T> which is an interface defining:

void onSubscribe(Disposable d);

void onSuccess(T value);

void onError(Throwable error);

Subscribing to a single is done in the same way:

single.subscribe(onSuccess,onError);

Hit Me Maybe One More Type

RxJava 2 introduces a new base reactive type called Maybe. Maybe is essentially a hybrid between Single and Completable. You can use Maybe when you have a provider that can emit 0 or 1 items. You don’t need to worry about handling backpressure because Maybe emits at most 1 item.

Maybe will offer only a subset of operators available in Flowable/Observable.

Example:

Maybe.just(1)
.map(v -> v + 1)
.filter(v -> v == 1)
.defaultIfEmpty(2)
.test()
.assertResult(2);

New BackPressured Subject: Processor

RxJava 2 introduces a new type, Processor, which is a Subject with backpressure support. AsyncSubject, BehaviorSubject, PublishSubject, ReplaySubject, UnicastSubject maintain their existing functionality from RxJava 1 and do not support backpressure. Their Processor counterparts do: AsyncProcessor, BehaviorProcessor, PublishProcessor, ReplayProcessor, and UnicastProcessor.

New Names for Function and Action

RxJava 2 brings new names for function interfaces: Func1 is now Function, Func2 is BiFunction and all other function interfaces in favor of Function<Object[],R>. Similar to Guava there will be a Predicate<T> for the common use case of Func1<T, Boolean>. Actions follow suit: Action0 becomes Consumer, Action1 is BiConsumer and ActionN becomes Consumer<Object[]>. (These two changes will lead to the largest amount of refactoring/migration in my apps.)

Subscriber is Now Disposable

Due to naming conflicts with Reactive-Streams, Subscriber has been renamed to Disposable. Disposables have a .dispose() method that’s similar to the .unsubscribe() method of Subscription:

ResourceSubscriber<Integer> subscriber = new ResourceSubscriber<Integer>() {

@Override
public void onStart() {
request(Long.MAX_VALUE);
}

@Override

public void onNext(Integer t) {
System.out.println(t);
}

@Override
public void onError(Throwable t) {
t.printStackTrace();
}

@Override
public void onComplete() {
System.out.println(“Done”);
}
};

Flowable.range(1, 10).delay(1, TimeUnit.SECONDS).subscribe(subscriber);

subscriber.dispose();

In the example above we see one more renaming change: onCompleted will now be onComplete. Yay for find/replace.

Composite Subscriptions Changes

Composite Subscriptions have been replaced with CompositeDisposable and a new subscribeWith method.

RxJava1:

CompositeSubscription composite = new CompositeSubscription();

composite.add(Observable.range(1, 5).subscribe(new TestSubscriber<Integer>()));

RxJava2:

CompositeDisposable composite = new CompositeDisposable();

composite.add(Flowable.range(1, 5).subscribeWith(subscriber));

The API change is due to Reactive-Streams .subscribe now being a void method.

Blocking Calls

RxJava2 provides several new operators to help with transforming asynchronous Observables into BlockingObservables. Particularly observable.blockingFirst() as a convenience observable.toBlocking.first(). Yay for less code and better performance.

Better Hooks for Plugins

One of my favorite changes is a rewrite of the plugin system. Now you’ll be able to override the values returned by the built in schedulers. This could be useful for overriding Schedulers.io() to return synchronous values during testing or even for making debug Schedulers that wrap the current ones inside of more logging. Way to go guys! I know this was a much clamored after and difficult-to-implement feature.

Summary

Overall I’m excited about the direction that RxJava is going. My favorite feature of the release is the new not null checks, which will surely lead to fewer elusive bugs. I’m also excited about the standardization with Reactive-Streams and the new Maybe and Flowable types.

With the stable release targeted for October 29, I hope everyone’s upgrades will be quick and painless. It seems like Retrofit already has support for RxJava2 for those that want to be on the bleeding edge. There’s also a nice library that helps convert from RxJava1 to RxJava2 types.

A big kudos goes to David Karnok, the lead contributor of RxJava, for his work on this release. While he might not be a name that many Android devs are familiar with, he’s been a leader in pushing reactive patterns into the community.

Sources:

http://reactivex.io/RxJava/2.x/javadoc/

https://github.com/ReactiveX/RxJava/wiki/What's-different-in-2.0

http://stackoverflow.com/questions/38423079/differences-between-rxjava1-and-rxjava2