Getting Started with your Android app

So, what’s the best way to get started with a project?

Most of our work at Novoda has been providing for companies that already have an iOS app or an outdated Android app – that is, for companies with an existing service and existing users. Part of this parcel also includes, from the client and existing users’ point of view, a set of core features – the requirements for the minimum viable product (MVP).

With Wutson, there is no existing userbase. There’s no iOS app or outdated Android app, nor is there an API or service which has been built specifically for our use.

How do we decide on what features should make up the MVP and how to prioritise various potential features? Which screens should we start working on, and do we just fill them with dummy data, or is it better to get the entire core of the app done before we do the UI (or vice versa)?

Writing user personas

There’s a good description of a user persona on Wikipedia:

In user-centred design and marketing, personas are fictional characters created to represent the different user types that might use a site, brand, or product in a similar way.

Here are some I prepared earlier:

Corl

Corl is a software developer in his mid-twenties. He doesn’t commute to work so primarily watches shows at home on his TV (via Chromecast/online services like Netflix). Corl speaks English well but prefers French; he currently uses SeriesTracker (backed by the French language BetaSeries API) enjoying the large community which shares reviews and comments about the shows and films he watches.

Rick

Rick is a police officer in his early forties. He works long hours in irregular shift patterns; it’s difficult for him to maintain a long-term routine because of this. Rick drives to work in his truck, taking his kids to school every day.

Beth

Beth is a second-year media arts uni student. She binges on Netflix and Amazon Prime trials when she can, else catches up on her stories by streaming them from various online sources. Her exam period is approaching, and she’s been studying hard – no TV shows/movies til exams are finished!

Maggie

Maggie is a final year computer science student. She torrents a lot, but does so like a pro; all the shows she watches are set up to download automatically, and she even gets a push notification on her phone when something has been downloaded. With all this automation, she’s on top of her studies and doesn’t feel much pressure to work much harder with exams approaching. In fact, she might watch a movie now…

When we write user personas, we should get a feel of the characters in the general sense – users of your app are not your users, they’re people that happen to use your app. In other words, don’t write personas to fit around the app you want to build; rather, we want to be able to use them to guide us to build the app they need. The product owner should be prepared to make decisions to avoid feature bloat.

We’re going to use these characters to write some stories later.

Constructing an information hierarchy

Spend some time to think about how the app will present data to the user, how it all ties together, and whether it fits into a cohesive model that can be learned without a conscious effort. Have a read of the Android design guidelines which discusses app structure in detail.

Looking at other apps, including Play Movies & TV, IMDb, and SeriesGuide among others, I came up with a set of all the screens that I thought could possibly be needed in the app:

Post-its with all the various screens of the app

This list assumes that we have some features – the ability to mark a show as “tracked”, split that list of “tracked” shows into “active” and “inactive”, and being able to obtain a list of related shows (to another show/actor).

The list isn’t exhaustive, nor does it mean we’ll have all these features and screens – it’s just a starting point for us to start writing some user stories.

Using static data from a live source

When you have access to the API, grab a copy of the JSON response(s) that’ll you’ll need using cURL or Postman.

This way you’ll have the ability to start building the models you need for the UI you need to implement, using real data, but you won’t have to sort out all the nitty-gritty behind how you’re obtaining the data.

Using appropriate ports means that it shouldn’t matter where you’re getting the data from. This is how I’m currently grabbing the data which I then pass to a RecyclerView.Adapter:

public class ShowsProvider {

    public List<Show> fetchTrendingShows() {
        DiscoverTvJsonParser parser = DiscoverTvJsonParser.newInstance();
        DiscoverTv discoverTv = parser.parse(MockDiscoverTv.JSON);
        ...
    }

    ...
}

MockDiscoverTv.JSON is just a String constant where I pasted the JSON response from the TMDb API. Later on, I can make ShowsProvider into an interface with multiple implementations – one could be retrieving this mock, another from a database, another from the live API, or one which has some strategy defining where it obtains data from.

You don’t even need to parse all the data from the JSON, just enough for what you need:

public class Show {

    private final Id id;
    private final Name name;
    private final PosterPath posterPath;

    public static Show from(DiscoverTv.Show discoverTvShow) {
        Show.Id id = new Show.Id(discoverTvShow.getId());
        Show.Name name = new Show.Name(discoverTvShow.getName());
        Show.PosterPath posterPath = new Show.PosterPath(discoverTvShow.getPosterPath());

        return new Show(id, name, posterPath);
    }

    ...
}

Note that I use Show to convert from a DiscoverTv.Show which is a TMDb specific model – this will let us switch out (or augment) the data source without remapping our entire app.

Clickable demo

A clickable demo is the end result of the first sprint of development (sprint 0). All our tools are setup, the project has been created and pushed to GitHub, and we’re ready to start working on implementing some stories!

The clickable demo shows the client that some work has happened. It’s always, intentionally, sketchy and gross-looking. This is too neat:


App implementing acceptance criteria as-is

By the end of sprint 0, we’d probably have a lot more than that done – at least some sketchy UI in the “detail” activity. The idea is to keep it as rubbish looking as possible for as long as possible – don’t let the client get stuck looking at details like font sizes and paddings when there’s more important things to do – that’s not important now.

That said, start as you mean to go on – just because we don’t want the client to be worrying about the details doesn’t meant that we shouldn’t: organise your assets, styles, dimens and strings meticulously so it’s easy to update when you get your designs updated.

Leave a Reply

Your email address will not be published. Required fields are marked *

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>