DEV Community: FARINU TAIWO

Designing Fault-Tolerant Onboarding: How to Resume User Progress After Reinstall

FARINU TAIWO — Sun, 26 Apr 2026 19:41:51 +0000

When building a multi-role platform, onboarding is not a single problem. It is several distinct problems presenting themselves as one. The customer app experience is a clean five-screen flow. The rider app experience is far more demanding, spanning eight screens that cover identity verification, vehicle documentation, biometrics, and photo uploads. When the architecture is poorly designed, the impact goes beyond reduced conversion. It leads to real data loss when riders abandon the process midway and are forced to start again from the beginning.

Working across both experiences reveals a clear progression. The customer flow is straightforward and optimized for speed, while the rider onboarding introduces deeper complexity and stricter requirements. This article reflects that journey. It explores how I approach flow design, how I build systems that allow users to resume progress even after reinstalling the app, and how I evaluate the two dominant onboarding patterns used across the industry today.

The Real Problem with Multi-Step Onboarding

Designing the screens is not the hard part. Most teams can build a sequence of forms. The real challenge is handling interruption. Users rarely complete onboarding in one sitting. They get distracted, lose connection, their app crashes, their phone dies, or they simply decide to come back later. Sometimes, they uninstall and return weeks after.

In a simple customer flow, this interruption is manageable. Restarting the process costs only a few minutes. In a rider flow, it is a different story. By the time a user reaches the KYC stage, they have already verified their phone number, filled in personal details, and submitted vehicle information. If they are forced to start over because their session expired or their data was not preserved, the experience breaks down. What should have been a continuation becomes a reset, and that is where conversion is lost.

The goal is to make every completed step permanent. Not tied to a session, not tied to a device, but saved in a way that the user can always continue from where they stopped.

Apps like the Uber Driver handle this well. If you leave the onboarding process halfway and return a week later, logging back in takes you straight to where you stopped. Your details are still filled in, your documents remain uploaded, and the system clearly shows what is complete and what is still missing. This is the standard onboarding experience should aim for.

Pattern A - Gated Sequential Onboarding

The first pattern is the traditional approach. Each step after OTP acts as a gate, and the user cannot access the Home screen until every required step is completed. The onboarding behaves like a strict linear flow with no shortcuts or skipping.

The Server as the Source of Truth

The key architectural decision in this pattern is that onboarding state is fully managed on the backend. The app does not try to remember or infer the user’s progress. Instead, it asks the server what has been completed and what is still required, then navigates the user accordingly.

This means that after OTP verification, once an access token is issued, every app launch or login triggers a profile status request. The server responds with the user’s current onboarding state, and the app routes them to the correct step. A typical response might look like this:

// The backend contract - every field has clear meaning

class ProfileStatus {
  final bool isOtpVerified;
  final bool isProfileComplete;   // name, phone, address filled
  final bool isKycVerified;        // identity docs approved by ops
  final String? photoUrl;           // null = never uploaded
  final Vehicle? vehicle;            // null = vehicle not added yet

  const ProfileStatus({
    required this.isOtpVerified,
    required this.isProfileComplete,
    required this.isKycVerified,
    this.photoUrl,
    this.vehicle,
  });
}

Design your null states deliberately: photoUrl == null means "never uploaded". This is different from photoUrl == "" which could mean "uploaded then removed". vehicle == null means "never added" is different from a vehicle object with isDocVerified: false. Each null state carries information. Document these in your API contract.

The Destination Resolver

The logic that decides where to send the user after login is a simple waterfall. Every step is checked in order, and the first incomplete step wins. This function runs in your splash handler or post-login use case:

Future<void> _resolveOnboardingDestination(
  ProfileStatus status,
  BuildContext context,
) async {
  if (!status.isOtpVerified) {
    return _navigate(context, Routes.verifyOtp);
  }
  if (!status.isProfileComplete) {
    return _navigate(context, Routes.addInfo);
  }
  if (status.vehicle == null) {
    return _navigate(context, Routes.addVehicle);
  }
  if (!status.isKycVerified) {
    return _navigate(context, Routes.kyc);
  }
  if (status.photoUrl == null || status.photoUrl!.isEmpty) {
    return _navigate(context, Routes.addPhotos);
  }

  return _navigate(context, Routes.home);
}

This is the entire resumability logic. There is no local step counter, no tracking of the last screen visited, and no complex client-side state machine. The server simply returns a profile status object, and a single routing function translates that response into a navigation decision. Whether the user reinstalls the app, switches devices, or logs in from a web client, they always resume from the correct step because the source of truth lives on the server.

Local Cache as a Hint, Not the Source of Truth

Even with a server-driven approach, caching the last known profile status locally is still useful. Its purpose is not to determine flow, but to improve perceived performance by avoiding a loading state on every app launch.

The approach I use is to render the cached state immediately while a fresh request runs in the background. Once the server response arrives, the app reconciles and updates the UI if the state has changed:

Future<void> loadAndResolve(BuildContext context) async {
  // 1. Render cached route instantly (Better UX performance)
  final cachedRoute = await _prefs.getString('rider_last_route');

  if (cachedRoute != null && context.mounted) {
    _replaceCurrentRoute(context, cachedRoute);
  }

  // 2. Fetch fresh status from server (source of truth)
  final result = await _fetchRiderStatusUseCase.call();

  result.fold(
    (failure) => _handleError(failure),
    (status) async {
      final resolvedRoute = _resolveRoute(status);

      await _prefs.setString(AppKeys.lastRoute, resolvedRoute);

      // 3. Reconcile cached route with server truth
      final isStaleCache = resolvedRoute != cachedRoute;

      if (isStaleCache && context.mounted) {
        _replaceCurrentRoute(context, resolvedRoute);
      }
    },
  );
}

One important navigation rule - Every navigation inside the onboarding resolver must use pushAndRemoveUntil (or go with a full stack replacement in go_router). The user should never be able to press back from the Add Info screen and return to the Sign Up screen. Each completed step should be permanently removed from the navigation stack.

When to Choose Pattern A

Gated sequential onboarding is the right choice when:

The app cannot function without complete data. A rider cannot receive deliveries without an approved identity and a profile photo. Letting them reach Home serves no purpose.
Regulatory compliance requires it. KYC in financial apps and driver verification in delivery are often legally mandated before the user can transact.
The onboarding steps have natural dependencies - KYC often requires a completed profile; photo approval may require a verified identity. The dependency chain makes a linear gate sensible.

Pattern B - Home-First with Progressive Nudges

This pattern has become increasingly common in consumer apps over the last few years. After OTP verification and receiving an access token, the user is taken directly to the Home screen, often with partial access to features. The remaining onboarding steps are no longer blocking gates but are surfaced gradually through banners, nudges, or contextual prompts.

Apps like Duolingo use this approach effectively, and many early-stage fintech apps follow the same model. The underlying principle is simple: time to value is more important than completing all profile data upfront. Letting users experience the product immediately reduces drop-off at the registration stage.

Instead of forcing completion, additional profile information is collected progressively and in context, only when it becomes relevant to the user’s actions or needs.

The Architecture Shift

In this pattern, your onboarding state still lives on the backend and nothing changes there. What changes is the interpretation layer. Instead of redirecting the user to a form when the state is incomplete, the Home screen subscribes to the profile status and renders nudges accordingly:

class HomeScreen extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    final status = context.watch<RiderProfileProvider>().profileStatus;

    return Scaffold(
      body: Column(
        children: [
          // Nudges appear in priority order - most critical first
          if (!status.isProfileComplete)
            OnboardingNudge(
              icon: Icons.person_outline,
              message: 'Complete your profile to go online',
              onTap: () => context.push(Routes.addInfo),
            ),
          if (status.vehicle == null)
            OnboardingNudge(
              icon: Icons.directions_bike_outlined,
              message: 'Add your vehicle to start receiving orders',
              onTap: () => context.push(Routes.addVehicle),
            ),
          if (!status.isKycVerified)
            OnboardingNudge(
              icon: Icons.verified_user_outlined,
              message: 'Verify your identity to unlock all zones',
              onTap: () => context.push(Routes.kyc),
            ),

          // ... rest of home content
        ],
      ),
    );
  }
}

Nudges are prioritized in order of importance. The most critical missing requirement is shown first. As each item is completed, it is removed and the next one takes its place. There is no separate onboarding flow and no navigation reshuffling. The Home screen simply reacts to the same profile status object it already consumes.

Nudges as a Post-Launch Feature Delivery Mechanism

This is where Pattern B becomes especially powerful beyond initial onboarding. Nudges are not just onboarding tools; they become a way to introduce new requirements to existing users without disrupting their experience.

Imagine the rider app has been in production for six months. Early users were onboarded without vehicle insurance verification because it was not part of the original requirements. Now it becomes mandatory. In Pattern A, this creates friction. You either force users back into a gated flow or attempt to reroute them through a modified onboarding process, both of which are disruptive and error-prone.

In Pattern B, the solution is simpler. You introduce a new field in the backend profile response, and the app automatically adapts without requiring changes to the user’s current state or flow.

{
  "isProfileComplete": true,
  "isKycVerified": true,
  "vehicle": { "type": "motorcycle", "plate": "ABC-123" },
  "photoUrl": "https://cdn.example.ng/photos/rider_1234.jpg",

  // Newly added requirement - existing riders get false automatically
  "isInsuranceVerified": false
}

The Home screen checks isInsuranceVerified, renders a nudge if false, and presents the upload screen when tapped. Existing riders who have not completed it see the prompt at the top of their home screen. New riders see it as part of their natural nudge stack during onboarding. No forced logout, no breaking change, no re-onboarding flow to design.

This is also how you gate features by compliance tier. A rider without KYC can still browse the Home screen and view earnings history, but the “Go Online” button is disabled with a tooltip that says: “Verify your identity to go online.” The restriction is contextual rather than blocking. The user has already experienced the product’s value, which makes completing verification feel meaningful instead of bureaucratic.

Local State in Pattern B

In Pattern B, local state becomes more important because the UI needs to render immediately, even before the network call completes. This is what allows nudges to appear instantly on the Home screen while fresh profile data is still being fetched in the background.

To achieve this, you need a local persistence layer that can act as a fast, reactive cache. Any database can technically work, but lightweight embedded databases like Isar or ObjectBox are particularly well suited for this pattern. They provide reactive streams out of the box, making it easy for the UI to update automatically when cached onboarding state changes.

Future<void> loadProfileStatus() async {
  // Render stale data instantly - no loading spinner
  final cached = _localRepo.getProfileStatus();
  if (cached != null) {
    _status = cached;
    notifyListeners();
  }

  // Fetch fresh - correct and persist
  final result = await _fetchProfileStatusUseCase.call();
  result.fold(
    (failure) => _setError(failure),
    (fresh) {
      _status = fresh;
      _localRepo.saveProfileStatus(fresh);
      notifyListeners();
    },
  );
}

With this setup, the flow becomes:

Render cached onboarding state immediately
Subscribe to local database changes for reactive UI updates
Sync with the server in the background and overwrite stale state when fresh data arrives

