DEV Community: Omotola Odumosu

Implementing Retry Policy (React Native & Beyond)

Omotola Odumosu — Mon, 23 Mar 2026 07:38:32 +0000

A seamless user experience is one of the biggest factors in determining whether users stick with your app or abandon it. One underrated technique that helps achieve this is retry policy.

What is a Retry Policy?

A retry policy is a strategy where your application automatically retries a failed request instead of immediately showing an error to the user.

From the user’s perspective, everything just works:

“I made a request → I saw a loader → I got my result.”

But behind the scenes, your app may have retried that request multiple times before eventually succeeding.

Why Does This Matter?

Network calls are not always reliable. Failures can happen due to temporary server issues (5xx errors), network instability (timeouts, poor connectivity), rate limiting, or other transient failures.

If you immediately show an error, you force users to retry manually, restart their whole flow again, and potentially lose trust in your app.

A retry policy helps smooth over these temporary issues and improves overall user experience.

Retry policies are widely used across backend services (e.g., microservices communication), Cloud systems, distributed systems, Message queues, etc.

It’s a universal resilience pattern, used to improve performance and user experience. When implemented correctly, users never even know something went wrong, and that’s exactly the goal.

Implementation

const wait = (ms: number) =>
  new Promise((resolve) => setTimeout(resolve, ms));

type RetryOptions = {
  retries: number;
  delay: number;
  factor?: number; // exponential multiplier
};

async function retryRequest<T>(
  fn: () => Promise<T>,
  { retries, delay, factor = 2 }: RetryOptions
): Promise<T> {
  let attempt = 0;

  while (attempt <= retries) {
    try {
      return await fn();
    } catch (error: any) {
      const status = error?.response?.status;

      // Do not retry client errors (4xx)
      if (status >= 400 && status < 500) {
        throw error;
      }

      if (attempt === retries) {
        throw error;
      }

      const backoff = delay * Math.pow(factor, attempt);
      await wait(backoff);

      attempt++;
    }
  }

  throw new Error("Unexpected error");
}

Understanding The Implementation Above

This implementation wraps any async operation (fn) with a retry mechanism.

retryRequest is a generic function, meaning it works with any return type while preserving type safety.
RetryOptions defines how many times to retry, the initial delay, and an optional exponential multiplier (factor).
The wait function simply pauses execution for a given time before retrying.

Implementation In Plain English

The function attempts to execute the provided operation, which is "fn". If it succeeds, the result is returned immediately, but if it fails, the error is inspected:

4xx errors are not retried (these are client-side issues), e.g., the client input wrong details.
Other errors (e.g., 5xx or network failures) are retried.

Before each retry, the function waits using exponential backoff, where the delay increases after every attempt. This is to ensure we don't overburden the server. Exponential backoff helps give the server the time it needs to respond:

delay × factor^attempt

The process continues until the request succeeds or the maximum number of retries is reached. If all retries fail, the error is thrown.

Usage

const fetchUser = async () => {
  const response = await fetch("https://api.example.com/user");

  if (!response.ok) {
    const error: any = new Error("Request failed");
    error.response = { status: response.status };
    throw error;
  }

  return response.json();
};

const getUserWithRetry = async () => {
  try {
    const data = await retryRequest(fetchUser, {
      retries: 3,
      delay: 1000,
    });

    console.log("Success:", data);
  } catch (error) {
    console.log("Final failure:", error);
  }
};

With this setup, you call the getUserWithRetry() function within your application whenever you need to fetch the user. If the request fails due to a transient issue, the retry policy automatically kicks in and attempts the request again behind the scenes.

In Conclusion

Retry policies are a simple but powerful way to improve reliability, reduce user frustration, and handle transient failures gracefully

It’s a small addition, but it can make your application feel significantly more stable and production-ready.

Did this post help simplify things for you?

If yes, drop a ❤️ or 🦄 reaction and follow me here on dev.to. I share more practical, plain-English breakdowns like this.

You can also connect with me on social media. I’d love to learn, share, and grow together with you!

LinkedIn: LinkedIn
Twitter: Twitter
Instagram: Instagram
Graphics Credit: Daniel Gustaw

Building and Signing Android Apps Locally with Gradle (React Native & Expo)

Omotola Odumosu — Sat, 24 Jan 2026 16:42:27 +0000

A practical, step-by-step walkthrough of generating debug and release builds, configuring keystores, fixing common Gradle errors, and preparing your app for Google Play.

If you’ve been using EAS Build, you already know how convenient it is. EAS automatically creates your keystore and signs your app for you, which makes building Android apps feel almost effortless.

However, you also discover the downside pretty quickly: long queues. Sometimes your build sits for hours before it even starts. That’s usually the moment you realize that building locally is not optional; it’s a skill you need.

When I attempted my first Android release build locally, I ran into a lot of confusion, debugging, research, and errors like:

debug vs release signing
keystore vs signingReport
Why my APK worked but wasn’t Play Store–ready
random Gradle errors that made no sense at first

And many more that I can’t fully cover here.

Even if the exact issue you’re facing isn’t listed above, don’t worry, just follow along, and we’ll get to the destination together.

For this article, I’ll be using React Native with Expo on Windows, but most of the concepts apply generally across platforms.

Prerequisites
Before anything else, make sure you have:

JDK 17 installed
Android Studio
- Android SDK
- Android SDK Build Tools
Node.js + npm
A React Native or Expo project

Step 1: Generate the Android Folder (Expo users)

If you’re using Expo (managed workflow), you first need the native Android files. From your project root:

npx expo prebuild --platform android

