Introduction to RxJava for Android: The Talk

2015-06-17

Earlier today, I gave my Intro To RxJava talk. I’m not thrilled at how clear I was at explaining certain aspects of RxJava, but here’s the video nonetheless. My talk starts at 28:32. Hopefully, I’ll do a better job when I finish the written version of this talk. If you want to hear a hilarious take down of the design of the new Pizza Hut app, check out Ian’s talk that happens before mine.…

An Introduction to RxJava for Android (Pt. 1)

2015-06-12

I’m taking a brief break from talking about testing. I’ll resume my discussion of how I’m making Google’s IOSched app unit testable after I’ve posted the content from my upcoming talk on RxJava. …

Developer Golf

2015-06-07

What is Developer Golf? Developer golf is a fun way to measure developer performance. It turns our job into a game of producing the most lines of high quality (bug free) code. …

Unit Testing Dynamically Constructed Views

2015-06-06

Some view hierarchies in Android are specified statically. The structure of these hierarchies does not change at run-time. Occasionally, we need to have dynamically constructed view hierarchies, hierarchies whose structure change at run-time. We might need to, for example, add or remove a view depending on some data we’ve fetched or in response to some input. The SessionDetailActivity in Google’s IOSched app has a dynamically constructed view hierarchy. The number of tags associated with a particular IO session determines how many tag views are added to the SessionDetailActivity’s view hierarchy. In this screenshot, the “Distribute,” “Android,” and “Games” tags are added to the view hierarchy based on the tags associated with the “Going global with Google Play” IO session. In this post, I’ll outline an approach that I used to write the code that is both unit testable and able to dynamically construct the SesisonDetailActivity’s view hierarchy. This post is a part of a series of parts in which I discuss how we can take steps towards making Google’s IOSched app unit testable. …

Towards A Unit Testable Fork of Google's IOSched App

2015-05-31

In my recent Against Android Unit Tests series, I discussed the difficulties of unit testing android applications and proposed a different way of building applications that would enhance their unit testability. My proposal in that series was really largely a rough sketch of what it would take to make parts of Google’s IOSched app unit testable. More recently, I’ve started to fill in the details of that proposal by forking the IOSched repo and refactoring it to make it unit testable. In the next few posts, I’ll be discussing some of the challenges that arose when attempting to make the SessionDetailActivity unit testable within the IOSched app. In this post, I want to provide a broad overview of the challenges I’ll be discussing. …

An Introduction to Unit Testing on Android

2015-05-29

Yesterday at IO Extended Orlando, I gave a talk on testing. What follows is a written version of the presentation I gave. Android 1.2 introduced unit testing support. Now, we can run junit tests on the jvm while we’re developing our apps. During my talk, we’ll discuss the following questions: Why should anyone care about this new feature? What the heck is unit testing anyways? Briefly, I’ll also mention some of the challenges of writing unit tests for Android. …

What I've Learned From Trying to Make An Android App Unit Testable

2015-05-22

For the past few posts, I’ve introduced and showed how we would apply The Square Way of building Android applications. The primary motivation for The Square Way was to increase the unit testability of our applications. As I stated in the introduction to this series, most tests in Android are slow, instrumentation tests and/or tests that rely on third-party frameworks like Roboletric. The Square Way was supposed to help us write fast unit tests that didn’t rely on any third-party frameworks. Now that we’ve discussed why unit testing in Android is so difficult and seen how The Square Way resolves those difficulties, we are finally in a position to assess The Square Way as a whole as a method of creating unit testable Android applications. That assessment is the subject of this article. My assessment consists of the following three claims: Removing all compile time dependencies on the Android SDK is not necessary for us write fast unit tests for Android. (Its also not really a practical thing to try to do anyway.) Provided that we redefine The Square Way so that it does not require us to remove compile-time dependencies on the Android SDK, the only problem that arises when trying to apply The Square Way is simply writing all of boilerplate code. Fortunately, much of this boilerplate can be written for us by Android Studio. Dependency Injection is really the main “active ingredient” that allows The Square Way enhance the unit testability of our applications. …

Android Unit Testing Guides

2015-05-09

In my last post, I showed how we can apply The Square Way to UI app component classes. More specifically I showed how The Square Way would have us rewrite the SessionDetailActivity so that we could unit test its onStop() method. At the end of my last post, I said that I’d be spending this and the next post doing an overall assessment of The Square Way. I actually won’t be doing that this post. I’ll be postponing the overall assessment of The Square Way until the next few posts. Instead, what I want to do in this post is simply present a few unit-testability guides. These cheatsheets summarize much of what’s been covered in the past few posts and provide you with simplified steps to follow if you are interested in enhancing your application’s unit-testability via The Square Way. …

How to Make Our Android Apps Unit Testable (Pt. 2)

2015-05-08

In my last post, I introduced the “The Square Way” of structuring our android code. I said that The Square Way is a generalization of the approach that Square used to make the logic within their Fragments unit testable. I also showed how The Square Way would have us rewrite the SessionCalendarService within Google’s IOSched app so that we could unit test the business logic within it. As we’ll see in this post, The Square Way also makes it easier/possible for us to unit test UI app component business logic. …

How to Make Our Android Apps Unit Testable (Pt. 1)

2015-05-01

Unit testing Android apps is hard, and sometimes it can be impossible. For the past two posts, I’ve been explaining why android unit testing is so difficult. The main conclusion from the last post is that it is difficult/impossible to unit test our Android applications because of the way we are encouraged to structure them. Google seems to want us to put our business logic in app component classes (e.g., Activitys, Fragments, Services, etc.). This approach to writing Android applications is what I have been calling the “standard way.” In this post, I outline an alternative approach to structuring Android applications that will make it easier to unit test them. As I pointed out in the introduction to this series, the approach that I suggest is a generalization of the approach that Square uses to remove Fragments from their applications. Since this approach is inspired by the folks at Square, I will call it “the square way.” The heart of the square way way is this: remove all business logic from app component classes (e.g., Activitys, Fragments, Services) and place that logic into “business objects,” POJO objects whose dependencies are injected, android-specific implementations of android-agnostic interfaces. If we follow the square way of developing our apps, we will be in a better position to unit test them. In this post, I explain how the square way would have us refactor non-UI app components like the SessionCalendarService I’ve been discussing for the past few posts. …