Android

Making a TDD-based HackerNews client for Android

2015-07-17

I’m using TDD to write a HackerNews client for Android. This post (and the ones that will likely follow it) share a little bit about some of the techniques I used to follow a TDD-based work-flow for developing this application. It also discusses the architecture that arises when Android apps are built with testability in mind from the ground up. …

Why Having Global Static References to Application Contexts is Probably not the Best Idea

2015-07-14

In my last post, I went over 6 things I wish I knew before I wrote my first Android app. One of the things I listed in that post was this: Don’t have static references to Contexts The reason I warned against this is that static references to Contexts can cause memory leaks. An astute reader pointed out that a static reference to an application Context wouldn’t cause a memory leak since the application Context is around for the lifetime the app is running anyway. I then qualified my warning by saying: Note: Technically, you can hold a static reference to an application Context without causing a memory leak, but I wouldn’t recommend that you do that either. In this post, I want to say a little more about why think having and using a static reference to an application Context is less-than-ideal. I emphasize “less-than-ideal” in the previous sentence as a way of highlighting what I’m not saying: I’m not saying that a kitten dies every time you use a static reference to an application Context. Once again, @codestandards is hilarious and relevant here: Please, for the sake of the kittens. pic.twitter.com/xaj7pNDVfH — Code Standards (@codestandards) February 24, 2015 Instead, all I’m doing in this post is offering a few points that suggest that using static references to Contexts is probably not the cleanest way of coding Android apps. …

6 Things I wish I Knew before I Wrote my first Android App

2015-07-09

My first app was terrible. It was so terrible, in fact, that I removed it from the store and I don’t even bother listing it on my resume’ anymore. That app wouldn’t have been so terrible if I knew a few things about Android development before I wrote it. Here’s a list of things to keep in mind as you’re writing your first Android apps. These lessons are derived from actual mistakes that I made in the source code of my first app, mistakes that I’ll be showing below. Keeping these things in mind will help you write an app that you can be a little prouder of. Of course, if you’re doing your job right as a student of Android development, you’ll probably hate your app later regardless. As @codestandards says, If the code you wrote a year ago doesn't seem bad to you, you're probably not learning enough. — Code Standards (@codestandards) May 21, 2015 If you’re an experienced Java developer, items 1, 2, and 5 probably won’t be interesting to you. Items 3 and 4, on the other hand, might show you some cool stuff you can do with Android Studio that you might not have known about, even if you’ve never been guilty of making the mistakes I demo in those items. …

My Response to Hannes Dorfmann on "the Circular Dependency Problem"

2015-07-08

In my last post, I argued that there are two disadvantages to Activities and Presenters. The first disadvantage is that they are often bloated classes. The second disadvantage is that these classes often have a circular dependency between themselves and their Views. Yesterday, Hannes Dorfmann made a comment on my post that was so thoughtful and excellent that I think its worth dedicating an entire post to responding to it. …

MVPR: A Flexible, Testable Architecture for Android (Pt. 1)

2015-07-07

Thorough unit testing helps us improve the internal quality because, to be tested, a unit has to be structured to run outside the system in a test fixture. A unit test for an object needs to create the object, provide its dependencies, interact with it, and check that it behaved as expected. So, for a class to be easy to unit-test, the class must have explicit dependencies that can easily be substituted and clear responsibilities that can easily be invoked and verified. In software engineering terms, that means that the code must be loosely coupled and highly cohesive —in other words, well-designed. Steve Freeman and Nat Pryce, Growing Object Oriented Software Guided by Tests Lately, I’ve been working towards making Google’s IO app unit testable. A part of the reason I’m doing this is to test the claims that Freeman and Pryce make in the above quotation about unit testing. Although I’m still not even done with refactoring one Activity in Google’s IOSched app, I’m already finding some truth to what they’re saying. The Activity that I’ve been working on is the SessionDetailActivity. If you’ve been following me for a while, you know exactly what Activity I’m talking about, but if you’re tuning in the first time, here’s what the SessionDetailActivity UI looks like: As I mentioned in the post that introduced this series, there have been several challenges to making the SessionDetailActivity unit testable. Unit testing its dynamically constructed views was a challenge that I discussed in my last post in this series, but in that post, I noted that my strategy for testing dynamically constructed views wasn’t entirely clean because of a circular dependency between Views and Presenters. This circular dependency is a symptom of a larger problem with how we structure our Android applications: both Activities and Presenters violate the principle of single responsibility. They are often responsible for at least two things: binding data to a View and responding to user input. This is a part of the reason why the SessionDetailActivity, a class that’s supposed to serve as a model for Android development, is over 1000 lines long. I think there’s a better way to structure our applications. In the next few posts, I’ll propose a new architecture that has the following properties: It breaks up the multiple responsibilities typically handled by Presenters and Activities It breaks the circular dependency that traditionally exists between Views on the one hand and Activities or Presenters on the other hand. It enables us to use constructor dependency injection for all of our objects that present data to the user and respond to user input. It makes our ui-related business logic classes easier to unit test, impossible to construct without the dependencies necessary to fulfill their responsibilities, and (slightly) more amenable to the use of composition and polymorphism to extend and/or modify object behavior. In this post, I will try to give some reasons why we might consider a new architecture for Android development in the first place. …

Introduction to RxJava for Android (Pt. 2)

2015-06-19

I concluded my last post by summing up what we’ve seen so far and what we still need to understand about RxJava: We now know what an asynchronous data stream is and we know that RxJava uses the Observer pattern to deliver these streams to everyone that’s interested. We still don’t know, however, what it means for a data stream to be “functionally transformed” nor do we know how RxJava allows us to represent anything as an asynchronous data stream that can be created and consumed on any thread. These are questions I’ll have to tackle in the second part of this written version of my upcoming RxJava talk. In this post, I’ll fill in the missing gaps in our understanding of my initial statement of what RxJava allows us to do. …

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. …

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. …