DEV Community: koreanDev

Why I Switched from http to Dio in Flutter — Centralizing Error Tracking with Interceptors

koreanDev — Sat, 18 Apr 2026 05:46:47 +0000

Your Flutter app has Crashlytics. Global handlers are set up. Feels safe.

Open the dashboard. How many API errors are recorded? Probably zero.

The problem

Dart's global error handler only catches uncaught Errors. In Dart, Error and Exception are different things. StackOverflowError is an Error — programming mistake. API failure is an Exception — expected, recoverable.

The thing is, API exceptions get caught in try-catch blocks. They never bubble up to the global handler. Crashlytics never sees them. Complete blind spot.

To track Exceptions, you need to record them separately. That's why I refactored my solo app Book Log's network layer from http to Dio.

Before: http package

// auth_repository.dart — repeat this for every request
final token = await _storage.read(key: 'serverToken');
final response = await http.post(
  Uri.parse('$_baseUrl/user/fcm-token'),
  headers: {
    'Authorization': 'Bearer $token',
    'Content-Type': 'application/json',
  },
  body: jsonEncode({'fcm_token': fcmToken}),
);
if (response.statusCode != 200) { ... }
// Crashlytics? gotta add it manually here

I had an ApiClient wrapper class. BookRepositoryImpl and SentenceRepositoryImpl used it. But AuthRepository was calling http directly. Crashlytics recording only happened inside ApiClient._execute(). All auth-related errors were in a blind spot.

After: Dio + Interceptors

Two interceptors. That's it.

AuthInterceptor — auto token injection

class _AuthInterceptor extends Interceptor {
  _AuthInterceptor(this._storage);
  final FlutterSecureStorage _storage;

  @override
  Future<void> onRequest(
    RequestOptions options,
    RequestInterceptorHandler handler,
  ) async {
    final authenticated = options.extra['authenticated'] ?? true;
    if (authenticated == true) {
      final token = await _storage.read(key: _kServerTokenKey);
      if (token == null) {
        return handler.reject(
          DioException(
            requestOptions: options,
            error: const ApiException(
              statusCode: 401, message: 'Not logged in'),
          ),
        );
      }
      options.headers['Authorization'] = 'Bearer $token';
    }
    handler.next(options);
  }
}

options.extra is a custom metadata map from Dio. Doesn't affect the HTTP request. Not sent to the server. Just a switch for the interceptor to decide: attach token or not.

authenticated: true → token injected (post-login APIs)
authenticated: false → no token (Apple login, pre-auth APIs)

CrashlyticsInterceptor — auto error logging

class _CrashlyticsInterceptor extends Interceptor {
  @override
  void onError(DioException err, ErrorInterceptorHandler handler) {
    FirebaseCrashlytics.instance.recordError(
      err,
      err.stackTrace,
      reason: '${err.requestOptions.method} ${err.requestOptions.path}',
    );
    handler.next(err);
  }
}

Every HTTP error recorded to Crashlytics. The reason shows POST /user/fcm-token so you know which API failed. Unlike the global handler, this catches all API failures regardless of try-catch.

Result

// Before
final response = await http.post(
  Uri.parse('$_baseUrl/user/fcm-token'),
  headers: {
    'Authorization': 'Bearer $token',
    'Content-Type': 'application/json',
  },
  body: jsonEncode({'fcm_token': fcmToken}),
);

// After
await _apiClient.post('/user/fcm-token', {'fcm_token': fcmToken});

Token injection, error handling, Crashlytics logging — all automatic.

Migration scope

Only two files were using http directly.

api_client.dart → replaced with Dio. Kept existing method signatures.
auth_repository.dart → now injects ApiClient instead of calling http.

BookRepositoryImpl and SentenceRepositoryImpl already used ApiClient. Zero changes needed. Keeping the get/post/patch signatures the same made this possible.

3 bugs from Claude Code

I delegated this migration to Claude Code. Overall result was solid. But server logs told a different story.

1. Wrong endpoint path

Original code used /validate-token from env variable. After migration it became /auth/validate. Route doesn't exist. 404.

2. Token not attached

validateToken was set to authenticated: false. Token validation API not sending the token. 400.

3. JSON key mismatch

Client sending fcmToken (camelCase). Server expecting fcm_token (snake_case). 400.

Found all three by running gcloud app logs tail. AI-generated code still needs manual verification. Especially env variables and API schemas — AI doesn't track those well.

Summary

	Before (http)	After (Dio)
Token injection	manual per request	interceptor auto
Crashlytics	only via ApiClient	all APIs auto
Error handling	duplicated per file	centralized
AuthRepository	direct http calls	via ApiClient

Set up error tracking infra before going to production. This migration was that work.

I Debugged Xcode for Hours. The Bug Was in My Joi Schema.

koreanDev — Fri, 17 Apr 2026 02:48:01 +0000

I Debugged Xcode for Hours. The Bug Was in My Joi Schema.

My first iOS app got rejected by Apple.

Reason: "Error when logging in with Apple account."

I had seen the exact same error a few days before. That time, it was a missing capability in Xcode. So I assumed the same cause.

I spent hours checking:

Provisioning profile
App ID capability
Distribution certificate
Sign in with Apple key
Bundle ID

Everything was fine.

Then I opened the server logs.

POST /apple/login → 400

