Slide 1

Slide 1 text

Build and Publish an Open Source Android Library for Fun and Non Profit #DevFestDakar2019 Rygel Louv

Slide 2

Slide 2 text

Software Developer R Y G E L L O U V @rygelouv @rygellouv @rygel

Slide 3

Slide 3 text

Library A library is a collection of Implementation of behavior, written in terms of language, that has a well-defined interface by witch the behavior is invoked W I K I P E D I A

Slide 4

Slide 4 text

Android Library An Android library is like App module instead it generates an AAR in place of an APK. An Android AAR file contains Android resources and Java classes

Slide 5

Slide 5 text

Build.

Slide 6

Slide 6 text

Android Library is a simple Module

Slide 7

Slide 7 text

Software Library - The Big Picture API Client Lib core

Slide 8

Slide 8 text

SOLID Principles These principle will help write better code and deliver a library code that makes sense to other developers

Slide 9

Slide 9 text

Design Patterns In software engineering, a software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design Software Design Patterns W I K I P E D I A

Slide 10

Slide 10 text

Design Patterns: Builder

Slide 11

Slide 11 text

Design Patterns: Singleton

Slide 12

Slide 12 text

Design Patterns: Factory

Slide 13

Slide 13 text

Design Patterns: Facade It’s a class that provides a simple interface to a complex subsystem. It might provide limited functionality in comparison to working with the subsystem directly and it includes only those features that clients really care about.

Slide 14

Slide 14 text

Design Patterns: Fluent API Also called Method Chaining Pattern, allow making modifier methods return the host object, so that multiple modifiers can be invoked in a single expression. M A R T I N F O W L E R

Slide 15

Slide 15 text

Domain Specific Language A Domain-Specific Language (DSL) is a computer language that's targeted to a particular kind of problem, rather than a general purpose language that's aimed at any kind of software problem M A R T I N F O W L E R

Slide 16

Slide 16 text

Android Context An Android library does not necessarily have to ask for Application Context

Slide 17

Slide 17 text

Android Context The library should be initialized it self and get the app context by it self

Slide 18

Slide 18 text

Android Context We can use content provider in our library to context and count on Manifest-Merger

Slide 19

Slide 19 text

Custom Views For libraries with UI, custom Views will allow us to add more functionalities to existing views or create complete new Views

Slide 20

Slide 20 text

Publish.

Slide 21

Slide 21 text

Github Release Publishing the library means creating a release on Github

Slide 22

Slide 22 text

Jitpack: A gift from the gods! JitPack is a novel package repository for JVM and Android projects. It builds Git projects on demand and provides you with ready-to-use artifacts (jar, aar).

Slide 23

Slide 23 text

Jitpack: A gift from the gods! JitPack uses the last release on your Github repository, builds it and publish by providing the dependency

Slide 24

Slide 24 text

Documentation: README.md A standard Readme should have at least this elements: Goal Installation Usage and snippets Proguard Rules TODO Licence

Slide 25

Slide 25 text

Documentation: Samples You should provide as many sample as you can. If the library has different usage, provide sample for each and every one of them

Slide 26

Slide 26 text

Maintain.

Slide 27

Slide 27 text

Open/Closed principle Software entities (classes or methods) should be open for extension but closed for modification Do not keep modifying classes and methods of your library after any new additional features or issues

Slide 28

Slide 28 text

Decorator Pattern Decorator is a structural design pattern that lets you attach new behaviors to objects by placing these objects inside special wrapper objects that contain the behaviors.

Slide 29

Slide 29 text

Testing: Our dirty little sin We should write at least few Unit test for the core features of our library If it’s UI related library, we should definitely write Espresso Tests

Slide 30

Slide 30 text

Continuous Integration: Yes you can Fail A CI will tell you if your Build passes or failed. This is important to make sure changes to the code doesn’t break anything and inform if the library is shippable If it’s UI related library, we should definitely write Espresso Tests

Slide 31

Slide 31 text

Continuous Integration: Travis CI Travis CI is a excellent CI for Open Source project. It require a few configuration

Slide 32

Slide 32 text

Issues: Don’t let them down We should take care of any reported issues and plan to fix them in upcoming release. Libraries aim to make other developers life easier no harder

Slide 33

Slide 33 text

Contributors: You’ll never walk alone Ask for contributors. Let people help you improve your library. Let them criticize your work

Slide 34

Slide 34 text

Stats: You have been watched

Slide 35

Slide 35 text

Wanna see it ? https://github.com/rygelouv/MagicPref

Slide 36

Slide 36 text

@rygelouv @rygellouv @rygel Thank you!

Slide 37

Slide 37 text

Images: unsplash.com Patterns: refactoring.guru martinfowler.com