Please enable JavaScript.

Coggle requires JavaScript to display documents.

Architecture, Adding a new feature - Coggle Diagram

- - - - storing small amounts of primitive data (like user preferences or settings)
        
        DataStore
        (link)
        
        Proto DataStore
        
        Stores custom data types.
        It requires a predefined schema (protobuf) that maps proto definitions with object structures. .
        
        Preferences DataStore
        
        Stores key-value pairs of basic data types (String, Boolean, Int, etc.).
        It does not store complex datasets.
        No predefined schema needed.
        The primary use case: to store user preferences on their device.
        
        Example
        (Dessert_Release_DataStore
        GitHub repo)
        
        UserPreferencesRepository.kt
        
        4 more items...
        
        DessertReleaseApplication.kt
        
        2 more items...
        
        SharedPreferences
        (almost deprecated)
  - - - Worker / CoroutineWorker
        Does work, produces Result
        
        how to use
        
        You extend the CoroutineWorker class.
        
        You override the doWork() method within your extended class.
        
        The doWork() method is where you place the code for the actual background work you want to perform.
        
        Outcome: doWork() method returns a Result indicating whether the work succeeded (Result.success()), failed (Result.failure()), or should be retried (Result.retry()).
        
        what is
        
        Worker: A class that performs work synchronously on a background thread.
        
        CoroutineWorker: A subclass of Worker designed for asynchronous work, offering interoperability with Kotlin Coroutines.
      - WorkRequest
        Defines how and when
        a Worker should run
        
        what is
        
        Represents a request to perform a specific piece of work. May run in order or in parallel.
        
        Allows you to set constraints that must be met before the work executes (e.g., the device must be charging).
        
        how to use
        
        You pass your CoroutineWorker instance as part of creating a WorkRequest.
        
        features
        
        Input Data: Pass data to your Worker.
        
        Backoff Policy: Define how WorkManager should retry the task if it fails (e.g., linear or exponential backoff).
        
        Tags: Add tags to your work request to easily identify and manage groups of tasks.
        
        types of WorkRequests:
        
        OneTimeWorkRequest
        A WorkRequest that only executes once.
        
        PeriodicWorkRequest
        A WorkRequest that executes repeatedly on a cycle.
      - WorkManager
        Schedules and runs WorkRequest
        
        what is
        
        It takes your WorkRequest (which points to your Worker) and enqueues it, ensuring it will run according to the specified constraints and policies. WorkManager handles persisting the work across app restarts and device reboots.
        
        under
        the hood
        (link)
        
        Under the hood, WorkManager manages and runs a foreground service on your behalf to execute the WorkRequest, while also showing a configurable notification.
        
        WorkManager relies on JobScheduler to schedule its work, even in situations where WorkManager creates a foreground service to run its tasks.
        
        creating
        chain of work
        
        var continuation = workManager.beginUniqueWork(...)
        
        continuation = continuation.then(OneTimeWorkRequestBuilder<BlurWorker>().build())
        
        continuation = continuation.then(OneTimeWorkRequestBuilder<SaveImageToFileWorker>())
        
        .beginUniqueWork(...)
        .then(...)
        .then(...)
        .enqueue()
        
        continuation.enqueue()
        
        Unique Work
        
        Unique work is a concept that guarantees that you only have one instance of work with a particular name at a time.
        (link)
        
        getting work information
        
        WorkManager exposes some APIs as LiveData. We use the LiveData APIs but convert and use them as a flow (.asFlow()).
        
        getWorkInfosForUniqueWorkLiveData() - returns LiveData<List<WorkInfo>> for all work in a unique chain of WorkRequests.
        
        getWorkInfosByTagLiveData() - returns the LiveData<List<WorkInfo>> for a tag.
        
        getWorkInfoByIdLiveData() - returns a single LiveData<WorkInfo> for a specific WorkRequest by its ID.
        
        WorkInfo object
        
        A WorkInfo object contains details about the current state of a WorkRequest, including:
        
        Whether the work is BLOCKED, CANCELLED, ENQUEUED, FAILED, RUNNING, or SUCCEEDED.
        
        If the WorkRequest is finished and any output data from the work.
    - - Data objects are lightweight containers
        for key/value pairs.
        They are meant to store a small amount of data that might pass into and out of a worker from the WorkRequest.
    - - TestWorkerBuilder
      - TestListenableWorkerBuilder
        
        For CoroutineWorkers use TestListenableWorkerBuilder for testing because it handles the threading complexities of the coroutine.
- - - - SharedFlow
        For one-time events/actions
      - StateFlow
        For holding and observing UI state (replaces LiveData in many cases)
      - Coroutine-based
      - Powerful operators
      - Requires lifecycle-aware collection in UI (repeatOnLifecycle, collectAsStateWithLifecycle)
      - Asynchronous data stream
    - - Connects to LifecycleOwner
      - Good for simple state
      - Main thread updates
      - Lifecycle-aware observable
- - - - AppContainer - custom class created to hold and manage an application's dependencies
        
        ● Dependency Holder: It acts as a central place or "toolbox" where instances of dependencies (like repositories, data sources, or factories) are created and stored.
        ● Manual Dependency Injection: It facilitates manual DI by providing a way for components (like Activities) to retrieve the dependencies they need from this shared container, rather than creating them themselves or using global singletons directly.
        ● Scoping: For larger applications, the AppContainer can also manage smaller, nested containers (sometimes called flow containers) to handle dependencies that should only live for a specific feature flow (e.g., a login flow).
        
        Custom Application class (in context of AppContainer): a central place to create, hold and provide access to the AppContainer instance. This ensures that the same container instance is accessible throughout the app, for example, from Activities or Fragments.
        AppContainer is accessed through the Application instance. Components needing dependencies typically get a reference to the Application and then access its appContainer property.