Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Build and Publish an Open Source Android Librar...

Rygel Louv
December 14, 2019

Build and Publish an Open Source Android Library for Fun and Non profit

This talk aims to educate about the development of Libraries in general and Android libraries in particular. We went through the most common Design Patterns used in Libraries and talked about the responsibilities of a Library developer.

Rygel Louv

December 14, 2019
Tweet

More Decks by Rygel Louv

Other Decks in Technology

Transcript

  1. Build and Publish an Open Source Android Library for Fun

    and Non Profit #DevFestDakar2019 Rygel Louv
  2. Software Developer R Y G E L L O U

    V @rygelouv @rygellouv @rygel
  3. 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
  4. 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
  5. SOLID Principles These principle will help write better code and

    deliver a library code that makes sense to other developers
  6. 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
  7. 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.
  8. 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
  9. 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
  10. Android Context We can use content provider in our library

    to context and count on Manifest-Merger
  11. Custom Views For libraries with UI, custom Views will allow

    us to add more functionalities to existing views or create complete new Views
  12. 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).
  13. Jitpack: A gift from the gods! JitPack uses the last

    release on your Github repository, builds it and publish by providing the dependency
  14. Documentation: README.md A standard Readme should have at least this

    elements: Goal Installation Usage and snippets Proguard Rules TODO Licence
  15. 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
  16. 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
  17. 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.
  18. 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
  19. 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
  20. Continuous Integration: Travis CI Travis CI is a excellent CI

    for Open Source project. It require a few configuration
  21. 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
  22. Contributors: You’ll never walk alone Ask for contributors. Let people

    help you improve your library. Let them criticize your work