LMODroid is a free and open-source AOSP fork, providing optionally de-googled Android experience and top-notch stability along with a bunch of useful features so that you can enjoy using your device.

Let's see the cool features that LMODroid have.

Android 14

LMODroid 5.0 is based on the latest Android 14 QPR2 with up-to-date security patches merged.

We keep up our sources with the latest Android releases so you will always run the latest thing and won't miss anything.

Not only that, we are actively fixing bugs and maintaining the source bug-free as much as possible.

OSS Face unlock

No proprietary code, 100% open source

LMODroid has an open-source face unlock developed from scratch using TensorFlow.

It uses an open-source model called keras-VGGFace VGG16 model for face verification.

It is fast enough in all devices and even unlocks in all angles.

App Lock

Don't worry about sensitive content being accessed by your friends, siblings, children and other people.

They won't stop but we can stop with our native AppLock support.

Lock away sensitive information with extra protection.

A worthy mention, it also supports biometric unlock.

Game Space

Ahhh! A call at the final moment of the game.

No more frustration! Let's control your gaming experience with our GameSpace.

GameSpace provides zero interruptions with useful floating actions for the games. It will take your gaming experience to the next level.

Block heads-up, record your super gaming skills, track your device FPS and so on.

Desktop Mode

Wanna use your phone on the big screen?

Hey, wait! It's not screen mirroring.

LMODroid's desktop mode will give a powerful desktop experience from your phone so you can use your favourite apps on the bigger screen at no performance cost.

Parallel Space

Yes, it's a pain to sign in / sign out for using different accounts in a game or Messenger.

No more pain, We got you.

With LMODroid's Parallel Space feature, you can run multiple instances of the same application in parallel.

Fully compatible with microG

You can use GMS / Google Play Services in LMODroid like as usual in custom ROMs.

But you don't like Google trackers and wanna use microG?

No surprise, LMODroid is fully compatible with microG as well.

It's 'Flash and play'.

More features

Not only these features, LMODroid is comprised of tons of useful features that you can't miss in your device.

To learn more, Please visit our website here.

For enterprise

No worries if the current public operating system doesn’t meet your needs.

We are a dedicated team of developers to provide you with what you want.

We implement all your product software requirements to provide you with a fully-fledged operating system for your device.

• CTS/GTS compatibility

• Get your device certified

• OEM premium experience

• MDM solutions as OS for your organization

• and more...

We build the OS. You build the brand. ❤️🔥

Contact us for more information: enterprise@libremobileos.com

Source code

Yes, you guessed it right. You can find the complete source code for LMODroid in our self-hosted GitLab.

👉 https://git.libremobileos.com/LMODroid

All the development happens in our Gerrit and it's open for everyone to contribute

👉 https://gerrit.libremobileos.com

Useful links

Find and download LMODroid for your devices on our download page.

👉 https://get.libremobileos.com

If you can't find your device in the list, Unfortunately, your device is not supported at the moment. 💔

👉 Discussion (Telegram): https://t.me/LMODroid_Discussion

👉 Website: https://libremobileos.com

You may come across a requirement in your app to store some configuration (not that big to use Room).

For example, the previous UI mode - (Dark/Light)

You might come across Shared Preferences for this requirement. Shared Preferences are used to persist data of key-value pairs.

I agree that shared preferences work fine but are still way too old. Imagine if you want to observe the live changes of a preference value. you can't.

DataStore

DataStore is a part of Jetpack libraries that lets you store data of key-value pairs or typed objects in the device.

Types

• Preferences DataStore - Stores key-value pairs

• Proto DataStore - Stores typed objects using protocol buffers.

In this guide, we will learn about the Preferences DataStore.

Proto DataStore is for another day.

Why you should use DataStore instead of Shared Preferences?

• Credits: Android Developers Blog

Guide

Setup

Add the datastore preference in your grade dependency

dependencies {
        implementation "androidx.datastore:datastore:1.0.0"
}

Build DataStore

Create a preference data store as an extension of context using the preferencesDataStore delegate in the top level of a Kotlin file.

The name of the Preferences DataStore is a mandatory parameter.

This ensures that a single instance of DataStore is created for the application process.

// Top level of any kotlin file.
val Context.dataStore: DataStore<Preferences> by preferencesDataStore(name = "configs")

Create Preference Keys

To store key-value pairs, we have to create keys for the preferences.

object PreferenceKeys {
    val booleanKey = booleanPreferencesKey(name = "key_for_bool_value")
    val byteArrayKey = byteArrayPreferencesKey(name = "key_for_byte_array_value")
    val doubleKey = doublePreferencesKey(name = "key_for_double_value")
    val floatKey = floatPreferencesKey(name = "key_for_float_value")
    val intKey = intPreferencesKey(name = "key_for_int_value")
    val longKey = longPreferencesKey(name = "key_for_long_value")
    val stringKey = stringPreferencesKey(name = "key_for_string_value")
    val stringSetKey = stringSetPreferencesKey("key_for_string_set_value")
}

Write data

Write a value to the preferences with the following code.

suspend fun writeValue(key: Preferences.Key<Int>, value: Int) {
    context.dataStore.edit { preferences ->
        // Set the new value to the preference.
        preferences[key] = value
    }
}

Write a value from a fragment or activity

// In an activity or fragment
// You can use any CoroutineScope other than lifeCycleScope.
lifeCycleScope.launch {
    writeValue(key = intKey, value = 17)
}

Read data

Read value from the preferences with the following code.

It returns a Flow.

fun readValue(key: Preferences.Key<Int>, defaultValue: Int): Flow<Int> {
    return context.dataStore.data.map { preferences ->
        preferences[key] ?: defValue
    }
}

Collect the value from the Flow

// In an activity or fragment
// You can use any CoroutineScope other than lifeCycleScope.
lifeCycleScope.launch {
    readValue(key = intKey, defaultValue = 0).collect { value ->
        // Utilize the value here
    }
}

Bonus

Extension function to work with all types of keys.

/***
 *
 * An Extension function to DataStore<Preference>.
 * Generic way to getting preference value from the data store.
 * Returns preference value for the @param key if found,
 * Otherwise it returns @param defValue
 *
 * @param key Preference key
 * @param defValue default value if the preference key is not found
 *
 * @return a Flow of type T
 */
fun <T> DataStore<Preferences>.getValue(
    key: Preferences.Key<T>,
    defValue: T
): Flow<T> {
    return data.map { preferences ->
        preferences[key] ?: defValue
    }
}

/***
 *
 * An Extension function to DataStore<Preference>
 * Generic way to editing preference value from the data store.
 * Edit the value of the preference @param key with @param value.
 *
 * @param key Preference key
 * @param value Value need to be set to the given key
 *
 */
suspend fun <T> DataStore<Preferences>.setValue(
    key: Preferences.Key<T>,
    value: T
) {
    edit { preferences ->
        preferences[key] = value
    }
}

That's it for today.

Please do like if it helped you.

Comment if you have any queries.

Share if you want to help others.

For more articles like this, Do follow.

Thanks for reading. <3

Imagine you are building a super cool android app!