This ensures the Home screen feels instant while still remaining fully consistent with the server as the source of truth.

When to Choose Pattern B

The home-first nudge approach is the right choice when:

Early user acquisition is the priority. The goal is to drive signups and activation, while encouraging profile completion through engagement rather than enforcing it through blocking gates.
The core value can be demonstrated with minimal user data. For example, a food ordering customer can browse restaurants and add items to a cart without providing a delivery address. That detail is only required at checkout.
You are building a platform expected to evolve over time. If compliance requirements are likely to increase, designing a nudge-based system from the start reduces significant rework later.
You also have early access users whose feedback is important. Even with partial profiles, you can still gather geographic distribution, engagement signals, and UX insights, all of which are valuable before the product reaches full maturity.

The Hybrid: Combining Both Patterns

In practice, the most thoughtful platforms are not purely one or the other. They use a layered approach: hard gates for the absolute minimum, nudges for everything else.

For Rider app specifically, a sensible split looks like this:

Step	Pattern	Reason
Phone + OTP verification	Gated	You need a verified identity to create any account at all
Full name + vehicle type	Gated	Minimum required to dispatch an order to a human rider
KYC document verification	Nudged	Required to go online, surfaced as a contextual prompt on Home
Profile photo upload	Nudged	Required for high-value order eligibility - shown after KYC
Vehicle insurance document	Nudged	Required for Zone B deliveries - new requirement, existing users prompted
Bank account for payouts	Nudged	Required to receive earnings - shown when rider first completes an order

Only enforce hard gates on data that makes it impossible for the core product to function. Everything else should be handled as a nudge, with contextual restrictions where necessary. When in doubt, prefer nudging. You can always tighten access later, but loosening a gate that has already frustrated users is much harder to recover from.

The Full Backend and Frontend Contract

Regardless of the onboarding pattern you choose, this contract is the most reliable foundation I have found across both apps. Think of it as the implementation checklist for building a truly resumable onboarding system.

Backend responsibilities

Every profile field must have a clearly defined state: null, empty, or populated. These meanings should be explicitly documented in the API contract and only changed through versioned migrations.
A single /me or /rider/status endpoint should return the full onboarding state. This endpoint is called on every app launch after login, so it must be optimized for speed and consistency.
All onboarding step endpoints must be idempotent. Submitting the same KYC document multiple times should not create duplicates or trigger errors.
The access token is issued immediately after OTP verification, not after full profile completion. This decision is what enables resumable onboarding in the first place.

The status endpoint should return granular boolean flags for each requirement rather than a single step index. A step counter only shows progress; it does not accurately represent what is actually missing.

Frontend responsibilities

On every app launch, after validating the token, the app must fetch the latest profile status before deciding navigation. Cached state alone should never determine routing.
Local cache can be used to render UI instantly, but only as a performance hint. The server response is always the source of truth and should correct any stale state.
A local step counter should never be used as the primary resume mechanism. It can drift out of sync when users switch devices or when backend actions update state outside the app.
Each onboarding screen should submit its own independent API call. There should be no single multi-step form submission. This ensures progress is persisted immediately as each step is completed.
Navigation within the onboarding flow must always reset the back stack. Users should not be able to navigate back from a deeper onboarding step to earlier authentication screens.

Closing Thoughts

The rider app is more difficult than the customer app, not because it has more screens, but because the cost of a poor onboarding experience is much higher. A customer who abandons signup can usually return without friction. A rider who drops off mid-KYC may never come back, and if they do, losing their progress is often enough reason to switch to another platform.

Building resumable, server-driven onboarding from day one is not overengineering. It is the baseline architecture for any serious multi-step flow.

Whether you choose to gate steps or use nudges is a product decision. It depends on your growth strategy, compliance requirements, and how much value your product can deliver before full verification. But the underlying infrastructure remains the same: idempotent APIs, well-defined state semantics, local caching as a performance hint rather than a source of truth, and a single resolver that translates profile state into navigation.

Design the backend contract with care. Build the resolver once. Everything else is just screens.

The Manifest You Never Wrote — A Flutter Developer's Guide to Android Manifest Merging

FARINU TAIWO — Wed, 22 Apr 2026 02:53:13 +0000

If you've been building Flutter apps for a while, you've probably touched your AndroidManifest.xml once during setup, added a permission or two when a plugin asked for it, and moved on. Flutter does a great job keeping Android complexity out of your way. But here's something worth knowing: the manifest you write is never actually the one that ships. By the time your app is packaged into an APK or AAB, Android's build system has quietly merged your manifest together with the manifest of every plugin in your pubspec.yaml. The result can look very different from what you started with.

That merged output is sitting in your build/ folder is what the Android OS reads, what users grant permissions against, and what Google Play's policy engine inspects on every upload. A plugin you added for image picking can silently pull in video and audio permissions you never intended to declare, and Play Console will flag them without mercy. This article walks you through how the merge works, how to read the merged output, and how to stay in control of what your app actually ships.

Here's everything we'll cover:

What Is Android Manifest?
The Merge Process Under the Hood
Where to Find the Merged Manifest
READ_MEDIA_*
Merge Tools And Markers
How Flutter Uses the Merged Manifest at Build Time
Why This Matters for Play Store Deployment

What Is Android Manifest?

Every Android application ships with a file called AndroidManifest.xml. It is the contract between your app and the Android OS. It declares who you are, what you need, and what you can do. Without it, your app simply cannot run.

In a Flutter project, yours lives at:

android/app/src/main/AndroidManifest.xml

At the top level, a manifest answers four fundamental questions the OS always asks:

Identity — <manifest>
Your app's package name (today mapped to applicationId in Gradle), version code, and version name live here. This is what uniquely identifies your app on a device and on the Play Store.
Permissions — <uses-permission>
Anything your app wants to access that belongs to the user or system, such as camera, location, storage, or internet, must be declared. Without a declaration, the runtime will deny the call even if the user tries to grant it manually.

<!-- Internet access — no runtime prompt needed -->
<uses-permission android:name="android.permission.INTERNET" />

<!-- Camera — triggers a runtime prompt on Android 6+ -->
<uses-permission android:name="android.permission.CAMERA" />

<!-- Fine location for GPS -->
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

Hardware Features — <uses-feature>
Declares hardware the app requires, such as a camera or GPS chip. Google Play uses these to filter which devices can install your app. Mark features as required="false" if they're optional enhancements.
Components — <application>
Registers every Android component your app uses: Activity, Service, BroadcastReceiver, ContentProvider. Flutter registers its own FlutterActivity here, and every plugin that uses a Service or a FileProvider adds its own entries too.

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

    <uses-permission android:name="android.permission.INTERNET"/>

    <application
        android:name="${applicationName}"
        android:label="App Name"
        android:icon="@mipmap/ic_launcher">

        <activity
            android:name=".MainActivity"
            android:exported="true"
            android:launchMode="singleTop">
            <intent-filter>
                <action android:name="android.intent.action.MAIN"/>
                <category android:name="android.intent.category.LAUNCHER"/>
            </intent-filter>
        </activity>
    </application>
</manifest>

The Merge Process Under the Hood

Here's the critical thing most developers miss: the manifest you write is never the manifest that ships. Android's build system (AGP — Android Gradle Plugin) merges manifests from every source in your project before packaging them into your APK or AAB.

Who contributes a manifest?

  [ Your App ] --------+
  app/src/main         |
                       |
  [ Build Variant ] ---+
  src/debug/release    |       (Manifest Merge)       [ Merged Manifest ]
                       +----------------------------→  What ships in 
  [ Flutter Plugins ]  |           processManifest     your APK
  Every pub.dev pkg    |
                       |
  [ AAR Libraries ] ---+
  Google/Firebase

The tool responsible is called the Manifest Merger, part of AGP. It runs during the processDebugManifest / processReleaseManifest Gradle task.

Merge priority order

Manifests are merged in a strict priority chain. Higher-priority entries win on conflicts:

Priority	Source	Description
Priority 1	App manifest	Your `android/app/src/main/AndroidManifest.xml`. Highest priority — always wins.
Priority 2	Build variant manifest	e.g. `src/staging/AndroidManifest.xml` — used for flavor-specific overrides.
Priority 3	Library / plugin manifests	Every package in your `pubspec` that has native Android code ships its own manifest. These are lowest priority and can be overridden.

Merge strategies

The merger applies a default strategy per element type. For most nodes, higher-priority entries win. For <uses-permission>, the union is taken — if any manifest declares a permission, it ends up in the final output.

1. merge (default)

Combines all attributes, preferring higher-priority source on conflicts. Most elements use this.

2. replace

Higher-priority element fully replaces the lower one. No attribute blending.

3. remove

Explicitly removes an element that a lower-priority manifest added. Your only way to un-declare a library's permission.

4. strict

Both manifests must declare the exact same value. Build fails otherwise. Good for enforcing consistency.

Permissions accumulate. Because permissions use a union strategy, adding a plugin is enough to add its permissions to your final APK — even if your Dart code never calls the relevant API. This is a common source of Play Store policy violations.

Where to Find the Merged Manifest

After any build, AGP writes the fully merged manifest to your build folder. This is the ground truth of what actually ships.

File location

android/app/build/intermediates/merged_manifests/<variant>/AndroidManifest.xml
For a typical Flutter project with debug/release:

android/app/build/intermediates/merged_manifests/debug/AndroidManifest.xml
android/app/build/intermediates/merged_manifests/release/AndroidManifest.xml

If you use flavors (e.g., staging, prod), each combination gets its own folder:

/merged_manifests/stagingRelease/AndroidManifest.xml
.../merged_manifests/prodRelease/AndroidManifest.xml

Merge report

AGP also writes a human-readable merge report that tells you exactly which library contributed each entry and why:

android/app/build/outputs/logs/manifest-merger-<variant>-report.txt

Android Studio shortcut: Open your source AndroidManifest.xml in Android Studio and click the Merged Manifest tab at the bottom of the editor. It renders the full merged file and shows the source of each element inline — indispensable for debugging.

After a Flutter build

Running flutter build apk or flutter build appbundle triggers the full Gradle build, which includes manifest merging. You can inspect the result immediately after:

# Build release AAB
flutter build appbundle --flavor prod --dart-define-from-file=env/prod.json

# Then inspect the merged manifest
cat android/app/build/intermediates/merged_manifests/prodRelease/AndroidManifest.xml

# Or search specifically for permissions
grep "uses-permission" android/app/build/intermediates/merged_manifests/prodRelease/AndroidManifest.xml

`READ_MEDIA_*`

This is one of the most common permission headaches in modern Flutter apps. Android 13 (API 33) split the old READ_EXTERNAL_STORAGE into granular media permissions. If you handle this wrong, your app either crashes on old devices, gets rejected on the Play Store, or worst silently ships permissions you never intended.

The old world (≤ Android 12)

One permission covered everything in external storage:

<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />

The new world (Android 13+, API 33+)

Android 13 introduced three scoped permissions. You only request what your app actually needs:

