Android

Testing Strategies with a React/Redux Architecture

2016-06-09

In my last post, I briefly introduced the principles behind React and Redux. I said that React is about making what gets rendered to the screen a function of some view-state object. I also said that Redux is about making updates to the screen a function of the current view-state object and an action describing a user’s interaction with the view. In this post, I explore a benefit of a React/Redux-like architecture vis-a-vis testing.…

How React-and-Redux-like Architectures for Android can make Testing Easier

2016-06-08

I think there’s a lot of value in seeing what else is happening, even if you’re not a master of one of those other languages. As long as you’re being exposed to it, you’re opening your mind up to different ways of approaching problems and solving problems and different techniques. Jake Wharton, Fragmented, Episode 6, 27:45-28:20 React and Redux are libraries that have taken the web development world by storm.…

PSA: Dont Use Espresso Idling Resources like Google does

2016-06-07

Roman Nurik: …That’s actually one of the harder things with writing good sample code. People are going to be copying and pasting the heck out of it so you can’t take those shortcuts that you sometimes hopefully aren’t taking. Chet Haase: I always take the shortcuts. That’s one of the more interesting things that the developer relations group does in general…we will put together tests and sample code for the features that we work but we really don’t have the time to dive in deeply and do it in a real context.…

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