You want to share it with your friends so you have to generate a signed version APK and share it with your friends yourself.

In the beginning, You will share an initial build with your friends. That won't take much time.

Eventually, you will make many changes in your app and want to share the APK with your friends for each change or each release. You may feel bored or it consumes a lot of time since you have to do the work manually to compile and share the APK. You will be tired of sharing the APK since you have to do the same steps every time.

Don't worry! We will automate the process of building, signing and sharing the APK using GitHub Actions, a feature of GitHub.

Prerequisites

• Git

• GitHub

• Basics of Android App Development

• Basics of shell commands (if no, still you can do it my windows users)

Basics

GitHub Actions

GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline.

You can set up workflows for your project and trigger it based on repository events like push, and pull requests etc.

Workflows are nothing but a set of actions/commands defined by the user that will be executed in the GitHub-provided virtual machines for your project.

To learn more about GitHub Actions, Check here.

Guide

In this guide, you will learn how to set up workflows in your GitHub repository. Make sure you have a GitHub repository that contains your project source files.

Setup workflow in your repository

1) Open your GitHub repository in your browser

2) Select the 'Actions' tab

3) Click 'set up a workflow yourself'

4) It will create a new file named main.yml in <project_root>/.github/workflows. You can rename it as your wish.

5) Now, you have to configure the instructions in the file editor to create a workflow.

Note: YAML language is used here. In case you want to learn more about it, check here.

We gonna use GitHub workflow syntax to write the YAML code. To learn more about that, check the official doc.

Let's write step-by-step.

Note: Changes in each step happen in the same file. So add code continuously in the same file. You can find the complete YAML code at the end of the guide.

• Set the name of the workflow

    name: Build App
  

  It will be shown in the 'Actions' tab.

• Configure in which repository event, you have to run your workflow.

    on:
      push:
        # Trigger only for main branch.
        branches: [ main ]
      # Allows you to run this workflow manually from the Actions tab
      workflow_dispatch:
  

  on is used to define which event you want to trigger your workflow.

  • Here we configured it to trigger the workflow on push commits to the main branch.

  • workflow_dispatch: is enable us to trigger the workflow manually in the actions of the repository.

• Now you have to define a job to do our task in the Runner (Virtual Machine).

  Job is a set of steps that will be executed in the Runner (Virtual Machine).

  A step may be a shell script or set of shell commands or an action.

  For our task, we gonna define a job with three steps.

  • Clone the project

  • Build the APK

  • Sign the APK

  • Send the APK

First, define our job

    jobs:
      build:
        runs-on: ubuntu-20.04

It will configure a job named build it will be run on a ubuntu-20.04 machine.

Now define our three steps one by one inside the build job

• Clone the project

    jobs:
      build:
        runs-on: ubuntu-20.04
        # Steps definition starts here
        steps:
          # Get the app source
          - name: Get the source
            uses: actions/checkout@v2
  

  Here, we are using GitHub's official checkout action to clone our project source code in the runner (VM).

  • As we know, name: defines the name of the step

  • uses: - tells which action needs to be run.

• Build the APK

            # Compile the apk
          - name: Generate Release APK
            run: ./gradlew assembleRelease
  

  with run: , you can define shell commands to execute in the step.

  Here we build the release APK by using the Gradle wrapper.

• Sign the APK

          # Sign the apk
          - name: Sign APK
            uses: r0adkll/sign-android-release@v1
            # ID used to access action output
            id: sign_app
            with:
              releaseDirectory: app/build/outputs/apk/release
              signingKeyBase64: ${{ secrets.SIGNING_KEY }}
              alias: ${{ secrets.ALIAS }}
              keyStorePassword: ${{ secrets.KEY_STORE_PASSWORD }}
              keyPassword: ${{ secrets.KEY_PASSWORD }}
            env:
              # override default build-tools version (29.0.3) -- optional
              BUILD_TOOLS_VERSION: "31.0.0"
  

  For signing the APK, we gonna use the r0adkll/sign-android-release@v1 action.

  • id - Unique ID of the step so we can refer to and get the output of the step in another step.

  • with - It is used to provide the input for the action used in the step.

    In our case, we have to provide the key information to the action to sign the APK.

    Some information is highly confidential so we can't add it to a public file, right? so we gonna use repository secrets for this. Let's see how to do it later.

    For now, just know how to use the repository's secret here.

    ${{ secrets.<KEY_NAME> }} - Use this way to get your repository secret.

    The following are the inputs required for this action. Refer here.

    • releaseDirectory - Release APK directory

    • signingKeyBase64 - The base64 encoded signing key used to sign your app

      This action will directly decode this input to a file to sign your release with. You can prepare your key by running this command on *nix systems.

        openssl base64 < some_signing_key.jks | tr -d '\n' | tee some_signing_key.jks.base64.txt
      

      Then copy the contents of the .txt file

    • alias - The alias of your signing key

    • keyStorePassword - The password to your signing keystore

    • keyPassword - The private key password for your signing keystore

    • env - This is used to define the environment variables required for a step. In our case, we have defined the BUILD_TOOLS_VERSION (optional).

• Share the APK

  In the previous step, we generated the signed APK successfully. Now it's time to send the APK somewhere so you share it easily.

  Two cases:

  • Directly send the APK

  • Upload the APK to some file transfer service and send the link

We gonna see both cases.

Case 1: Directly send the APK to a messenger like Telegram or Discord.

You can use any messenger but know about its API.

Here we gonna send our APK to a Telegram Chat via Bot API. I ain't gonna explain about Telegram Bot API since it's out of track. You can learn it from here.

              # Send to the APK to Telegram
              - name: Send the APK to Telegram
                env:
                  APK_PATH: ${{steps.sign_app.outputs.signedReleaseFile}}
                  BOT_API_KEY: ${{ secrets.BOT_API_KEY }}
                  CHAT_ID: ${{ secrets.CHAT_ID }}
                run: |
                  curl -F chat_id=$CHAT_ID -F document=@"${APK_PATH}" -F caption="Template-$(date +"%Y%m%d-%H%M")" https://api.telegram.org/bot${BOT_API_KEY}/sendDocument

• env - Here we have defined the environmental variables required for this step.

  • APK_PATH - Get it from the previous step. See the use of id that we defined in the previous step.

  • BOT_API_KEY - Your bot API key that you got from the Bot Father. Get from repository secrets.

  • CHAT_ID - ID of the telegram chat to where you want to send the APK. It can be a group, channel or your ID. Get from repository secrets.

    Note: It's not the username of your chat or group. It's a numerical value that you can get by using some other bots.

• run - It contains the list of shell commands that we need to execute in this step.

  Here, we send the APK by making a request to the Telegram BOT API with cURL tool. Customize on your needs.

Case 2: Upload the APK to some file transfer service and send the link

