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
Problem
Scaled
Within onCreate Scaled

7
Activity as ClickListener
Problem
Scaled
Activity as ClickListener Scaled

8
ButterKnife Example
Problem
Scaled
ButterKnife Scaled

9
Problem
Mixed

10
Problems
• View id’s
• Refactoring
• Confusion
• Inconsistency
• Hand over rate

11
Project Culture
• Conventions
• External Dependencies
• Resources
• Names
• Migrations

12
Project Culture
Conventions
• 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
RESOURCES
Naming 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.
RESOURCES
Naming Conventions
Back to click listener example

17
RESOURCES
Structuring
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
RESOURCES
Structuring

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
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 Bus
Side 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
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
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
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
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
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
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
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 Art
Design Patterns
MVP PASSIVE VIEW

31
State of Art
MVP Passive View Implementation

32
State of Art

33
State of Art

34
State of Art

35
State of Art

36
Conclusion
What 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ĞRAORAL
37

Building Large Sustainable Apps

Recommended

Recommended

More Related Content

Similar to Building Large Sustainable Apps

Similar to Building Large Sustainable Apps (20)

Recently uploaded

Recently uploaded (20)

Building Large Sustainable Apps