API Level	Permission	Description
API 33+	READ_MEDIA_IMAGES	Read images and photos from shared storage. Replaces READ_EXTERNAL_STORAGE for photos.
API 33+	READ_MEDIA_VIDEO	Read video files. Required only if your app accesses video — a chat app or media player, for instance.
API 33+	READ_MEDIA_AUDIO	Read audio files. Required only for music or voice note apps.

The trap: image_picker and other plugins

If you use image_picker, file_picker, or photo_manager, check their shipped manifests. Some older versions blanket-declare all three READ_MEDIA_* permissions even if your app only needs images. You'll find them added to your merged manifest without writing a single line yourself.

Here's what the merged manifest might look like for a basic profile photo only feature:

<!-- ✅ You declared this -->
<uses-permission android:name="android.permission.READ_MEDIA_IMAGES" />

<!-- ❌ image_picker added these — you never use video or audio! -->
<uses-permission android:name="android.permission.READ_MEDIA_VIDEO" />
<uses-permission android:name="android.permission.READ_MEDIA_AUDIO" />

<!-- Still needed for Android 12 and below -->
<uses-permission
    android:name="android.permission.READ_EXTERNAL_STORAGE"
    android:maxSdkVersion="32" />

Play Store policy alert. Declaring READ_MEDIA_VIDEO or READ_MEDIA_AUDIO on an app that has no video/audio feature triggers a Sensitive Permissions policy warning in Google Play Console. Your app may be rejected or removed. This is exactly the kind of issue you only catch by inspecting the merged manifest.

The fix: remove what you don't need

In your app’s manifest, use the tools:node="remove" attribute to explicitly remove unwanted permissions that may be coming from libraries or merged manifests. To use this feature, you must first declare the tools namespace in the manifest root.

This allows you to cleanly remove specific permissions without modifying the library that added them.

<manifest
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools">

    <!-- Only images needed for profile photo -->
    <uses-permission android:name="android.permission.READ_MEDIA_IMAGES" />

    <!-- Constrain READ_EXTERNAL_STORAGE to Android 12 and below -->
    <uses-permission
        android:name="android.permission.READ_EXTERNAL_STORAGE"
        android:maxSdkVersion="32" />

    <!-- Remove VIDEO permission added by image_picker -->
    <uses-permission
        android:name="android.permission.READ_MEDIA_VIDEO"
        tools:node="remove" />

    <!--  Remove AUDIO permission added by image_picker -->
    <uses-permission
        android:name="android.permission.READ_MEDIA_AUDIO"
        tools:node="remove" />

    ...
</manifest>

Merge Tools and Markers

The xmlns:tools namespace acts as your control panel for the manifest merge process. It allows you to add special instructions to manifest elements that tell the Android manifest merger exactly how to handle them. These instructions override the default merge behavior and give you direct control over the final merged manifest.

tools:node — control the element itself

<!-- Remove an element a library added -->
<uses-permission
    android:name="android.permission.RECORD_AUDIO"
    tools:node="remove" />

<!-- Replace a library's activity declaration entirely -->
<activity
    android:name="com.some.lib.SomeActivity"
    tools:node="replace">
    <!-- your overridden content -->
</activity>

<!-- Merge children but not attributes -->
<application
    tools:node="mergeOnlyAttributes">
    ...
</application>

tools:attr — control individual attributes

Sometimes you need finer control — just override a single attribute from a library without replacing the whole element:

<!-- Force our label, ignore what the library set -->
<activity
    android:name="com.some.lib.SomeActivity"
    android:label="@string/app_name"
    tools:replace="android:label" />

<!-- Remove just the theme attribute, keep everything else -->
<activity
    android:name="com.some.lib.OtherActivity"
    tools:remove="android:theme" />

android:maxSdkVersion — scoping permissions by OS version

This is not a tools: attribute. It is a native Android attribute that tells the OS to automatically revoke the permission on devices running a newer API level. It's the correct way to handle the READ_EXTERNAL_STORAGE to READ_MEDIA_* migration:

<!-- Grant READ_EXTERNAL_STORAGE only on Android 12 (API 32) and below.
     On Android 13+, the granular READ_MEDIA_* permissions take over. -->
<uses-permission
    android:name="android.permission.READ_EXTERNAL_STORAGE"
    android:maxSdkVersion="32" />

<!-- Similarly, WRITE_EXTERNAL_STORAGE has been a no-op since API 29.
     Constrain it to avoid unnecessary permission requests. -->
<uses-permission
    android:name="android.permission.WRITE_EXTERNAL_STORAGE"
    android:maxSdkVersion="28" />

How maxSdkVersion actually works. It's enforced at install time and at system update time. When a user updates their OS from Android 12 to 13, the OS automatically revokes the permission for apps that declared maxSdkVersion="32". Your app never needs to hold the old permission on a new OS version.

tools:ignore — silence false-positive merge warnings

If you intentionally declare something that triggers a merger warning, suppress it cleanly rather than leaving the warning in CI output:

<application
    android:allowBackup="false"
    tools:ignore="GoogleAppIndexingWarning,MissingApplicationIcon">
    ...
</application>

How Flutter Uses the Merged Manifest at Build Time

Understanding the build pipeline helps you know exactly when and where the manifest merge happens relative to your Dart code and assets.

flutter build      Dart compile       Gradle assemble      processManifest      package / sign
CLI entry point  → AOT kernel      →  AGP kicks in     →   Manifest merge  →    APK / AAB output

Flutter's Gradle plugin (flutter.gradle) executes the full Android build chain. The Dart compilation happens first, producing a snapshot that is bundled as native assets. Then Gradle takes over and performs the standard Android build — including manifest merging as part of process<Variant>Manifest.

Flutter plugin registration contributes to the manifest

When you run flutter pub get, Flutter's tooling auto-generates the GeneratedPluginRegistrant class and also ensures each plugin's android/src/main/AndroidManifest.xml is registered as a library manifest source with Gradle. This is why you don't need to manually add plugin permissions — they merge in automatically. But it also means they merge in whether you want them to or not.

Flavors and the manifest per build variant
In a repo with dev, staging, and prod flavors, each flavor can have its own source set manifest:

android/app/src/dev/AndroidManifest.xml — dev-only debug overrides

android/app/src/staging/AndroidManifest.xml — staging environment flags

android/app/src/prod/AndroidManifest.xml — production, minimal, clean

A common pattern is to put android:usesCleartextTraffic="true" only in the dev manifest (so it never ships to prod), and to declare android:debuggable="false" explicitly in the prod manifest as a safeguard.

<manifest xmlns:android="http://schemas.android.com/apk/res/android">
    <application
        android:usesCleartextTraffic="true"
        android:networkSecurityConfig="@xml/network_security_config_dev"/>
</manifest>

Why This Matters for Play Store Deployment

Google Play Console runs its own manifest analysis on every AAB you upload. It extracts the final merged manifest and cross-checks it against multiple policy layers. Unintended permissions in your merged manifest are one of the top reasons for pre-launch warnings, policy violations, and outright rejections.

Common Play Store issues caused by the merged manifest

Issue in Play Console	Root Cause in Manifest	Fix
Sensitive permissions warning	Plugin added `READ_MEDIA_VIDEO` or `READ_MEDIA_AUDIO` you don't need	`tools:node="remove"`
Broad storage access policy	`READ_EXTERNAL_STORAGE` without `maxSdkVersion` — triggers review for API 33+	Add `maxSdkVersion="32"`
MANAGE_EXTERNAL_STORAGE requires declaration	A plugin declares this without your knowledge — it requires a special Play Store form	`tools:node="remove"` unless needed
Background location without foreground	Library adds `ACCESS_BACKGROUND_LOCATION` — needs explicit policy approval	Remove if unused; otherwise file declaration form
QUERY_ALL_PACKAGES policy	Some plugins query all installed packages — requires justification	`tools:node="remove"` if avoidable
Uses-feature incompatibility	Plugin declares a required hardware feature, filtering out valid device categories	Override with `required="false"`
Cleartext traffic in production	`usesCleartextTraffic="true"` leaking from a dev-flavored manifest into a prod build	Scope to dev flavor manifest only

Pre-submission checklist

Before uploading any AAB to Play Console, run through these steps:

1. Build and inspect.

Run flutter build appbundle --flavor prod and open the merged manifest. Use grep "uses-permission" to get a clean list of all declared permissions.

2. Audit against features.

For every permission in the merged manifest, ask: Does my app actually use this? If not, remove it with tools:node="remove".

3. Scope storage permissions.

Ensure READ_EXTERNAL_STORAGE has maxSdkVersion="32" and WRITE_EXTERNAL_STORAGE has maxSdkVersion="28".

4. Read the merge report.

Check build/outputs/logs/manifest-merger-prodRelease-report.txt for any merge conflicts flagged as errors or warnings — fix them before upload.

5. Cross-check with Play Console's App Content section.

If you declare any sensitive permissions, ensure your privacy policy and data safety form are updated to reflect them. Undeclared data collection is a separate but related violation.

Add manifest inspection to your CI pipeline. In your GitHub Actions release workflow, after flutter build appbundle, add a step that greps the merged manifest for a blocklist of sensitive permissions. Fail the job if any appear unexpectedly before the AAB ever reaches Play Console.

.github/workflows/release.yml

- name: Audit merged manifest permissions
  run: |
    MANIFEST="android/app/build/intermediates/merged_manifests/prodRelease/AndroidManifest.xml"
    BLOCKLIST=(
      "READ_MEDIA_VIDEO"
      "READ_MEDIA_AUDIO"
      "MANAGE_EXTERNAL_STORAGE"
      "ACCESS_BACKGROUND_LOCATION"
      "QUERY_ALL_PACKAGES"
    )
    for perm in "${BLOCKLIST[@]}"; do
      if grep -q "$perm" "$MANIFEST"; then
        echo "❌ BLOCKED: $perm found in merged manifest!"
        exit 1
      fi
    done
    echo "✅ No blocked permissions found"

Conclusion

Your source AndroidManifest.xml is the beginning of the story, not the end. Every plugin you add such as image_picker, geolocator, firebase_messaging, and camera ships its own manifest, and those entries silently merge into yours at build time.

The merged manifest in your build/ folder is the only version that matters. It is what the OS installs, what Play Console reviews, and what users grant permissions against. Making it a regular part of your release workflow by building it, reading it, and asserting on it in CI is one of the highest leverage habits you can build as a Flutter developer shipping to Android.

Why String.fromEnvironment() Might Return an Empty String in Dart

FARINU TAIWO — Thu, 16 Apr 2026 06:23:25 +0000

A complete guide to why String.fromEnvironment() silently returns an empty string when used with final, what Dart is actually doing under the hood, and how to structure your environment configuration so it can never happen again, from local development all the way to production builds.

I ran into this issue myself while working on a service class where I used String.fromEnvironment() with a final variable to read my API base URL. Everything compiled successfully, there were no warnings, and the code looked perfectly valid. But when the app ran, the value kept resolving to an empty string. Nothing explicitly failed, the application simply behaved as if the configuration was missing.