In this case, we gonna upload our APK to a file transfer service like GoFile, WeTransfer etc and then send the link to a messenger. Here I gonna use Telegram.

              # Upload the APK to WeTransfer and send link to Telegram
              - name: Send the APK to Telegram
                env:
                  APK_PATH: ${{steps.sign_app.outputs.signedReleaseFile}}
                  BOT_API_KEY: ${{ secrets.BOT_API_KEY }}
                  CHAT_ID: ${{ secrets.CHAT_ID }}
                run: |
                  # Get the transfer script to upload the apks
                  curl -sL https://git.io/file-transfer | sh
                  # Upload and get the link
                  LINK=$(./transfer wet $APK_PATH | grep "Download Link" | sed 's/Download Link://g')
                  # Create a message
                  MESSAGE="Template $(date +'%Y-%m-%d %H:%M')\n\nLink: ${LINK}"
                  # Can't make the telegram markdown working
                  TEXT=$(echo -e $MESSAGE)
                  # Send the message to telegram
                  curl -F chat_id=$CHAT_ID -F text="$TEXT" -F disable_web_page_preview=true https://api.telegram.org/bot${BOT_API_KEY}/sendMessage

Here we are using this tool to upload our APK to WeTransfer and then send the link to Telegram chat or channel.

Final workflow code for case 1: [main.yml]

name: Build App
on:
  push:
    # Trigger only for main branch.
    branches: [ main ]
  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-20.04
    steps:
      # Get the app source
      - name: Get the source
        uses: actions/checkout@v2

      # Compile the apk
      - name: Generate Release APK
        run: ./gradlew assembleRelease

      # Sign the apk
      - name: Sign APK
        uses: r0adkll/sign-android-release@v1
        # ID used to access action output
        id: sign_app
        with:
          releaseDirectory: app/build/outputs/apk/release
          signingKeyBase64: ${{ secrets.SIGNING_KEY }}
          alias: ${{ secrets.ALIAS }}
          keyStorePassword: ${{ secrets.KEY_STORE_PASSWORD }}
          keyPassword: ${{ secrets.KEY_PASSWORD }}
        env:
          # override default build-tools version (29.0.3) -- optional
          BUILD_TOOLS_VERSION: "31.0.0"

      # Send to the APK to Telegram
      - name: Send the APK to Telegram
        env:
          APK_PATH: ${{steps.sign_app.outputs.signedReleaseFile}}
          BOT_API_KEY: ${{ secrets.BOT_API_KEY }}
          CHAT_ID: ${{ secrets.CHAT_ID }}
        run: |
          curl -F chat_id=$CHAT_ID -F document=@"${APK_PATH}" -F caption="Template-$(date +"%Y%m%d-%H%M")" https://api.telegram.org/bot${BOT_API_KEY}/sendDocument

Final workflow code for case 2: [main.yml]

name: Build App
on:
  push:
    # Trigger only for main branch.
    branches: [ main ]
  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-20.04
    steps:
      # Get the app source
      - name: Get the source
        uses: actions/checkout@v2

      # Compile the apk
      - name: Generate Release APK
        run: ./gradlew assembleRelease

      # Sign the apk
      - name: Sign APK
        uses: r0adkll/sign-android-release@v1
        # ID used to access action output
        id: sign_app
        with:
          releaseDirectory: app/build/outputs/apk/release
          signingKeyBase64: ${{ secrets.SIGNING_KEY }}
          alias: ${{ secrets.ALIAS }}
          keyStorePassword: ${{ secrets.KEY_STORE_PASSWORD }}
          keyPassword: ${{ secrets.KEY_PASSWORD }}
        env:
          # override default build-tools version (29.0.3) -- optional
          BUILD_TOOLS_VERSION: "31.0.0"

      # Upload the action artifact
      - name: Upload the APK (artifact)
        uses: actions/upload-artifact@v2
        with:
          name: Template
          path: ${{steps.sign_app.outputs.signedReleaseFile}}

      # Upload the APK to WeTransfer and send link to Telegram
      - name: Send the APK to Telegram
        env:
          APK_PATH: ${{steps.sign_app.outputs.signedReleaseFile}}
          BOT_API_KEY: ${{ secrets.BOT_API_KEY }}
          CHAT_ID: ${{ secrets.CHAT_ID }}
        run: |
          # Get the transfer script to upload the apks
          curl -sL https://git.io/file-transfer | sh
          # Upload and get the link
          LINK=$(./transfer wet $APK_PATH | grep "Download Link" | sed 's/Download Link://g')
          # Create a message
          MESSAGE="Template $(date +'%Y-%m-%d %H:%M')\n\nLink: ${LINK}"
          # Can't make the telegram markdown working
          TEXT=$(echo -e $MESSAGE)
          # Send the message to telegram
          curl -F chat_id=$CHAT_ID -F text="$TEXT" -F disable_web_page_preview=true https://api.telegram.org/bot${BOT_API_KEY}/sendMessage

6) Now commit the changes by clicking the 'Start commit' button.

7) Add repository secrets

• Open the Settings tab in the repository

• Click Secrets and Variables under the 'Security' section

• Open Actions

• Add the required secrets with the proper keys used in the workflow (main.yml).

8) Now you can verify your action by making repository events like pushing new commits or by manually running it from the 'Action' Tab.

Bonus: Multiple APK

In case, you are building multiple APKs for your project, then use this workflow code as a reference.

name: Build App
on:
  push:
    # Trigger only for main branch.
    branches: [ main ]
  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-20.04
    steps:
      # Get the app source
      - name: Get the source
        uses: actions/checkout@v2

      # Compile the apk
      - name: Generate Release APK
        run: ./gradlew assembleRelease

      # Sign the apk
      - name: Sign APK
        uses: Dhina17/sign-android-release@master
        # ID used to access action output
        id: sign_app
        with:
          releaseDirectory: app/build/outputs/apk/release
          signingKeyBase64: ${{ secrets.SIGNING_KEY }}
          alias: ${{ secrets.ALIAS }}
          keyStorePassword: ${{ secrets.KEY_STORE_PASSWORD }}
          keyPassword: ${{ secrets.KEY_PASSWORD }}
        env:
          # override default build-tools version (29.0.3) -- optional
          BUILD_TOOLS_VERSION: "31.0.0"

      # Upload all APK variants to GoFile and send links to Telegram
      - name: Send the APK to Telegram
        env:
          APK_VARIANT1: ${{steps.sign_app.outputs.signedReleaseFile0}}
          APK_VARIANT2: ${{steps.sign_app.outputs.signedReleaseFile1}}
          APK_VARIANT3: ${{steps.sign_app.outputs.signedReleaseFile2}}
          APK_VARIANT4: ${{steps.sign_app.outputs.signedReleaseFile3}}
          BOT_API_KEY: ${{ secrets.BOT_API_KEY }}
          CHAT_ID: ${{ secrets.CHAT_ID }}
        run: |
          # Get the transfer script to upload the apks
          curl -sL https://git.io/file-transfer | sh
          # Upload and get the link
          LINK1=$(./transfer wet $APK_VARIANT1 | grep "Download Link" | sed 's/Download Link://g')
          LINK2=$(./transfer wet $APK_VARIANT2 | grep "Download Link" | sed 's/Download Link://g')
          LINK3=$(./transfer wet $APK_VARIANT3 | grep "Download Link" | sed 's/Download Link://g')
          LINK4=$(./transfer wet $APK_VARIANT4 | grep "Download Link" | sed 's/Download Link://g')
          # Create a message
          MESSAGE="Template $(date +'%Y-%m-%d %H:%M')\n\narm64: ${LINK1}\narm: ${LINK2}\nx86_64: ${LINK3}\nx86: ${LINK4}"
          # Can't make the telegram markdown working
          TEXT=$(echo -e $MESSAGE)
          # Send the message to telegram
          curl -F chat_id=$CHAT_ID -F text="$TEXT" -F disable_web_page_preview=true https://api.telegram.org/bot${BOT_API_KEY}/sendMessage

