· flutter · 9 min read

This week developing in Flutter - Riverpod - Firebase - Posthog - GoRouter

Refactoring Authentication, removing Firebase Analytics, Added Go_Router

This week I mainly focused on the “Pickleball Eye Trainer” application. Here is a summary of what I did:

  • Rewrite the entire UserRepository to be a “Riverpod Notifier” instead of a simple future provider.
  • Add the AppStartupWidget from @CodeWithAndrea
  • Added Go_Router to the app
  • Remove Firebase Analytics for Posthog

Rewrite the UserRepository

After writing the post about how I implemented authentication with Firebase and Riverpod for my simple application, I decided to improve the code a bit more because there was a small flaw with that approach:

Every time the user saved their state, the whole provider needed to invalidate itself and therefore call Firebase again.

For a small app it’s okay because you have 50,000 reads daily, but believe me, those can be used quite fast. I was looking at how many reads per day I had (see following screenshot) and for my current number of users, that’s way too high.

How do I explain that

  1. The userRepository does a read for every user save (after a game finishes, if they buy an item, etc.).
  2. I was loading the game_assets (items of my app) and achievements from Firebase, and every time the user opened the app it was generating approximately 100 reads just for the items and achievements.

How did I solve that

UserRepository

There will be only one read when the user loads the app, and then it’s going to return the cached user. When we write something to the user, we will update that cached user and send a request to write in Firebase, but we won’t wait for it to return.


part 'user_repository.g.dart';

class UserState {
  const UserState({
    required this.appUser,
    this.firebaseUser,
  });

  final AppUser appUser;
  final User? firebaseUser;

  @override
  String toString() {
    return 'UserState(appUser: ${appUser.name}, firebaseUser: ${firebaseUser?.uid})';
  }
}

@Riverpod(keepAlive: true)
class UserRepository extends _$UserRepository {
  final FirebaseAuth _auth = FirebaseAuth.instance;
  final FirebaseFirestore _firestore = FirebaseFirestore.instance;

  // Add cached user reference
  AppUser? _cachedAppUser;

  @override
  Future<UserState> build() async {
    final firebaseUser = _auth.currentUser;
    if (firebaseUser == null) {
      return UserState(appUser: AppUser.empty());
    }

    // Use cached user if available
    if (_cachedAppUser != null) {
      return UserState(
        appUser: _cachedAppUser!,
        firebaseUser: firebaseUser,
      );
    }

    // Get corresponding AppUser and cache it
    final appUser = await _getAppUser(firebaseUser.uid);
    _cachedAppUser = appUser;
    return UserState(
      appUser: appUser,
      firebaseUser: firebaseUser,
    );
  }

  Future<void> updateUser(Map<String, Object?> data) async {
    final currentState = state.value;
    if (currentState?.firebaseUser == null) return;

    // Update cache immediately using AppUser's update method
    _cachedAppUser = currentState!.appUser.copyWithMap(data);

    // Update state immediately
    state = AsyncData(
      UserState(
        appUser: _cachedAppUser!,
        firebaseUser: currentState.firebaseUser,
      ),
    );

    // Fire and forget Firebase update
    unawaited(_getAppUserRef(currentState.firebaseUser!.uid).update(data));
  }
}

Like before, I can retrieve my user like before this way


 // to get my app user.
 final user = ref.read(userRepositoryProvider).requireValue.appUser;


 // to call any of the method of the userRepositoryProvider
 ref
    .read(userRepositoryProvider.notifier)
    .updateUserFromUser(user);

Static data aka Game assets

I had them in Firebase because I wanted the flexibility to change the item prices in coins, for example, for everyone on the fly.

I was using a caching mechanism as this one (this is for the leaderboard but it was the same idea)

@riverpod
Future<List<LeaderboardItem>> loadLeaderboard(Ref ref) async {
  const lastUpdateKey = 'last_leaderboard_update';
  final prefs = await SharedPreferences.getInstance();
  final lastUpdate = prefs.getString(lastUpdateKey);
  final now = DateTime.now();

  if (lastUpdate == null ||
      DateTime.parse(lastUpdate)
          .isBefore(now.subtract(const Duration(days: 1)))) {
    final data = await _fetchLeaderboard(Source.server);
    await prefs.setString(lastUpdateKey, now.toIso8601String());
    return data;
  }

  // Otherwise use cache
  return _fetchLeaderboard(Source.cache);
}

Future<List<LeaderboardItem>> _fetchLeaderboard(Source source) async {
  final scoresSnapshot = await FirebaseFirestore.instance
      .collection('scores')
      .withConverter(
        fromFirestore: (snapshot, _) =>
            LeaderboardItem.fromMap(snapshot.data()!),
        toFirestore: (value, options) => value.toMap(),
      )
      .get(GetOptions(source: source));

  return scoresSnapshot.docs.map((e) => e.data()).toList()
    ..sort((a, b) => a.order.compareTo(b.order));
}