The request was reaching the server with all the data. But the server was returning 400.

The real cause? During a refactoring session with an AI coding tool, a Joi validation middleware was added. The schema was missing one field that the client was sending — identityToken.

The controller never ran. Joi blocked it silently.

The fix was one line.

identityToken: Joi.string().required()

I wrote about the full debugging process, the wrong assumptions I made, and what I learned about reviewing AI-generated code.

👉 Read the full post on Medium

Claude Code for Solo Developers — Prompt Engineering That Keeps Things Clean

koreanDev — Sun, 12 Apr 2026 19:45:35 +0000

I'm building an iOS reading app by myself. The stack is Flutter, Express/TypeScript, and Supabase. I used Claude Code for most of the heavy lifting — Apple Sign In, account deletion, API client abstraction, design system, card sharing, and localization.

What I found out pretty quickly is that how you write the prompt changes everything. This is a record of what worked, what didn't, and the calls I made along the way.

I wrote prompts with Claude, not for Claude

I didn't start with perfect prompts. I'd explain what I needed, Claude would draft a prompt, and then I'd add my own rules or split the task up before running it.

Error handling is a good example. Claude's first draft looked like this:

Add consistent error handling across all API call sites.
Wrap every API call in try-catch.

Here's what I added on top:

Scan the entire codebase — not just repositories.
- Catch ApiException and rethrow as-is
- Catch all other exceptions and wrap in ApiException(statusCode: 0, message: e.toString())
Maintain existing feature-first clean architecture.

I knew that "all repository methods" would miss files like auth_repository. So I made it explicit. Claude drafts, I refine, then we run it.

1 — Always declare the scope

This was the most important thing I did. Every prompt had a clear list of what to touch and what to leave alone.

## Constraints
- Only modify setting_page.dart
- Do not modify auth or book features
- Maintain existing feature-first clean architecture

Because of this, I had zero unintended file changes across the whole project. Claude never touched something I didn't ask it to. Every result stayed exactly in the lane I set.

2 — Give architecture context in one line

Early on I wrote "Keep Riverpod pattern." Too narrow. What I actually needed was the whole structure to stay intact.

So I switched to this:

Maintain existing feature-first clean architecture.

One line. Covered Riverpod, directory structure, and file responsibilities all at once. Anthropic's own docs say to think of Claude like a smart new hire with limited context — give enough to work with, but don't over-explain.

3 — Split the work

When you throw too much at once, instructions can conflict or things get dropped. Anthropic's docs recommend giving instructions as sequential steps.

For the design system, I split it like this:

Round 1 — Extract design constants:

Extract design constants into a centralized theme system.
Inside lib/app/:
- app_colors.dart
- app_text_styles.dart
- Update existing theme.dart
Replace all hardcoded color/font values.
Do not change any UI layout or behavior.

Round 2 — Navigation and Settings:

Simplify navigation and complete Settings page.
Reduce bottom tabs to 2: Books and Settings.
Complete Settings page with user info and logout.

Splitting made it easy to verify each result and track down issues if something went wrong.

4 — Product decisions are mine to make

Claude writes good code. It doesn't make good product decisions.

When I needed to store a language setting, Claude suggested a new table and middleware layer. But there was already a language_code column in the DB. I just used that.

Claude tends to over-engineer for flexibility. In solo development, simplicity wins. That call is mine to make.

Same thing with the sentence delete feature. I cut it from the MVP. A bad sentence can just stop being the representative one — and having sentences pile up is actually part of the app's value.

What I didn't know

After the project, I read through Anthropic's official prompt engineering guide. A few things stood out.