Here, is a small change in the signing APK step, I have used my fork Dhina17/sign-android-release since multiple APK signing needs some changes. The original repo is not active to accept the contribution so.

You can understand this with my previous explanations.

I hope you can save your valuable time in building and sharing apps with your friends and testers.

Add your valuable feedback in the comments.

Thanks for reading. <3

Make sure you know about the following topics.

• Basic Programming

• Open Source

• Git and GitHub

Introduction

What is open source?

Open source projects are a type of project that is open and free for everyone so anyone can view, use and modify it.

Benefits of Open Source contribution

• Gain real-world software development experience and skills.

• Learn from other developers.

• Network with worldwide developers.

• It will increase the value of your career profile.

• Give back to the community.

• and more.

Guide to Contribute

1) Choose a project

Choose a field

Open Source is an ocean. Accept the truth, you can't contribute to every project out there. Choose any field. For example, Android, Web Dev, Cyber Security etc

Find a niche in your field

Now you have chosen a field but it may contain a lot of sub-fields further. Let's say

• Android - It has Android custom ROM development which includes the device-specific, android framework, kernel and so on, and app development which includes app UI, and libraries like custom views, utility etc.

  Example:

  Custom ROMs like LineageOS,

  App Development - Open-source apps and libraries.

• Web Development - It has two parts - front end, back end and so on.

  For example, react.js projects, node packages, and whatever.

• Other fields - Every other field has open-source projects that you may be interested in and choose it.

Choose one.

Note: You can contribute to many projects at a time. For beginners, I recommend sticking with one good project to learn.

Consume open-source projects

I always say - "First, consume then contribute" In your niche, maybe there are handy tools, libraries, and so on. Go and try them. Maybe you are using some projects already without knowing it's open source. Make a list.

Pick a project

→ Obviously yes, Pick one which you like the most from your list.

Two types of projects:

1) Big project

• More users

• Community driven

2) Small project

• Personal project

• Fewer users

• No Community

→ Pick one big project you like, join the community, learn from the community, and contribute to the project.

→ It's always good to be in a community so you can find mentors, seek help and learn from them.

→ FAQ: Where can I find the community?

Check the project README or project website. You can find the community discord or slack link easily

→ So, Pick one big project and STICK to it.

→ Play the long-run game here.

Keep the above points aside. let's get into the small projects.

→ I didn't say don't contribute to small projects. You can start with small projects but ensure you are in a community-driven project for the long run.

Tips to pick:

• Go for projects in which you have a real use case and consume it. You will know how it works clearly. (User-wise) As much as you consume, you will get ideas and will need more improvements/features in that project.

• For example, you may be using an app daily, a Money Manager app. In that case, try to find an open-source alternative, consume and then contribute.

2) Involve and find areas of improvement in the project

→ Clone/Download the project.

→ Compile or run yourself.

→ You can find errors or warnings. Fix it and contribute to the project.

→ Read the docs. You can find typos and grammar mistakes in the docs. Correct them and contribute to the project.

→ Check the Pull Request of the project. Help the maintainers by:

• Test, verify the patch, and comment in the PR - CodeReview

→ Check the issues of the project.

• Try to help if you know the workaround or try to fix it on the project side.

→ Help in your language translation to the project. Check the README or Project website to know "How to".

Points to remember:

• Don't go for random repo which you don't use but do just for the sake of the word "open source contributions"

• Be specific in choosing the project

• Join at least one community-driven project for the long run.

• Stick to ONE in the beginning. START TODAY.

• You will contribute as much as you consume the project. Simple

• If you loved the project but don't get any ideas, No worries check the issues tab, try to fix them and contribute to the project.

3) Learn to track the code

Imagine, You have chosen a project which fulfills your needs. You have used it enough to know how to use it and how it works from the user mindset. You got some improvements in your mind or took issues from the issues tab.

Now get into tracking the code For example, You want to update a print line (Output) in a CLI tool. In this case, you can easily track the part of the code responsible for printing by doing a quick search for the string in the project.

If you want to track the code for a logical part, let's say a logic or a dynamic content part, you can't track it easily since you can't find the exact words in the output as in the code.

In this case, you have to find the static part associated with the dynamic part. Let's say the title, header, or logs part (Typically strings). Once you find this part in the source code, you can find the dynamic part or logical part in the code easily.

Sometimes tracking is a bit time-consuming and harder when the projects are big and consist of many packages/modules. In this case, one part of the code points to another and another package/module. You need PATIENCE here.

4) Learn to read the code

Now you tracked the code successfully, What's next?

You have to read that part of the code and understand how it works. Here you don't need to read and understand the whole project source code to contribute. That's COOL, right?

You have to understand the specific part which you are going to modify. If you are familiar with the project tech stack/language, you can read and understand it easily.

if you are not familiar with it, Don't worry I got you.

→ Since you tracked the code, take that part of the code and google it (Syntax wise). I am sure you can understand it if you have basic programming knowledge. Sometimes it takes time, Be PATIENT!

Note: Use documentation if the project has one.

5) Learn to change

You know what are you going to do and what that piece of code is doing there. Now, what's next?

Add your part there. if you are familiar with that project tech stack/language, you can convert your idea into code easily.

if you are not familiar with it, Don't worry I got you again

→ If you have basic programming knowledge, your mind can visualize how you can convert your idea into programming logic.

→ Google the syntax of the language in which you have to write the code

→ Sometimes you have to learn some basics about the framework/stack.

→ Sometimes you have to learn much more. Yeah, depends on your change. if you had come this far, you could have managed this. :-)

Using the above things - Write the code - Run - Verify

6) Contribute

→ Commit the change and push it to your forked repo.

→ Make a Pull Request to the original project repo.

→ Wait for the maintainer.

Have PATIENCE!

Make sure you followed the contributing guidelines of the project if it has one.

It's good to get feedback about your idea from the maintainers before implementing it. So you will be aligned with the project goals and your contributions have more chances to get accepted.

For example, If you want to redesign or refactor some parts of the project, ask the maintainer, get the confirmation and then start the work.

Note: There are a lot of guides on 'How to use git?' out there. Please refer to them.

7) Community

Open Source wouldn't have come this far without collaborations among great minds. If the project that you are contributing to, has a large user base, sure it will have a common online platform where the users and developers interact.

→ Engage with the community members.

→ Talk more about the project.

→ Get help. Give help

→ Make friends. Make friends

→ Learn from them

Points to remember in a community

→ Don't expect a spoon feed from the community members.

→ Avoid asking things that you can find by a simple google search.

