Notes

- Jetpack Paging Library
- Images Libraries
- Dagger 2

 
Paging library
The Paging Library helps you load and display small chunks of data at a time. Loading partial data on demand reduces usage of network bandwidth and system resources.

 
Paging Support different data architectures
● Served only from a backend server.
● Stored only in an on-device database.
● A combination of the other sources, using the on-device database as a cache.
 

Jetpack Paging 3 library
● The Paging library helps you load and display pages of data from a larger dataset from local storage or over network.
● This approach allows your app to use both network bandwidth and system resources more efficiently.
● The components of the Paging library are designed to fit into the recommended Android app architecture, integrate cleanly with other Jetpack components, and provide first-class Kotlin support.
 
Paging library Benefits
● In-memory caching for your paged data. This ensures that your app uses system resources efficiently while working with paged data.
● Built-in request deduplication, ensuring that your app uses network bandwidth and system resources efficiently.
● Configurable RecyclerView adapters that automatically request data as the user scrolls toward the end of the loaded data.
● First-class support for Kotlin coroutines and Flow, as well as LiveData and RxJava.
● Built-in support for error handling, including refresh and retry capabilities.

 
Paging Library Architecture
Paging library's components operate in three layers of your app:
● The repository layer
● The ViewModel layer
● The UI layer
 
Repository layer
The primary Paging library component in the repository layer is PagingSource. Each PagingSource object defines a source of data and how to retrieve data from that source. A PagingSource object can load data from any single source, including network sources and local databases.
Another Paging library component that you might use is RemoteMediator. A RemoteMediator object handles paging from a layered data source, such as a network data source with a local database cache.

 
ViewModel layer
The Pager component provides a public API for constructing instances of PagingData that are exposed in reactive streams, based on a PagingSource object and a PagingConfig configuration object.
The component that connects the ViewModel layer to the UI is PagingData. A PagingData object is a container for a snapshot of paginated data. It queries a PagingSource object and stores the result.
 
UI layer
The primary Paging library component in the UI layer is PagingDataAdapter, a RecyclerView adapter that handles paginated data.
Alternatively, you can use the included AsyncPagingDataDiffer component to build your own custom adapter.
 
Android Image Libraries
Images libraries is very helpful to android developers to show remote, local or cached images on android application.
Following are the popular Android images libraries:
● Coil
● Picasso
● Glide


 
Coil
Coil — an open-source Kotlin-first image loading library for Android. Coil is fast, lightweight, modern, and treats Kotlin Coroutines, OkHttp, Okio, and AndroidX Lifecycles as first-class citizens.
Coil is an acronym for Coroutines Image Loader.

 
Picasso
A powerful image downloading and caching library for Android
 
Glide
Glide is a fast and efficient open source media management and image loading framework for Android that wraps media decoding, memory and disk caching, and resource pooling into a simple and easy to use interface.
Glide supports fetching, decoding, and displaying video stills, images, and animated GIFs. Glide includes a flexible API that allows developers to plug in to almost any network stack. By default Glide uses a custom HttpUrlConnection based stack, but also includes utility libraries plug in to Google's Volley project or Square's OkHttp library instead.

 
Dependency Injection
The process of constructing required dependencies (objects/entities/instances) should be out side of the dependent object and providing them to the dependent object when needed.
Entities (Objects/Instances) must depends on abstraction not on concretions
 
Dependency injection in Android
Dependency injection (DI) is a technique widely used in programming and well suited to Android development. By following the principles of DI, you lay the groundwork for good app architecture.
Implementing dependency injection provides you with the following advantages:
● Reusability of code
● Ease of refactoring
● Ease of testing
 
Popular Dependency Injection Libraries
1. Dagger is a popular dependency injection library for Java, Kotlin, and Android that is maintained by Google. Dagger facilitates using DI in your app by creating and managing the graph of dependencies for you. It provides fully static and compile-time dependencies addressing many of the development and performance issues of reflection-based solutions.
2. Hilt is Jetpack's recommended library for dependency injection in Android. Hilt defines a standard way to do DI in your application by providing containers for every Android class in your project and managing their lifecycles automatically for you. Hilt is built on top of the popular DI library Dagger to benefit from the compile time correctness, runtime performance, scalability, and Android Studio support that Dagger provides.
 
Dagger basics
● You can limit your project's complexity as it scales up by using Dagger to manage dependencies.
● Dagger automatically generates code that mimics the code you would otherwise have hand-written. Because the code is generated at compile time, it's traceable and more performant than other reflection-based solutions

 
Benefits of using Dagger
Dagger frees you from writing tedious and error-prone boilerplate code by:
● Generating the AppContainer code (application graph) that you manually implemented in the manual DI section.
● Creating factories for the classes available in the application graph. This is how dependencies are satisfied internally.
● Deciding whether to reuse a dependency or create a new instance through the use of scopes.
● Creating containers for specific flows using Dagger subcomponents. This improves your app's performance by releasing objects in memory when no longer needed.
 
Dagger – Build time
Dagger automatically does all of this at build time as long as you declare dependencies of a class and specify how to satisfy them using annotations. Dagger generates code similar to what you would have written manually. Internally, Dagger creates a graph of objects that it can reference to find the way to provide an instance of a class. For every class in the graph, Dagger generates a factory-type class that it uses internally to get instances of that type.
At build time, Dagger walks through your code and Builds and validates dependency graphs, ensuring that:
● Every object's dependencies can be satisfied, so there are no runtime exceptions.
● No dependency cycles exist, so there are no infinite loops.
● Generates the classes that are used at runtime to create the actual objects and their dependencies.

 
Dagger – Constructor Injection
Use @Inject with primary constructor of the class which we declare a dependency for dependent classes.
 
Dagger – Components
Dagger can create a graph of the dependencies in your project that it can use to find out where it should get those dependencies when they are needed. To make Dagger do this, you need to create an interface and annotate it with @Component. Dagger creates a container as you would have done with manual dependency injection.
Inside the @Component interface, you can define functions that return instances of the classes you need. @Component tells Dagger to generate a container with all the dependencies required to satisfy the types it exposes. This is called a Dagger component; it contains a graph that consists of the objects that Dagger knows how to provide and their respective dependencies
 
Dagger – Module
When there is no access on third-party classes to @Inject them, then we need to make Modules classes and use provider function to get instance of these class. Lastly we need to declare these modules in our component class.


 
Dagger – Interface Injection
While injecting with Interface we could make a class which implements with Interface and use @Inject on primary constructor of this class.
And make a module class and make provider function to return object.
Attach module class in @Component interface within modules array.
 
Dagger – Binds Inject
In Dagger we can use @Binds annotation, when there is an Abstract class and abstract function could return some class object.
 
Dagger – Field Injection
Add field injection on class variables which use to have instance of other class.
 
Dagger – States in Modules
Dagger discourage to use states in Modules.
But if need to maintain the status in module, we need to builder() with DaggerComponent and provide state to modules.
 
Application Class
When some tasks need to run before the creation of first activity, we need to make a Application subclass.
If there is some immutable data or global object which need to shared across all components then we could used Application subclass.
For Example: Firebase Analytics, Shared Preferences, Crash Reporting.

 
Dagger – Singleton
Using @Singleton annotation with dependency class and component class to achieve the singleton behaviors with our dependency graph. Singleton injections will not recreated within application life cycle.