XML tags — Wrapping sections in <instructions>, <constraints>, <context> tags helps Claude parse the prompt more cleanly. I used markdown headers (##) the whole time.

Few-shot examples — Including 3–5 examples alongside instructions can significantly improve output quality. I never did this. For consistency-heavy work like design systems, it probably would've helped.

There's also stuff in the docs about parallel tool calls and agent behavior control. Didn't use any of it. Worth looking into for the next project.

Wrapping up

Scope declaration, architecture context, splitting the work — those three things kept everything clean. No unintended changes, no broken structure, results that stayed exactly where I put them.

Prompting is just communication. The clearer you are about what you want, what's off limits, and what the constraints are — the better the output. But what to build, how to break it down, how simple to keep it — that's still on you.

I Threw Away My Keyword Strategy Right Before Launch — Here's What I Did Instead

koreanDev — Sun, 12 Apr 2026 15:30:12 +0000

Some context

I had already built and shipped a vocabulary learning app on both iOS and Android before. It was pretty basic — nothing fancy in terms of design. But it kept getting steady organic downloads without any marketing at all. The revenue wasn't life-changing, but watching users show up on their own was honestly motivating.

I wanted that same feeling with my second app. I wasn't chasing big money. I just wanted to build something where users would keep coming in, little by little. And I figured the best way to do that was to focus on one sharp feature instead of building an app that tries to do everything. I wanted to nail one thing and see how people react.

So I came up with the idea for a reading app — you save sentences you like from books, turn them into nice-looking cards, and share them. I built it with Flutter, and the MVP was almost done.

Why I went back to check the keywords

During the early planning phase, I used AI to do some market research. Back then, it suggested a certain keyword as my main target — something along the lines of "reading ****s." The competition looked manageable at the time.

But right before launch, I asked the same AI again. And it gave me a different answer. Maybe the market had changed, or maybe it was just looking at things from a different angle. Either way, I decided I couldn't just go with the old plan. Time to start over.

What I was really looking for

It wasn't just about finding keywords with low competition. I needed to check three things:

Is this a niche that actually exists?
Is there proven demand?
Can a new app actually get in?

I needed all three to be true at the same time.

I started searching myself

I thought about using paid ASO tools, but decided to just search the app stores directly first. I grabbed my iPhone, typed in keywords one by one, and took screenshots of every result.

The keyword ideas came up naturally while chatting with AI. I'd check what showed up in autocomplete, look at how competitor apps wrote their subtitles, and we'd go back and forth narrowing things down.

First search: my original target

I searched for the keyword I had picked during planning. Turns out my earlier judgment was wrong. The top app had 18,000 reviews and was ranked #19 on the charts. Four more apps below it had reviews in the thousands. App names were even showing up in autocomplete — that's how packed it was.

Second search: similar keyword

Tried a variation. Same apps showed up again. The top two apps combined had over 20,000 reviews. Pass.

Third search: a feature-based keyword

This time I searched for something that directly describes what my app does. Things looked different here. The top app had around 360 reviews. That told me two things — the demand is real, and the top spot isn't locked down by a giant. From the second result on, most apps had fewer than 30 reviews.

Fourth search: the turning point

Then I tried one more keyword, and the results were completely different.

The top app had 17,000 reviews. So clearly, people search for this term a lot. But here's the thing — that app wasn't even in the "Books" category. It was in a totally different one. Same for the second result. There wasn't a single Books-category app ranking for this keyword.

So the search volume was there, but the category was wide open. Honestly, I wasn't sure if this was a real opportunity or not — I'd only know after launching. Whether the people searching actually want what my app offers, whether they'd actually install it — that's something only real data can answer. But it definitely felt worth trying.

What autocomplete told me

I also noticed something useful while typing. When I entered a certain word, autocomplete suggested several related keyword combinations. That's a pretty clear sign that real people are actually searching for those terms.

Checked Android too

I didn't stop at iOS. I ran the same searches on Google Play. There were a few more competing apps on Android, but the overall pattern was the same — demand exists, but there's no great solution yet.

What I learned from competitor reviews

I downloaded the most direct competitor and tried it out. Read through the reviews too.

Users loved that it was "lightweight," "fast," and "easy to use." That confirmed the demand is real. I also saw feature requests and complaints, but I didn't adjust my app's direction based on those. I just took note and moved on. All I needed to confirm was two things: the market exists, and existing apps aren't perfect.

The result

After taking around 20 screenshots and going through everything, my keyword strategy changed completely. I dropped all the keywords I had picked during planning and rebuilt around the ones I found through this process.

What's next

The app is almost ready to ship. Right now I'm thinking about how to make the store screenshots stand out, and how to put together marketing content that actually grabs attention.

Flutter Apple Sign In Error 1000: The Fix No One Talks About

koreanDev — Fri, 10 Apr 2026 15:50:27 +0000

I'm building an iOS reading app solo. The idea is simple — save sentences that stop you while reading, turn them into beautiful cards, and share them. The stack is Flutter, Express/TypeScript, and Supabase. Authentication is handled with Apple Sign In.

Apple requires apps to support account deletion, or they'll reject your app during review. So I built it. And with Apple Sign In, deleting an account isn't just about wiping the user from your database. You have to revoke the Apple refresh_token too. That's how Apple officially disconnects the user from your app.

I got it working. Revoke call on the server, soft delete in the database. Everything looked fine.

Then It Broke

After testing account deletion, I tried signing in again. The moment I tapped the login button, it crashed. No Apple authentication sheet. Nothing. Just an error.

SignInWithAppleAuthorizationException(
AuthorizationErrorCode.unknown,
The operation couldn't be completed.
(com.apple.AuthenticationServices.AuthorizationError error 1000.)
)

My first thought was a bad request to Apple, or maybe a network issue. I deleted the app, reinstalled it. Same error.

Debugging

I was using the sign_in_with_apple Flutter package. To figure out exactly where it was failing, I added logs at every step inside signInWithApple().

debugPrint('🍎 [1] signInWithApple started');
debugPrint('🍎 [2] before appleLogin call');
final result = await repo.appleLogin();
debugPrint('🍎 [3] appleLogin complete');

The output was this:
🍎 [1] signInWithApple started
🍎 [2] before appleLogin call
🍎 [ERROR] SignInWithAppleAuthorizationException(...)

It crashed right after [2]. The package's getAppleIDCredential() method was failing instantly. No request ever reached the server. The Apple authentication sheet never even had a chance to appear.

This wasn't a server issue. It wasn't a Flutter logic issue. Something was wrong at a much lower level.

The Cause

After spending a little bit time on this with claude, I Googled it.

Sign in with Apple was missing from Xcode Capabilities.

At some point during a pod install or a Flutter dependency update, the Xcode project settings got reset and the capability disappeared. Without it, Apple Authentication Services simply doesn't work. It fails immediately and returns error 1000. The system blocks it before anything else runs.

The Fix

Xcode → Select Runner target → Signing & Capabilities → + → Add Sign in with Apple

That was it. After adding it back, the Apple authentication sheet appeared immediately.

One More Thing

I asked AI about this while debugging. Every single answer it gave was wrong. It pointed me toward token revocation policies, network issues, things that had nothing to do with the actual problem. I solved it by Googling myself.

AI is genuinely useful for a lot of things in development. But it doesn't always get it right. When you're stuck, don't forget that Google is still there.

Why Android Camera Permission Stops Showing After First Denial — A Flutter Deep Dive

koreanDev — Thu, 09 Apr 2026 14:49:38 +0000

About a year ago at my previous company, I got a task from my boss that seemed straightforward at first.

Our Flutter app had a structure where all permissions were requested at once during app initialization — handled inside a single service class that ran on startup. The request was simple: if a user denies camera permission at that point, make sure the permission popup shows up again when they navigate to a screen that actually needs the camera.

So I started working on it.

The Problem

On a Samsung Galaxy device, the behavior was not what I expected.

First request on app launch → popup shows up fine.

User denies it → navigates to the camera screen → tries to request again → nothing happens.

Flutter just returns "requested" with no popup.

const channel = MethodChannel('fida_app/camera_permission');
final result = await channel.invokeMethod('requestPermission', {
  'permission': 'android.permission.CAMERA',
});
// second call → result: "requested", no popup

I Thought It Was a Code Problem

My first instinct was to look at the native side. I checked PermissionHandler.kt and thought maybe the onRequestPermissionsResult callback wasn't properly connected to MainActivity. So I tried wiring it up.

That's when something unexpected happened. The app started freezing on the splash screen.

I couldn't pinpoint the exact cause, but my guess — and I later looked into this through ChatGPT — was that ad SDKs like AudienceNetworkAds and AdPopcornSSP were being initialized synchronously inside configureFlutterEngine(), blocking the main thread before Flutter could reach runApp().

The general fix for this kind of issue is to wrap those SDK calls in Handler.post { }, so they run after the Flutter engine has already attached.

// before — blocking the main thread
AudienceNetworkAds.initialize(this)
AdPopcornSSP.init(this, appKey)

// after — deferred asynchronously
Handler(Looper.getMainLooper()).post {
    AudienceNetworkAds.initialize(this)
    AdPopcornSSP.init(this, appKey)
}

I rolled back the permission code changes and the splash freeze went away. I had gone in to fix one thing and accidentally touched something else entirely.

The Actual Root Cause

I stepped back and thought about it more carefully.

What made this confusing was that the behavior wasn't consistent. Sometimes the popup showed up, sometimes it didn't — with no clear pattern. So naturally I assumed this was something I could control through code. That assumption was wrong.

I dug into this further with ChatGPT to understand the OS-level behavior, and the answer was simpler than I expected.

Android stores permission state at the OS level.

If granted → stored as GRANTED. Calling requestPermissions() again does nothing. The system just passes through silently.
If denied → stored as "explicitly denied". Standard Android policy allows another popup on the next request. But on Samsung One UI (Android 13~15), even a single denial can internally flip to Don't ask again state — skipping the popup on the very next call.

What looked like inconsistent behavior was actually Samsung's OEM customization policy sitting on top of standard Android rules. It wasn't something I could fix through code — the OS was making the call.

How Android Permission Behavior Changed Across Versions

While looking into this, I also checked how permission behavior evolved across Android API levels — again with the help of ChatGPT to get the details right.

API 22 and below (Android 5.x)

No runtime permissions. Everything was granted at install time.

API 23~29 (Android 6.0~10)

Runtime permissions introduced. On denial, shouldShowRequestPermissionRationale() returns true and the next request shows the popup again. The popup only gets permanently blocked if the user explicitly checks "Don't ask again" before denying.

API 30~32 (Android 11~12L)

One-time permissions added for camera, mic, and location. Choosing "Only this time" means the permission gets revoked when the app goes to background or closes — so the popup appears again on next entry. auto-reset was also introduced here: the OS automatically revokes permissions for apps that haven't been used in a while.

API 33+ (Android 13~)

Same behavior as above. Notification permission is now a separate runtime request (POST_NOTIFICATIONS). Camera permission logic stays the same.

Our app was on targetSdk = 35, minSdk = 23 — so all of these policies applied, including Samsung's OEM behavior on top.

iOS Is Simpler, But Stricter

iOS has one clear rule: deny once, and that's it.

After a user denies, AVCaptureDevice.requestAccess(for: .video) always returns false. The system will never show the popup again no matter how many times you call it.

The only option is to open the settings screen directly.

UIApplication.shared.open(
    URL(string: UIApplication.openSettingsURLString)!
)

I didn't know this at first and kept calling requestPermission from Flutter expecting something to happen. Nothing did.

To open the iOS settings screen from Flutter, you need to register a native channel in AppDelegate.swift.

let settingsChannel = FlutterMethodChannel(
    name: "fida_app/open_settings",
    binaryMessenger: controller.binaryMessenger
)
settingsChannel.setMethodCallHandler { call, result in
    if call.method == "openAppSettings",
       let url = URL(string: UIApplication.openSettingsURLString),
       UIApplication.shared.canOpenURL(url) {
        UIApplication.shared.open(url, options: [:], completionHandler: nil)
        result(nil)
    } else {
        result(FlutterMethodNotImplemented)
    }
}

So I Changed the Approach

What I originally expected:

Enter camera screen → call requestPermission → popup shows

What I actually built:

Enter camera screen
→ request permission
→ granted → proceed
→ denied
→ show explanation modal
→ try requesting again
→ still denied → open settings directly

Android flow:

static Future<bool> ensureCameraPermission(BuildContext context) async {
  String? result = await _channel.invokeMethod<String>(
    'requestPermission',
    {'permission': 'android.permission.CAMERA'},
  );

  if (result == 'granted') return true;

  bool retry = false;
  await showDialog(
    context: context,
    builder: (_) => AlertModal(
      message: 'Camera permission is required to use this feature.',
      onConfirm: () async { retry = true; },
    ),
  );

  if (retry) {
    result = await _channel.invokeMethod<String>(
      'requestPermission',
      {'permission': 'android.permission.CAMERA'},
    );
    if (result != 'granted') {
      await _settingsChannel.invokeMethod('openAppSettings');
    }
  }

  return result == 'granted';
}

iOS — go straight to settings on denial:

if (Platform.isIOS) {
  result = await _iosChannel.invokeMethod<String>('requestPermission');
  if (result == 'granted') return true;

  await _settingsChannel.invokeMethod('openAppSettings');
  return false;
}

The original ask was simple — show the permission popup again when users enter a camera screen after denying at launch. Turns out that’s not something you can freely control through code. The OS decides, and each platform has its own rules.

Understanding how the permission system actually works at the OS level was more useful than any code fix I could have written.

Provider to Riverpod AsyncNotifier: A Real Migration with Before & After Code

koreanDev — Mon, 06 Apr 2026 20:54:21 +0000

Recently, I made a decision to change the state management library in my personal app. For a long time, I used Provider and Bloc packages for state management. GetX as well.

In medium-scale apps, I prefer using Provider with the MVVM pattern. But I realized that currently in the Flutter community, most developers use Riverpod. I thought that Provider was going to become a legacy skill. Riverpod provides more convenience than Provider, in terms of dependency injection and overall usability.

Riverpod doesn't rely heavily on context and the widget tree, and it allows easier testing.

My App's Architecture

Previously, my app's architecture followed Feature-First and Clean Architecture partially. The reason I designed it that way was that this was a private app and I didn't want to create a lot of boilerplate. But I did want to make this app maintainable and scalable. So even if I see this code again in the future, I can easily read it.

On the project root, there was a feature folder, and it included individual feature folders. Each feature had its own data, domain, and presentation folders. When a new feature was added, it would be placed in the feature folder, and it would have its own data, domain, and presentation folders as well.

When I changed Provider to Riverpod, my app's architecture didn't require many changes. My app didn't have many features, so I could easily refactor it.

What Changed

I just changed the spot where dependencies were injected, and changed ChangeNotifier to AsyncNotifier. The domain layer and data layer were not affected at all. I just changed some Provider functions to Riverpod methods.

When I used the Provider package, I followed the MVVM pattern, and after the migration, it didn't change. Because the architecture separated concerns properly, the migration only affected the presentation layer.

I haven't added an abstract layer or use cases yet, because it's enough to add them when needed.

Technical Decisions

During this process, I made some technical decisions. First of all, as far as I know, there are a few coding approaches when using Riverpod, such as StateNotifier, Notifier/AsyncNotifier, and codegen.

In my project, every API call was async, and the codegen approach would make this project over-engineered. So I thought AsyncNotifier was the best choice for my case.

Migration with Claude Code

I didn't want to migrate file by file, so I decided to use Claude Code for the migration. I focused on making sure Claude Code didn't touch the overall structure and approached the project carefully. I wanted to easily read the migrated code after the migration.

Here is the prompt I used:

Migrate the entire Flutter project from Provider to Riverpod (AsyncNotifier, no codegen).

## Scope
- Remove `provider` package, add `flutter_riverpod`
- Convert all ChangeNotifier classes to AsyncNotifier
- Declare Repositories as global Riverpod Providers
- Replace MultiProvider in main.dart with ProviderScope
- Convert all UI files using Provider API (Consumer, context.read, context.watch) to ConsumerWidget + ref
- Preserve all existing behavior: auto-login, country selection branching, book search/add/list

## Migration comments
Add brief inline comments at key migration points for learning reference.
Format: `// Migration: [what changed and why]`
Keep comments concise — one line per migration point, only at meaningful changes.

## Rules
- Do NOT modify Repository classes (data layer stays untouched)
- Do NOT modify Entity/model classes
- Do NOT add new features or refactor business logic
- Keep the same file/folder structure

Before & After

DI — main.dart

Before (Provider):

// main.dart
return MultiProvider(
  providers: [
    ChangeNotifierProvider(
      create: (_) => AuthProvider(AuthRepository()),
    ),
    ChangeNotifierProvider(
      create: (_) => BookProvider(BookRepository()),
    ),
  ],
  child: MaterialApp(...),
);

After (Riverpod):

// main.dart
runApp(const ProviderScope(child: MyApp()));

// di.dart — Repositories declared as global providers
final authRepositoryProvider = Provider((ref) => AuthRepository());
final bookRepositoryProvider = Provider((ref) => BookRepository());

MultiProvider and constructor injection were replaced by ProviderScope at the root and global provider declarations. Dependencies are now resolved through ref instead of being passed through constructors.

State Management — book_provider.dart

Before (Provider):

class BookProvider with ChangeNotifier {
  final BookRepository _repository;
  BookProvider(this._repository);

  List<Book> books = [];
  bool isLoading = false;
  String? error;

  Future<void> fetchBooks() async {
    isLoading = true;
    error = null;
    notifyListeners();
    try {
      books = await _repository.getBooks();
    } catch (e) {
      error = e.toString();
    } finally {
      isLoading = false;
      notifyListeners();
    }
  }
}

After (Riverpod):

class BookNotifier extends AsyncNotifier<List<Book>> {
  @override
  Future<List<Book>> build() async {
    return ref.read(bookRepositoryProvider).getBooks();
  }

  Future<bool> addBook(Book book) async {
    try {
      await ref.read(bookRepositoryProvider).addBook(book);
      ref.invalidateSelf();
      return true;
    } catch (e) {
      return false;
    }
  }
}

final bookNotifierProvider =
    AsyncNotifierProvider<BookNotifier, List<Book>>(BookNotifier.new);

The isLoading, error, and notifyListeners() boilerplate disappeared entirely. AsyncValue handles loading, error, and data states automatically. The build() method replaces the manual fetchBooks() that was called in initState.

UI — books_page.dart

Before (Provider):

class BooksPage extends StatefulWidget {
  // ...
  @override
  State<BooksPage> createState() => _BooksPageState();
}

class _BooksPageState extends State<BooksPage> {
  @override
  void initState() {
    super.initState();
    WidgetsBinding.instance.addPostFrameCallback((_) {
      context.read<BookProvider>().fetchBooks();
    });
  }

  @override
  Widget build(BuildContext context) {
    return Consumer<BookProvider>(
      builder: (context, provider, _) {
        if (provider.isLoading) return const CircularProgressIndicator();
        if (provider.error != null) return Text(provider.error!);
        // ...
      },
    );
  }
}

After (Riverpod):

class BooksPage extends ConsumerWidget {
  // ...
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final asyncBooks = ref.watch(bookNotifierProvider);

    return asyncBooks.when(
      loading: () => const CircularProgressIndicator(),
      error: (e, _) => Text(e.toString()),
      data: (books) => ListView.builder(...),
    );
  }
}