→ No "Hello" and "Hi". Ask your question directly.

→ Prefer the common chat over DM. Seek help in public. So you will get help from more people and others will learn from your convo.

→ Learn to wait. People have their own life to live - value others' time.

→ Be kind to others.

Sound rude or not friendly? Trust me, follow the above points blindly. You will see the magic in your community. You will realize soon why it's important.

8) Final Note

→ This article is written for BEGINNERS to help them to kick-start the open-source journey.

→ Here I used changing a string as an example to make the beginners understand it clearly. You can do big stuff.

→ This article is more focused on contributing with code, but you can also contribute open-source in other ways like helping in translations.

→ OpenSource is for EVERYONE. Just start. Learn on the go.

ALL THE BEST.

OpenSource is <3

I hope it adds some value to you.

Thanks for reading.

Let's see some common 'How to' in Hilt in this article.

How to field-inject dependencies in non-Android classes?

As we know, To field-inject a dependency, we use @Inject annotation but it supports only Android classes by default with a predefined entry point @AndroidEntryPoint.

To field-inject a dependency in non-android classes (not supported by @AndroidEntryPoint), we must create a new entry point and access the dependencies through it.

Example

class Developer() {
    // We gonna inject for this
    private val cup = Cup()

    fun drinkCoffee() {
        // further steps to drink coffee
    }
}

class Cup() {
    // A cup
}

As you can see from the example, we gonna field-inject Cup instance into the Developer class.

First, define a new entry point which provides the Cup instance.

import dagger.hilt.EntryPoint
import dagger.hilt.InstallIn
import dagger.hilt.components.SingletonComponent

@EntryPoint
@InstallIn(SingletonComponent::class)
interface CupEntryPoint {
    var cup: Cup
}

Next, access the cup instance from the entry point in the Developer class.

import dagger.hilt.android.EntryPointAccessors

class Developer {

    // Get the entry point
    private val entryPoint = EntryPointAccessors.fromApplication(
        applicationContext,
        CupEntryPoint::class.java
    )
    // Get the instance
    private val cup = entryPoint.cup

    fun drinkCoffee() {
        // further steps to drink coffee
    }
}

First, get the entry point using the respective method from the EntryPointAccessors.

Here we have used fromApplication() since the CupEntryPoint was created as a singleton component. You can use other methods like fromActivity() based on your needs.

After that, we accessed the dependency via the entry point. Simple.

How to provide multiple instances of the same type in Hilt?

In some cases, you may need to inject multiple instances of the same type into a class. In this scenario, you have to differentiate your hilt bindings with Qualifiers.

Example

class Developer @Inject constructor(
    private val coffeeCup: Cup,
    private val teaCup: Cup
) {

    fun drinkCoffee() {
        // further steps to drink coffee
        coffeeCup.useHere()
    }

    fun drinkTea() {
        // further steps to drink tea
        teaCup.useHere()
    }
}

class Cup() {
    // A cup
}

From the above example, you may guess the requirements. The Developer class needs two Cup instances i.e one to drink the coffee and another one to drink the tea.

By default, Hilt doesn't about how to differentiate the bindings when you provide the two instances of the Cup. So we have to use Qualifiers to let the hilt know which one is for coffee and which one is for tea.

@Qualifier
annotation class CoffeeCup

@Qualifier
annotation class TeaCup

@Module
@InstallIn(SingletonComponent::class)
object DeveloperModule {

   @Provides
   @CoffeeCup
   fun provideCoffeeCup(): Cup {
     // Your way to create the coffee cup
     // For simplicity
     return Cup()
   }

   @Provides
   @TeaCup
   fun provideTeaCup(): Cup {
     // Your way to create the tea cup.
     // For simplicity
     return Cup()
   }

   @Provides
   fun provideDeveloper(
        @CoffeeCup coffeeCup: Cup,
        @TeaCup teaCup: Cup
   ): Developer {
        return Developer(coffeeCup, teaCup)
   }
}

I have created Two annotation classes - CoffeeCup and TeaCup with annotation @Qualifiers.

Then use the qualifiers to differentiate the instances. Simple.

Note: Here I have used the Cup class with no difference and no constructor parameters for the sake of simplicity. Anyway the same way, you can provide bindings as per your needs easily.

I hope you learned something from this article.

Thanks for reading. <3.

What is Dependency Injection?

Consider this example, you are an Android Developer who drinks coffee. To drink coffee, you need a cup (of course xD).

Implement this concept in the code

class Developer() {

    fun drinkCoffee() {
        // steps to drink coffee
    }
}

class Cup() {
    // A cup
}

From this example, you can assume the Developer class needs a Cup instance to drink coffee.

class Developer() {

    fun drinkCoffee() {
        val cup = Cup()
        // further steps to drink coffee
    }
}

class Cup() {
    // A cup
}

The above approach creates a new instance of a Cup whenever the Developer drinks coffee.

Generally, do you buy a new cup whenever you drink coffee? Big No (Except for an insane rich dude)

One person needs only one cup to drink coffee.

Similarly, in programming, creating unwanted instances is costly so you need to properly handle it.

Let's come back to our example, To avoid the creation of the Cup instance every time inside the Developer class, we gonna provide a Cup instance to the Developer class. This technique is called Dependency Injection.

Cup is a dependency of the Developer class.

We can inject the dependency in two ways:

• Constructor injection - Provide the dependency via the constructor

• Field injection - Provide the dependency via field (setters)

class Developer(private val cup: Cup? = null) {

    lateinit var fieldCup: Cup

    fun drinkCoffee() {
        // Use the cup here
        // further steps to drink coffee
    }
}

class Cup() {
    // A cup
}

fun main() {
   // Create cup instance
   val cup = Cup()
   // Constructor injection
   val developer = Developer(cup)
   // Field injection
   val developer = Developer()
   developer.fieldCup = cup
}

Dependency injection makes our code loosely coupled so easily testable and reusable.

Manual Dependency Injection

We can manually handle the dependency by creating and providing the instances as we do in the above code snippet.

It takes more time and is even hard to manage its lifecycle properly.

Example: Consider the Developer and Cup example, Having the cup all the time at your work table is unwanted, agree? You need the cup only when you drink the coffee.

Similarly, providing dependencies according to the consumer's lifecycle is crucial. For example, creating and providing an instance to an activity should happen only in the activity lifecycle. In this case, holding a singleton instance is not a good way.

Hilt

Hilt is a dependency injection library created on top of Dagger specifically for Android projects.

Hilt reduces the code boilerplates and makes dependency management easier for developers.

Setup Hilt in your project

Add dependencies

Add hilt-android-gradle-plugin plugin to your project's root build.gradle file.

buildscript {
    ext {
        ...
        hilt_version = '2.44.2'
    }

    dependencies {
        ...
        classpath "com.google.dagger:hilt-android-gradle-plugin:$hilt_version"
    }
}

Apply the plugin and add the following dependencies in your app/build.gradle file.

...
plugins {
  id 'kotlin-kapt'
  id 'com.google.dagger.hilt.android'
}

android {
  ...
}

