https://github.com/wongcain/okuki

Places and Navigation

Okuki provides a way to define and navigate your application’s view hierarchy in an abstract way, decoupled from your various Activity/Fragment/View implementations.
With Okuki, you can organize your application around a hierarchy of named Place classes. Each Place may be annotated to define its parent, establishing the hierarchy. Additionally each Place defines a type argument for a data payload it may carry when being requested:

@PlaceConfig(parent = KittensPlace.class)
public class KittensDetailPlace extends Place<Integer> {

    public KittensDetailPlace(Integer data) {
        super(data);
    }

}

In the above example, KittensDetailPlace is a descendant of KittensPlace, and carries an Integer payload. …

Several months ago, as a way to get myself up to speed with using and unit-testing RxJava, I developed and posted this reference application. I had ambitions of immediately following it up with a blog post, but I got distracted and I never got around to sharing it with anyone. So better late than never I suppose.

Use Case

The application is that of a metronome with the following features:

• A core metronome “engine” which triggers “beat” events on a timed interval. The engine exposes methods for starting and stopping the metronome, as well as a method for changing the tempo (i.e…

Originally posted March 11, 2015

Edit: July 19, 2016: I now consider this article “deprecated” as I have since joined the masses in treating Activities and Fragments as views, with necessary system services injected into separate presenters.

Edit: March 9, 2017: My current ideal MVP architecture for Android is reflected in this sample that is included in my view-state-navigation library Okuki. You can read more about Okuki here.

Today I want to share my own approach to implementing the MVP (Model-View-Presenter) pattern in Android. …

Originally posted February 12, 2015

In this final installment of EventBus series I want to discuss how Green Robot’s EventBus can be used to more simply handle asynchronous tasks running across multiple threads.

AsyncTasks, Loaders, and Executors… oh my!

There are quite a number of ways to execute code asynchronously (i.e. in parallel to the UiThread) on Android. AsyncTask is the easiest to user mechanism and requires a relatively small amount of set-up and code. However, it’s proper use is limited in scope. As it states in the Android Documentation:

AsyncTask is designed to be a helper class around Thread and Handler and does not constitute…

Originally published January 29, 2015.

As I mentioned in my previous post, my EventBus implementation of choice for Android is Green Robot’s EventBus, and I am not alone. At last check it has been forked about twice as many times as Otto, the EventBus implementation by Jake Wharton and other Android rockstars over at Square. While GR’s EventBus apparently has some significant performance improvements over Otto, what really sells it for me are the out-of-the-box add-on features that you get with it. Today I want to talk about one of those: event caching with “sticky” events.

What is this sticky stuff?

Sticky events are events…

Originally published January 22, 2015

An EventBus is a great tool for decoupling components in your application. Over the next few posts I will describe the ways that I have been using it to make my code cleaner, easier to read, and easier to test. But first, this week I want to discuss why I use an EventBus in the first place. In particular, I will compare its use to some alternative techniques.

vs. Listener Interfaces

A common pattern in Java, and particularly in Android is the use of Interfaces to define “Listeners”. In this pattern, the class implementing the Listener Interface must…