The only way I was able to trace the issue was through debugging, where I eventually discovered what Dart was actually doing under the hood. If you have ever experienced a mysteriously empty environment variable or want to make sure this subtle bug never happens in your project, this article is for you.

final vs const

Both final and const prevent a variable from being reassigned after it has been given a value. That is the only similarity between them. Apart from that, they behave differently in almost every other way.

final — assigned once at runtime

A final variable is assigned once and cannot be changed after that. However, its value is determined at runtime when the code is executed. This means the value can come from a function call, a network response, user input, or any other data available while the app is running.

// All of these are valid final assignments
final timestamp = DateTime.now();          // computed at runtime
final name = prefs.getString('name');      // read from disk at runtime
final url = computeBaseUrl();              // result of a function at runtime

const — a compile-time constant

A const value must be fully determined before the app is compiled. The Dart compiler evaluates it, checks it, and embeds the result directly into the compiled binary. It does not exist as a runtime object in memory. Instead, it is stored as a fixed literal inside the generated machine code.

// These are compile-time constants
const pi = 3.14159;
const appName = 'Clock App';
const timeout = Duration(seconds: 30);

// This is NOT valid, DateTime.now() is only known at runtime
const now = DateTime.now(); // compile error

String.fromEnvironment()

Looking at the Dart SDK source, String.fromEnvironment() is declared like this:

// From the Dart SDK — dart:core
abstract class String {
  external const factory String.fromEnvironment(
    String name, {
    String defaultValue = '',
  });
}

Three things in that signature matter enormously:

const factory — it is a const constructor. The Dart spec says a const constructor can only produce a meaningful value when called in a const context.
external — the actual implementation is provided by the compiler toolchain, not by Dart code. When the compiler sees a const invocation, it substitutes the value from --dart-define. There is no runtime implementation that reads environment variables.
defaultValue: '' — if the compiler finds no substitution to make, it uses the default. Silently. No error, no warning.

String.fromEnvironment does not actually read any values at runtime. It is a compiler directive that looks like a constructor call. During compilation, the Dart compiler replaces it with a plain string literal. By the time the app runs, there is no special logic left, only the final string value as if it had been written directly in the source code.

The two evaluation paths

When the Dart compiler encounters String.fromEnvironment('UPLOAD_URL'), it takes one of two paths depending on the call context:

Call is in a const context
The compiler looks up UPLOAD_URL in the --dart-define flags. If found, it substitutes the literal string value into the binary. If not found, it substitutes '' (the default). Either way, the value is resolved at at compile time.
Call is in a final or non-const context
The compiler sees a regular constructor call and defers it to runtime. At runtime there is no mechanism to read --dart-define flags because those were consumed during compilation. The constructor returns its defaultValue, which is ''. Every single time.

// What the compiler does with const:
static const baseUrl = String.fromEnvironment('UPLOAD_URL');
//  compiler substitutes at build time
static const baseUrl = 'https://upload.example.com';

// What happens with final:
static final baseUrl = String.fromEnvironment('UPLOAD_URL');
//  deferred to runtime  --dart-define is gone
static final baseUrl = ''; // defaultValue returned every time

Why it is so hard to debug: static final compiles without error. The analyser produces no warning. Your app launches normally. The empty string only surfaces when a network request silently fails, far from the actual cause, with no stack trace pointing back to the declaration.

The same rule applies to all three environment constructors

This is not specific to String.fromEnvironment. All three environment constructors in Dart share the same external const factory signature and behave identically:

Type	Method	Description	Default Value
`String`	`String.fromEnvironment('KEY', defaultValue: '')`	Reads a string value from environment variables	`''` (empty string)
`bool`	`bool.fromEnvironment('KEY', defaultValue: false)`	Reads a boolean value from environment variables	`false`
`int`	`int.fromEnvironment('KEY', defaultValue: 0)`	Reads an integer value from environment variables	`0`

All three must be called in a const context to produce any value other than their default. Using final with any of them gives you the default silently.

// Every one of these will silently return its default with 'final'
static final apiUrl    = String.fromEnvironment('API_URL');     // ''
static final debugMode = bool.fromEnvironment('DEBUG_MODE');   // false
static final version   = int.fromEnvironment('APP_VERSION');   // 0

// All three correct with 'const'
static const apiUrl    = String.fromEnvironment('API_URL');     // your URL
static const debugMode = bool.fromEnvironment('DEBUG_MODE');   // true/false
static const version   = int.fromEnvironment('APP_VERSION');   // your int

This is written in the String.fromEnvironment documentation:

This constructor is only guaranteed to work when invoked as const. It may work as a non-constant invocation on some platforms which have access to compiler options at run-time, but most ahead-of-time compiled platforms will not have this information.

How to structure your environment config correctly

Rather than spreading String.fromEnvironment calls across your codebase where any of them could mistakenly use final, keep all environment access in one place. Create a single class responsible for it and ensure this is the only place in your entire project where fromEnvironment is used.

abstract class AppEnv {

  // API endpoints 
  static const apiBaseUrl = String.fromEnvironment('API_BASE_URL');
  static const uploadUrl = String.fromEnvironment('UPLOAD_URL');
  static const socketUrl = String.fromEnvironment('SOCKET_URL');

}

Because the class is abstract, it cannot be instantiated. Every field is static const, which makes misuse (calling them on an instance, or shadowing them with final) structurally impossible. Any other service in the project references it directly:

// lib/core/network/upload_service.dart

class UploadService {
  // No fromEnvironment call here, always go through AppEnv
  static const _baseUrl = AppEnv.uploadUrl;

  static Future<dynamic> request({ ... }) async {
    final uri = Uri.parse('$_baseUrl$endpoint');
    // ...
  }
}

Enable the lint rule so the analyser catches this automatically

Dart's prefer_const_declarations lint rule will flag any final variable whose value is a compile-time constant, including all three fromEnvironment constructors. This turns a silent runtime bug into a compile-time analyser warning.

# analysis_options.yaml
linter:
  rules:
    prefer_const_declarations: true
    prefer_const_constructors: true
    prefer_const_literals_to_create_immutables: true

This will immediately show a warning in your IDE:

//  Lint: Prefer const with constant initialized variables.
// Replace 'final' with 'const'.
static final baseUrl = String.fromEnvironment('UPLOAD_URL');

The env file setup

Correct file structure
The file must be a flat JSON object. No nesting. Keys match exactly what you pass to fromEnvironment.

// env.json - flat, no nesting, exact key names
{
  "API_BASE_URL": "https://api.example.com",
  "UPLOAD_URL": "https://upload.example.com",
  "SOCKET_URL": "wss://socket.example.com",
  "BUILD_ENV": "production",
  "ENABLE_ANALYTICS": "true",
}

Note: All values in the JSON must be strings including booleans and integers. Dart's toolchain reads them as strings and performs the type conversion internally. "false" not false, "12" not 12.

The four rules to remember

#	Rule	Description
1	Always `const`	`fromEnvironment` is a compiler directive. Use `static const`. Always. No exceptions.
2	Centralise	Call `fromEnvironment` in exactly one file (`AppEnv`). Everywhere else imports from there.
3	Enable the lint	Add `prefer_const_declarations: true` to `analysis_options.yaml`. Let the analyser enforce rule 1.
4	Flat JSON	Your `env.json` must be a flat `{ "KEY": "value" }` object. No nesting. All values are strings.

Flutter Widget Design: Write Once, Reuse Everywhere

FARINU TAIWO — Sun, 05 Apr 2026 17:44:52 +0000

UIs in Flutter are built from widgets, and as an app grows the number of widgets in the codebase grows with it. Because of this, designing widgets well becomes essential. Good widgets should be declarative, focused, and responsible for doing one thing well so the UI layer stays simple. The way widgets are structured largely determines whether a codebase remains clean and scalable or gradually becomes difficult to maintain.

The underlying widget system is intentionally simple. Everything is a widget, widgets compose together, and the UI is rebuilt from state. Internally, widgets are lightweight configurations that describe the UI, while the render tree performs the actual layout and painting. This design makes rebuilding inexpensive, but it also requires developers to be intentional about component design. The real challenge is creating widgets that are truly reusable: components that accept only the data they need, render it, and emit events upward without depending on where they are used or which state management sits above them. Ultimately, well-designed Flutter widgets are independent, data-driven, event-based, and built for reusability.

Prefer Parameters Over Hardcoded Values

The most common mistake is embedding values directly in a widget. Colors, sizes, strings, and padding cannot adapt if they are hard coded."

// ❌ Don't do this
class PrimaryButton extends StatelessWidget {
  final String label;

  const PrimaryButton({super.key, required this.label});

  @override
  Widget build(BuildContext context) {
    return ElevatedButton(
      style: ElevatedButton.styleFrom(
        backgroundColor: Colors.blue,      // ❌ hardcoded colour
        minimumSize: const Size(double.infinity, 52), // ❌ hardcoded size
        shape: RoundedRectangleBorder(
          borderRadius: BorderRadius.circular(8),  // ❌ hardcoded radius
        ),
      ),
      onPressed: () {}, // ❌ no-op — caller can't respond
      child: Text(label),
    );
  }
}

This widget above is an example of a rigid button.
This button looks reusable, but it is not because every visual property is built in.

Now here's how to fix it. Every dimension, colour, and behaviour must flow in as a parameter:

class AppButton extends StatelessWidget {
  const AppButton({
    super.key,
    required this.label,
    required this.onPressed,
    this.isLoading = false,
    this.isDisabled = false,
    this.backgroundColor,
    this.textColor,
    this.borderRadius = 10.0,
    this.height = 52.0,
    this.width = double.infinity,
    this.icon,
  });

  final String label;
  final VoidCallback? onPressed;
  final bool isLoading;
  final bool isDisabled;
  final Color? backgroundColor;
  final Color? textColor;
  final double borderRadius;
  final double height;
  final double width;
  final Widget? icon;

  @override
  Widget build(BuildContext context) {
    final theme = Theme.of(context);
    final effectiveColor = backgroundColor ?? theme.colorScheme.primary;
    final isActive = !isDisabled && !isLoading;

    return AnimatedOpacity(
      duration: const Duration(milliseconds: 200),
      opacity: isActive ? 1.0 : 0.55,
      child: SizedBox(
        height: height,
        width: width,
        child: ElevatedButton(
          onPressed: isActive ? onPressed : null,
          style: ElevatedButton.styleFrom(
            backgroundColor: effectiveColor,
            foregroundColor: textColor ?? theme.colorScheme.onPrimary,
            shape: RoundedRectangleBorder(
              borderRadius: BorderRadius.circular(borderRadius),
            ),
          ),
          child: isLoading
              ? SizedBox(
                  width: 20,
                  height: 20,
                  child: CircularProgressIndicator(
                    strokeWidth: 2,
                    color: textColor ?? theme.colorScheme.onPrimary,
                  ),
                )
              : Row(
                  mainAxisSize: MainAxisSize.min,
                  children: [
                    if (icon != null) ...[icon!, const SizedBox(width: 8)],
                    Text(label),
                  ],
                ),
        ),
      ),
    );
  }
}