dependencies {
  implementation "com.google.dagger:hilt-android:$hilt_version"
  kapt "com.google.dagger:hilt-compiler:$hilt_version"
}

Hilt application class

@HiltAndroidApp
class App: Application()

<manifest xmlns:android="http://schemas.android.com/apk/res/android">
    ...
    <application
        ...
        android:name=".App"
        ... >
    </application>
</manifest>

HiltAndroidApp annotation creates a hilt application component which generates the base class for your application which acts as the application-level dependency injection container.

It obeys the Application object lifecycle.

Using Hilt in MVVM architecture

Model-View-ViewModel (MVVM) is the recommended app architecture by Jetpack/developer docs.

The simple architecture that we use to demonstrate hilt here

Activity/Fragment ---> ViewModel ---> Repository ---> Datasources

The above flow indicates the dependency of each class.

In text,

• Datasources (database/network) are needed by the repository

• The repository is needed by the ViewModel

• The ViewModel is needed by the Activity/Fragment

Initial class setup

MainActivity.kt

package io.github.dhina17.template.activities

import android.os.Bundle
import androidx.appcompat.app.AppCompatActivity
import androidx.databinding.DataBindingUtil
import io.github.dhina17.template.R
import io.github.dhina17.template.databinding.ActivityMainBinding

class MainActivity : AppCompatActivity() {

    private lateinit var binding: ActivityMainBinding

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = DataBindingUtil.setContentView(this, R.layout.activity_main)
    }
}

MainViewModel.kt

package io.github.dhina17.template.activities

import androidx.lifecycle.ViewModel


class MainViewModel(private val repository: Repository) : ViewModel() {

}

Repository.kt

package io.github.dhina17.template.activities

import io.github.dhina17.template.Database

class Repository(database: Database) {

}

Data sources are nothing but instances (however static) of a database or network service(retrofit).

Dependency Injection using Hilt

@AndroidEntryPoint
class MainActivity : AppCompatActivity() {
}

@AndroidEntryPoint - It's a predefined entry point in the hilt library that generates a hilt component for the specified Android class (list of supported classes)

Since we can't use constructor injection in an activity, We will field-inject the MainViewModel in the MainActivity.

We use @Inject annotation to inject an instance into a field of a class.

Note: The field which will be injected cannot be private.

@AndroidEntryPoint
class MainActivity : AppCompatActivity() {
    @Inject lateinit var something: Something
}

However, in the case of ViewModel, we will take the advantage of Hilt extensions to make our work easier. We don't need to provide any binding information to the hilt. We will see about bindings later.

To provide the MainViewModel object, add @HiltViewModel annotation and @Inject annotation to the constructor of the MainViewModel class.

@Inject annotation in the constructor provides the binding information to the Hilt to generate an instance. The parameters of an annotated constructor of a class are the dependencies of a class.

Here, MainViewModel has a dependency i.e Repository

package io.github.dhina17.template.activities

import androidx.lifecycle.ViewModel
import dagger.hilt.android.lifecycle.HiltViewModel
import javax.inject.Inject

@HiltViewModel
class MainViewModel @Inject constructor(
    private val repository: Repository
): ViewModel() {

}

Simply, in the MainActivity, get the MainViewModel object by using viewModels() delegate from KTX.

package io.github.dhina17.template.activities

import android.os.Bundle
import androidx.activity.viewModels
import androidx.appcompat.app.AppCompatActivity
import androidx.databinding.DataBindingUtil
import dagger.hilt.android.AndroidEntryPoint
import io.github.dhina17.template.R
import io.github.dhina17.template.databinding.ActivityMainBinding

@AndroidEntryPoint
class MainActivity : AppCompatActivity() {

    private lateinit var binding: ActivityMainBinding

    private val viewModel: MainViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = DataBindingUtil.setContentView(this, R.layout.activity_main)
    }
}

We don't need to create any Hilt Module i.e Telling hilt how to create an instance of MainViewModel. Hilt will take care of that for us.

Now, we are injecting the Repository instance into the MainViewModel.

However, hilt doesn't know how to create an instance of a Repository (i.e Other than supported android classes).

To tell hilt about that, we have to provide binding information to the hilt with a Hilt Module.

Note: We don't need to do anything if the Repository doesn't have any parameters in the constructor. @Inject annotation is only enough. Hilt will take care of that.

Create a hilt module for the Repository

package io.github.dhina17.template.activities

import dagger.Module
import dagger.Provides
import dagger.hilt.InstallIn
import dagger.hilt.android.components.ViewModelComponent

@Module
@InstallIn(ViewModelComponent::class)
object RepoModule {

    @Provides
    fun provideRepository(database: Database): Repository {
        return Repository(database)
    }
}

@ Module - Indicates that a Hilt Module

@InstallIn(ViewModelComponent::class) - To make available the dependencies in the ViewModel scope. For more info, here.

Now, hilt doesn't know how to provide a database instance so we have to tell hilt by creating a module for it again.

package io.github.dhina17.template.activities

import android.content.Context
import dagger.Module
import dagger.hilt.InstallIn
import dagger.hilt.android.qualifiers.ApplicationContext
import dagger.hilt.components.SingletonComponent

@Module
@InstallIn(SingletonComponent::class)
object DatabaseModule {

    fun provideDatabase(@ApplicationContext context: Context): Database {
        return Database(context)
    }
}

@InstallIn(SingletonComponent::class) - Hilt will create a singleton instance of the database since we require a single instance for the complete application lifecycle.

@ApplicationContext - This is a predefined Qualifier in the Hilt. Hilt will provide the application context by itself.

That's it for today. We will see some other extra use cases of Hilt in the next post.

I hope you gained some knowledge here. Share with your friends.

Thanks for reading. <3

Generally, Java/Kotlin code will be compiled into java bytecode. So we need a Virtual Machine to run the bytecode.

Android has an optimized runtime environment (like a virtual machine) to execute the compiled app instead of a Java VM. So android doesn't accept java byte code. It needs a different format based on the runtime.

• Dalvik VM

• Android Runtime (ART)

Let's see about them.

Dalvik VM

Dalvik VM is an optimized virtual machine for android to run android applications. It executes the .dex files.

Android APK contains the compiled app code in DEX format. You can check that by unpacking your apk and seeing the list of .dex files in it.

Your app code conversion happens in the following way.

.java / .kt (source) ---> .class (bytecode) ---> .dex ---> Dalvik VM ---> machine code

• Dalvik uses JIT (Just In Time) compilation for translating the dex code into machine code to execute.

• Whenever your app runs, Dalvik will JIT compile the part of the code which will run instead of the complete code.

• Since Dalvik VM interprets the DEX every time the app runs, it gives a lower performance than native code execution. (like why python is slower than C++).

• It's deprecated in Android 5.0

Android Runtime (ART)

ART is introduced to solve the performance issue of Dalvik VM. It enables android applications to run natively.

There is no change in the APK. ART is also using the DEX format under the hood.

• ART uses Ahead-of-time compilation (AOT) to compile apps into an ART-specific file format called oat at the time of app installation.

• ART uses the dex2oat tool to compile the oat files for an app.

