building large sustainable apps

Building Large Sustainable Apps

Buğra Oral

© 2003–2014 Monitise Group Limited. All Rights Reserved. Confidential.

1


2

AGENDA

• Problem

• Project Culture

• Structuring a Sustainable Project

• UI Structuring Dilemmas

• GUI Software Architectures

• State of Art

3


Problem

4


Problem

5


Problem


6

Within onCreate

ProblemScaled

Within onCreate Scaled


7

Activity as ClickListener

ProblemScaled

Activity as ClickListener Scaled


8

ButterKnife Example

ProblemScaled

ButterKnife Scaled

9


ProblemMixed


10

Problems

• View id’s

• Refactoring

• Confusion

• Inconsistency

• Hand over rate


11

Project Culture

• Conventions

• External Dependencies

• Resources

• Names

• Migrations

12

Project CultureConventions

• Main tool of communication is the code.

• Code blocks

• Field / Method / Class names

• Tip : Feature Component Based Names i.e: FlippingContactActivity / FlippingContactFragment

• Tip: Android Support Annotations, ex: View.VISIBLE,GONE

• Don’t ignore exceptions and handle errors gracefully

• Don’t use finalizers, no guarantees.

• Don’t duplicate code

• Have sense of maximum line and method length

• Favor equals methods over static objects

• Avoid nested blocks

• Use checkstyle tools to minimize alienation margin


13

External Dependencies

• What could be an external dependency?

• Network library – Retrofit, Volley, Picasso, Wasp• Parceable Generators - Parceabler• Factory Method generators - IcePick• View libraries • ORM’s – Greendao• Check out android-arsenal.com

• Select your tools and debate so that there will be no place for two dependency doing similar stuff


14

RESOURCES

What are the resources?

• Color

• Drawable

• Arrays

• Strings

• Dimensions

• Styles

• Themes

• Layout

• Menu


15

RESOURCESNaming Conventions

Having a resource convention is very important. Resources can will expand drastically depending on how you structure them. It’s general conception to rely on prefixes.

• Colors: it is better to have the names set by the designer, and reuse them as logically as possible. Material guidelines will also encourage you to use them this way, i.e; colorPrimary, colorAccent. For colors with alphas, it is encouraged to use a $colorname_alpha_percent notation.

• Drawables: same as colors, debate with your designer. It’s helpful to come up with a pattern that uses prefixes as ic_ logo_ bg_ and so on.

• Layouts: Layout naming are very important, because they also effect your way of coding and increase clarity.

• activity_$activity_java_name• fragment_$fragment_java_name• list_item_$what_this_layout_renders• pager_item_$what_this_layout_renders• layout_$what_this_layout_renders



16

• Layout View Id’s. • Duplicate layout id’s are the birth marks of a

chaotic project.• Refactor renaming an id will change every

single layout file as well as Java class.• Id’s are too generic, we don’t know that it does.• From Java file we can’t navigate to actual view

without further investigation.• What happens if there are two views with same

id’s in a view group? What will findViewbyId return?

• Suggestion is to use a id pattern, such as $(layoutfilename)_$viewtype_$whatitdoes

• Also now I can see all the views under some xml file just by writing R.id.$(layout_name)_ yaay!

Same goes for String resources.

RESOURCESNaming Conventions

Back to click listener example

17

RESOURCESStructuring

Android Themes and Styles has strong parenting relationships. Utilize them to diminish line of code and increase their usage. It’s very important not to break a style/theme structuring pattern.

• For Themes, always have base theme that does not vary from configuration to configuration.

• For styles, same, maintain a base themes; for all base views, TextView, EditText, Button and so on.

• Don’t break parenting for different activity themes and view styles.

• How to know you did a correct style/theme structure? If you need very little adding and modification while adding new layouts, that’s when you can assume it works.

When all are done accordance with a scalable logic, which is all your files under /res follow a certain rule, there won’t be much a need to create, duplicate and defect.



18

RESOURCESStructuring

19

Application Structure

• Abstractions

• What should I abstract?

• Almost every Android Component. Application, Activity, Fragment, TextView, Button and so one.• Why? You will or may need application global behavior the first day of development or 6 months later.• But, be aware of the overhead! Every abstraction brings 500 byte of overhead to java classes.• Force your view to use your styles by default in constructer.

• Package structure;

• From experience, in most cases feature based approach works best for Android.• We can use public/private/package private modifier as they are intended.• For large apps, containing multiple features, it is such more easier to navigate and locate classes.• A developer working on a specific feature does not need to go beyond his scope.• Keep java packages and their resources aligned i.e;• Different string resource files for features• Different style/theme parents for feature sets.


20

Architectural Design