Notice how backgroundColor falls back to theme.colorScheme.primary. When a caller doesn't pass a colour, you get the theme's primary. When they do, you get exactly what they passed. Defaults first, overrides second.

Isolate business logic with callbacks

A reusable widget must not know what happens when it is interacted with. It only knows that something happened and reports it upward. All logic lives in the parent, provider, or use case but never in the widget itself.

An example is a product card that includes action buttons such as Add to Cart, a favorite icon, and onTap functionality.

class ProductCard extends StatelessWidget {
  const ProductCard({
    super.key,
    required this.product,
    required this.onTap,
    required this.onAddToCart,
    this.onToggleWishlist,
    this.isWishlisted = false,
  });

  final ProductModel product;
  final VoidCallback onTap;
  final VoidCallback onAddToCart;
  final VoidCallback? onToggleWishlist;
  final bool isWishlisted;

  @override
  Widget build(BuildContext context) {
    return GestureDetector(
      onTap: onTap,
      child: Card(
        child: Column(
          children: [
            Stack(children: [
              ProductImage(url: product.imageUrl),
              if (onToggleWishlist != null)
                WishlistIcon(
                  isFilled: isWishlisted,
                  onTap: onToggleWishlist!,
                ),
            ]),
            ProductInfo(product: product),
            AppButton(
              label: 'Add to cart',
              onPressed: onAddToCart,
            ),
          ],
        ),
      ),
    );
  }
}

Usage

ProductCard(
  product: product,
  isWishlisted: context.watch<WishlistProvider>().contains(product.id),
  onTap: () => context.push('/product/${product.id}'),
  onAddToCart: () => context.read<CartProvider>().add(product),
  onToggleWishlist: () => context.read<WishlistProvider>().toggle(product),
);

Composition over inheritance

Flutter explicitly favours composition. Instead of subclassing a widget to add features, build small focused widgets and compose them. This keeps each piece testable, readable, and independently reusable.

Although the section header is a simple widget, it can be broken down into three separate widgets.

// Three small, composable widgets

class SectionHeader extends StatelessWidget {
  const SectionHeader({
    super.key,
    required this.title,
    this.action,
  });

  final String title;
  final Widget? action;

  @override
  Widget build(BuildContext context) {
    return Row(
      mainAxisAlignment: MainAxisAlignment.spaceBetween,
      children: [
        Text(title, style: Theme.of(context).textTheme.titleMedium),
        if (action != null) action!,
      ],
    );
  }
}

class SeeAllButton extends StatelessWidget {
  const SeeAllButton({super.key, required this.onTap});
  final VoidCallback onTap;

  @override
  Widget build(BuildContext context) {
    return GestureDetector(
      onTap: onTap,
      child: Text('See all', style: TextStyle(color: Theme.of(context).primaryColor)),
    );
  }
}

// Compose them freely at call sites
SectionHeader(
  title: 'Popular Restaurants',
  action: SeeAllButton(onTap: () => context.push('/restaurants')),
);

You can notice that action is nullable because some section headers do not have an action button like See all.

Provide sensible defaults

A button that needs 12 parameters just to render is hard to use. Instead, use optional parameters with default values for the most common case. People using the widget should only have to provide what is different for their situation.

Every required parameter is friction. If a value has a sensible default, make it optional. Aim for your widget to be usable with one or two parameters in the most common case, while still allowing overrides for less common scenarios.

Let’s take, for example, an empty state widget.

class EmptyState extends StatelessWidget {
  const EmptyState({
    super.key,
    this.title = 'Nothing here yet',
    this.subtitle = 'Check back later.',
    this.icon = Icons.inbox_outlined,
    this.iconSize = 64.0,
    this.action,
  });

  final String title;
  final String subtitle;
  final IconData icon;
  final double iconSize;
  final Widget? action;

  @override
  Widget build(BuildContext context) { ... }
}

// Minimal usage, defaults handle the rest
const EmptyState()

// Context-specific override
EmptyState(
  title: 'No orders yet',
  subtitle: 'Your completed orders will appear here.',
  icon: Icons.receipt_long_outlined,
  action: AppButton(label: 'Browse restaurants', onPressed: onBrowse),
)

Handling theming and responsive sizing

Hardcoded pixel values are the silent killer of cross-device consistency. Always pull colours from Theme.of(context) and sizes from a responsive utility (like flutter_screenutil) or define them via ThemeData extensions.

class AppChip extends StatelessWidget {
  const AppChip({
    super.key,
    required this.label,
    this.isSelected = false,
    this.onTap,
  });

  final String label;
  final bool isSelected;
  final VoidCallback? onTap;

  @override
  Widget build(BuildContext context) {
    final theme = Theme.of(context);
    final colorScheme = theme.colorScheme;

    return GestureDetector(
      onTap: onTap,
      child: AnimatedContainer(
        duration: const Duration(milliseconds: 180),
        padding: EdgeInsets.symmetric(
          horizontal: 14.w,  // responsive via screenutil
          vertical: 8.h,
        ),
        decoration: BoxDecoration(
          color: isSelected ? colorScheme.primary : colorScheme.surface,
          border: Border.all(
            color: isSelected ? colorScheme.primary : colorScheme.outline,
          ),
          borderRadius: BorderRadius.circular(100),
        ),
        child: Text(
          label,
          style: theme.textTheme.labelMedium?.copyWith(
            color: isSelected ? colorScheme.onPrimary : colorScheme.onSurface,
            fontWeight: isSelected ? FontWeight.w600 : FontWeight.w400,
          ),
        ),
      ),
    );
  }
}

Common anti-patterns to avoid

Designing reusable widgets is not only about following best practices, it is also about avoiding patterns that quietly make a codebase harder to maintain. Many widget problems do not appear immediately, but over time they lead to rigid components, duplicated logic, and difficult refactoring.

Below are some common anti patterns that often appear in Flutter codebases as they grow.

Building God widgets

A widget that renders a product card, handles pagination, manages a search bar, and displays error states is not reusable. It is a screen masquerading as a component. Split it. Each widget should do one thing and do it well.

For example, a “god widget” might look like this:

class ProductWidget extends StatefulWidget {
  const ProductWidget({super.key});

  @override
  State<ProductWidget> createState() => _ProductWidgetState();
}

class _ProductWidgetState extends State<ProductWidget> {
  final TextEditingController searchController = TextEditingController();
  List<Product> products = [];
  bool isLoading = false;
  String? error;

  Future<void> fetchProducts({int page = 1}) async {
    setState(() => isLoading = true);

    try {
      final result = await Api.fetchProducts(
        query: searchController.text,
        page: page,
      );

      setState(() {
        products = result;
        error = null;
      });
    } catch (e) {
      error = "Failed to load products";
    }

    setState(() => isLoading = false);
  }

  @override
  Widget build(BuildContext context) {
    if (isLoading) {
      return const CircularProgressIndicator();
    }

    if (error != null) {
      return Text(error!);
    }

    return Column(
      children: [
        TextField(
          controller: searchController,
          decoration: const InputDecoration(
            hintText: "Search products",
          ),
          onSubmitted: (_) => fetchProducts(),
        ),
        Expanded(
          child: ListView.builder(
            itemCount: products.length,
            itemBuilder: (_, index) {
              final product = products[index];

              return Card(
                child: ListTile(
                  leading: Image.network(product.image),
                  title: Text(product.name),
                  subtitle: Text("\$${product.price}"),
                ),
              );
            },
          ),
        ),
        ElevatedButton(
          onPressed: () => fetchProducts(page: 2),
          child: const Text("Load more"),
        )
      ],
    );
  }
}

This widget is trying to do too many things at once:

Fetching data
Handling search input
Managing pagination
Showing loading and error states
Rendering product cards

Widgets that combine all of these responsibilities are difficult to maintain and reuse.

A better approach is to split responsibilities into smaller, focused widgets:

ProductSearchBar – handles user input for searching
ProductList – displays the list of products
ProductCard – renders a single product item
ProductErrorState – shows errors when data fails to load
ProductPagination – manages pagination controls

By giving each widget a single responsibility, they become easier to reuse independently. The resulting UI is also simpler to reason about, easier to test, and much more flexible to modify in the future.

Depending on a specific model type

A widget that accepts a RestaurantModel directly can't show a GroceryStoreModel even if the UI is identical. Prefer accepting primitives or a thin display-specific abstraction.

// Wrong! Only works for RestaurantModel
class VendorTile extends StatelessWidget {
  final RestaurantModel restaurant; // ❌
  ...
}

// Right! Use primitives
class VendorTile extends StatelessWidget {
  const VendorTile({
    required this.name,
    required this.imageUrl,
    required this.rating,
    this.badge,
  });
  final String name, imageUrl;
  final double rating;
  final String? badge;
  ...
}

Defining child widgets as inline functions

Writing helper methods like Widget _buildHeader() and calling them inside build() still executes as part of the same build scope. They don't get an independent element and won't be skipped when irrelevant parts of the tree change."

// Wrong! Helper method — always runs with the parent
Widget build(BuildContext ctx) {
  return Column(children: [
    _buildHeader(),   // ❌ re-runs every build
    _buildBody(),
  ]);
}
Widget _buildHeader() => Text('Header');

// Right! Separate widget class — gets its own element
Widget build(BuildContext ctx) {
  return Column(children: [
    const _Header(),  // ✅ skipped if props unchanged
    const _Body(),
  ]);
}
class _Header extends StatelessWidget {
  const _Header();
  @override
  Widget build(BuildContext ctx) => Text('Header');
}

Using boolean flags to switch between entirely different UIs

Parameters like isCompact, isGrid, isDetailed are a sign the widget is doing two or three separate jobs. Each boolean adds a hidden code path and exponentially increases mental overhead.

// ❌ Three different layouts hidden behind boolean flags
class ProductCard extends StatelessWidget {
  final bool isCompact;
  final bool isGrid;
  final bool isHorizontal;
  ...
}

// ✅ Three focused widgets, each doing one thing
class ProductCardCompact extends StatelessWidget { ... }
class ProductCardGrid    extends StatelessWidget { ... }
class ProductCardHorizontal extends StatelessWidget { ... }

Not marking immutable constructors as const

If you leave out const in a widget constructor, Flutter cannot skip rebuilding it. If a widget can be const, always make it const. It makes your app faster.

// ❌ New instance on every parent rebuild
Column(children: [
  Icon(Icons.home),       // ❌ missing const
  SizedBox(height: 8),   // ❌ missing const
  Text('Home'),           // ❌ missing const
])

// ✅ Flutter skips it with no cost to rebuild
Column(children: [
  const Icon(Icons.home),
  const SizedBox(height: 8),
  const Text('Home'),
])

Well-designed Flutter widgets are focused, reusable, and data-driven. Avoid hardcoding, god widgets, and hidden boolean logic. Let each widget do one thing and report events upward. By embracing composition, sensible defaults, and theming, you truly achieve “write once, reuse everywhere,” keeping your code clean, flexible, and future-proof.

Asynchronous Programming in Dart

FARINU TAIWO — Tue, 11 Apr 2023 08:00:48 +0000

Introduction