• oat file is an executable file format which contains the AOT compiled code of the app. Technically, it's an ELF file.

• After that, the app code will be executed from the compiled oat file directly.

Your app code conversion happens in the following way

.java/kt (source) ---> .class (bytecode) ---> .dex ---> .oat ---> ART (execution)

• It has a better performance than Dalvik since it runs the code natively.

• It is the default runtime in Android 5.0+.

Difference between Dalvik and ART

image source: Wikipedia

A lot to learn in Android Runtime. A deep dive guide for another day.

Thanks for Reading ❤️

Note: This article is about android XML layouts!

Prerequisites

• Basic Android App Development

• Two-way data binding

• Kotlin Coroutines and Flows (Flow / StateFlow)

1) Create form layout

Create the XML layout for the form UI

Here we are creating a sign-in form which contains email and password fields.

• Create a 'viewModel' variable to bind the ViewModel reference to the layout.

• With the ViewModel reference, we can access the variables in the ViewModel which we gonna hold the field values (text input). (Two-way data binding - Check android:text attribute.)

Note:

We have used Material Design Components to create the views since it has a lot of features like error text which is very convenient for us to show errors in the field.

<?xml version="1.0" encoding="utf-8"?>
<layout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools">

    <data>

        <variable
            name="viewModel"
            type="io.github.dhina17.justmyfinance.ui.signin.SignInViewModel" />
    </data>

    <LinearLayout
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:gravity="center"
        android:orientation="vertical">

        <com.google.android.material.textfield.TextInputLayout
            android:id="@+id/emailContainer"
            style="@style/Widget.MaterialComponents.TextInputLayout.OutlinedBox"
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:hint="Email"
            android:paddingHorizontal="20dp"
            android:paddingVertical="10dp">

            <com.google.android.material.textfield.TextInputEditText
                android:id="@+id/emailField"
                android:layout_width="match_parent"
                android:layout_height="wrap_content"
                android:inputType="textEmailAddress"
                android:text="@={viewModel.email}" />
        </com.google.android.material.textfield.TextInputLayout>

        <com.google.android.material.textfield.TextInputLayout
            android:id="@+id/passwordContainer"
            style="@style/Widget.MaterialComponents.TextInputLayout.OutlinedBox"
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:hint="Password"
            android:paddingHorizontal="20dp"
            android:paddingVertical="10dp">

            <com.google.android.material.textfield.TextInputEditText
                android:id="@+id/passwordField"
                android:layout_width="match_parent"
                android:layout_height="wrap_content"
                android:inputType="textPassword"
                android:text="@={viewModel.password}" />
        </com.google.android.material.textfield.TextInputLayout>

        <com.google.android.material.button.MaterialButton
            android:id="@+id/signInButton"
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:layout_gravity="center"
            android:layout_marginHorizontal="20dp"
            android:layout_marginVertical="10dp"
            android:paddingVertical="15dp"
            android:text="Sign In"
            tools:text="Sign In" />

    </LinearLayout>

</layout>

2) Create a fragment with a ViewModel

• Create a ViewModel named "SignInViewModel.kt' with two MutableStateFlow<String> fields named 'email' and 'password' to hold the respective text input from the UI (form fields).

• We already bound the ViewModel fields to the respective TextInputEditText widget (view). (See the above XML code)

• Create a fragment named 'SignInFragment.kt' and inflate the view using data binding.

• Initialize the ViewModel and bind it to the layout. (In simple words, assign the created ViewModel reference to the variable present in the XML layout)

// SignInViewModel.kt
package io.github.dhina17.justmyfinance.ui.signin

import androidx.lifecycle.ViewModel
import dagger.hilt.android.lifecycle.HiltViewModel
import kotlinx.coroutines.flow.MutableStateFlow
import javax.inject.Inject

@HiltViewModel
class SignInViewModel @Inject constructor() : ViewModel() {
    val email = MutableStateFlow("")
    val password = MutableStateFlow("")
}

// SignInFragment.kt
package io.github.dhina17.justmyfinance.ui.signin

import android.os.Bundle
import android.view.LayoutInflater
import android.view.View
import android.view.ViewGroup
import androidx.fragment.app.Fragment
import androidx.fragment.app.viewModels
import dagger.hilt.android.AndroidEntryPoint
import io.github.dhina17.justmyfinance.databinding.FragmentSignInBinding

@AndroidEntryPoint
class SignInFragment : Fragment() {

    private lateinit var binding: FragmentSignInBinding

    private val viewModel: SignInViewModel by viewModels()

    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View {
        // Inflate the view and bind the view model to the UI
        binding = FragmentSignInBinding.inflate(inflater, container, false)
        // We have create a variable named 'viewModel' in the layout.
        // Assign a value to it.
        binding.viewModel = viewModel
        return binding.root
    }
}

Note: Here I have used Hilt for dependency Injection so ViewModel creation is much easier and no boilerplates. Don't confuse with it. You can use your own way to initialize the ViewModel**.**

You can also create an activity instead of a fragment.

3) Combine fields and validate

In your 'SignInFragment.kt',

• Combine all the form fields (StateFlow) to create a new boolean flow with producer code containing the form validation logic. This boolean flow named 'isFormValidFlow' emits true if all the form fields are valid otherwise false.

• Here I have checked only if the fields are empty or not. You can use your form validation logic here.

private val isFormValidFlow: Flow<Boolean> by lazy {
        // Combine the fields to create a flow for form validation
        combine(
            viewModel.email,
            viewModel.password
        ) { email, password ->
            // Check your validation here
            // Here I simply check if it's empty or not
            val isEmailValid = email.isNotEmpty()
            val isPasswordValid = password.isNotEmpty()
            // Return the boolean value indicates if the form fields are valid or not
            isEmailValid && isPasswordValid
        }
    }

4) Collect the form validation flow

As we know, the producer code of a flow will run on its collection (terminal operator like collect(), etc ) since it's cold in nature.

In SignInFragment's onViewCreated() method,

• On the sign-in button click, collect the form validation flow so the validation code will run with the current values of the email and password fields.

• Depending on the validation value (boolean), proceed with your sign-in process if it's true otherwise simply show the common error for all fields like a toast.

override fun onViewCreated(view: View, savedInstanceState: Bundle?) {

        binding.signInButton.setOnClickListener {
            lifecycleScope.launch {
                // For us, it's enough to run the isFormValidFlow producer code only once on sign in button click.
                // since we don't want to collect the values continuously, use first() instead of collect()
                val isFormValid = isFormValidFlow.first()
                if (isFormValid) {
                    // Proceed to sign in
                } else {
                    Toast.makeText(requireContext(), "Form fields are invalid", Toast.LENGTH_SHORT)
                        .show()
                }
            }
        }
    }

Now the form validation part is done. However, showing errors via toast is not a good practice for the form fields. We have to show the error on the respective field, right?

Let's do it.

5) Show errors on the fields

As we know we are using Material Design Components to take the advantage of its own error text attr of a TextInputLayout to show the field errors.

• For our convenience, create an extension function for TextInputLayout to set the error text.