This generates an Android folder in your project.

Step 2: Move into the Android Directory

cd android

All Gradle commands are run inside the Android folder, not the project root.

Step 3: Clean the Project (Important)

Before building anything, always clean once:

./gradlew clean

This command clears old build artifacts and ensures Gradle starts from a clean state. You usually run this once per project, unless

you hit strange build errors,
you change signing configs, or
You change native dependencies

Common Windows Issue
If you come across this error, "Filename longer than 260 characters." It means the path to your project is too long.

Fix:
Move your project closer to the drive root, e.g.

C:\my-project

Step 4: Understanding Build Types

Gradle can generate different build types, such as:

Development build

A development build can be generated using the command below

./gradlew assembleDebug

Development builds are:

Signed with debug keystore
Used for local testing while coding, just like Expo Go
Not for Play Store

Release APK

A release build can be generated with the code below

./gradlew assembleRelease

This produces a release APK that can be installed on your device and used. It is fully functional, but not necessarily Play Store ready.

Play Store Bundle (Recommended)

Play Store doesn't accept APK files for app uploads anymore, and as such, an AAB file is required as per Play Store's requirements. The command below generates a .aab file

./gradlew bundleRelease

Step 5: Where Your Builds Are Located

After a successful build, your apps are located in the directory below:

APKs

android/app/build/outputs/apk/debug/app-debug.apk
android/app/build/outputs/apk/release/app-release.apk

If you initiated a debug APK build, you'll find your app in the first path above, but if you initiated a release build, you'll find your app in the second path above.

Play Store Bundle

android/app/build/outputs/bundle/release/app-release.aab

For Google Play Store builds (.aab), you'll find your app in the directory above

Step 6: Understanding signingReport

To see how your app is signed, run this command:

./gradlew signingReport

This shows:

Variant (debug / release)
Config (which keystore was used)
Store file
Alias
SHA1 / SHA256 fingerprints

Important Discovery 💡

If you ran a release build in step 4 above, and after running the command in step 6, you see:

variant: release
config: debug

Config tells you which keystore was actually used, not the build type you intended to use. Seeing the above means that your release APK is still signed with the debug keystore. The implication of this is that your app will work normally and will be fully functional; you can share it with friends or anyone, and it will still work, but you can't upload it to the Google Play Store. It will get rejected because the app was signed with a debug keystore. If your intention wasn’t to upload to the Play Store but maybe to just have the app and test that it works fine, or share it with friends, then you have no issues to bother about. However, if you plan to upload to the store, you need to generate a release keystore so your app can be signed with that release keystore.

Step 7: Generating a Release Keystore (Windows)

Open PowerShell as administrator, and navigate to the directory below:

C:\Program Files\Java\jdkX.X.X\bin

Then run this command:

.\keytool.exe -genkeypair -v `
  -storetype PKCS12 `
  -keystore my-upload-key.keystore `
  -alias my-key-alias `
  -keyalg RSA `
  -keysize 2048 `
  -validity 10000

You’ll be asked to set the following:

Name, organization, country, Keystore password, Key password, etc.

Important
Save your passwords and aliases. You can’t recover them later. And also, while typing the passwords, your terminal won't show the letters you're typing at all; that's a security measure put in place to secure your password, so be very careful when typing

Step 8: Back Up Your Keystore (Very Important)

Create a backup folder with this code :

mkdir "$env:USERPROFILE\Documents\android-keys"

Then use this code to duplicate the keystore to the folder created

copy my-upload-key.keystore "$env:USERPROFILE\Documents\android-keys"
copy my-upload-key.keystore "my-upload-key.BACKUP.keystore"

This code also renames the duplicated version to this name "my-upload-key.BACKUP.keystore"

To verify if the duplication was successfully performed, run this code

dir "$env:USERPROFILE\Documents\android-keys"

This code will show the directory to the duplicated keystore

Important
If you lose this keystore, you permanently lose the ability to update your app on the Play Store, so you can always copy your keystore to an external hard-drive or flash.

Step 9: Verify Keystore and Alias

To verify the existence of your keystore and key-alias, run this code

.\keytool.exe -list -keystore my-upload-key.keystore

This code lists the aliases available. It will ask for your keystore password. if password is correct, you should see something like this

"my-key-alias, PrivateKeyEntry"

This confirms your alias exists. However, this won't show the full details of the key-alias; it just confirms whether your alias actually exists. its basically a confirmation check.

To View full details of your alias

To see the full details of your key-alias and other credentials, run this

.\keytool.exe -list -v `
  -keystore my-upload-key.keystore `
  -alias my-key-alias

This shows your:

Alias name,
Creation date,
Certificate fingerprints (SHA1, SHA256),
Validity period.

It will never show passwords (that’s correct).

Step 10: Configure Gradle Properties

Edit "android/gradle.properties" by adding this at the bottom of the file :

MYAPP_UPLOAD_STORE_FILE=my-upload-key.keystore
MYAPP_UPLOAD_KEY_ALIAS=my-key-alias
MYAPP_UPLOAD_STORE_PASSWORD=*****
MYAPP_UPLOAD_KEY_PASSWORD=*****

Important
If you followed step 7 without changing anything there, then all you need to add above is your password that you set when creating your release keystore in step 7. But if you changed the alias name template or any other field there, then you need to put whatever name you used.

Step 11: Configure Release Signing in build.gradle

Navigate into "android/app/build.gradle" file and add this part :