• What are the most common Android Architectural designs?

• What are Activities and Fragments from a architectural point of view?

• Some will say they are class that you do everything in them.• When do I use an Fragment instead of Activity?• Some will say that they are Presenters from MVP pattern.• If they are Presenters, what are their responsibilities?• Is a Fragment simply view which should render given data or a something that has some deciding,

loading, changing data capabilities?• Or are fragments mini activities capable of maintaining their jobs themselves? If so what do I do with

child fragments? • Wait child fragments? If a fragment a child, does it have to report to its parent fragment or the

Activity?• Hey what do I do if I need to use a picker? A whole activity, fragment? How do I return the selected

values?

So the fun and chaos begins…


21

Architectural Design Organized Utilization of Activity and Fragments

• In a Application consisting of a bunch of features, a better way to organize is to think your individual Activities as features.

• They will most generally do data operations, display fragments, open other activities. So they will become a descriptor of that feature, containing no UI related elements at all.

• All UI stuff should be in Fragments, so that they can be used both in tablets and phones. By replacing your Fragment with a new one with better design, we begin to maintain better by plunging out and in a new peace of Lego.

• To arrange Activity and Fragment communication; general conception is to use activities as callback interfaces, but to further decouple components, we encourage the use of Event Buses.


22

Event BusSide Explanation

• Event bus is a way of communication between objects. An object subscripts to the bus for certain events.

When the certain event is fired, all that are registered will be notified.


23

Architectural Design Tip

• It is highly encouraged to escape android components and move to plain old java objects. Clean all codes you can and move to an external java module so that you can run simple unit tests and export your business logic.


24

Architectural Design Exploring Design Patterns

• What is the general problem we need to attack at? %99 Android projects are

• Hard to test code• Hard to read code• Hard to refactor code• Hard to reuse code• Hard to handle-config changes code• Hard to replicate edge-cases code• Hard to hand-over code


25

Architectural Design Exploring Design Patterns

• Why is it this then?

• ~99% of the Android examples are written this way• It mostly works• Framework classes and libraries work this way.• People have got used to hearing that Android works this way and accepted it.


26

Architectural Design MVC

MVC (Model-View-Controller) : The term MVC is in my opinion highly subjective and highly abstract. The pain point seems to be around the definition of Controller. There are genuinely two different interpretations of MVC.

• (less-often) An over-arching term, which is a superset of all MV* architectures that separate some View from some Model and other middle-ish layer than may or may not communicated with the View & Model components directly.

• (more-often) A slightly more concrete notion of a pattern that relates the M V and C components in a triangular relationship which does not allow the user to interact with the View directly but only via a View and / or Controller. View displays the Model and Model is manipulated via the Controller.


27

Architectural Design MVP

MVP (Model-View-Presenter) : MVP is still to general to understand. Main thing is there is linear relationship between M V and P components.

• Generally Model is accepted as the source of data and View is acknowledge as a rendering component.

• Responsibilities of Presenter on the other hand differ from interpretation to interpretation.

• one hand there is the case where all view logic is left in the view and the presenter doesn’t get involved in deciding how to render the model.

• you can also move all the way to having the presenter do all the manipulation of the widgets


28

Architectural Design MVVM

MVVM (Model-View-ViewModel) : This is a popular one in the Microsoft (& Xamarin) world. The thing that all MVVM architectures have in common is…data-binding!

In a nutshell the ViewModel can define the binding between Views and data properties and if bound two ways then changes to the view update the model and changes to the model update the view, pretty much for free.


29

Architectural Design MVA

MVA (Model-View-Adapter) : This one is interesting as its pretty simple. This is like a linear MVC (the same as MVP above), meaning that there is no communication between the View and the Model.

From what I can deduct, this seems to be very similar to MVP, except for the fact that Adapter can not store view state, while the presenter could.


30

State of ArtDesign Patterns

MVP PASSIVE VIEW


31

State of ArtMVP Passive View Implementation


32



33



34



35



36

ConclusionWhat did we gain?

• We have project that maintains a culture

• We have logically structured resources

• We can have objects independent from lifecycle methods

• All presenters can be exported and used with other layouts

• All view’s behavior can be changed by its presenter

• Modularity boost by moving presenters and view interfaces to a library.

• Presenters are JUnit testable

• View objects can be mocked via classes that implements the view interfaces

• Cool stuff like RxJava and Dagger could be leveraged in the presenters, in the business logic where their benefit boosts up.


Q&A

BUĞRA ORAL


37

building large sustainable apps

Software

monitise group limited

clicklistener problem

oncreate problem

agenda problem project

butterknife example

dont use finalizers

external dependency

dont duplicate code