IMStudio

📖 Table of Contents

• Project Structure
• Convention
• RxJava
• Common Scripts
• Technical Stack
• Dependencies
• Library
• Architecture
• Case Study
• Authors

Architecture Component

Architecture Paging

Clean Architecture

🌈 Git Flow

Flow

1. Pull newest code from develop branch
2. Create new branch from develop branch
3. Code, test on new branch. Make sure that all feature is true and have no error
4. Pull newest code from develop branch again, merge into new branch
5. Create merge request

Commit Rules

• feat (new feature for the user, not a new feature for build script)
• fix (bug fix for the user, not a fix to a build script)
• docs (changes to the documentation)
• style (formatting, missing semi colons, etc; no production code change)
• refactor (refactoring production code, eg. renaming a variable)
• test (adding missing tests, refactoring tests; no production code change)
• chore (updating grunt tasks etc; no production code change)

Example: create new feature branch

1. Branch name: feature/{feature_name}
2. Commit message describe core of commit change. Start with:

• feature: description
• fix: description
• refactor: Refactoring source code, optimize source code...

    find . -name build -exec rm -rf {} \;

    find . -name build -exec rm -r "{}" \;

task clean(type: Delete) {
    delete rootProject.buildDir
}

    find . -name '.DS_Store' -type f -delete

    find . -name ".DS_Store" -type d -exec rm -r "{}" \;

    find . -name ".hprof" -type d -exec rm -r "{}" \;

    find . -name '.iml' -type f -delete

    git rm -r --cached .idea | git rm -r --cached *.iml

    ./gradlew -q dependencies [module]:dependencies

    git config --global pull.rebase true

🌈 Technical Stack

This project takes advantage of many popular libraries, plugins and tools of the Android ecosystem. Most of the libraries are in the stable version, unless there is a good reason to use non-stable dependency.

The architecture is built around Android Architecture Components.

We followed the recommendations laid out in the Guide to App Architecture when deciding on the architecture for the app. We kept logic away from Activities and Fragments and moved it to ViewModels. We observed data using LiveData and used the Data Binding Library to bind UI components in layouts to the app's data sources.

We used a Repository layer for handling data operations. FUTA's data comes from a few different sources - user data is stored in Cloud Firestore (either remotely or in a local cache for offline use), user preferences and settings are stored in SharedPreferences, conference data is stored remotely and is fetched and stored in memory for the app to use, etc. - and the repository modules are responsible for handling all data operations and abstracting the data sources from the rest of the app (we liked using Firestore, but if we wanted to swap it out for a different data source in the future, our architecture allows us to do so in a clean way).

Kotlin

We made an early decision to rewrite the app from scratch to bring it in line with our thinking about modern Android architecture. Using Kotlin for the rewrite was an easy choice: we liked Kotlin's expressive, concise, and powerful syntax; we found that Kotlin's support for safety features for nullability and immutability made our code more resilient; and we leveraged the enhanced functionality provided by Android Ktx extensions.

🎨 Dependencies

• Jetpack:
  • Android KTX - provide concise, idiomatic Kotlin to Jetpack and Android platform APIs.
  • AndroidX - major improvement to the original Android Support Library, which is no longer maintained.
  • Data Binding - allows you to bind UI components in your layouts to data sources in your app using a declarative format rather than programmatically.
  • View Binding - View binding is a feature that allows you to more easily write code that interacts with views. Once view binding is enabled in a module, it generates a binding class for each XML layout file present in that module. An instance of a binding class contains direct references to all views that have an ID in the corresponding layout.
  • Lifecycle - perform actions in response to a change in the lifecycle status of another component, such as activities and fragments.
  • LiveData - lifecycle-aware, meaning it respects the lifecycle of other app components, such as activities, fragments, or services.
  • Navigation - helps you implement navigation, from simple button clicks to more complex patterns, such as app bars and the navigation drawer.
  • Paging - 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.
  • ViewModel - designed to store and manage UI-related data in a lifecycle conscious way. The ViewModel class allows data to survive configuration changes such as screen rotations.
  • Worker - A class that performs work synchronously on a background thread provided by WorkManager.
• Dagger2 - dependency injector for replacement all FactoryFactory classes.
• Retrofit - type-safe HTTP client.
• Timber - a logger with a small, extensible API which provides utility on top of Android's normal Log class.
• Stetho - debug bridge for applications via Chrome Developer Tools.
• Shimmer - Shimmer is an Android library that provides an easy way to add a shimmer effect to any view in your Android app.
• 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.

⚙️ Copyright

Created by $username on $today
Copyright (c) $today.year . All rights reserved.
Last modified $file.lastModified

🚀 Authors

• https://github.com/nphau
• https://nphau.medium.com
• https://nphau.github.io/