I wrote this article based on my interest in asynchronous tasks. Asynchronous programming is important for developers because it allows their applications to perform multiple tasks at the same time, without one task blocking the others. For example, when an application needs to wait for data from a server, asynchronous programming allows it to continue running other tasks, rather than waiting for the data before proceeding. This results in a smoother and more responsive user experience for the application's users.

Synchronous And Asynchronous Programming

Explaining to a kid, synchronous programming means doing things one at a time, step by step, and waiting for each step to finish before moving on to the next one. It's like doing your homework one page at a time and not moving to the next page until you finish the one you're working on.

On the other hand, asynchronous programming means doing things at the same time, without waiting for each step to finish before starting the next one. It's like listening to music and drawing a picture at the same time, without having to stop one activity to do the other.

In Dart, we can write programs that work synchronously or asynchronously, depending on what we need to do. Synchronous programming is good for simple tasks that can be done quickly, while asynchronous programming is better for tasks that take a long time or need to run in the background while we do something else.

So, when we write a Dart program, we can choose whether to do things one at a time (synchronously) or things at the same time (asynchronously), depending on what we want to achieve.

What is Future?

Future is used in a dart to denote an operation that is to be completed or not completed. If the task is completed, we get a result otherwise, we return an error. In asynchronous programming, we are forcing the long-processed task to follow an ordered path.

void main() {
  print('Fetching user data...');
  var userData = fetchUserData();
  print('User data received: $userData');
  print('End of main');
}

Future<String> fetchUserData() {
  // Imagine that this function is more complex and slow.
  return Future.delayed(
    Duration(seconds: 3), 
    () => 'John Doe'
  ); // simulate network delay
}

Output:

Fetching user data...
User data received: Instance of '_Future<String>'
End of main

From the code above, The fetchUserData() function returns a Future object that will be completed with the result of the network request after a delay of 3 seconds, represented by the Future.delayed() method. In this case, the result is simply a string containing the name 'John Doe'.

The output shows that the main function is executed synchronously, printing the first message to the console.

Next, the fetchUserData() function is called, which returns a Future<String> object. The returned future is assigned to the userData variable.

The second message is then printed to the console, which shows the value of the userData variable. Since userData contains a Future<String> object, the output displays "Instance of '_Future'" instead of the actual user data.

Finally, the last message is printed to the console, indicating the end of the main function.

The reason for this output is that the fetchUserData() function returns a Future<String> object, which represents the eventual result of the asynchronous operation. When we assign this future object to a variable and try to print it immediately, we see the type of the object instead of its value.

To access the value of the Future object, we need to use the .then() method or the await keyword in an async function.

Using .then() method

The .then() method is used to register a callback function that will be called when a Future object completes.

When we have a Future object representing an asynchronous operation that will complete at some point in the future, we can use the .then() method to attach a callback function that will be executed when the future is resolved with a result.

void main() {
  print('Fetching user data...');
  fetchUserData().then((userData) {
    print('User data received: $userData');
    print('End of main');
  });
}

Output:

Fetching user data...
User data received: John Doe
End of main

In this example, we use the .then() method to register a callback function to be called when the Future returned by fetchUserData() is completed. The callback function takes the userData string as its argument, which is then printed to the console along with another message indicating the end of the main function.

Note that in the example above, the print() statement after the fetchUserData() call has been removed, because we are now using the .then() method to access the result of the Future instead of assigning it to a variable and printing it directly.

What if we place print() after the fetchUserData() call?

void main() {
  print('Fetching user data...');
  fetchUserData().then((userData) {
    print('User data received: $userData');
  });
  print('End of main');
}

Output:

Fetching user data...
End of main
User data received: John Doe

The third message ("End of main") is printed before the Future is completed, because the call to fetchUserData() returns a Future immediately, and the .then() method is used to register a callback function that will be executed later, when the Future is complete.

This example shows how we can use the .then() method to perform some action with the result of an asynchronous operation once it becomes available, without blocking the main thread.

For an ordered execution, you need to place the print inside the .then() callback after userData is retrieved.

Using async/await

The async and await keywords are used to write asynchronous code that looks synchronous and is easier to read and understand, without blocking the main thread.

void main() async {
  print('Fetching user data...');
  var userData = await fetchUserData();
  print('User data received: $userData');
  print('End of main');
}

Output:

Fetching user data...
User data received: John Doe
End of main

The async keyword is used to mark the main function as asynchronous, which allows us to use the await keyword inside the function to pause its execution until a Future is completed with a result.

In this case, when the await keyword is used with the fetchUserData() function call, it pauses the execution of the main function until the Future returned by fetchUserData() is resolved with a result.

Once the Future is completed, the await keyword assigns the result to the userData variable, and the execution of the main function resumes, printing the second message to the console.

Using async and await in this way makes it easier to write and read asynchronous code, because it looks similar to synchronous code, and makes it clear what the flow of the code is. It also makes it easier to handle errors and exceptions that might be thrown by asynchronous operations, because they can be caught using a try-catch block like in synchronous code.

Conclusion

In Dart, asynchronous programming can be achieved using Future objects, which represent a value that may not be available yet, and the async and await keywords, which allow us to write asynchronous code that looks synchronous and is easier to read and understand.

How To Make Custom Radio Buttons With Cool Effects in Flutter

FARINU TAIWO — Sun, 02 Apr 2023 10:06:59 +0000

This tutorial will help you to understand how to create a group of custom radio buttons. Radio buttons are buttons that can be used to choose from different options.

So, we are creating the screen below:

Prerequisites

Basic knowledge of Dart programming language.
Familiarity with Flutter framework and its widgets.
A working installation of Flutter SDK and Android Studio or VS Code
Understanding of Stateful widgets and their role in managing state in a Flutter app.
Basic knowledge of layout and positioning in Flutter
Familiarity with using image assets in Flutter.

Tutorial

Open either of the IDE. Create a flutter project (Application) and name the project any name of your choice.

After the project is created, run the application on your device or emulator.

Download the three payment platforms' logos and the tick circle icon. I downloaded them from the images on Google.

Add the four images to the assets folder, or you may need to create the folder at the root of the project folder.
assets/images/

Add the path of the images to pubspec.yaml

 # To add assets to your application, add an assets section, like this:
assets:
    - assets/images/visa.png
    - assets/images/mastercard.png
    - assets/images/paypal.png
    - assets/images/tick-circle.png

In main.dart file, replace your code with the code below. The code sets up a basic Flutter app with an app bar and an empty container on the home page.

import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      debugShowCheckedModeBanner: false,
      theme: ThemeData(
        primaryColor: const Color(0xFF5C6ED1),
      ),
      home: const HomePage(),
    );
  }
}
class HomePage extends StatefulWidget {
  const HomePage({super.key});

  @override
  State<HomePage> createState() => _HomePageState();
}

class _HomePageState extends State<HomePage> {
    @override
    Widget build(BuildContext context) {
        return Scaffold(
          appBar: AppBar(
            title: const Text("Custom Radio Button Demo"),
          ),
          body: Container();
     }
}

The HomePage class is a stateful widget that has a state object of type _HomePageState. The build() method of this class returns a Scaffold widget, which is a basic visual structure for the app. The Scaffold widget has an AppBar and a body. The AppBar has a title with the text "Custom Radio Button Demo", and the body is an empty Container.

...
class _HomePageState extends State<HomePage> {
  int selectedPayment = 0;

  Widget CustomPaymentCardButton(String assetName, int index) {
    return OutlinedButton(
      onPressed: () {
        setState(() {
          selectedPayment = index;
        });
      },
      style: OutlinedButton.styleFrom(
        padding: const EdgeInsets.symmetric(horizontal: 5, vertical: 5),
        shape:
            RoundedRectangleBorder(borderRadius: BorderRadius.circular(10.0)),
        side: BorderSide(
            width: (selectedPayment == index) ? 2.0 : 0.5,
            color: (selectedPayment == index)
                ? Colors.green
                : Colors.blue.shade600),
      ),
      child: Stack(
        children: [
          Center(
            child: Image.asset(
              assetName,
              fit: BoxFit.contain,
              width: 120,
              height: 120,
            ),
          ),
          if (selectedPayment == index)
            Positioned(
              top: 5,
              right: 5,
              child: Image.asset(
                "assets/images/tick-circle.png",
                width: 25,
                fit: BoxFit.cover,
              ),
            ),
        ],
      ),
    );
  }
...

Inside the _HomePageState which extends State class. There is a variable named selectedPayment that is initially set to 0. It is used to keep track of the selected payment option. There is a method CustomPaymentCardButton takes two parameters, assetName and index. assetName is a string that represents the path to an image asset, and index is an integer that represents the position of the button in a list of payment options.

The method returns an OutlinedButton widget, which is a Material Design styled button with an outlined border. The onPressed callback of the button sets the value of selectedPayment to the index of the button that is pressed.

The child property of the button is a Stack widget that contains an Image.asset widget with the image specified by the assetName parameter. The Stack also contains a Positioned widget that shows a checkmark icon if the button is selected.

The style property of the button is used to set its padding, border shape, and color based on whether it is selected or not. If the button is selected, its border width is set to 2.0, and its color is set to green. Otherwise, its border width is set to 0.5, and its color is set to blue.

...
@override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: const Text("Custom Radio Button Demo"),
      ),
      body: Padding(
        padding: const EdgeInsets.symmetric(horizontal: 20),
        child: Column(
          children: [
            const SizedBox(
              height: 20,
            ),
            Row(
              mainAxisAlignment: MainAxisAlignment.spaceBetween,
              children: [
                Expanded(
                  child: CustomPaymentCardButton("assets/images/visa.png", 0),
                ),
                const SizedBox(
                  width: 20,
                ),
                Expanded(
                  child: CustomPaymentCardButton(
                      "assets/images/mastercard.png", 1),
                ),
              ],
            ),
            const SizedBox(
              height: 16,
            ),
            CustomPaymentCardButton("assets/images/paypal.png", 2),
          ],
        ),
      ),
    );
  }
...

The body is defined using a Padding widget with a horizontal padding of 20. The padding contains a Column widget that contains a list of payment options.

The Row widget contains two Expanded widgets that each contain a custom payment card button defined using the CustomPaymentCardButton method. The first button shows an image of a Visa card and has an index of 0. The second button shows an image of a Mastercard and has an index of 1. The Row widget is used to display the two buttons side-by-side with an equal width.

The CustomPaymentCardButton method is called again with an image of a PayPal logo and an index of 2 to display a third button below the Row.

The overall code is the code below:

import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      debugShowCheckedModeBanner: false,
      theme: ThemeData(
        primaryColor: const Color(0xFF5C6ED1),
      ),
      home: const HomePage(),
    );
  }
}

class HomePage extends StatefulWidget {
  const HomePage({super.key});

  @override
  State<HomePage> createState() => _HomePageState();
}

class _HomePageState extends State<HomePage> {
  int selectedPayment = 0;