StatefulWidget with initState became a simple ConsumerWidget. The ref.watch automatically triggers the initial fetch and rebuilds the UI when data changes. The asyncBooks.when() pattern replaces the manual if/else chain for loading, error, and data states.

As a next step, I'm planning to add an abstract layer and use cases. My app has two ways to add a book — manual input and search via API — so abstracting this part makes sense. But before that, I want to refine the product direction and find a sharper niche first.

"This AdWidget is already in the Widget tree" — It Only Crashed After One Specific Flow

koreanDev — Thu, 02 Apr 2026 20:01:56 +0000

The Error

I was working on a Flutter app that uses google_mobile_ads for banner ads. One day, I got this error on the MyPage screen:

This AdWidget is already in the Widget tree

Make sure you are not using the same ad object in more than one AdWidget.

The error message was clear. But the weird thing was — it didn't always happen.

Finding the Pattern

I tested different scenarios and found a pattern:

Switch tabs normally → no crash
Go to another page and come back → no crash
Update address → go back to main page → open MyPage tab → crash

So the question became: what's different about the address update flow?

What Was Different

The app uses BottomNavigationBar with IndexedStack. After the address update, the code navigated back to the main page like this:

Navigator.push(
  context,
  MaterialPageRoute(builder: (context) => MainPage()),
);

