software design patterns on android english

Software Design Patterns on AndroidPedro Vicente Gómez Sánchez - Mobile Software Engineer, Tuenti Technologies.

@pedro_g_s , @TuentiEng

pgomez@tuenti.com

http://corporate.tuenti.com/es/dev/blog - @TuentiEnghttp://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.

● 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.

● 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: MementoName: 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 solveRender video

information inside a ListView

Data origin Use cases

Renderer

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

RendererName: 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.

RendererStructure: 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.

RendererBuilder: 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

RendererDelegate: 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

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

Renderer

Worth?

Resultado?

Renderer

One adapter to rule them all?

https://github.com/pedrovgs/Renderers

RepositoryName: 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.

Because I don’t care if the data comes from an external API or a local DB!!!

That’s an implementation detail.

Repository

CommandName: 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?

http://corporate.tuenti.com/es/dev/blog - @TuentiEnghttp://corporate.tuenti.com/es/jobs

software design patterns on android english

software design

software design

model view

pedrogs renderer

patterns exists

external api

pedrogs patterns

data origin

Documents

social design patterns for android

android service patterns

design patterns english

droidcon 2011 - android design patterns

design patterns in the android framework

android design patterns chapter 3: android fragmentation...

verb patterns in english

android app mistakes: avoiding the anti-patterns

android developer skills, techniques, and patterns

rapid android development - english

android ui design patterns & best practices

dev fest x (sapporo) android ui patterns

android design patterns

mining energy-greedy api usage patterns in android...

android effective ui: tips, tricks and patterns

android navigation anti-patterns

android anti patterns

the case of android unlock patterns

english sentence patterns

android design principles and popular patterns