Modern Android Application Architecture & Development: Part 2 – Architecture Basics, Project Organization and Clean Code

In continuation of the series of posts with our friends on the Nordstrom Technology team we’re going to be creating a simple StackOverflow client utilizing the technologies discussed in Part 1 – Tools & Libraries.

The image to the right is the final screen that will be presented to the user.

You can access part 1 on GitHub at:
Screen Shot 2015-06-10 at 2.18.16 PM

git clone
cd StackRX
git checkout stack_rx_1_architecture_basics

Before we jump into code let’s take a look at the anatomy and organization of the project.

StackRX Client Application vs StackRX Services

As mentioned in Part 1 we completely decouple the service layer from the view layer.  Projects that combine these become extremely unwieldy, limit code reusability and are much harder to test.

Android specific logic will never exist within the service layer.  Keep in mind that another team may use the service layer for their project so keep it clean.
Screen Shot 2015-06-10 at 2.24.36 PMTo create the services project simply right click File–>New–>New Module

In the editor be sure to select ‘Android Library’. Also make sure the library is included in your app build.gradle as a dependency

dependencies {
compile project(‘:stackrx-services’)

The services build.gradle should include any libraries shared between the application front-end and the services layer.

build.gradle (app)                                                                      build.gradle (services)

Screen Shot 2015-06-10 at 2.26.44 PMScreen Shot 2015-06-10 at 2.26.36 PM

Notice how we have the new Material Design cardview library only in the app dependencies but the services library contains Roboguice which is used both in the services and app.

Package Structure

Android applications are often organized by object type but we organize by feature.

Screen Shot 2015-06-10 at 2.29.52 PM

We do this for the following reasons:

  •  As projects get more complex, standard naming is imperative.  As we progress in the project development you will notice that all packages resemble each other in both the unit tests, client code and service layer.  This prevents problems like a fragment package with 30 fragment files with no context or classes being in packages for no rhyme or reason.
  • Coming into a large Android project can be hell.  As a new developer getting your first commit can be overwhelming.  However if the application is broken into features it’s much easier to get started.  Need to make changes to the shopping page?  Most likely it will be in the shop->fragment package. Some oversight will be needed for shared objects.
  • We will touch on this further, but fragment classes should be as small as possible.  Complex things such as adapters should be moved into their own packages and classes when possible.  This leads to more testable code in general.

Let’s Write Clean Code Together.  Android Code Best Practices.

We’ve spent a lot of time thinking of ways to keep our code base as uniform and readable as possible.  Following good practices from day #1 will reduce code complexity, tech debt and refactoring time.  Many projects race to release but are so disorganized and non-uniform a rewrite is almost necessary afterwards.

Code Grouping and Organization

Android Studio supports regions; a little known feature that really helps organize classes.

Pulling open StackRXActivity (or any other classes in the view layer) you will see our code regions defined:

Screen Shot 2015-06-10 at 2.32.35 PM

Figure 1                                                                       Figure 2

These are just like pragma marks in other languages.  To collapse the regions hit


to grow the region


The categories above are the same for every fragment, adapter, activity etc.

This won’t be crystal clear initially, but I’ll explain each region and its purpose.


This section is for dependency Roboguice injected classes

@Inject UserSession
private UserSession mUserSession;


This section is for injected Roboguice views.  There should be no view.findByViewId’s littered throughout the code

private DrawerLayout mDrawerLayout;


Local constants are immutable constants pertaining to the class.  If they are string constants and used in other classes they should live in an AppConstants

private static final String TAG = QuestionFragment.class.getSimpleName();


Local class variables.  We tend to perserve the ‘m’ prefix.

private QuestionFragment mQuestionFragment;


Any constructors associated with the class

public StackRXActivity () {}


All life cycle methods.  For fragments and activities order matters.  Ex: onCreate should never be after onDestroy

onCreateView(LayoutInflater, ViewGroup, Bundle)

protected void onCreate(Bundle savedInstanceState) {


Widget is used as a catch-all for widgets within the screen.

public boolean onCreateOptionsMenu(Menu menu) {


Listeners are all component type listeners in the view (OnClickListener, OnTextChangeListener)
Listeners should always be separate classes and never be inline in the life cycle methods.  Also set the listener in the code and never implement or extend on the class level.

private class OnLoginButtonClickListener extends View.OnClickListener {
        public void onClick (View v) { }


Events are triggered by the EventBus.  All fragment/activity level uses of the event bus are captured here

public void OnButtonSelectEvent(ButtonSelectEvent buttonSelectEvent) { }


Local methods pertaining to the fragment

public void AddItemToList(String item) {


Observers are listening for observables that have sent down a single typically from network calls

private class GetQuestionObserver implements Obvserver {


Getters and setters the class

public void getItemCount () {
       return itemCount;


Inner classes that are not discussed above

private class SomeInnerClass {

Variable Naming

Let Android Studio name your variables for you! Rather than using a shorthand like  "adaptor" or "qda" for a “QuestionDetailAdapter” simply start typing the first letter of the class name to have it automatically named that.

We use the m prefix on all class level variables.  While this is always up for debate, you never have any of the time wasting this.variableName on constructors.


public QuestionDetailAdapter(Context context) {
       context = context;      // no!
       mContext = context;  // nice!

You can configure Android Studio to automatically prepend the ‘m’ right when you type the variable name

Android Studio-->Preferences-->Edit-->Code Style-->Java-->Code Generation-->Field-->Name Prefix-->m

Layout Naming Conventions

Too many projects do not name layouts or layout ids consistently.  Our convention is as follows:

The layout name always matches the class exactly.  This makes it is incredibly clear which layout file is for which class.

Ex: → question_fragment.xml

Variable naming should always match the layout name appended with what it is and its type.

How many times have we seen: or

This gives no context.

Instead: or

Do you have any other tips / tricks for keeping your project sane and beautiful?  Drop us a comment!  Stay turned for Part 3:  Dependency Injection, RxJava, DAO’s and more!

Thanks for reading. If you have any questions or would like to know more about working with the Nordstrom Technology team feel free to shoot us an email!

Modern Android Application Architecture & Development: Part 1 – Tools & Libraries

In continuation to our series of posts with our friends on the Nordstrom Technology team we’re going to take a detour from RxJava and start looking at modern application architecture.


Android development has changed significantly since we first started developing applications circa 2009.  Typically the build system was Ant, (Maven if you were adventurous and really wanted package management), the IDE was Eclipse and the language was of course Java.  The emulator was, until only recently, laughably bad. Android library support was still evolving. Simple tasks like talking to a JSON backend and presenting data was painful.

public class MainActivity extends Activity {

    private TextView responseText;

    protected void onCreate(Bundle savedInstanceState) {

        // call AsynTask to perform network operation on separate thread
        new HttpAsyncTask().execute("");

    public static String GET(String url) {

        InputStream inputStream = null;
        String result = "";

        try {
            // create HttpClient
            HttpClient httpclient = new DefaultHttpClient();

            // make GET request to the given URL
            HttpResponse httpResponse = httpclient.execute(new HttpGet(url));

            // receive response as inputStream
            inputStream = httpResponse.getEntity().getContent();

            // convert inputstream to string
            if (inputStream != null)
                result = convertInputStreamToString(inputStream);
        catch (Exception e) {
            Log.d("InputStream", e.getLocalizedMessage());

        return result;

    private static String convertInputStreamToString(InputStream inputStream) throws IOException {

        BufferedReader bufferedReader = new BufferedReader(new InputStreamReader(inputStream));
        String line = "";
        String result = "";

        while ((line = bufferedReader.readLine()) != null)
            result += line;


        return result;


    private class HttpAsyncTask extends AsyncTask&lt;String, Void, String&gt; {
        protected String doInBackground(String... urls) {
            return GET(urls[0]);

        // onPostExecute displays the results of the AsyncTask.
        protected void onPostExecute(String result) {

            Toast.makeText(getBaseContext(), "Received!", Toast.LENGTH_LONG).show();

Who remembers, and who still does, a GET request like this?

It’s huge and we haven’t even marshalled the data into objects yet!  Fortunately things have been evolving especially after Google introduced Android Studio and Gradle as their defacto environment. Libraries have made our lives infinitely easier and tooling has gotten significantly better. However, a lot of projects are still being built as if it was five years ago. Now I don’t blame developers for this.  Android, unlike iOS, has a ton of options to choose from, and there is often no clear direction from Google.  Even some of Google’s own libraries; Volley, a solution for Async networking, for example; are poorly advertised.

Android often feels it is plagued by JQuery syndrome.  There are  a thousand ways to do something, but what works best?  In this series of blog posts we’ll build a real life application that uses what we feel is the best architecture/technology to achieve robust and well made apps.  We’ll focus on building a pretty typical client server application piece by piece.

In Part 1 we’ll discuss the basics of our Android architecture and the libraries we use to build our applications.  If you’re unfamiliar with what’s out there, or what’s being used, give it a read.  If you want to dive straight into the implementation then start with Part 2: Architecture Basics, Project Organization and Clean Code (Coming soon!)

IDE’s, Languages & Build Systems

As previously mentioned Android Studio and Gradle are now the recommended development environment for Android. If you’re still considering using Eclipse for a new project it’s unsupported. Frankly it’s time to get used to Android Studio.

Java is still the dominant development language on android. Though it’s completely possible to build an app using different JVM languages for example: Groovy, Kotlin etc. The New York Times app for example is based on RxJava and Groovy:

Getting Groovy With Reactive Android

We would still recommend sticking to Java due to the wealth of information currently out there. In our project we’ll slowly migrate to use RetroLambda to reduce the verbosity of our code.

Having a build server such as Jenkins will make managing builds in any environment that much simpler. A good alternative is Travis if you don’t want to spin up your own infrastructure.

Android Versions

What Android versions should you support? It’s pretty safe to no longer support anything Ice Cream Sandwich (4.0) and below. Version statistics are always available on the Android Developers Site.

Android Version Statistics

There were significant changes between 2.x and 4.x SDK levels. Android Studio now provides you with an easy guide on what features are supported on project creation. Google has done a nice job offering backward compatibility libraries to support older devices as well. More on that:


Having a good emulator is essential for rapid development, reducing build times and testing on different device configurations. Previously the Android default emulator was so poor that most developers just used physical devices. Google has finally released a decent emulator utilizing Intel’s HAXM technology. While it’s gotten better, we currently recommend Genymotion. Genymotion is fast, really fast. It’s free for personal development and simulates the most popular phones on the market today.


Play Services

Chances are you will use Google Play Services somewhere within your app. Using Google Play services is an easy way to leverage Google’s other product offerings. The most popular are of course Google Maps and Google Wallet, however it supports a host of others (Wearables, Google Fit, Drive, Places etc). Keep in mind each individual component may be included separately:

Ex: compile ‘’ (All Google services)


compile ‘’ (Google Fit)
compile ‘’ (Wearables)

Material Design

Material design was introduced with Lollipop last year. It’s an attempt to unify look and feel of apps on the Android platform. The entire design guide can be found here:

It’s worthwhile to get yourself up to speed on Material Design and its principals. Any apps not adhering to the new Material Design will not be getting much love in the Play Store.

Why is this section under libraries? Well, Google, for whatever reason gave us some components and not others. While there is a library for the new card view from Google, something like the floating action button is missing (Update: this is now part of the support libraries). Open source alternatives are needed until Google officially supports its components. We’ll dive into these components more later. Below is a megalist of Android libraries and a lot of material design libraries are highlighted:


Talking with Restful backends is how most apps communicate with servers. The common data retrieval use case

1) User Needs Data
2) Asynchronous Call is Made
3) Data is Requested
4) Return JSON is Marshalled into Objects
5) Data is Presented to the User

Let’s take each individual step:

User Needs Data

Typically triggered by a user action (sign in button, displaying a list) We always break out the service layer apart from the view layer. Projects get ugly quickly when the view layer and service layers are intermixed. We’ll create a separate Android library to accomplish this. When a user needs to perform any action against our Restful backend we’ll call into the service layer.

Asynchronous Call is Made

Not blocking the Android UI thread is critical to prevent Android from killing your app. Some of the major libraries used for this are Volley, Retrofit and Robospice. Each have their strengths and weaknesses. We chose Retrofit for a few reasons. Syntactically it’s very simple and Retrofit also plays well with RxJava which we’ll use to communicate with the view layer and beyond.

Ex: @GET(“/2.2/questions?order=desc&sort=activity&site=stackoverflow”)
Observable getQuestions();

Part 3: Dependency Injection, RxJava, DAO’s and more! will give a full example of this. Much more on this later.

Data is Requested

Once again there are a lot of alternatives for this. Some typical ones are Google HTTP Client and OkHTTP. We use OkHTTP as it’s also by Square and easily integrates with Retrofit. Note: The Apache HTTP libraries have been deprecated for some time now so stay away from them.

Return JSON is Marshalled into Objects

In order to easily work with our data we want it returned as objects. A lot of projects still do this by hand and it’s painful and error prone. Common libraries to do this are Jackson and GSON. We will use GSON in our project.

Data is Presented to the User

In order to present the data to the user we must get back the requested data in a useful form. Once again Volley, Robospice, Retrofit and various others all support this. We are using RxJava. RxJava is a reactive style of programming that is extremely powerful and solves a lot of problems other libraries do not. RxJava was originally developed for the .NET platform but has been ported to seemingly every language known to man. ReactiveCocoa for iOS is extremely popular.

A common use case:

User Logs In -> Server Must Verify Username / Password -> User’s addresses, credit cards, and list of orders are returned from the server. Managing all these interactions is handled with RxJava in an elegant way. Also more on this later.

Event Bus

An event bus is an easy way to communicate between fragments, activities etc. Android has a default event bus but the most popular is Otto by SquareUp. Event busses are a great way to communicate within the app but can be grossly overused. Used sparingly they solve a whole host of issues and reduce callback hell. We’ll use Otto in small doses.

Image Loading

There are a host of image loading frameworks out there. The most popular include Picasso, Volley, Glide, and Universal Image Loader. Recently Facebook released Fresco. Fresco is a robust image library that uses an image pipeline to efficiently manage memory. This solved a host of memory problems in a recent app we were working on as it was extremely image heavy.

Dependency Injection

Dependency injection helps manage inter-dependencies in the application. The most commons ones are Butterknife, Roboguice and Dagger. We use Roboguice as it’s less complex than Dagger and plays well with Mockito for our unit testing. We are currently investigating Dagger as a viable alternative now that it is supported by Google.


Testing has traditionally been a pain in Android. More projects than not have no tests at all. Tools often don’t play well together and the Android lifecycle and Context often make testing difficult. Things have improved with better testing integration with Android Studio’s recent releases.

Mocking Data

Mock data is important. It allows you to manipulate data to easily perform varying tests. It also allows you to develop without being dependent on the service layer or making live calls. Common mocking frameworks are Mockito, Powermock and Easymock. For our project we’ll use Mockito as it plays well with Roboguice, RxJava and Espresso.

Unit Testing

We’ll test our business logic using straight, and fast, JUnit tests. The app must be structured in a smart way to truly make this achievable. Typically too much logic happens in Android’s lifecycle methods which makes testing extremely fragile. We’ll create helpers to test our business components.

Integration Testing

Numerous libraries allow for on device integration tests. These tests tend to be slower but are able to test both business logic and UI. The most common ones are Espresso, Robolectric (which is a headless JVM and does not require a device), and Robotium. For our project we’ll use Espresso. We chose Espresso as it’s maintained by Google and has good API’s. We’ve experienced a lot of compatibility problems with Robolectric and Robotium especially with new features added by Google.

As you can see there are lots of choices to architect an Android app. In our case we’re drawing from personal experiences in large scale projects. This is by no means the definitive list of everything. There is always better solutions and things are always changing. We’ll take our selected technologies and begin to build our client in Part 2: Architecture Basics, Project Organization and Clean Code

Thanks for reading. If you have any questions or would like to know more about working with the Nordstrom Technology team feel free to shoot us an email!