Vaughandroid blog

Revisiting Fragments in 2018

2018-07-15T00:00:00+01:00

Or: How I stopped worrying and learned to love Fragments.

Fragments have been a contentious topic in the Android developer community pretty much since they were first introduced. Ever since I read Square’s influential blog post, Advocating Against Android Fragments I have been firmly in the anti-Fragment camp. Recently, I’ve had cause to revisit Fragments. As it turns out, I think it might be time to switch sides.

In this post, I review the main problems with Fragments, then look into some of the recent changes that have alleviated those issues.

What was wrong with Fragments anyway?

When Fragments were first introduced way back in 2011, the main goal was to have a mechanism for creating modular, reusable, and largely self-sufficient components. This was an excellent goal, but the problems quickly arose. As I see it, the main issues were as follows:

Fragments had a lot of responsibilities to support, which made them challenging to implement correctly. E.g. lifecycle management, navigation state, composition, helping manage async operations.
The lifecycle was very complicated (see here) especially when you consider that there were differences in behaviour between different Android versions.
The implementation was buggy, and some areas (notably nested Fragments) suffered from a host of lingering issues. Often the bugs only arose in edge cases, and were very tricky to work around.

So what has changed?

In the past couple of years Google has doubled down on Fragment support, and they have made this clear at Google I/O ’17 and ’18. Fragments are being given a central role in the new Architecture Components libraries, and Google are now advocating a single-Activity, multi-Fragment architecture.

Bug fixes

Google have clearly been putting concerted effort into fixing bugs. I’m not going to try to list all of the issues that have been addressed, but in my investigations the only issues I came across have already been resolved in the AndroidX 1.0.0-beta builds.

New library support

Many of the new Architecture Components are designed to handle a smaller subset of the responsibilities owned by Fragments - we now have straightforward, “official” means of delegating the responsibilities out to other classes. They also smooth over a lot of the tricky edge cases that users of Fragments have previously had to deal with. Taken collectively, they have a massive impact on how easy it is to work with Fragments.

Lifecycle

For me, the main benefit of the Lifecycle library is that it manages to put a simplified, clean and consistent wrapper around the mess that exists under the hood. It is simplified to something like this:

Google have even taken steps to ensure that onSaveInstanceState() is called at a consistent point in the lifecycle. (See here). Also, in the AndroidX 1.0.0 release, Google have seen fit to recognise that the Fragment’s View has its own lifecycle. (See here.)

Previously, in order to write a well-behaved Fragment you essentially needed to implement a state machine which could keep track of multiple system callbacks to determine how to act appropriately. As far as I can see, we’ve now moved to a situation where we don’t need to track any state internally. This is a huge win in terms of ease of implementation.

ViewModel

I find the name confusing, but ViewModels are great. In essence, they give you an object that is bound to the logical lifecycle¹ of a Fragment (or an Activity). It’s great to finally have an “official” mechanism for this.

The ViewModel becomes the owner for the transitive state of the Fragment, including asynchronous operations.

LiveData

Lets you perform async operations without having to worry about memory leaks or updating he UI after onSaveInstanceState(). Lovely!

Honestly, I haven’t looked into this one in detail yet, but its role is to take over navigation responsibilities from the Fragment which definitely a good idea.

In conclusion

I still don’t have enough real-world experience with the new libraries to make a decisive call. I certainly don’t think Fragments are perfect - even with the new libraries, there are some wrinkles remaining. There are other things I still haven’t figured out yet, like the best approach to testing. What I will say is that I am very encouraged by my experience so far. Using the new libraries, it is now possible to write lightweight Fragments which just do I’m tentatively changing my assessment of Fragments from “actively harmful” to “actually useful”.

It’s worth mentioning that there are still perfectly sound - possibly better - alternatives. You can stick with Activities, use a library like Conductor, or roll your own solution. The playing field isn’t exactly level though: many teams will use Fragments simply because they are Google’s recommended approach. (I make no judgements here - there are valid reasons for doing this.)