This looks normal. But Navigator.push adds a new page on top of the stack. It does not remove the old one. So the old MainPage — and the old MyPage inside it — was still alive in memory.

When I opened MyPage on the new MainPage, the old MyPage's State was still holding a BannerAd with its AdWidget mounted. Now there were two AdWidgets trying to use the same ad resources at the same time. That's why it crashed.

In normal tab switching, this never happened because there was only one MainPage and one MyPage State.

The Fix

I changed Navigator.push to Navigator.pushAndRemoveUntil:

Navigator.pushAndRemoveUntil(
  context,
  MaterialPageRoute(builder: (_) => MainPage()),
  (route) => false,
);

This clears the entire navigation stack. The old MainPage and its MyPage get properly disposed. When the user opens MyPage again, it's a completely new instance — no duplicate AdWidget.

After this change, the crash never happened again.

I Also Removed `didUpdateWidget` for Ads

The original code had this:

@override
void didUpdateWidget(covariant MyPage oldWidget) {
  super.didUpdateWidget(oldWidget);
  _bannerAd?.dispose();
  _bannerAd = AdHelper.createBannerAd();
}

This recreated the ad every time the parent widget rebuilt. But if the old AdWidget was still in the tree, disposing and recreating the ad caused the same duplication problem. I removed this entirely. Banner ads should only be created in initState and cleaned up in dispose.