• In the 'isFormValidFlow' producer code, set the error text based on the field. (Since it will run whenever the Flow is collected)

private val isFormValidFlow: Flow<Boolean> by lazy {
        // Combine the fields to create a flow for form validation
        combine(
            viewModel.email,
            viewModel.password
        ) { email, password ->
            // Check your validation here
            // Here I simply check if it's empty or not
            val isEmailValid = email.isNotEmpty()
            val isPasswordValid = password.isNotEmpty()
            with(binding) {
                val errorText = "Please fill out this field."
                // See the 'not' operator
                // since if the field is valid, error is false (vice versa)
                emailContainer.setFieldError(!isEmailValid, errorText)
                passwordContainer.setFieldError(!isPasswordValid, errorText)
            }
            // Return the boolean value indicates if the form fields are valid or not
            isEmailValid && isPasswordValid
        }
    }

    /**
     * Set the given error text to the TextInputLayout based on isError.
     *
     * @param errorText Error Text which need to be set.
     * @param isError If it's error or not.
     */
    private fun TextInputLayout.setFieldError(isError: Boolean, errorText: String) {
        error = if (isError) errorText else null
    }

Note:

We have validated only if the field is empty or not. You can use your own validation and set error text based on that easily. Like this way.

private val isFormValidFlow: Flow<Boolean> by lazy {
        // Combine the fields to create a flow for form validation
        combine(
            viewModel.email,
            viewModel.password
        ) { email, password ->
            // Check your validation here
            // Here I simply check if it's empty or not
            val isEmailValid = email.isNotEmpty()
            val isPasswordFilled = password.isNotEmpty()

            // Check if the password length is less than 8.
            val isPasswordValidLength = password.length >= 8

            with(binding) {
                val errorText = "Please fill out this field."
                val passwordLengthError = "Password must be 8 or more characters"
                // See the 'not' operator
                // since if the field is valid, error is false (vice versa)
                emailContainer.setFieldError(!isEmailValid, errorText)
                passwordContainer.setFieldError(!isPasswordFilled, errorText)
                // Check if the password field is filled or not. then proceed for length check.
                // Here use your own logic to show the error properly.
                if (isPasswordFilled) {
                    // Set error for password length
                    passwordContainer.setFieldError(!isPasswordValidLength, passwordLengthError)
                }
            }
            // Return the boolean value indicates if the form fields are valid or not
            isEmailValid && isPasswordFilled && isPasswordValidLength
        }
    }

Note: Use your logic to show the error properly without overriding one error with another error.

Now you can remove the toast since we show the error in the fields itself.

You may notice that, even after filling something in the field, still the error shows until you click the sign-in button again, right?

It's fine for most cases.

However, If you want to show real-time updates to the form fields after clicking the sign-in button for the first time,

• In the onViewCreated() method, Collect the 'isFormValidFlow' outside the sign-in button click listener lambda and store the validation boolean value in a local variable.

• Lazily start the collection job once after the sign-in button clicked for the first time. In this way, you can see real-time updates to the fields.

override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        val validationJob = lifecycleScope.launch(start = CoroutineStart.LAZY) {
            isFormValidFlow.collectLatest { isValid ->
                isFormValid = isValid
            }
        }

        binding.signInButton.setOnClickListener {
            // Start the job only on click
            validationJob.start()
            if (isFormValid) {
                // Proceed to sign in
            } else {
                Toast.makeText(requireContext(), "Form fields are invalid", Toast.LENGTH_SHORT)
                    .show()
            }
        }
    }

Now you know how to validate the form fields in a simple way.

If you have any doubts or you know of any other way to validate the form fields, please let me know in the comment section.

Thanks for reading! ❤️

Dhina17

Note: This guide doesn't contain any technical tutorials. This will show you a good way to start your AOSP / Android Custom ROM development journey in a community-oriented way.

1) Get an android device which has good community support

→ I recommend buying a device with a good community if you don't have any prior experience with android modding/custom ROMs.

→ If you have prior knowledge of custom ROMs, you can go for any good device.

→ How to know if a device has a good community? Check Telegram and XDA (More detail in the next point).

Why not an emulator?

You can start learning AOSP (framework, internals) using an emulator but I want you to involve in the android ROMs community and learn from them so the actual device is the best way.

2) Join your device community

→ Nowadays, every device has a community in Telegram. You can find it simply by searching your device name or codename in Telegram.

→ How to know my device codename? A simple google search "<device_name> codename" will do the work.

→ Check XDA Developers Forum for your device forums. There you can find threads (posts) for your device.

Search "<your device name> xda" in google. You can find your device forum easily (only if your device has forums in XDA)

Now you found your device community, what's next?

→ Engage with the community members.

→ Talk more about your device.

→ Get help. Give help

→ Make friends. Make friends

→ Learn from them

Points to remember in a community

→ Don't expect a spoon feed from the community members.

→ Avoid asking things that you can find by a simple google search.

→ No "Hello" and "Hi". Ask your question directly.

→ Prefer the common chat over DM. Seek help in public. So you will get help from more people and others will learn from your convo.

→ Learn to wait. People have their own life to live - value others' time.

→ Be kind to others.

Sound rude or not friendly? Trust me, follow the above points blindly. You will see the magic in your community. You will realize soon why it's important.

3) Use custom ROMs on your device

You joined your device community, Now let's get into the core.

Note: Make sure you know what you are doing.

→ Get the basics of android custom ROM and its related terms like ADB, bootloader, recovery and so on.

→ Unlock the bootloader

→ Install a custom recovery

→ Flash a custom ROM via recovery

Properly follow the instructions mentioned in the ROM thread/post.

→ Get help from the community. Don't follow anything blindly or your device will become unusable (worst case).

→ Enjoy the perks of custom ROMs. You will love it for sure.

In this phase, Explore custom ROMs and become familiar with them.

There is a lot to mention. But I am sure you will learn all the things eventually from the community.

4) Build a custom ROM for your device

You are a pro user now, let's do something more.

Let's compile an Android ROM for your device.

To build an Android ROM, you need a good specs PC.

Check the requirements: https://source.android.com/docs/setup/start/requirements

Most people (like me) can't have a machine that meets the requirements. I got you.

What you can do about that?

→ Try to get a free trial from services like Google Cloud Platform (GCP), Azure or AWS. Then create a virtual machine (VM)

→ Ask for help from your community friends. They may help you.

Now you have the machine to build.

How to build?

I ain't gonna write it about in detail since there are a lot of guides out there. (a thread for another day)

Lineage wiki (device-specific): https://wiki.lineageos.org/devices/onclite/build Official doc: https://source.android.com/docs/setup/start

From the lineage wiki, up to this https://wiki.lineageos.org/devices/onclite/build#download-the-source-code are common for all devices.

For the next step

→ You have to download/clone your device sources - Device config tree, kernel tree and vendor tree.

→ Lunch your device

→ Start the build

I recommend you get the details from your community. Learn from them. Get help from them. (no spoonfeeding)

Build errors: Try to get help after trying something yourself. Don't go straight to the community without any try. (a thread for another day)

I hope, Now you know how to get started in Android custom ROM development.