If, like me, you hated the ‘old’ Fragments, I’d encourage you to try the ‘new’ ones. You might be surprised! You’re likely to need to use them sooner or later, so I think it’s worth getting comfortable with them.

This isn’t quite true, as they don’t survive the process being killed by the system. There’s a brilliant blog post about that here. ↩

Comment annotations

2017-04-14T00:00:00+01:00

Comments

How many times have you seen (or written) comments like these:

// This needs tests
// Needs testing
// Need to test this

Those comments are easy to write, but you only notice them when you’re looking at that bit of code.

Let’s say you have some time to pay off some tech debt and you want to add some tests. How are you going to find that code again? A project-wide search for “test” is going to turn up words like “fastest” or the @Test annotation, and a whole bunch of things like that.

Similarly, what if you wanted to track the incidence of these of comments in your codebase over time? You’re never going to do it because the cost of writing the regex (or whatever filtering script you want to write) is always going to outweigh any benefit, and it’s

Annotations

The dictionary defines annotations as follows:

an·no·ta·tion /noun/ a note of explanation or comment added to a text or diagram.

It’s right there in the definition. At heart, annotations are nothing more than comments about our code. We already have comments in Java though, so why not just use them? Well, because comments are code, they are highly structured and tools (like your IDE, or CI) can make use of them easily.

If I want to use IntelliJ find all the uses of @Deprecated in my codebase, I just find all the references to that annotation. Similarly, I could easily write an annotation processor to count the uses of that or any other annotation in my codebase, for use in a CI report.

Custom annotations to the rescue

So, how could we replace all those comments about missing tests with an annotation? Fortunately, custom annotations are easy to write in Java. Here’s a simple example:

public @interface NeedsTests {
}

We can probably do better than that though. This annotation is never going to be needed at runtime, and it wouldn’t make sense to put it on anything other than a method or a class, so let’s specify that:

@Retention(RetentionPolicy.SOURCE)
@Target(value = {ElementType.METHOD, ElementType.TYPE})
public @interface NeedsTests {
}

Better. But maybe we want to include some extra information, like an estimation of the effort it would take to write those tests. We can do that too:

@Retention(RetentionPolicy.SOURCE)
@Target(value = {ElementType.METHOD, ElementType.TYPE})
public @interface NeedsTests {
    int estimatedMinutes();
}

You can even specify defaults for optional default values if you want.

Other ideas

@NeedsTests is definitely my most used of these “comment annotations”, but here are some other ideas (I’ll leave their uses up to your imagination):

@NeedsRefactor
@TechDebt
@WTF
@ToDo
@LocaleSpecific
@NeedsLocalising

Really, your imagination is the limit here. If you have any other ideas, I’d love to hear them in the comments section.

Test doubles and Mockito

2016-10-17T00:00:00+01:00

I want to be clear up front: I’m a big fan of Mockito. It’s very easy to use, and quite powerful. It has saved me a ton of time when writing unit tests. With that said, I’m going to grumble about it for most of this post.

My main gripe with Mockito is it plays fast and loose with naming conventions for test doubles. The terminology we use for test doubles can get a bit muddled at the best of times, and Mockito pretty much stomps all over it.

Test doubles

You might be asking “what are test doubles?” You might know them as “mocks” or “stubs”. (This is actually part of the problem, as we’ll see.) We can define a test double as any object we substitute for a production object, for testing purposes.

That definition is pretty vague. Most of my test doubles just return some fixed values - can’t we have a specific name for those? What about ones that record interactions? In his book XUnit Test Patterns, Gerard Meszaros did us all a favour and came up with 5 different categories. Briefly, they are:

Stubs provide predefined (“canned”) responses to method calls, returning a value or throwing an exception.
Spies are stubs that record their interactions, for later verification.
Dummies are placeholders which are used only to satisfy method/constructor parameters. The code being tested shouldn’t actually interact with the dummy.
Mocks are configured with a set of expected interactions, which are verified later.
Fakes are different from other test doubles in that they actually implement real behaviour, albeit in a simplified form.