android {
    ...

    signingConfigs {
        release {
            if (project.hasProperty('MYAPP_UPLOAD_STORE_FILE')) {
                storeFile file(MYAPP_UPLOAD_STORE_FILE)
                storePassword MYAPP_UPLOAD_STORE_PASSWORD
                keyAlias MYAPP_UPLOAD_KEY_ALIAS
                keyPassword MYAPP_UPLOAD_KEY_PASSWORD
            }
        }
    }

    buildTypes {
        release {
// Important: ensure ONLY ONE signingConfig exists here.
// If debug is present, remove it and leave only release.

            signingConfig signingConfigs.release
        }
    }
}

Step 12: Build Your App Again (This Time Properly Signed)

Since you have correctly set up the release configuration, building your app again will now use the release configuration to sign your app, making it acceptable by playstore

./gradlew clean
./gradlew assembleRelease

After your build has completed, let's check which signing configuration was used just to be sure everything works as it should. Run this code

./gradlew signingReport

You should see

variant: release
config: release

This confirms the correct keystore is being used. SigningReport always reflects the current Gradle configurations used for our most recent build, not past builds.

Step 13: Generate Upload Certificate for Play Store (Final Step)

Google Play requires your upload certificate (done once per app). Run:

.\keytool.exe -export -rfc `
  -keystore my-upload-key.keystore `
  -alias my-key-alias `
  -file upload_certificate.pem

To verify the upload certificate was created successfully, Run

notepad upload_certificate.pem

You should see something like this

-----BEGIN CERTIFICATE-----
MIIF...
-----END CERTIFICATE-----

Upload this file to Google Play Console → App Signing.

Common Error I Faced (And the Fix)

Error

Execution failed for task ':app:mergeReleaseNativeLibs'
2 files found with path 'lib/arm64-v8a/libworklets.so'

Cause

Both:

react-native-reanimated
react-native-worklets were installed.

In modern React Native, react-native-worklets should NOT be installed separately

Fix

npm uninstall react-native-worklets
cd android
./gradlew clean
./gradlew assembleRelease

In Conclusion
This process felt confusing at first, but if you made it here, I am sure you now have an app ready for Google Play Store upload. Take note that you don’t need to manually delete old APKs before building a new one; Gradle overwrites them automatically. SigningReport reflects current Gradle config, not past builds. Google Play prefers .aab files, not APKs. Back up your keystore like your career depends on it (because it does)

Did this post help simplify things for you?

If yes, drop a ❤️ or 🦄 reaction and follow me here on dev.to. I share more practical, plain-English breakdowns like this.

You can also connect with me on social media. I’d love to learn, share, and grow together with you!

LinkedIn: LinkedIn
Twitter: Twitter
Instagram: Instagram
Graphics Credit: Torcheux Frédéric

Google Sign-In in React Native (Expo): A Practical, Production-Ready Guide

Omotola Odumosu — Wed, 24 Dec 2025 14:40:32 +0000

Google authentication is one of the most common login methods in modern mobile apps. However, despite how common it is, developers still find it difficult to implement correctly. In this article, I’ll walk you through how to set up Google Sign-In in a React Native app using Expo, explaining every step in simple terms. This guide covers the complete setup, common pitfalls, and production considerations.

For simplicity, this guide assumes:

You are using React Native with Expo
You want Google Sign-In to work on Android and iOS
You are not using Expo Go (Google Sign-In does not work on Expo Go app, so you need a development build, but dont worry, everything will be covered in this guide)

Why Google Sign-In Doesn’t Work in Expo Go

Expo Go is a generic app. Google Sign-In requires native configuration, which means you must use a development build or a production build.

Step 1: Configure the OAuth Consent Screen

Go to Google Cloud Console
Create a new project (or select an existing one)
Navigate to APIs & Services → OAuth consent screen
Click Get Started on the consent screen dashboard
Then fill in the required information. This screen tells Google who you are and why you’re requesting user data

Under App Information, fill

   - App name
   - User support email

Under Audience, choose

   - External

Under Contact Information, fill

   - your email address

Then, click Create. Your OAuth consent configuration has been created.

Step 2: Create OAuth Client IDs

From the OAuth consent dashboard, you can just click the create OAuth Client button, or go to APIs & Services → Credentials → Create Credentials → OAuth Client ID

Create three client IDs:

Web Client ID
Android Client ID
iOS Client ID

Even though we have three client IDs, we will only use the Web Client ID in the app. However, having the Android Client ID and iOS Client ID allows the Google Auth to work without error in our Android and iOS applications. Without them, Google authentication may fail or behave inconsistently on Android or iOS.

After creating the Web Client ID, copy it. It looks like this:


432096137304-vj6daolt1t0c7ta233ql9avcum9brt6q.apps.googleusercontent.com

Step 3: Store the Client ID in an Environment Variable

In the root of your project, create either

.env
or .env.local

Note: You do NOT need to install dotenv package; Expo already supports this.

Add your web client ID to the env file. It'll look like this:


EXPO_PUBLIC_CLIENT_ID=432096137304-vj6daolt1t0c7ta233ql9avcum9brt6q.apps.googleusercontent.com

Important
Take note of the prefix EXPO_PUBLIC_ , it is mandatory. This prefix tells Expo to expose the variable to the client at build time. Without it, Expo will NOT expose the variable to your app

Step 4: Install Google Sign-In Package

Run this in your terminal:


npm install @react-native-google-signin/google-signin

This installs the Google sign-in package required for our authentication to work.

Step 5: Create an Expo Development Build

As mentioned earlier, Expo Go does not support Google Sign-In, so now we need to run a development build following Expo's official documentation

https://docs.expo.dev/develop/development-builds/create-a-build/

Once the build is installed on your device/emulator, it is what we will use for testing.

Step 6: Configure Google Sign-In (Root Layout)

In your root layout or root component, configure Google Sign-In once when the app loads.


import { useEffect } from "react";
import { GoogleSignin } from "@react-native-google-signin/google-signin";

useEffect(() => {
  GoogleSignin.configure({
    webClientId: process.env.EXPO_PUBLIC_CLIENT_ID,
  });
}, []);

This tells Google which app is requesting authentication and which client ID to trust.

Step 7: Create the Google Sign-In Function

In your sign-in screen, create the function that triggers Google authentication.


import { GoogleSignin } from "@react-native-google-signin/google-signin";

const signInWithGoogle = async () => {
  try {
    await GoogleSignin.hasPlayServices();

    const user = await GoogleSignin.signIn();
    console.log(user);

  } catch (error: any) {
    console.log(error.message);
  }
};

What’s happening here?

hasPlayServices() checks if Google services are available
signIn() opens the Google account picker
Google returns a user object after successful login

Step 8: Use the User Object

After sign-in, Google returns a user object containing:

Email
Name
ID token
Profile picture

With this returned user object, you can do whatever you like with it. you can

Send the token to your backend
Create or authenticate users
Store the data securely, etc.

However, for the purpose of this guide, we only logged the user object in the console so you can always have a look at the returned structure. For now, logging it helps you confirm everything works.

Additional Tip:

While this guide uses Expo, the same Google Sign-In flow applies to bare React Native apps. The JavaScript logic remains the same, but bare React Native requires additional native configuration for Android and iOS, such as manual native setup and environment variable handling, which don’t come preconfigured in bare React Native.

Conclusion

Google authentication can seem tricky and hard when you don't know the right approach to implementing it. But I believe I've shown you that with the right guidance, Google authentication in React Native (Expo) isn't hard; you just need to follow the right setup. Once configured, it provides a fast, secure, and familiar login experience for users.

If you follow each step carefully, you’ll have Google Sign-In working smoothly in your app right now.

Have you run into Google Sign-In issues before? And did this post help simplify things for you?

If yes, drop a ❤️ or 🦄 reaction and follow me here on dev.to. I share more practical, plain-English breakdowns like this.

You can also connect with me on social media. I’d love to learn, share, and grow together with you!

LinkedIn: LinkedIn
Twitter: Twitter
Instagram: Instagram
Graphics Credit: LeadSync

[Boost]

Omotola Odumosu — Sat, 20 Dec 2025 17:24:18 +0000

Nigeria's Tax Reform 2025: What It Means for You (And Why TaxEngine Changes Everything)

Odumosu Matthew ・ Nov 20

#nigeria #tax #fintech #automation

Easily Convert your React Native Project To Desktop App

Omotola Odumosu — Thu, 06 Nov 2025 10:49:57 +0000

As someone who has gone through the emotional turmoil you are currently experiencing when it comes to building your react native projects to a desktop app, I totally understand your frustration, and because I've been in that position at one point in my life and made it out, I'm telling you, you will too, so just stick with me.

Now popularly React Native is popularly known for mobile development as it is a framework for React, which is a web development tool. Here comes the huddle using react native to build a Windows desktop (.exe or MSI) app. React Native has a broader library, which is "React native for Windows", which is basically for building desktop apps, but as you can testify to it, just like I did, the documentation is a little too thin, leaving us with more questions and confusion as opposed to solutions. Now here comes the approach I used to solve this big issue, and it got me unstuck and believing again. All the built-up tension from trying too many things and endless failed debugging mode came to an end, so I'll let you in on it if you're still with me as we go.

First things first, my approach is built on you developing your mobile apps as you normally would countless number of times, up to the point that you are ready to deploy as a desktop app in production or as a desktop app in development mode, but keep in mind, while you are building your app, make sure it works on the web as well. I mean, as you test your app in development mode on your physical devices or emulator, test on the web as well to ensure your app scales to the screen, as how your app views on the web is exactly how your desktop app will view. This is a prerequisite, so do it before coming to this post, so I can literally walk you through it myself. Now I will use an Expo managed project to explain this because I make use of Expo myself, but that doesn't mean this approach doesn't work on a bare react native workflow. I just haven't tried it yet, but I believe it should, so you can give it a try.

Step 1

If you get to this paragraph, that means you're ready for the next step (building your desktop app). Now, since your app works on the web in development mode, run

npx expo export

This command will build your app for Android, iOS, and the web. If this doesn't work for you, you can try

npx expo export:web

Note: This command requires having webpack installed in your project, else it won't work. So to install webpack, run

npm install @expo/webpack-config@^19.0.1 @pmmmwh/react-refresh-webpack-plugin@^0.5

This will install Webpack and make the build work successfully, but sometimes it might act up, so the first approach is easier.

If you encounter any error or your build wasn't successful, debug the error, make necessary corrections to your project, and rebuild.

If you got to this paragraph, it means your build was successful. Massive congratulations to you because you are 60% done already. Now let's proceed. Since your build was successful, check your project root folder. For people who used npx expo export, you should find a dist folder added to your folder structure, and for people who used npx expo export:web, you will see a web-build folder. These folders are important as they are the foundations of our desktop app, so confirm they exist in your project root directory.

Step 2

Since we now have the dist or web-build folder, proceed, we need to install Tauri and Rust. npm is also needed, but I don't think you can get to this stage if you don't have Node already working in your development environment. These are the packages that will make our journey seem like a walk in the park. It simplifies all the procedures. To download Rust, click the link below

click me to download Rust

Once downloaded, when you click on it to install, it opens a terminal with 3 options: choose the one that says install Rust with all of its dependencies. This is usually the third option, but the arrangement might change. Once the installation is complete, run

rustc --version

cargo --version

If your installation was successful, you should see their versions in your terminal; else try installing Rust again.

Step 3

Since we now have Rust installed globally on our development environment, we will be using Tauri to convert our app to an exe, leveraging the dist or web-build folder we generated in stage 1. To install Rust globally, run this command

windows

npm install -g @tauri-apps/cli

make sure you have Visual Studio Build Tools. I'm not sure if that is a requirement, but I have it on my device already sometimes back before running this Windows command, but you can try it without Visual Studio, and if it fails and the error message was relating to Visual Studio, then you can get it.

Linux

cargo install tauri-cli

And ensure you have dependencies like libwebkit2gtk and build-essential on your development environment.

macOS

brew install tauri-cli

Confirm if Tauri is installed successfully using this command

tauri -V

Step 4

In your project directory, run

npx tauri init

Once it initialises, it will ask you a few questions like

What is your app name?
What should the window title be?

(this means the name you want your exe file to be called)

Where are your web assets (HTML/CSS/JS) located, relative to the "/src-tauri/tauri.conf.json" file that will be created?

(Now this is very important; it is asking for the name of the folder we generated in step 1.) This question usually has a placeholder in front of it like ../build. Just delete the "build" and replace it with your own folder name, eg dist or web-build
so your answer should be like ../dist or ../web-build

What is the URL of your dev server?

(This means in development mode, when you try to run your project on the web, what was the host it loaded on). Your answer resembles something like http://localhost:3000. Just make sure the host you provide is where your project actually runs on

What is your frontend dev command?

(meaning, when you want to run your project in development mode, what command do you use). For Expo users, your answer should be like npm start
For bare react native users, just type the command you use

What is your frontend build command?

(This means what command do you use to build your project for production. Now just stick with whichever command you used in stage 1 that gave you your dist or web-build file. Stick with it because that command already proved to be successful with your project, so when Tauri runs it, it won't fail. Your answer should be like npx expo export or npx expo export:web or whatever you used.

After all these questions, check your project directory; you will see a newly added folder called src-tauri. Open it and go to the file tauri.conf.json. Look out for the key "identifier" it will look like this "identifier": "com.tauri.dev" the com.tauri.com is a placeholder, change it with your own. Your own identifier can be like com.yourname.yourappname. It wasn't that we generated this before, it is just a way of making our app unique, just like we are required to provide a packname for Android apps and bundleIdentifier for iOS . Save the file and click the Cargo.toml file while still inside the src-tauri folder look for this tauri-plugin-log = "2" and change it to tauri-plugin-log = "2.0.0" save the file and lastly navigate to your package.json file in your project root directory under the script key add "tauri": "tauri" so your package.json script should now look like this

"scripts": {
"start": "expo start",
"reset-project": "node ./scripts/reset-project.js",
"android": "expo start --android",
"ios": "expo start --ios",
"web": "expo start --web",
"lint": "expo lint",
"tauri": "tauri"
},

Now save the file.

Step 5

If you make it here, congratulations, you're almost done. All that remains is to run the command.

if you want to run in dev mode

npm run tauri dev

if you want to run in Production mode

npm run tauri build

Now, from here, your build should run successfully, and it might take a while for Rust to bundle all the required tools if you're using it for the first time. At this stage, I don't expect you to have any errors, but if you do, check the error message and try correcting whatever the process is complaining about. After a successful build, you should find your .exe and MSI path in this directory

(projectRootDirectory)\src-tauri\target\release\bundle\msi\wallora_0.1.0_x64_en-US.msi

(projectRootDirectory)\src-tauri\target\release\bundle\nsis\wallora_0.1.0_x64-setup.exe

Now I know it's taken a bit of our time getting here, but I'd say it's worth it, won't you agree? I know how frustrating the chaos, debugging, and not figuring out what to do to resolve a failure can be, which is why I took my time to take us through all the steps detailedly. Congratulations once again for reaching this part, and now that frustration is behind you.

Did this post help simplify things for you?

I hope this helped you a lot. If yes, drop a ❤️ or 🦄 reaction and follow me here on dev.to. I share more practical, plain-English breakdowns like this.

You can also connect with me on social media. I’d love to learn, share, and grow together with you!

LinkedIn: LinkedIn
Twitter: Twitter
Instagram: Instagram
Graphics Credit: mobilecoderz.com

Build Your React Native Project into an APK

Omotola Odumosu — Tue, 23 Sep 2025 09:09:10 +0000

As a React Native Developer, some time back in the course of my career, I could spin up an app from scratch: designing, coding, debugging, and everything ran smoothly in development. But when it came time to ship it as an APK, so I could share it? Here comes the Roadblock.

Honestly, it felt like building a whole house, installing a front door… and then realizing you can’t open it. Ridiculous, right? Yet, that’s exactly the challenge I faced.

So if you’re stuck at this same stage, don’t worry, you’re not alone. In this post, I’ll walk you through the exact process I learned (step by step) to successfully build your React Native project into an APK using Expo CLI & EAS.

Step 1: Install EAS CLI

First, install the Expo Application Services (EAS) CLI globally:


npm install -g eas-cli

👉 Docs: https://docs.expo.dev/build/setup/

If you’re on macOS and building for iOS, you’ll also need an Apple Developer account.

Step 2: Fix PowerShell Permissions (Windows Only)

Before running builds on Windows, allow PowerShell to execute EAS commands:


Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope Process

This command is only active for a session. Once you close your terminal/cmd prompt, you'll have to rerun the code to allow eas commands to execute. So you can run it in your project terminal

Step 3: Build with EAS

Run this command inside your React Native project:


eas build --platform android

For iOS, just replace Android with iOS (but it’ll prompt for your Apple Developer account).

👉 If the build fails, check your terminal for the error message and fix whatever is causing the failure from within your code and retry. After the build succeeds, your built file will be in .aab format, downloadable from the Expo dashboard or via the download link displayed in your terminal after the successful build.

Step 4: Download & Set Up BundleTool

Google requires AAB files for Play Store uploads, but for direct installation, we’ll need an APK. That’s where BundleTool comes in.

Download bundletool-all-x.x.x.jar from the official GitHub releases. Create a folder (e.g. on Desktop) and put both the .aab file and the BundleTool.jar inside.

👉 GitHub: https://github.com/google/bundletool/releases

Step 5: Getting your Signing Credentials

Unsigned APKs won’t install on devices. You’ll need your keystore credentials, but don't worry, while you were building your app with the "eas build" command in step 3, Expo already helped you create a keystore credential it used to convert our project into .aab file , now we just need that same credential to convert the .aab file to .apk file

Run in project root directory:


eas credentials --platform android

Follow the prompts to download credentials.json (contains passwords) and keystore.jks (binary file) by using the arrow key to select "Download credentials from EAS to credentials.json" from the available options. Once it is downloaded, keep these safe as they are very important.

Now navigate back to the folder you created earlier holding both the .aab file and the jar bundletool via your cmd prompt/terminal, build your signed APK with the credential details in credential.json file by running the code below:


java -jar bundletool-all-x.xx.x.jar build-apks --bundle=YOUR APP NAME.aab --output=YOUR APP NAME.apks --ks=PATH TO KEYSTORE.JKS FILE FROM PROJECT ROOT DIRECTORY --ks-key-alias=YOUR KEYSTORE ALIAS --ks-pass=pass:YOUR KEYSTORE PASSWORD --key-pass=pass:YOUR KEY PASSWORD --mode=universal

E.g.: your "ks path" in the code above should look like this:


--ks="C:\Users\Young\My Files\Coding\React Native Projects\ProductionReady\credentials\android\keystore.jks"

But ensure it is the correct path to your keystore.jks file in your project on your local device.

👉 Replace bundletool-all-x.xx.x.jar with your actual downloaded bundletool name up to its version e.g: bundletool-all-1.21.2.jar , and YourAppName.aab with your own AAB file name, the ks-key-alias with your own key alias, which can be found in the credentials.json file we generated in step 5. you should see the credentials.json file in your project root directory.

This step creates an .apks file (which is really just a ZIP file).

Step 6: Extract the Installable APK

Since .apks is really a ZIP, rename and extract the .apk file from it by running this code:


Rename-Item -Path YourApp.apks -NewName YourApp.zip
Expand-Archive -Path YourApp.zip -DestinationPath extracted-apks

Inside the new extracted-apks folder, you’ll find universal.apk 🎉. That’s your signed, installable APK, which you can install on your devices, share with friends, testers, etc.

Step 7: If You Update Your Code…

Whenever you make changes, just:

Push code to GitHub (to always have an updated version remotely)
Run eas build --platform android or ios, as the case may be
Convert the new AAB to APK following the same process

📌 Important Note on Play Store Uploads

For Google Play Store, you must upload the AAB file, not the APK.

The APK is mainly for testing, sharing, or sideloading.

Conclusion

If you’ve ever felt stuck after building a full React Native project but not being able to generate an APK, trust me, I’ve been there. It’s frustrating, but the solution is straightforward once you know the steps.

Now you can:

Build with EAS
Convert AAB → APK with BundleTool
Sign it properly with your keystore
Share or install it directly

💬 Did you face the same issue at any point in your career? Drop your experience in the comments, I’d love to hear!

Did this post help simplify things for you?

If yes, drop a ❤️ or 🦄 reaction and follow me here on dev.to. I share more practical, plain-English breakdowns like this.

You can also connect with me on social media. I’d love to learn, share, and grow together with you!

LinkedIn: LinkedIn
Twitter: Twitter
Instagram: Instagram

Clean Architecture in C#

Omotola Odumosu — Thu, 11 Sep 2025 07:29:18 +0000

As I continue my journey into backend development, one question keeps bugging me: Why can’t we just write all the logic inside the controller? It feels so simple. grabbing the data, applying some rules, and updating the database, all in one place. Oh, and I did, but I learnt it wasn't efficient for big companies, and you can't break into big companies with code like this, but I never really understood it or why

But here’s the reality: while that might be fine for a small side project, in large-scale applications (like financial systems) it quickly turns into chaos. That’s why big companies insist on using layered architecture. Splitting responsibilities into Controllers, Business Logic (Services), and Repositories.

For the longest time, I didn’t fully grasp why this separation mattered. I researched, experimented, and honestly struggled until it finally clicked. Once I understood, it completely changed how I think about structuring my software. And because I know many others are walking the same path, I want to share this knowledge in layman’s terms so it finally makes sense.

Let’s dive in with simple analogies, clear diagrams, and practical code to make it stick.

Think of Your App Like a Company

Layer	Who It Is	What It Does
Controller	Front Desk Clerk	Takes in requests and passes them along
Service	Bank Manager	Applies rules, makes decisions, enforces policy
Repository	Records Clerk	Fetches and updates records in the system
ILogger	Security Camera	Keeps a history of what happened (audits/logs)
Serilog/NLog	Storage Room	Decides where those logs are stored

The Flow (Diagram)


[ User Request ]

      ↓

[ Controller ] → Receives request and passes it along to the Services

      ↓

[ Service ] → Applies business rules and logic

      ↓

[ Repository ] → Talks to the database (fetching and updating details only)

Controller: The Front Desk

The controller is the entry point. It doesn’t make decisions or talk to the database; it just receives requests and forwards them.


[ApiController]

[Route("api/transfer")]

public class TransferController : ControllerBase

{

   private readonly ITransferService _service;



   public TransferController(ITransferService service)

   {

       _service = service;

   }



   [HttpPost]

   public IActionResult TransferMoney([FromBody] TransferRequest request)

   {

       _service.Transfer(request.FromAccount, request.ToAccount, request.Amount);

       return Ok("Transfer completed");

   }

}

Service: The Bank Manager

The service (business logic layer) applies rules. For example, “Does the sender have enough money to transfer?”


public class TransferService : ITransferService

{

   private readonly IAccountRepository _repository;

   private readonly ILogger<TransferService> _logger;



   public TransferService(IAccountRepository repository, ILogger<TransferService> logger)

   {

       _repository = repository;

       _logger = logger;

   }



   public void Transfer(string fromAcc, string toAcc, decimal amount)

   {

       var from = _repository.GetAccount(fromAcc);

       var to = _repository.GetAccount(toAcc);



       if (from.Balance < amount)

       {

           _logger.LogWarning("Insufficient funds for account {Account}", fromAcc);

           throw new Exception("Insufficient funds");

       }



       from.Balance -= amount;

       to.Balance += amount;



       _repository.UpdateAccount(from);

       _repository.UpdateAccount(to);



       _logger.LogInformation("Transferred {Amount} from {From} to {To}", amount, fromAcc, toAcc);

   }

}

Repository: The Records Clerk

The repository is where data access happens. No rules, no decisions, just reading and writing data.


public class AccountRepository : IAccountRepository

{

   private readonly BankingDbContext _context;

   private readonly ILogger<AccountRepository> _logger;



   public AccountRepository(BankingDbContext context, ILogger<AccountRepository> logger)

   {

       _context = context;

       _logger = logger;

   }



   public Account GetAccount(string accountId)

   {

       _logger.LogInformation("Fetching account {AccountId}", accountId);

       return _context.Accounts.FirstOrDefault(a => a.Id == accountId);

   }



   public void UpdateAccount(Account account)

   {

       _context.Accounts.Update(account);

       _context.SaveChanges();

       _logger.LogInformation("Updated account {AccountId}", account.Id);

   }

}

Logging: The Security Camera

In finance, logging is crucial. Every transaction, success, or error must be tracked. That’s where ILogger comes in.


_logger.LogInformation("Transaction {TransactionId} completed at {Time}", transaction.Id, DateTime.UtcNow);

_logger.LogError("Failed to process transaction {TransactionId}", transaction.Id);

But ILogger is just an interface. You still need a logging provider like Serilog or NLog to decide where to store those logs (file, cloud, DB, etc.).


// Program.cs setup example with Serilog

Log.Logger = new LoggerConfiguration()

   .WriteTo.File("logs/transactions.txt")

   .CreateLogger();



builder.Host.UseSerilog();

Summary: Who Does What

Layer	Responsibility	Analogy
Controller	Accepts requests and returns responses	Front Desk Clerk
Service	Applies business rules	Bank Manager
Repository	Handles data access	Records Clerk
ILogger	Records actions, errors, and audits	Security Camera
Serilog/NLog	Stores logs (file, DB, cloud, etc.)	Storage Room

Big Companies vs Small Projects

Small projects: You might mix everything in the controller. It works for a while.
Big companies: This structure is mandatory. It makes apps:
- Easier to test
- Easier to scale
- Easier to maintain
- Safer (especially for money-related systems)

View it this way:

If it’s about handling API requests → Controller
If it’s about rules, logic, or decisions → Service
If it’s about fetching or saving data → Repository
If it’s about tracking activity → ILogger (with Serilog/NLog to store it)

Final Thoughts

If you’re hacking together a side project, you can cut corners. But if you’re aiming to work in big companies or build software that can grow and last, this layered architecture is the foundation you must follow.

Always Think About: Front desk clerk, bank manager, records clerk, and security camera, each with their own role. This helps you remember and know under which classification/section a code is supposed to be. Keeping them separate makes your system stay clean, scalable, and professional.

Did this post help simplify things for you?

If yes, drop a ❤️ or 🦄 reaction and follow me here on dev.to. I share more practical, plain-English breakdowns like this.

You can also connect with me on social media. I’d love to learn, share, and grow together with you!

LinkedIn: LinkedIn
Twitter: Twitter
Instagram: Instagram
Graphics Credit: Ramesh Fadatare

Understanding SOLID Principles in Layman’s Terms

Omotola Odumosu — Fri, 29 Aug 2025 08:12:07 +0000

If you’ve ever felt like the SOLID principles sound too abstract, don’t worry; in this article we’ll break them down into simple, relatable examples with analogies. By the end, you’ll understand each one in a way you’ll never forget. Let’s dive in!

1. Single Responsibility Principle (SRP)
This means one class should only do one job. Think of your phone. You have a camera app to take pictures, you have a messaging app to send messages, and you have a music app to play songs.

Each app does one job well. If your camera app also tried to send messages and play music, it would become messy and hard to maintain.

In code terms, this means:

❌ Don’t do this:

✅ Do this:

Each class does one thing well, making it easier to maintain, test, and reuse.

2. Open/Closed Principle (OCP)

This means classes should be open for extension but closed for modification. In the sense that you should be able to add new features without changing existing code.

Example:
Imagine you have a payment system. Initially, it only supports credit cards.

Now, if you want to add PayPal, you’d need to edit the same class, which risks breaking existing code.

✅ Better approach:

Now you can extend by adding new classes instead of editing old ones.

3. Liskov Substitution Principle (LSP)

This is only saying that a subclass (child class) should be able to replace its parent class without breaking things.

Example with birds:

This breaks LSP. Even though Penguin is a bird, substituting it as a flying bird is wrong.

✅ Fix: Split responsibilities

Solution:

Bird = general parent class
FlyingBird = parent class for birds that fly
Eagle = subclass (child class) that can fly
Penguin = subclass (child class) that doesn’t fly

Now we can substitute any subclass correctly without confusion.

4. Interface Segregation Principle (ISP)

Here, although the principle name is like a combination of big words, here is what it simply means. Don’t force a class to implement things it doesn’t need.

Example:
Let’s say we have a Worker interface:

Now, we create a Robot class:

The robot is forced to implement Eat() even though it doesn’t need it.

✅ Fix: split into smaller interfaces:

Now a robot who is also a worker doesn’t need to implement Eat().

5. Dependency Inversion Principle (DIP)

This principle is saying we should rely on abstractions, not on concrete implementations, as it makes it easier to add features without breaking or modifying our existing code and ensures testing works flawlessly.

Example:
Imagine your phone and apps again. Your phone doesn’t care if you install WhatsApp, Telegram, or Signal. It just says, “I’ll allow any messaging app as long as it follows the rules.”

In code:

❌ Without DIP:

Here Notification is stuck with Email.

✅ With DIP:

Now you can swap email, SMS, or even WhatsApp without changing notifications.

Bonus: Why SOLID Matters So Much

It’s important to know that SOLID isn’t just about writing “good code.” This is like saying, "Your smartphone, even though it has multiple features like browsing, playing music, watching movies, etc., you just want to restrict to making/receiving calls." SOLID is more than that. It’s about writing maintainable, scalable, and flexible code that doesn’t break when you add new features. You might not know the magnitude of this when you're writing your code from the initial start, but a few years down the line when you have to maintain or add features to code another developer wrote, or even if you wrote it, if SOLID was applied at the inception of the code, you'll appreciate it massively because it'll make your work a lot easier.

By following SOLID, your code becomes easier to test, you reduce bugs, and you can adapt faster to changes

SOLID might look intimidating at first, but when you think about apps on your phone, birds that may or may not fly, and robots that don’t eat, it becomes much easier to digest.

Once you practice applying it, you’ll never forget it.

This is the layman’s guide to SOLID I promised. What do you think? Did I break it down enough for your easy assimilation? Drop your opinions in the comment section.

I remain Omotola Odumosu. Catch me on my socials below.

LinkedIn Account: LinkedIn
Twitter(X) Account: Twitter

🔐 ASP.NET Core Identity vs JWT (Without Identity)

Omotola Odumosu — Tue, 19 Aug 2025 10:42:42 +0000

Over the past few projects, I’ve had to make this exact choice: Do I go with ASP.NET Identity or roll my own JWT solution? Each comes with its pros and cons, and I’ve learned it really depends on the project and here’s how I usually view and explain it in simple terms

Imagine you’ve just moved into a new house. You need locks for your doors, and you have two options:

Option 1: ASP.NET Core Identity (The Professional Locksmith)

You call a locksmith (ASP.NET Identity).
They bring the lock, install it, and ensure it’s tamper-proof.
Every time you use the door, the lock automatically checks the key.
You don’t worry about the details, it just works, and it’s secure.

Less work for you, industry best practices, and battle-tested security.

Option 2: JWT Without Identity (Build Your Own Lock)

You decide to build your own lock (JWT without Identity).
You design how the keys are cut (hashing & storing passwords).
You decide how the lock works (generating JWTs).
Every time someone uses the door, you must check if the key really fits (manual validation).

More flexibility, but you carry the full responsibility for security.

The Trade-off

Use ASP.NET Identity if you want a secure, ready-made solution.

Use JWT without Identity if you need full control, but be prepared to handle every detail carefully.

💡 One lesson I’ve learned about ASP.NET Identity

It doesn’t always provide clear error handling out-of-the-box when signup or login fails. That leaves the client guessing what went wrong.

Here’s a better approach: Create a custom login or signup endpoint that wraps UserManager or SignInManager calls in a try-catch and returns clear error messages:

This way, your API communicates exactly why a login/signup failed instead of leaving the client in the dark.

Example of JWT without Identity (build-your-own lock)

On the flip side, if you choose the JWT without Identity route, you have to manually handle things like token creation and signing.

Here’s a simple example of generating a JWT:

This is the DIY (Do It Yourself) lock-making approach: you’re in control of how tokens are created, but you’re also responsible for keeping everything secure (keys, expiration, claims, etc.).

Industry Insight

I’ve noticed that larger enterprises often lean towards the JWT without Identity approach, since it gives them full control and the ability to fine-tune authentication to their unique business logic.

But at the end of the day, both approaches can keep your house (app) safe 🏡. The difference is whether you’d rather trust the locksmith or build your own lock system.

LinkedIn Account: LinkedIn
Twitter(X) Account: Twitter