Upgrade to Pro — share decks privately, control downloads, hide ads and more …

A Pirate's Guidelines for Android

A Pirate's Guidelines for Android

Fragments suck. State is hard. Android is hostile. How can you write a crashfree, bug free app on such a buggy, fragmented OS? In the spirit of Jack Sparrow, I’ve come up with some guidelines for making Android development less of a headache. Talk would basically be about how we’ve adapted and used each of these in the Electric Objects companion app.

- There is a one to one correspondence between a wireframe screen and an Activity.
- Every Activity has it's own layout file.
- Reusable View code belongs in a View class.
- Fragments are not simple. Don't use fragments.
- Embrace state machines.
- Corollary: Every Activity is a State Machine.
- Override on configuration changed at your own peril (aka never)
- Retain nothing but state (and hardware adapters)

This talk was first given at DroidCon NYC 2015.
http://droidcon.nyc/2015/dcnyc/10/

NeiL saitug

August 27, 2015
Tweet

More Decks by NeiL saitug

Other Decks in Programming

Transcript

  1. Pirate Guideline #1 There is a one to one correspondence

    between a wireframe screen and an Activity
  2. A State Machine —States are explicitly defined —Can only do

    certain things in each state —Where you can go next depends on where you are now
  3. —There is a one to one correspondence between a wireframe

    screen and an Activity —Every Activity has its own layout file —Reusable View code belongs in a View class —Fragments are not simple. Don't use fragments.* —Never override configuration changed* —Retain nothing but state* —Embrace state machines