  Widget CustomPaymentCardButton(String assetName, int index) {
    return OutlinedButton(
      onPressed: () {
        setState(() {
          selectedPayment = index;
        });
      },
      style: OutlinedButton.styleFrom(
        padding: const EdgeInsets.symmetric(horizontal: 5, vertical: 5),
        shape:
            RoundedRectangleBorder(borderRadius: BorderRadius.circular(10.0)),
        side: BorderSide(
            width: (selectedPayment == index) ? 2.0 : 0.5,
            color: (selectedPayment == index)
                ? Colors.green
                : Colors.blue.shade600),
      ),
      child: Stack(
        children: [
          Center(
            child: Image.asset(
              assetName,
              fit: BoxFit.contain,
              width: 120,
              height: 120,
            ),
          ),
          if (selectedPayment == index)
            Positioned(
              top: 5,
              right: 5,
              child: Image.asset(
                "assets/images/tick-circle.png",
                width: 25,
                fit: BoxFit.cover,
              ),
            ),
        ],
      ),
    );
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: const Text("Custom Radio Button Demo"),
      ),
      body: Padding(
        padding: const EdgeInsets.symmetric(horizontal: 20),
        child: Column(
          children: [
            const SizedBox(
              height: 20,
            ),
            Row(
              mainAxisAlignment: MainAxisAlignment.spaceBetween,
              children: [
                Expanded(
                  child: CustomPaymentCardButton("assets/images/visa.png", 0),
                ),
                const SizedBox(
                  width: 20,
                ),
                Expanded(
                  child: CustomPaymentCardButton(
                      "assets/images/mastercard.png", 1),
                ),
              ],
            ),
            const SizedBox(
              height: 16,
            ),
            CustomPaymentCardButton("assets/images/paypal.png", 2),
          ],
        ),
      ),
    );
  }
}

Run the app.

The overall code creates an app that displays custom payment card buttons that can be selected and displays a tick mark for the selected payment option.

Conclusion

Custom radio buttons can provide a great way to enhance the user experience of your Flutter app. By using custom widgets and carefully selecting visual cues, you can create radio buttons that stand out and communicate their purpose to your users. With the example code we've covered here, you can get started on creating your custom radio buttons in your Flutter projects. With some practice and attention to detail, you can create radio buttons that are both functional and visually appealing for your users.

Thanks for reading.

Getting into GitHub Campus Expert (GCE) Program

FARINU TAIWO — Sat, 24 Sep 2022 09:05:27 +0000

Joining GitHub Campus Expert Program was a great experience for me though I struggled when I joined the program. I overcame those difficulties by learning during the program curriculum and by asking pertinent questions. I wrote this article to share few tips that helped me during the application process and during the program and I hope these tips will help you too.

I should have written this article some time ago, but I kept postponing it due to procrastination. So, I finally decided to share what I think you need to know when applying for the GCE program.

Application

When you apply for the GitHub Campus Expert program, the first thing to know is always capitalizing ‘H’ in GitHub.

I am joking, however it is good you know this. Wherever you mention GitHub, take note of capitalizing the letter ‘H’. It is Git + Hub. I learnt this from one of the program managers at GitHub Education.

Let’s dive in to why you are interested in this article…

Firstly, let me share my story. I became the second GitHub Campus Expert in Ladoke Akintola University of Technology early (LAUTECH) 2019, however I submitted my application around September 2018. It was life changing experience for me when I got into the program. I learned about the program from my eldest brother’s friend, who was the GCE at the time. He sent me the application link, and I applied. I had recently started my exam around that time. So I remembered that I had applied for the program at the Olusegun Oke Library.

One thing I know I can’t avoid mentioning is the problem that practically all tech communities have, which I feel I will fix with the help of other tech community organizers if I become a GCE. It is the gender ratio (percentage of male to female) of the participants in any tech program.
Unless the event is centered on females, most tech activities in LAUTECH at the time involve a few ladies. I had no idea that I still didn’t know what it meant to address this problem.

I applied with the intention of helping every female student on campus to join the campus tech community. That aided my application. I eventually got in.

Getting in was thus simple back then. The problem I encountered occurred during the program’s learning phase, which will put my talents in technical writing, tech community inclusion, and public speaking to the test. Please keep in mind that all of your abilities will be expressed in writing. So, if you are strong at technical writing, the GCE program is for you; if you are not, like me, the curriculum will teach you how to write properly.

Application tips

Technical writing: Basic writing is one of the essential skills you need when applying for this program.
Know your community: The Tech community is made up of people that are interested in technology or are about to embark on a career in technology. The majority of participants in campus tech communities are people that enjoy technology as a hobby, whether it be design, programming, product, cloud, or anything else.
Contribution to your existing group: Be passionate about contributing to your tech ecosystem. As a student, you can start this with your department or faculty.
Show it in your application that you have organized a meetup or were a volunteer for an event is a plus.
GitHub will review your application to determine what hurdles your tech group has overcome and what kind of problems you will solve if you join the program. Students can currently join a variety of IT groups on campus. The Developer Student Club (DSC), the Google Developer Group (GDG), Pyladies, Figma, and departmental groups are among them.
GitHub is looking for someone who can serve as a mentor to other tech organizers by assisting them in resolving issues.
Highlight problems: The issues confronting the tech group are numerous. Accessing tech events, handing over duties after each tenure to the right people, and gender ratio are part of the issues. There are not enough trainers to teach about technology. How can a hackathon foster collaboration? Maybe you are organizing your first tech event.
Solutions: Giving answers to the problems you address in your application also demonstrates your problem-solving skills.
Inclusive community: In your application, demonstrate what an inclusive community by telling them how you can make your tech community inclusive. Inclusive community is also centered on diversity.
Networking: Once accepted into the program, I recommend you begin networking on campus. Know the organizers of every tech groups on your campus. Share contacts, connect with them, and explain how you can assist them.

Some of my unforgettable experience

I got my swags (hoodie, flag, bag and so on). Twitter
I got to speak at a tech meetup full of women in tech.
I met with a lot of other GCEs online, I travelled to another state to speak while mentoring over 120 secondary school students.
I met with the GitHub CEO at a GitHub event in Lagos held in Civic Center Towers, Lagos 2019 despite arriving late due to traffic.

Congratulatory Email

If you are selected you to the program, you will be invited to do some tasks to know who you are. More like onboarding to the program.

Conclusion

Give the essay application your best. You can do it.

If you still don’t know how to go about your application you can DM on Twitter.

I wish you the best and I hope that you get into the program. It is an awesome experience.

Connect your android device using Wi-Fi on VS Code

FARINU TAIWO — Sat, 16 Jul 2022 06:55:28 +0000

For mobile developers building an Android app, it's important that you always test your app on a real device (phone, tablet) before releasing it to users.

Connecting your device through a USB cord when running your app can be stressful when you are using the device for other things like checking other apps and changing music or charging your device (if it is low). All of these can cause the USB to detach from the device and you will need to connect and run it again when the device is detached.

This solution is too simple, in my opinion. Once your device has been connected to a USB port, you can allow Wi-Fi to maintain the connection.

Android Debug Bridge (ADB) connection is used to connect our Android smartphone to our PC.

Set up a device for development

To set up a device for development read this

Connect to your device using USB

You should already be aware that a USB cable is necessary.

Check you have Android studio installed on your PC and your have installed the SDK Platform Tools.

Verify that your device is connected by running the adb devices command from your android_sdk/platform-tools/ directory. If connected, you'll see the device listed

Make sure the platform-tools directory is present in your environment variable. Adding the directory is required if not.

For flutter developers, before running your app, check if flutter doctor is working correctly.

Connect to your device using Wi-Fi

Ensure that your workstation or PC and device are connected to the same wireless network.
This wireless network can be established by sharing your PC's hotspot with your android device or vice-versa.

Install extension

Click on the extension tab in the left area on VS Code.

Search for Android ADB WLAN by deskbtm (developer name). Install the extension.

Restart your VS Code. The extension added beside the run button on your VS Code.

Click on the icon and select the android device name you want to connect.
Select the number by pressing Enter,
Select the prompted IP address of the WIFI your PC is connected to by pressing Enter.
Connect successfully
Unplug your device and enjoy!

If there is any issue restart the adb by using the extension button and follow the process again.

Thanks for reading. Don't forget to share.

Contact me
Twitter
LinkedIn

Best libraries for Android Developers

FARINU TAIWO — Sat, 16 Jul 2022 06:48:31 +0000

Android libraries to help you with your app development. Some of them you may already know, but I am sure you can find a hidden gem among these! I have used some of these libraries here that have made development fun and easy for me.
There are hundreds of new libraries being developed every day, but very few can impress developers and prove potent

What are Android libraries?

Libraries are major game changers in software development irrespective of platform or stack. With libraries, developers leverage the efforts of other developers to perform actions/functions faster, more effective, and with lesser boilerplate codes. In this article, we will look at various categories in Android development and the common libraries used in them.
These libraries for developers provide with basic pre-written codes and other important elements that can be used instantly rather than performing these tasks from scratch.

Before we start, why don’t we take a moment and understand what Dependency Injector is?

Dependency Injector Library

Dependency injection (DI) is a method that is broadly used in programming for Android development. One can create a good Android library architecture for apps by following the principles of DI.

You get the following benefits for using Android libraries for Dependency Injection:

Reusability of code
Ease of testing
Ease of refactoring

Popular libraries used for DI are Hilt, Dagger2 and Koin.

Hilt

Hilt, famously known as the dependency injection library, helps decrease the boilerplate of performing manual dependency injection in your Android project. Performing manual dependency injection needs the construction of each class and its dependencies. Also, the containers will help to reuse and organize dependencies.

Hilt makes it easy to integrate Dagger dependency injection into Android apps. Hilt’s goals are to make Dagger-related infrastructure for Android apps easier to use. To make setup, readability/understanding, and code exchange between apps easier, a common set of components and scopes was created.

Koin

Navigation is known as a framework to easily move between destinations within the Android app. Using Navigation Library makes it easier to create navigation in your Android app. However, it only works with an app that offers a proper API regardless of the destination implementation.

To utilize this component in your app, add Activities, Fragments, or other components as well. Add the Google Maven repository to add dependencies on Navigation.

Dagger

We cannot complete the list without mentioning Dagger here.
Dagger is a fully static, compile-time dependency injection framework for Java, Kotlin, and Android. It is an adaptation of an earlier version created by Square and now maintained by Google.

Dagger sets itself apart from other dependency injection libraries.

The dependency injector library helps to provide smaller components to another model and helps them remain intact with each other.

While developing larger applications, it would be challenging to handle dependency injection. This time, Dagger will save you in this situation as it creates a dependency injection graph in compile-time via annotation processors.

Networking Libraries

Here are the tools that you need for establishing any kind of network communication within the Android app.

Retrofit

Retrofit is a type-safe HTTP client for Android and Java – developed by Square.

Retrofit is the best library that lets you connect to HTTP-based API services from your Android applications. It leverages the OkHttp library’s core functionality, adding a bunch of features to it while eliminating the boilerplate code.

One can effortlessly manipulate endpoints and headers, add a request body and query parameters, and select request methods – all with just annotations in Retrofit. Moreover, this Android library also takes care of parsing POJOs by using converters.