The only difference was that I was caching the data for 7 days, so I will revalidate the cache only every 7 days. You can use different strategy to invalidate your cache but for me it was good enough :)

I took the decision to put all the game_assets directly inside the application, so it’s just a static variable inside the app with all the info. No more calls to Firebase for that. I lost my flexibility to update on the fly but I don’t have that many reads anymore.

A lot of people download the app, play 5 games then never open the app again, so I felt like a lot of resources were being used for nothing. If I feel it’s necessary, I might improve this by switching back to server mode if the user plays more than x days or if they login, for example.

Side note about Leaderboard

For the Leaderboard, I’m storing in firebase the top 100 users for 4 categories. To reduce the read, I decided to use an Map Array in Firestore.

Here is the full class for the LeaderboardItem

import 'package:cloud_firestore/cloud_firestore.dart';

class LeaderboardItem {
  LeaderboardItem({
    required this.updatedTime,
    required this.title,
    required this.order,
    required this.playerScore,
  });

  factory LeaderboardItem.empty() => LeaderboardItem(
        updatedTime: Timestamp.now(),
        playerScore: [],
        title: '',
        order: 0,
      );

  factory LeaderboardItem.fromMap(Map<String, dynamic> map) {
    return LeaderboardItem(
      updatedTime: map['updated_time'] as Timestamp,
      title: map['title'] as String,
      order: map['order'] as num,
      playerScore: List<LeaderboardPlayer>.from(
        (map['player_score'] as List).map(
          (x) => LeaderboardPlayer.fromMap(x as Map<String, dynamic>),
        ),
      ),
    );
  }

  final Timestamp updatedTime;
  final List<LeaderboardPlayer> playerScore;
  final String title;
  final num order;

  Map<String, dynamic> toMap() {
    return <String, dynamic>{
      'updated_time': updatedTime,
      'player_score': playerScore.map((x) => x.toMap()).toList(),
      'title': title,
      'order': order,
    };
  }

  @override
  String toString() =>
      'LeaderboardItem(updatedTime: $updatedTime, playerScore: $playerScore, title: $title, order: $order)';

  LeaderboardItem copyWith({
    Timestamp? updatedTime,
    List<LeaderboardPlayer>? playerScore,
    String? title,
    num? order,
  }) {
    return LeaderboardItem(
      updatedTime: updatedTime ?? this.updatedTime,
      playerScore: playerScore ?? this.playerScore,
      title: title ?? this.title,
      order: order ?? this.order,
    );
  }
}

class LeaderboardPlayer {
  LeaderboardPlayer({
    required this.playerName,
    required this.uid,
    required this.score,
  });

  factory LeaderboardPlayer.fromMap(Map<String, dynamic> map) {
    return LeaderboardPlayer(
      playerName: map['player_name'] as String,
      uid: map['uid'] as String,
      score: map['score'] as num,
    );
  }

  final String playerName;
  final String uid;
  final num score;

  Map<String, dynamic> toMap() {
    return <String, dynamic>{
      'player_name': playerName,
      'uid': uid,
      'score': score,
    };
  }

  @override
  String toString() =>
      'LeaderboardPlayer(playerName: $playerName, uid: $uid, score: $score)';
}

So now, it generates only 4 reads to read the whole leaderboard.

AppStartupWidget

If you don’t know CodeWithAndrea and you are into flutter development, well you should have a look. In his latest newsletter he spoke about a robust way to App Initialization. His article here https://codewithandrea.com/articles/robust-app-initialization-riverpod/ .

I love the idea, and before I was just Waiting all in my main, now I’ve this nice way that at least show a message to the user if something went wrong


  // in my main, I still have some initialization which are "Configuration initialization"
  await Future.wait([
    CustomFirebase.ensureInitialized(),
    CustomPurchase.ensureInitialized(),
    SystemChrome.setPreferredOrientations([DeviceOrientation.portraitUp]),
    CustomAnalytics.ensureInitialized(),
    EasyLocalization.ensureInitialized(),
  ]);

  // app_startup.dart

part 'app_startup.g.dart';

// https://codewithandrea.com/articles/robust-app-initialization-riverpod/
@Riverpod(keepAlive: true)
Future<void> appStartup(Ref ref) async {
  ref.onDispose(() {
    ref
      ..invalidate(sharedPreferencesProvider)
      ..invalidate(onboardingRepositoryProvider)
      ..invalidate(userRepositoryProvider);
  });

  await ref.read(sharedPreferencesProvider.future);

  await Future.wait([
    ref.read(onboardingRepositoryProvider.future),
    ref.read(loadAchievementsProvider.future),
    AppDatabase.ensureInitialized(),
    ref.read(userRepositoryProvider.future),
    _precacheImageFromAsset(splashBgAsset),
    _precacheImageFromAsset(splashMidAsset),
  ]);
}