This was a step forward, and it became popular with the help of people like Martin Fowler - see his famous article mocks aren’t stubs. This gave us all a common vocabulary to use to talk about this stuff.

Mockito

So, along comes Mockito, which gives us 2 methods (and 2 matching annotations) for creating test doubles:

Mockito.mock() or @Mock When you call Mockito.mock(Thing.class), Mockito generates a subclass of Thing (or an implementing class if Thing is an interface) on the fly, and returns an instance of that class. Depending on what you then do to that instance, it can be used as a stub, a spy, a dummy, or a mock.
Mockito.spy() or @Spy The difference with Mockito.mock() is that rather than using default return values and having no behaviour, the default behaviour here is to delegate to thing (or an instance of the class if thing is an instance of Class). You get the behaviour of thing, with the ability to record any interactions with it and provide override methods with stubbed implementations. The normal term for this sort of test double is a partial test double. (Some people call them partial mocks, but I obviously take issue with that!)

Is this really that big a deal?

Names are powerful. Using clear, accurate names helps others immediately latch onto concepts - they provide mental shortcuts we can all share. It’s jargon, and we can infer its value from the fact we see it used everywhere.

As an example, look at design patterns. They encapsulate complicated concepts into simple names. If you see a class called UrlFactory you can immediately guess at how it works. If I say “X just delegates to an instance of Y”, you immediately know what I’m talking about.

If we use overly-vague names, we don’t get to take any of those mental shortcuts. Imagine trying to describe OO programming to someone without using the words “class”, or “object”. It would be really hard! You’d probably end up coming up with new names for those concepts.

Now imagine someone explaining OO programming to you, but they keep mixing up those terms. That’s even worse! This is what Mockito is doing.

Examples

Let’s look at some examples. You’ll see that Mockito doesn’t differentiate between the different types based on name - you have to look at how the objects are used to work out which type of double they are.

Mocks

A simple test using a mock in Mockito goes something like this:

// ARRANGE
// Throw an exception for any unexpected interactions, by specifying a default answer.
Thing mockThing = mock(Thing.class, new Answer<Object>() {
  @Override public Object answer(InvocationOnMock invocation) throws Throwable {
    throw new RuntimeException("Unexpected interaction!");
  }
});

// Set up expected interactions.
when(mockThing.getString()).thenReturn("result");

// ACT...

// ASSERT
// Verify expected methods were called.
verify(mockThing).getString();

Side note: Notice that we have to explicitly call verify() for the same methods that we set up expectations for at the beginning. There’s no verifyOnlyExpected() method. It turns out, Mockito’s support for mocks isn’t actually that great!

Spies

Another simple test:

// ARRANGE
Thing spyThing = mock(Thing.class);

// Override default method stub.
when(spyThing.getString()).thenReturn("result");

// ACT...

// ASSERT
// Verify expected methods were called.
verify(spyThing).getString();
verifyNoMoreInteractions(spyThing);

The only thing which changed here is that we don’t specify a default answer. (On a side note, I hope you find the spy = mock() bit in the first line as jarring as I do.)

Stubs

Another simple test:

// ARRANGE
Thing stubThing = mock(Thing.class);

// Override default method stub.
when(stubThing.getString()).thenReturn("result");

// ACT, ASSERT...

Look familiar? Same as the spy, but we lost the verification at the end.

The manual approach

I feel obliged to point out that it should generally be as easy, or easier, to write stubs manually than it is to use Mockito. If you find yourself using Mockito to stub a class because it has 10 methods and your test only cares about 2 of them, then that’s a code smell. You might want to split up the class, or at least define separate interfaces for different bits of behaviour.

Dummies

Dummies are really simple:

// ARRANGE
Thing dummyThing = mock(Thing.class, new Answer<Object>() {
  @Override public Object answer(InvocationOnMock invocation) throws Throwable {
    throw new RuntimeException("Unexpected interaction!");
  }
});

// ACT, ASSERT...

This is the same as the mock, but without setting up or validating any expected interactions.

