The document discusses the benefits of developing Android applications using frameworks. It highlights that frameworks provide a common code base that is reusable across multiple applications and contexts. This prevents teams from reinventing the wheel and allows for easy onboarding of new team members. The document also identifies several important components that should be included in a framework, such as libraries for REST consumption, object serialization, caching, local databases, in-app communication, automated testing, and build systems. It provides examples of popular libraries that can be used for each component and additional considerations for a successful framework.

1. Android Frameworks
Highlighting the need for a solid
development framework

2. A little about me...
●
●
●
●
In the industry since 2002.
Started at Mutual Mobile in 2011.
Last hair cut 2011.
During which I’ve released 7 apps.

3. What is a framework
● Starting from scratch is unsustainable.
● A framework is a common code base that is
reusable in multiple contexts
● Basically its just an Android project ready to
be copied
● This is possible because most app share
common basic tasks

4. Technical benefits
● All libraries are bootstrapped and ready to
play
● Prevents reinventing the wheel
● Common build system interface

5. Organizational benefits
● Allows all team members a common ground
for communication
● Allows for cross team problem solving
● Allows for easy onboarding
● Unifies non collocated teams
● Measure team member success

6. Components of a Framework

7. Component: REST Consumption
Most app currently leverage REST. As such
this is one of your most important decisions.
● Existing Libraries
○
○
○
○
○
HttpUrlConnection
ApacheHTTPClient
Volley
Retrofit
okhttp

8. Component: Object Serialization
While ReST services are great at returning
strings, POJO’s are better.
● Existing Libraries
○
○
○
○
Gson
Jackson
Simple
Protobuf

9. Component: Caching
As mobile matures so do the users. Redundant
REST requests won’t cut it any more.
● Existing Libraries
○ Volley
○ okhttp
○ DiskLruCache

10. Component: Local Database
Invariably the app will need to keep state. Your
devs will need a place to keep it.
● Existing Libraries
○
○
○
○
○
Shared Preferences
Sqlite
Ormlite
GreenDAO
DB4O

11. Component: In App Communication
Communicating is hard, even more so if you
have Asynctasks, Services and, Fragments in
the mix.
● Existing Libraries
○ Android intent system
○ Otto
○ Eventbus

12. Component: Automated Testing
Well done. Here are the test results: You are a horrible
person. I'm serious, that's what it says: "A horrible person."
We weren't even testing for that.
-- GLaDOS / Portal 2
● Testing Options and Support Libraries
○ Android Test Projects
○ JUnit
○ Robolectric
○ Mockito
○ Robotium
○ uiautomator

13. Component: Build system & CI
Autonomous build creation is a wonderful thing
and gives you moment to moment status of
your projects.
● Existing Options
○ ANT build process
○ Maven (kinda...)
○ Gradle build process

14. Additional Considerations
This is not an exhaustive list keep your eyes
open for other things as well.
●
●
●
●
Logging
Crash reporting
Code Metrics
Image loading

15. Component: Glue
Even with the best libraries selected a
successful framework needs to be pulled
together.

16. Mutual Mobile’s Framework
Praxis: the process by which a theory, lesson,
or skill is realized.
● Libraries Used
○
○
○
○
○
○
○
ApacheHTTPClient
Gson / Simple
DB4O
Otto
JUnit / Robotium
ANT
Dagger

17. Care and feeding of your framework
● Frameworks only last so long.
● Some of the libraries listed haven’t had their
first birthday yet.
● Keep looking for new ways to improve and
adapt.

18. Keeping up with the times
● Some examples from Mutual Mobile’s
framework
○ On 2.2 we used a segmented controller but, after
ICS we changed to Android’s Actionbar.
○ We used singletons and static members to keep
system state, now we use our DI framework to
moderate standard POJOs, holding state
○ We used Handlers to communicate AsyncTask
results, now we ride the bus.

19. Questions?