Key Takeaway

The google_mobile_ads plugin internally tracks whether each ad is already mounted in the widget tree. In the source code (ad_containers.dart), _AdWidgetState.initState checks the ad's ID through instanceManager.isWidgetAdIdMounted(). If the ad is already mounted somewhere, the build method throws the "already in the Widget tree" error. The ad ID is only released when _AdWidgetState.dispose calls unmountWidgetAdId. This means one BannerAd can only be used by one AdWidget at a time — the plugin enforces this at the code level.

The real lesson was about navigation. Navigator.push keeps the old page alive. If that page owns native resources like ads, those resources stay alive too — and the old AdWidget never gets disposed, so the ad ID is never released. When you need to "reset" to the main page, use pushAndRemoveUntil to make sure the old state is fully disposed.

Flutter iOS: Did Not Find a Dart VM Service — Fixed by Recreating the Xcode Runner Scheme

koreanDev — Sun, 29 Mar 2026 15:37:57 +0000

The Dart VM Service was not discovered after 60 seconds. This is taking much longer than expected... Open the Xcode window the project is opened in to ensure the app is running.

If the app is not running, try selecting "Product > Run" to fix the problem.

blah blah..

Error: Did not find a Dart VM Service advertised for com.app.myproject.

I got stuck on this error while building an iOS app in Android Studio. The strange thing was that the app built just fine in Xcode.
At first, I suspected it might be related to iOS local network permissions.

