Why talk about patterns when we
could be at the bar?
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
“If I see again json parsing annotations inside a business logic domain
class, please, kill me.”
“If I see again other project without dependency injection, I will jump out
the window.”
“If I see again a class with 3000 lines of code, I will go to develop for
iOS.”
“If I see again a class with 3000 lines of code, I will stop working on
Android and I will change to iOS.”
“If I see again a project with more than 7 dependencies per class, I will
go to work from Nepal.”
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
Pedro V. Gómez
● Introduction
● Problem to solve.
● Patterns on Android
● Renderer Pattern.
● Repository Pattern.
● Command Pattern.
● Some advices.
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
What is a Software Design Pattern?
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
Software Design Patterns?
A Software Design Pattern is a possible solution to a problem.
Similar problems can be solved using a similar approach.
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
What defines a pattern?
● Name.
● Problem to solve.
● Structure.
● Consequences.
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
What types of patterns exists?
Creation Structure
Behaviour
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
What types of patterns exists?
● Creation:
○ Abstract Factory.
○ Builder.
○ Singleton.
● Behaviour:
○ Adapter.
○ Facade.
○ Bridge.
● Structure:
○ Command.
○ State.
○ Memento.
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
Pros
● Each pattern is a valid and already defined solution for a concrete
problem.
● Are useful when you want to reuse structures and avoid duplicity.
● Eases the extensibility of your design and accelerate long-term
developments.
● Decouples your code.
● Favors change.
● Reduces maintenance efforts.
● Usually, propose a better solution for responsibility assignations.
● Poses a common vocabulary.
● Solves already solved problems by other developers.
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
Cons
● Is not always easy to identify which pattern to apply.
● Can suppose a work overload in a short-term period.
● Apply a pattern is not always so easy as apply the structure.
● Can affect to the software performance.
● You can die by the refactoring illness if you only think in
patterns.
● Apply the wrong pattern can create an anti-pattern.
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
Problem to solve
● Show a list full of different videos.
● Video’s information will be provided by an external API.
● Video list information will be provided by an external API.
● We will show different video types:
○ Normal videos.
○ Popular videos.
○ Favorite videos.
○ Live videos.
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
Software Design Patterns on Android
Adapter
Chain of
Responsibility
Memento
Model View
Controller
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
Patterns on Android: Adapter
Name: Adapter.
Problem to solve: Transform a class interface
into other interface that the client code wants to
use. Allows the already implemented class
usage with a different interface.
Our problem: Give some views to the Android
SDK to be rendered inside a ListView without
information about the future implementation.
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
Patterns on Android: Adapter
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
Patterns on Android: Memento
Name: Memento.
Problem to solve: Capture and externalize the
internal state of an object - keeping the
encapsulation principle - and be able to restore
the object state in the future.
Our problem: Save the Android Activity state to
recover it once the phone changes the
orientation to portrait or landscape.
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
Patterns on Android: Memento
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
Patterns on Android: Chain of Responsibility
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
Name: Chain of Responsibility.
Problem to solve: Avoid to couple the sender of
a message from the receiver and be able to cut
the event processing from one of the receivers.
Our problem: Notify events to different
receivers in the application until one of them
decides to process the event.
Patterns on Android: Chain of Responsibility
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
Patterns on Android: Model View Controller
Name: Model View Controller.
Problem to solve: Decouple the view
implementation from the model
implementation.
Our problem: Create an application where the
views implementation and the business logic
model don’t be coupled.
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
ACTIVITIES ARE NOT CONTROLLERS!!!
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
Problem to solve
Render video
information inside a
ListView
Data origin Use cases
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
Renderer
Name: Renderer.
Problem to solve: Decouple the rendering
process from our adapters and avoid
ViewHolder pattern.
Our problem: We have different video types to
render with different visual representations.
Normal, favorite, popular and live videos.
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
Renderer
Structure: This pattern is a join of other three
patterns.
● Builder: Separate the complex object
instantiation from the object representation.
With this pattern the same construction
process can create different object
representations.
● Delegate: Pattern applied when a class needs
to delegate the implementation in other class
that works as helper.
● Template Method: Define an algorithm
skeleton separated by steps and define some
of them in the subclasses.
Software Design Patterns on Android - Pedro V. Gómez Sánchez - pgomez@tuenti.com
Renderer
Builder: Used to create or recycle a view in the getView method of your adapter.
This is not a simple creation process because the view could be recycled in
some cases.
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
Renderer
Template Method: Applying this pattern
we can declare the main rendering
algorithm and modify it, if need it, in the
subclasses implementations.
For example, a live video will be
represented with a play button that is
not able in the normal representation
and we can add that part of the
algorithm in the LiveVideoRenderer
implementation.
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
Renderer
Delegate: To apply the delegate pattern we are going
to delegate the recycling and rendering classic
adapter implementation into the
VideoRendererBuilder and into our new
VideoRenderer.
Renderer
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
Renderer
Delegate: With this implementation change you will see how the new implementation will
be based on this schema.
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
One adapter to rule them all?
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
https://github.com/pedrovgs/Renderers
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
Repository
Name: Repository.
Problem to solve: Abstract the data origin in a
system with different possible data sources.
Our problem: Abstract the data origin. I don’t
care about where the data comes from. A
memory storage system, a database or an
external API accessed using an API client are
just an implementation detail.
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
Repository
Different repository
implementations can offer
different benefits. The idea is
to abstract all the client code
to the data origin and be able
to change the repository
implementation as easy as
possible.
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
Because I don’t care if the data comes
from an external API or a local DB!!!
That’s an implementation detail.
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s
Command
Name: Command.
Problem to solve: Encapsulate a message like
an object being able to parametrize the clients
with different requests, add that messages into
a queue and support undo/redo mechanism.
Our problem: Model our use cases abstracting
the execution process from itself and abstracting
the delivery mechanism code from our model.
Software Design Patterns on Android - Pedro V. Gómez Sánchez - pgomez@tuenti.com
Command
Your model should be between the interactor
and the repository. An interator doesn’t
implements business logic, only use our model
to stimulate it and delegate the implementation
to the business logic domain.
This is just an example, I’m not going to desing
all the business model xD
Software Design Patterns on Android - Pedro V. Gómez Sánchez - pgomez@tuenti.com
Some advices
● Implement one model by domain.
● Avoid code duplicity.
● Refactor day by day.
● Apply the single responsibility principle.
● Defer the important decisions.
● Think into the framework like a delivery mechanism, not the
architecture of your application.
● Work from the use case.
● Create testable code.
● Write code for your mates not for the machine.