What about `Mockito.spy()`

I mentioned this earlier, but it bears repeating: Mockito.spy() gives you something commonly referred to as a partial test double. It can function as a partial mock, a partial spy, or a partial stub. (Partial dummies don’t really make sense, for hopefully obvious reasons.)

The use of partial mocks is almost always a code smell, but they can be a useful stopgap when working with legacy code.

A simple test with a partial test double might look like this:

// ARRANGE
Thing partialMockThing = spy(new Thing("result"));

// ACT...

// ASSERT
// Verify expected methods were called.
verify(partialMockThing).getString();
verifyNoMoreInteractions(partialMockThing);

A case for the defence?

I’m not a mind reader, so I don’t know what the exact thought processes that led to Mockito functioning the way it does. I can suggest some possibilities though:

Software development is full of trade-offs, and we cope with this by prioritising certain features over others. In this case, the developers may have valued simplicity (of API and implementation) over precision.
The developers may have felt that the terminology established by Meszaros wasn’t worth following - maybe they felt it wasn’t ubiquitous enough, or maybe they thought it was undermined by the existing confusion between mocks, stubs and test doubles.
The really liked their pun on “mock”, but couldn’t come up with good ones for “spy” and “stub”. ;)

Conclusion

The first thing I said was that I’m a big fan of Mockito, and I am. I think you should be, too! But I don’t think it’s perfect. Names matter, and Mockito breeds confusion where it could bring clarity.

If you’ve never heard of test doubles, I hope this has been a good introduction. Even if you had heard of them before, I hope this post has been food for thought. (Especially if you happen to be one of the maintainers of Mockito!)

Killing an emulator - not as simple as you might think

2016-05-27T00:00:00+01:00

Background

I’ve been doing a bunch of work recently trying to fix up and improve our Android CI setup. I’m planning on doing a future series of posts on the topic, but I thought this warranted its own post since it concerns a recent update.

If you’re running CI tests on an emulator, you’re going to need to restart it - ideally you want a freshly started emulator for every test run. This helps minimize the effects of bugs in the emulator itself, which are a fact of life for the time being.

SDK Tools 25.1.6 (May 2016) includes this note in the release notes:

To improve the security of the Android Emulator and to address a reported security vulnerability, the Android Emulator Console now requires authentication before you can enter commands. Enter the auth auth_token command after you telnet to an emulator instance. auth_token must match the contents of the .emulator_console_auth_token file in your home directory.

Great - they fixed a security vulnerability!¹ Great, right?

The problem

Unfortunately the extra auth requirement breaks adb emu kill, which has long been the proper way to kill an emulator instance (though weirdly this doesn’t appear in the current documentation). The command just fails silently now.

Since adb emu kill doesn’t work, we’re left with these options:

Disable the new authentication feature. You can do this by replacing the .emulator_console_auth_token file with an empty file. (Source)
Kill the emulator process with kill -9.
Telnet in to the emulator, authenticate, and issue the kill command there.

Disabling authentication

Disabling the authentication would probably be OK - since we’re just talking about CI tests we probably don’t care too much about securing it. The problem here is that the .emulator_console_auth_token file lives in the user’s home directory. This system-level config is a pain in the arse for portability - you have to remember to change the system setting for every environment you want to run the CI scripts on. That also means exposing dev machines to the security vulnerability (if they ever want to run CI scripts locally).

Killing the process

kill -9 is considered bad practice because you don’t give the process the chance to do any cleanup. That could mean a variety of bad things: corrupting the filesystem image, not closing ports correctly, etc. You’re opening the door to a host of potential issues.

Doing it the right way (hopefully)

So, option 3 it was! The below Expect script opens a telnet session to the emulator, authenticates, and then issues the kill command (this is different to kill -9 since it allows the emulator to shut down correctly). There’s not much else to say really, other than I hope you find it useful.

Oh, and it’s my first Expect script, so please be kind. :)

I’ll save my amazement that we have to worry about emulator security for another day. ↩