"Did not find a Dart VM Service" usually means the Flutter framework failed to connect over the local network. So I checked whether my Info.plist included the NSLocalNetworkUsageDescription key.

But the key was already included in my Info.plist file.

I decided to reinstall the app to retrigger the permission prompt. I deleted the app from my iPhone.

And I tried resetting the trust settings on my iPhone.
I went to Settings > General > Transfer or Reset iPhone > Reset > Reset Location & Privacy, then reconnected via USB to trigger the "Trust This Computer?" prompt again.

After tapping Trust, I launched the app — it came to the foreground, and the local network permission popup appeared. I allowed it.
But nothing happened. No connection. Flutter was still silent.

I can't remember every single thing I tried at that time. I tried many things to get it building on Android Studio.

At some point, I realized — I had switched from an iPhone 8 to an iPhone 12 right before this issue started. Both were my debugging devices, and I hadn't thought much about it at the time. That felt like the real clue.

I shared this suspicion with AI, and it confirmed that this is actually a common issue. When you change the target debug device, Xcode's internal project configuration can get corrupted — the Runner Scheme ends up still tied to the old device's settings.

So I went to Product > Scheme > Manage Schemes in Xcode, deleted the existing Runner scheme, and created a new one.

After that, the app finally built successfully on Android Studio — and kept working after restarts.

Before Writing Code, I Write the Spec Myself

koreanDev — Mon, 23 Mar 2026 15:21:22 +0000

Before you start coding, you usually need to clearly define what needs to be built. In other words, you take unclear requirements and turn them into actual features based on what you hear from your client, senior developer, or designer.