/// Widget class to manage asynchronous app initialization
class AppStartupWidget extends ConsumerWidget {
  const AppStartupWidget({required this.onLoaded, super.key});
  final WidgetBuilder onLoaded;

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final appStartupState = ref.watch(appStartupProvider);
    return appStartupState.when(
      data: (_) => onLoaded(context),
      loading: () => const AppStartupLoadingWidget(),
      error: (e, st) => AppStartupErrorWidget(
        message: e.toString(),
        onRetry: () => ref.invalidate(appStartupProvider),
      ),
    );
  }
}

/// Widget to show while initialization is in progress
class AppStartupLoadingWidget extends StatelessWidget {
  const AppStartupLoadingWidget({super.key});

  @override
  Widget build(BuildContext context) {
    return const Scaffold(
      body: Stack(
        children: [
          Image(
            image: AssetImage(splashBgAsset),
            fit: BoxFit.cover,
            width: double.infinity,
            height: double.infinity,
          ),
          Center(
            child: Image(
              image: AssetImage(splashMidAsset),
            ),
          ),
        ],
      ),
    );
  }
}

/// Widget to show if initialization fails
class AppStartupErrorWidget extends StatelessWidget {
  const AppStartupErrorWidget({
    required this.message,
    required this.onRetry,
    super.key,
  });
  final String message;
  final VoidCallback onRetry;

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(),
      body: Center(
        child: Column(
          spacing: 16,
          mainAxisSize: MainAxisSize.min,
          children: [
            Text(message, style: Theme.of(context).textTheme.headlineSmall),
            ElevatedButton(
              onPressed: onRetry,
              child: const Text('Retry'),
            ),
          ],
        ),
      ),
    );
  }
}

My main.dart will still have some initialization that can only crash when a configuration is wrong. In my app_startup I’ll have all the other one. In my previous implementation, that’s where I was also loading my static assets from Firebase.

Added Go_Router to the app

Really, I don’t know why I did that… :) It has no real value for my users (they won’t see the changes); for me it was a really annoying task.

This app “Pickleball Eye Trainer” is a “Base App” for me. Once I’ve implemented all the Game mechanics I want to implement (Achievements, Daily Missions, Weekly Missions, Daily Rewards, etc.), I’ll use it as a template for other games.

There is still a small win with Go_Router package and it’s the “redirect” mechanic.

  GoRouter(
    ... some routes
    refreshListenable: GoRouterRefreshStream(
      ref.read(userRepositoryProvider.notifier).authStateChanges(),
    ),
    redirect: (context, state) {
      final onboardingRepo =
          ref.read(onboardingRepositoryProvider).requireValue;
      final user = ref.read(userRepositoryProvider).requireValue;
      final userAlreadyExist = user.firebaseUser != null;

      final isOnboardingComplete = onboardingRepo.isOnboardingComplete();
      final isDialogOnboardingComplete =
          onboardingRepo.isDialogOnboardingComplete();

      if (state.uri.toString().contains('/onboarding') &&
          isOnboardingComplete &&
          isDialogOnboardingComplete &&
          userAlreadyExist) {
        ref.read(logUserProvider(user.firebaseUser!.uid).future);

        final userProperties = {
          'name': user.appUser.name,
          'gender': user.appUser.gender,
        };
        ref.read(
          identifyProvider(
            user.firebaseUser!.uid,
            userProperties: userProperties,
          ),
        );
        return '/';
      } else if (!isDialogOnboardingComplete &&
          isOnboardingComplete &&
          state.uri.toString().contains('/onboarding')) {
        ref.read(logUserProvider(user.firebaseUser!.uid).future);

        final userProperties = {
          'name': user.appUser.name,
          'gender': user.appUser.gender,
        };
        ref.read(
          identifyProvider(
            user.firebaseUser!.uid,
            userProperties: userProperties,
          ),
        );
        return '/real';
      } else if (!userAlreadyExist &&
          !isOnboardingComplete &&
          !state.uri.toString().contains('/onboarding')) {
        return '/onboarding';
      }

      return null;
    },
  )
  1. redirect: Before I was doing that inside the build method of my first component which was a bit hacky, now I do that in the redirect mechanism.
  2. refreshListenable : So now, when the user signOut, it will trigger the redirect mechanism and so automatically redirect him to the onboarding page

Remove Firebase Analytics for Posthog

I don’t like Google Analytics… I don’t know why, it has never clicked with me. Someone recommended me to switch to Posthog and so I did. They have a Flutter SDK which works great.

I must say it’s way easier to configure a meaningful dashboard compared to Google Analytics.

They are in Beta for Session Replay and so it’s free right now, which is a great feature. I can see where my users click in the app and really follow them; that will help me understand where they drop off.

Conclusion

That’s all for this week. Next week I’ll work on adding Easy_Localization and translate the app into 5 languages, then add UpgradeAlert to the app so I can force users to update the app and not stay on an old version if needed. I plan to also explain how I use RevenueCat in my app or maybe write about sqflite.

Share:
Back to Blog