Software Design patterns on Android English

Software Design Patterns on Android
Pedro Vicente Gómez Sánchez - Mobile Software Engineer, Tuenti Technologies.
@pedro_g_s , @TuentiEng
pgomez@tuenti.com

http://corporate.tuenti.com/es/dev/blog - @TuentiEng
http://corporate.tuenti.com/es/jobs
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s

Why talk about patterns when we
could be at the bar?

“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.”
Pedro V. Gómez

● Introduction
● Problem to solve.
● Patterns on Android
● Renderer Pattern.
● Repository Pattern.
● Command Pattern.
● Some advices.

DISCLAIMER

Software Design Patterns on Android - Pedro V. Gómez Sánchez

What is a Software Design Pattern?

Software Design Patterns?
A Software Design Pattern is a possible solution to a problem.
Similar problems can be solved using a similar approach.

What defines a pattern?
● Name.
● Problem to solve.
● Structure.
● Consequences.

What types of patterns exists?
Creation Structure
Behaviour

What types of patterns exists?
● Creation:
○ Abstract Factory.
○ Builder.
○ Singleton.
● Behaviour:
○ Adapter.
○ Facade.
○ Bridge.
● Structure:
○ Command.
○ State.
○ Memento.

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.

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.

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
Adapter
Chain of
Responsibility
Memento
Model View
Controller

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.

Patterns on Android: Adapter

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.

Patterns on Android: Memento

Patterns on Android: Chain of Responsibility
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

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.

ACTIVITIES ARE NOT CONTROLLERS!!!

Problem to solve
Render video
information inside a
ListView
Data origin Use cases

Renderer
Software Design Patterns on Android - Pedro V. Gómez Sánchez - pgomez@tuenti.com

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.

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.

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.

Builder

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.

Template method

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

Renderer
Delegate: With this implementation change you will see how the new implementation will
be based on this schema.

Renderer

Worth?

Resultado?

One adapter to rule them all?

https://github.com/pedrovgs/Renderers

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.

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.

Why?

Because I don’t care if the data comes
from an external API or a local DB!!!
That’s an implementation detail.

Repository

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.

Command Use case

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

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.

Questions?

Software Design patterns on Android English

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Software Design patterns on Android English

Similar to Software Design patterns on Android English (20)

Software Design patterns on Android English