Write better code with Conductor's Controller

Kittinun Vantasin

About me

Mobile Enthusiastic

💖 Kotlin + Open source

Work at Mercari (Merpay) in Tokyo, Japan

github.com/kittinunf

@kittinunf

Agenda

1. How to architect your components in Android app

2. How Conductor fits into this

Design Philosophy

Using classes to separate Concerns ! ! !

Storage, Networking, Parsing, Routing, Business logic, Display

Easily abused! >_< 😱

Abused ? Why?

Business Logic

View Setup / Loading

Model observation

Datasource interaction / Network

Handling permission / API differences

Screen

Problems

Hard to understand 😕

Hard to test ❌

Fragile to change 💔

7,000 lines seems acceptable 🙅

Do something?

So, Yet another arch?

NO

MVP, MVVM, MVI, M** ... (🔮 🙅‍♂️ we aren't talking about arch today™)

Then, what?

Slowly changing the way you design your code structure and screen

With 6 simple Concepts

Concept #1

Use appropriate data structures & code structures

Data structures

~ 80 % of the time choose List<T>

When you need something more like association e.g. A <-> B tries Map<A, B>

Ownership, does this contains that? picks Set<T>

Need something like a hierarchy use Tree<T>

Code structures

  
  fun getFoos(): List<Foo> {
     val size = bars.size
     val arr = ArrayList()
     for (i in 1..size) {
       arr.add(Foo(bars[i].bar))
     }
     return arr
  }

  
  fun getFoos(): List<Foo> =
    bars.map { Foo(it) }

Use the right patterns where it is appropriate

Don't overuse it

Learn tools' strength and weakness!

Concept #2

Naming affects intentions!

2 Hardest Probs in CS

1. Cache Validation

2. Naming things

3. Off-by-one errors 󠀫󠀫󠀫󠀫󠀫󠀫󠀫🤔

Naming!

*View should belong to View layer

e.g. View, TextView, CalendarView

*Manager should belong to **Controller** Layer

e.g. LocationManager, AlarmManager, SearchManager

*Data, *Cursor usually a helper to Model layer

e.g. SqlLiteDatabase, SqlLiteCursor

Please choose GOOD NAMES!

Concept #3

Activity™ and Fragment are just a regular VIEW

Responsibilities

Loads Views

Layout Views

Perform Animation on Views

Show/hide Views

Transition Views

It is all about Views ...

So ... Maybe it is View?

If they are only doing View stuffs ...

Implications?

No networking

No data persistent layer

No navigation (Activity™)

No business logic

No model observation

Just displaying stuffs ...

Concept #4

Views are usually small™

Smallness

Views are small components of a screen

They do only one job and do it really well

A View != A screen

Small Fragments

A Fragment != A screen

You don't have to fill the screen with one fragment!

Use multiple fragments where it makes sense!!

Concept #5

Views are great when they use as composable/reusable units

Composing

Adding small things to make big things

The single most important skill as software engineer

Reusing

We don't rewrite TextView? we don't rewrite RecyclerView?

We adjust the style and reuse them

We adjust the style and reuse them

WHY DO WE DO THAT WITH FRAGMENT ?

Reusing cont.

It is not 🙅	It is a 🙆‍♀️
ShoppingListItemFragment	ListItemFragment with Adapter that shows ShoppingItem
AddressFormFragment	Fragment that shows multiple EditTextFragment as a form item
ImageView subclass that hits network	ImageRemoteFragment with an image provider (local / network)

Concept #6

We need an actual place for our logic

Case study

1. Install/Uninstall + Open app

2. Read What's new

3. Rate App

4. Contextual information

5. Related application

6. Read Description

Logic

Model observation
Determine Action
Observe the state
List related apps

Actions

Uninstall/Install Open
Rate the app
Go to the different app
See the images
Search and more ...

If we do this in one Fragment, it would be horrible to maintain

Then, how ?

GooglePlayStoreItemInfoFragment

StoreHeaderFragment

StoreWhatsNewFragment

StoreContextualLinkFragment

StoreRelatedItemFragment

StoreDescriptionFragment

How?

Then, how ?

StoreItemInfoF

StoreHeaderF

StoreWhatsNewF

StoreContextLinkF

StoreRelatedItemF

StoreDescriptionF

How?

What is this?

It can be anything!

MVVM - it is View Model

MVP - it is Presenter

MVC - it is a Controller™

M** - it is a something that sits in the middle managing components

A better code structure

1. Use appropriate data structures & code structures

2. Naming affects intentions!

3. Activity™ and Fragment are just a regular VIEW

4. Views are usually small™

5. Views are great when they use as composable/reusable units

6. We need an actual place for our logic

It looks like we are done here ...

but ...

Exception java.lang.IllegalStateException: 
 Can not perform this action after onSaveInstanceState
android.support.v4.app
 .FragmentManagerImpl.checkStateLoss (FragmentManagerImpl.java:1538)
android.support.v4.app
 .FragmentManagerImpl.enqueueAction (FragmentManagerImpl.java:1556)
android.support.v4.app
 .BackStackRecord.commitInternal (BackStackRecord.java:696)
android.support.v4.app
 .BackStackRecord.commit (BackStackRecord.java:662)

We don't like Fragments?

Entering Conductor

Promote the View-based Application

Fragment alternative (much simpler)

Just works™ (with a little setup)

bluelinelabs/Conductor

Conductor

Activity

Router

Controller 1..n

View

Setup Conductor

class SampleActivity : AppCompatActivity() {

  private lateinit var router: Router

  override fun onCreate(bundle: Bundle?) {
    super.onCreate(bundle)
    setContentView(R.layout.activity_sample)

    router = Conductor.attachRouter(
               this, 
               container, 
               bundle)

    if (!router.hasRootController()) {
      router.setRoot(RouterTransaction.with(
                     MainController()
                     ))
    }
  }
}

<com.bluelinelabs.conductor.
  ChangeHandlerFrameLayout
  
  android:id="@+id/container"
  android:layout_width=
      "match_parent"
  android:layout_height=
      "match_parent"

/>

Setup Controller

class MainController : Controller() {
  override fun onCreateView(
    inflater: LayoutInflater, 
    container: ViewGroup): View = 
      inflater.inflate(R.layout.controller_demo, container, false).apply {
         //setup your view
      }
}

Similar to Fragment counterparts

Easier lifecycle!

Navigate!

Use Router to push/pop controllers

  
  router.pushController(RouterTransaction.with(
                        AnotherController()))

animation, horizontal/vertical/fade?

  
  router.pushController(
   RouterTransaction.with(AnotherController()).
     pushChangeHandler(HorizontalChangeHandler()).
     popChangeHandler(HorizontalChangeHandler())
  )

How about Lifecycle?

New instance (init)

onCreateView

Controller is on top!

onDestroyView

Controller is on top again

Send to back / Configuration Change e.g.

Remove from Router / Got killed by System