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

I'm taking a brief hiatus from blogging here...

2015-06-26

…so that I can focus on ensuring that Droid Journal has a successful inaugural edition. I did, however, just post on Droid Journal’s blog.

Taylor Swift, Photographers, and "working for nothing"

2015-06-25

If you don’t already know, here’s a quick run down of what’s happening with the whole Taylor Swift/Apple/Indie Artists debacle: Last month, Apple released its streaming service and offered a three month trial period to users for free. During the trial period, they weren’t planning on paying the artists whose music was streamed by the service. Last week, Taylor Swift published an open letter to Apple in which she basically claimed that Apple was wronging artists by not paying them for three months. Two days ago, Jason Sheldon produced a contract that he had to sign to photograph one of Swift’s older tours, and because the contract allows for his work to be used indefinitely without compensating him for each use, he basically calls Swift a hypocrite. Swift’s spokesman said that Sheldon is misrepresenting the contract. A few hours ago, Joel Goodman, another freelance photographer, leaked a contract for the 1989 tour that contains even stricter rules. This debacle raises two philosophical questions: Is Swift a hypocrite? Have musicians like Swift or photographers like Sheldon even given a compelling argument for why they’ve been treated wrongly in the first place? I do think Swift is a hypocrite, but I don’t think that it really matters because neither Swift nor Sheldon has given us a good reason to think that artists are being wronged by companies like Apple and Firefly Entertainment. Let me try to convince you to see things my way. …

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

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