Image Loading Libraries

Image loading libraries are a knight in shining armor combating the problem of “out memory errors” in Android apps caused by loading multiple images at a time. Let’s look at the best Android libraries options out there in this category.

Picasso

Maintained by Square, Picasso is a trusted and widely used Android image library. Picasso claims to allow for hassle-free image loading in the application—often in one line of code.

Some of the pitfalls that Picasso takes care of include handling ImageView recycling and downloading cancellation in an adapter, facilitating complex image transformations using minimal memory, automatic memory, and caching.

Additional features that makes Picasso a popular choice among Android app developers are –

Picasso automatically detects adapter re-use and the previously canceled download.
It easily and effectively transforms images to make them fit better into layouts and reduce memory size.
For more advanced effects, one can specify custom transformations.

Glide

Glide is yet another praised image loader and one of the best new Android libraries for developers, managed by Bumptech. Not just this, but it is also recommended straight by Google.

Glide not only provides animated GIF support while handling image loading and caching but also helps in fetching, decoding, displaying video calls, images, and these GIFs. It also includes a flexible API allowing developers and programmers to plug in any network stack, as its default stack is HttpUrlConnection.

This library primarily aims at making the scrolling process for any list of images as smooth as it can be. More so, it is also effective in case you need to fetch, resize, or even display a remote image.

Debugging libraries

Almost an indispensable step in the app development process, debugging an application before its final release is as important as it gets. For this purpose, let’s have a look at some useful libraries.

Stetho

Stetho claims to be a “sophisticated debug bridge for Android applications”. The use of this library is not limited to just Network inspection, Database inspection, JavaScript Console, etc. but developers use it to have access to the Chrome Developer Tools features that are natively part of the Chrome desktop browser. Moreover, developers can choose to enable the optional dump app tool offering a powerful command-line interface to application internals.

Hyperlog-Android

This is a standard Android Log class for storing logs in an Android database library and push them to a distant server for debugging. It is also a utility logger library.

This library provides end to end visibility and helps to debug issues. HyperTrack SDK pushes log to the Hyperlog server, and the server makes use of ELK stack to process the logs and visualize them on Kibana.

Reactive Programming libraries

In Reactive programming, data is released from a component (a source if you will) to the other component known as Subscriber, assisting in handling asynchronous tasks efficiently. So in short, these libraries help with transferring data from source to subscribers. Some of the widely used Android app development libraries for this purpose are:

RxJava2

If you are looking for a library that helps you in implementing reactive programming (create reactive applications), then RxJava is an ideal choice for you. It is officially described as “a library for composing asynchronous and event-based programs by using observable sequences”.

This library is considered unbeatable by Android app developers because it simplifies the process to chain async operations, opens a more explicit way to declare how concurrent operations should work, is able to highlight errors sooner than other libraries, among other things

Observables are the data sources and they exist in various types: Observer, Single, Flowable, Maybe, and Completable. Each of these types has a unique use case which we can read more about here.

RxAndroid

RxAndroid, on the other hand, is an extension of RxJava2. It offers functionalities just peculiar to the Android platform, like the provision of a Scheduler that schedules on the main thread or any given Looper.

Drawing libraries

Here are some Android apps graphic libraries that have stood apart from the crowd.

MPAndroidChart

MPAndroidChart is an impeccable Android chart/graph view library. It supports radar, line, bar, bubble, pie, candlestick charts along with scaling, animations, and panning.

If you are looking for its iOS counterpart then, Charts is the one for iOS app development.

Holo Graph library

It is another new graphic library which is continuously becoming a favorite of many Android app development companies. This library is ideal for adding impeccably designed graphs and charts into Android applications. It includes:

LineGraph view (which looks something like this) –
BarGraph View
PieGraph View
MultiSeriesDonutGraph View

AnimatedPieView

AnimatedPieView is another method for showing pie charts and ring graphs on Android.

This library offers various benefits like: alpha animation on touch, fitting text field position itself during an animation, transformation between a pie diagram and a ring chart, animation while drawing charts and so on.

MyLittleCanvas

It is one of the top libraries for Android developers. This Android Library is used to achieve features such as custom underline on a TextView. It is also used to apply Textshape, lineshape, etc. with canvas methods. If you don't know how to use Canvas, use MyLittleCanvas instead!

Testing libraries

In scaling up your skills as an android developer, you need to learn how to test your code. Writing tests as you code is one of the best practices in android development. Testing your project shows the competence and efficacy of your mobile app. You can use these libraries to test your mobile app before you ship it to the market.

Espresso

A part of the Android testing support library, Espresso is evidently a test framework that enables developers to build user interface tests for Android applications. Implying that this library lets you write tests and check whether the text of a TextView is similar to another text or not. It imparts the impression of a real user using the app while it is running on both real device and emulators.
To use this library, you are required to add dependencies to the app module build.gradle file.
Once you have done this, you can set the instrumentation runner and sync the Gradle files, followed by creating a test file. This is the reason why businesses prefer Android app bundles.

Mockito

Most times, the classes we intend to write tests for depend on other classes. Configuring these classes just for this purpose can be hectic. This is where Mockito comes in. It is a mocking framework that helps us create and configure mock (fake) objects. It is usually used with together with JUnit.

Robolectric

Robolectric is another unparalleled unit testing library. What this library does is that it handles inflation of resource loading, views, including other things. It makes the tests created in the library more efficacious and potent in performing functions that real devices with Android framework dependencies perform. In a sense, Robolectric simulates the Android SDK for the tests, eliminating the need for additional mocking frameworks like Mockito.

Now again, you need to add the dependency in your app’s build.gradle file, followed by creating a sample test class .

These Android libraries list have made it to this record based on the popular recommendation of the Android developers. Their features, functions, and performance together emit excellence in their niche of purpose.

Database Helper Library

Offline data persistence is very important to enhance user experience. We usually need our applications to store important information that will be required on a next startup of the app or to make data available when no internet connection is available. As storing data is more complex than just combining key and value pairs, numerous libraries have been created to make storing this task easier in Android. In this section, we will look at one great persistence library: Room.

Room

Room is a persistence library which is part of the Android Architecture Components. Room provides local data persistence with minimal boilerplate code. It provides an abstraction layer over SQLite, thereby making it easier to work with databases in our app. This library comes with a lot of advantages such as verifying SQL queries at compile time, rejecting database queries on the main thread (except when explicitly stated while initializing the database), providing implementation best practices, etc.

Room is composed of three main components: the Database, the DAO (Data Access Objects), and Entities. Each of them is co-related in order to make the library functional. The Entity class represents a database table and has to be annotated with @Entity. The variables in the class represent the columns the table will have. The DAO is an interface that contains the methods used for accessing the database. Room uses the interface to generate an implementation class for us.

There are four specific annotations for the basic DAO operations: @Insert, @Update, @Delete, and @Query. Then, we have the Database class. This is an abstract class annotated with @Database and that extends RoomDatabase. This class defines the list of entities and their DAOs to be used.

Obectbox

Object Box is a widely used Android databinding library that allows you to devote your valuable time to Various USPs of the product instead of storing and retrieving data. This library acts as an object oriented embedded database considered as a right alternative for SQLite. Since its documentations and portfolio are well defined, it is a perfect suit for IoT (Internet of Things) apps.

Custom Fonts Library

Almost every Android developer is passionate about the look and feel of their app. Sometimes we might need to go the extra mile into choosing a unique font for the app to give it the same feel across all devices. In situations like this, there are some libraries that can help us to use a custom font for all our texts in the app.

Calligraphy

Calligraphy is one of the most popular custom font libraries available and it is quite easy to get along with. With this library, we can easily declare a single font across our whole application or define fonts individually to a text.

View Binding Libraries

The need for view binding libraries first surfaced when the need to reduce the boilerplate code when assigning views to variables arose. As a matter of fact, the number of Android support libraries worth mentioning for this purpose is numbered and two of the most prominent of them are:

Android View Binding

View binding is a feature that allows you to more easily write code that interacts with views. Once view binding is enabled in a module, it generates a binding class for each XML layout file present in that module. An instance of a binding class contains direct references to all views that have an ID in the corresponding layout.

In most cases, view binding replaces findViewById.

Android Data Binding

The Data Binding Library is a support library that allows you to bind UI components in your layouts to data sources in your app using a declarative format rather than programmatically.

Layouts are often defined in activities with code that calls UI framework methods.

Binding components in the layout file lets you remove many UI framework calls in your activities, making them simpler and easier to maintain. This can also improve your app's performance and help prevent memory leaks and null pointer exceptions.

Scanning Libraries

In order to integrate scanning features while developing custom Android apps and increase their functionality level, developers prefer the below-mentioned libraries.

Zxing

Acronym for ‘Zebra Crossing’, ZXing is a barcode image-processing Android library that is implemented in Java, with ports to other programming languages. This library also has support for the 1D product, 1D industrial, and 2D barcodes.

Google also uses ZXing in order to make millions of barcodes indexable on the web. It also forms the basis of Android’s Barcode Scanner app and is integrated into Google Book Search and Google Product.

CAMView

This is an effective alternative to the ZXing barcode scanner. It is an Android camera easy access library with an embedded QR scanner which is based on ZXing.

CamView library possesses a set of components (views in simple words) which are set to be put to your layout files, allowing developers and giving immediate access to-

Live preview video feed from the device camera
Scanning barcodes with the help of ZXing’s built-in decoding engine
To perform your own camera live data processing

Image Cropper

Tools used in cropping images and also adding some styling to the image.

CanHub

CanHub is a powerful tool used to zoom and rotate the image from the camera or gallery. The image cropped can be customized in shape, limits and style. It is a project forked from ArthurHub.

Android Jetpack

Android Jetpack is a suite of libraries to help developers follow best practices, reduce boilerplate code, and write code that works consistently across Android versions and devices so that developers can focus on the code they care about. Some libraries like Room, View binding and Data Binding are part of Android jetpack. Other libraries are WorkManager, Navigation, CameraX.

Jetpack libraries are published in the androidx namespace.

Conclusion

These libraries/tools significantly reduce the amount of boilerplate code written to perform various functions while developing for Android. Knowing the best libraries can help us improve the quality of our apps and make us produce more in less time.

Contact me
Twitter
LinkedIn

Why Technical Writing?

FARINU TAIWO — Thu, 07 Jul 2022 22:27:43 +0000

Helping people to understand tech has always been my passion.

Being a developer has made me realize that I can code with any tool if I understand the basic concept of the tool. For instance, most programming language tutorials start with how to print "Hello world!". Then, understanding how "Hello world!" is printed in the next step. This shows that a programmer does not only need to know how to instruct a computer but can understand how the computer carries out the instruction. The more you know the basics the better it will be to understand the advanced concepts.

Technical writing helps users understand a skill or product by providing detail-oriented instructions.
Instruction is detailed information about how something should be done or operated.
Technical writing helps users efficiently use tools and products.
Technical writing also gives you a better sense of user empathy. When you write, you must pay more attention to what the readers or users of a product feel rather than what you think.