I started my career in a small company, and in many small companies, the development process is not well systemized. (I'm in Korea.)
In my case, I often didn't receive proper feature specification documents, and sometimes there were no API documents at all.

Because of that, I had to take responsibility for clarifying the requirements myself. I would summarize the feature requirements, write them down in my own words, and then go back to confirm whether my understanding was correct.

This process helped me avoid misunderstandings and reduce unnecessary rework during development.

Regardless of company size, clear documentation is essential. When it's properly shared and used across the team, it helps reduce unnecessary communication and meetings.

Recently, I did some additional work for a previous company.

The requirements were mainly about user verification use cases.
My boss was not a developer and didn't have much knowledge of programming. Because of that, the requirements were often quite messy and not clearly defined, so I had to put effort into organizing and structuring them myself.

Our app had multiple user statuses, such as guest, blocked user, and pending user. However, communication between the backend and frontend was not very clear, which made things more complicated.

To solve this, I broke down the user verification flow into clearly defined statuses and documented them. For example:

*** Non-member**

guest: active && none (no authentication)

*** Member **

user: pending && not_submitted (just signed up)
user: pending && submitted (documents submitted to admin)
user: active && approved (approved by admin)
user: pending && rejected (rejected by admin)

To make sure my understanding was correct, I created a Confluence document based on this.

It worked as a shared reference for everyone involved - my boss could verify that each use case matched what he had in mind, and the backend developer could confirm whether the status values he was returning were correct.

Another thing I liked was that whenever requirements changed or something new was added, we could just update that one document. No more back-and-forth messages trying to remember what we agreed on.

One doc, three people, way less confusion.

Flutter App Stuck on Splash Screen: A dev_dependencies Mistake

koreanDev — Thu, 19 Mar 2026 12:34:45 +0000

Recently, i added some features to my side project flutter app.
The app is available on both platforms: Google Play Store and App Store.

If I release to both platforms at once and some bugs occur, it would be difficult to handle.
So I decided to release my new build to the Google Play Store first.
After the new build was released on the Google Play Store, I installed the app.
But something went wrong.

I couldn't access the main page. The app was stuck on the splash screen.

At that moment, something came to my mind.
I had just resolved an issue related to the sign_button package.
I was using the sign_button package on the login page, but the Apple login button didn't render correctly.

So I replaced it with the sign_in_button package and added it to dependencies in the pubspec.yaml file.
I started to think that I might have messed up the pubspec.yaml structure while doing this.
I might have placed the package in the wrong section.

It should have been in dependencies, but I accidentally added it to dev_dependencies.
I checked my pubspec.yaml again and realized that I had placed the package in dev_dependencies.
So I modified it and submitted a new build again. After that, the problem was solved.

If Flutter packages are placed in the dev_dependencies section, the app can still build while running in the debug environment.
But if they have runtime dependencies, they should be placed in the dependencies section.

Otherwise, crash problems can happen.
Actually, most Flutter packages have runtime dependencies, except for a few packages,
such as flutter_test, flutter_lints, and flutter_launcher_icons.
These have nothing to do with running the app.

Google Play Store reviewers are not that strict, i think.
I assume they didn't test my new build in the release environment.
Anyway, I fixed the packages in pubspec.yaml properly.

What My Failed Apps Taught Me About Building Products

koreanDev — Wed, 18 Mar 2026 11:19:06 +0000

I have released a few apps on the app stores.

Most of them were small-scale applications.

They were not built for learning purposes.

These apps had fewer than five pages

and only one or two features.

Pop-up advertisements were shown to users on almost every page.

That was okay.

I did build these apps mainly for ad revenue.

But there was a problem.

Most of them had very low retention.

They didn’t really make money,

and they didn’t give me meaningful experience either.

That said, not all of my apps were built casually.

I did put real effort into a fortune-telling app

and an emotion tracking app.

They were more complete technically,

but the planning and features were driven mostly by my assumptions,

not by actual user needs.

In that sense, they also failed.

Interestingly, a very simple Korean language learning app

that I built with much less effort

is still generating around three to four dollars per day.

At some point, I felt that even if I made no ad revenue at all,

I just wanted the experience of running an app

where users actually accumulate over time.

And I needed a Flutter portfolio.

My Git repository was full of low-quality apps.

I didn’t really have anything I could call a portfolio,

nothing that clearly showed my experience or skills,

even though I had been developing for almost five years.

Long story short,

these days I decided to start another app.

This time, I’m really focusing on planning.

I’m comparing similar apps

and spending a lot of time researching

what kind of app makes sense to build,

based on niche markets and real user needs.

At the beginning, I considered making a running app

that helps people with running.

But I dropped that idea at the planning stage.

I didn’t want to compete with big applications

like Nike Run Club.

Beyond that,

there are already too many apps

that simply measure distance.

So now I’m about to make an app related to book reading.

I joined a book reading group on a social media app,

and I’m quite active in that group.

Because of that, I know there are many people

who are interested in growing their reading habits

or recording book phrases that impressed them.

Actually, I’m rarely coding right now.

I’m mostly forming the directory structure

and considering which libraries would fit this project.

As much as possible, I want to choose effective tools,

considering maintainability and scalability.

I don’t want to overengineer it,
but I do want to build a well-structured project.

DEV Community: koreanDev

Why I Switched from http to Dio in Flutter — Centralizing Error Tracking with Interceptors

The problem

Before: http package

After: Dio + Interceptors

AuthInterceptor — auto token injection

CrashlyticsInterceptor — auto error logging

Result

Migration scope

3 bugs from Claude Code

1. Wrong endpoint path

2. Token not attached

3. JSON key mismatch

Summary

I Debugged Xcode for Hours. The Bug Was in My Joi Schema.

I Debugged Xcode for Hours. The Bug Was in My Joi Schema.

Claude Code for Solo Developers — Prompt Engineering That Keeps Things Clean

I wrote prompts with Claude, not for Claude

1 — Always declare the scope

2 — Give architecture context in one line

3 — Split the work

4 — Product decisions are mine to make

What I didn't know

Wrapping up

I Threw Away My Keyword Strategy Right Before Launch — Here's What I Did Instead

Some context

Why I went back to check the keywords

What I was really looking for

I started searching myself

First search: my original target

Second search: similar keyword

Third search: a feature-based keyword

Fourth search: the turning point

More searches: finding more gaps

What autocomplete told me

Checked Android too

What I learned from competitor reviews

The result

What's next

Flutter Apple Sign In Error 1000: The Fix No One Talks About

Then It Broke

Debugging

The Cause

The Fix

One More Thing

Why Android Camera Permission Stops Showing After First Denial — A Flutter Deep Dive

The Problem

I Thought It Was a Code Problem

The Actual Root Cause

How Android Permission Behavior Changed Across Versions

iOS Is Simpler, But Stricter

So I Changed the Approach

Provider to Riverpod AsyncNotifier: A Real Migration with Before & After Code

My App's Architecture

What Changed

Technical Decisions

Migration with Claude Code

Before & After

DI — main.dart

State Management — book_provider.dart

UI — books_page.dart

"This AdWidget is already in the Widget tree" — It Only Crashed After One Specific Flow

The Error

Finding the Pattern

What Was Different

The Fix

I Also Removed didUpdateWidget for Ads

Key Takeaway

Flutter iOS: Did Not Find a Dart VM Service — Fixed by Recreating the Xcode Runner Scheme

The Dart VM Service was not discovered after 60 seconds. This is taking much longer than expected... Open the Xcode window the project is opened in to ensure the app is running.

Before Writing Code, I Write the Spec Myself

Flutter App Stuck on Splash Screen: A dev_dependencies Mistake

What My Failed Apps Taught Me About Building Products

I Also Removed `didUpdateWidget` for Ads