If you have ever spent hours taking manual screenshots, wrestling with complex UI test setups, or trying to configure Fastlane for multiple device sizes and localizations, you know it can be a tedious process.

Over the weekend, I released a new package called flutter_store_screenshots to make this workflow smooth, visual, and highly efficient.

But wait, aren't there already dozens of screenshot tools out there? Yes, there are. But this package takes a fundamentally different approach. Here is why it completely changes the game.

The Problem with Existing Workflows

Most existing screenshot tools fall into one of two categories, and both come with specific challenges:

1. The Beautiful Wrappers: Tools that put your screenshots inside a nice device frame with a gradient background and a catchy title. They look great, but you still have to provide the raw screenshots yourself. If you change a button color or a layout feature in your app, you have to retake all those base images manually.

2. The Automation Monsters: Solutions that integrate with UI tests (like integration tests or Fastlane framing). While powerful, setting up UI tests just to snap pictures is incredibly complex. You have to maintain test scripts, handle mock data or asynchronous loading, and run them across countless device simulators and localized environments.

Neither of these solutions leverages the true power of what we already do best: building UIs with Flutter.

The Solution: Screenshots as Widgets

flutter_store_screenshots takes a completely different route. It doesn't ask you to manually take photos, and it doesn't force you into complex automated testing.

Instead, it treats your screenshots exactly like the rest of your app: as Flutter Widgets.

The core idea is elegant: You create a tiny companion project (a Flutter desktop app, optimized for macOS) right next to your main mobile application. This project takes a dependency on both your actual app and the flutter_store_screenshots package.

Because you have direct access to your app's codebase, you can import and render your real app UI directly inside the screenshot builder.

Instead of writing test scripts to navigate to a specific page, you just instantiate the Widget directly:

StoreScreenshot(
  name: 'home_screen',
  builder: (context) => const HomeScreen(),
),

Absolute Flexibility and Control Since you are writing standard Flutter code, you have ultimate control over how the screenshots look. The package automatically handles the heavy lifting of simulating different operating systems, screen sizes, and localizations. It passes this environment data down via the BuildContext.

Want a plain, full-screen snapshot of your UI? Done. Want a highly customized, branded store asset with a custom font, background gradients, device frames, and translated marketing text? Just build it with Widgets!

StoreScreenshot(
  name: 'home_fancy',
  builder: (context) => MyFancyStoreFrame(
    title: mapLocalizationToText(context),
    device: Devices.ios.iPhone15ProMax,
    child: const HomeScreen(),
  ),
),

If you know how to build a layout in Flutter, you already know how to design your perfect App Store assets. No external design tools, no complex configurations.

The Real Superpower: Instant Updates

The biggest drain on a developer's time isn't creating the first set of screenshots, it's updating them when the app evolves.

When you change a feature, tweak your branding, or update a page design, traditional workflows require you to redo everything from scratch. With this package, your screenshots are inherently tied to your live production UI.

If you update the HomeScreen in your main app, your screenshot project automatically reflects those changes. You simply run your desktop screenshot app, preview how the screens look across all configurations in real-time, and hit Export. With a single click, a fresh batch of perfect store assets is generated and saved directly to your disk.

A Faster Way to Ship

Generating store assets shouldn't be a bottleneck in your release cycle. By leveraging the power of Flutter’s own rendering engine and desktop capabilities, you can turn screenshot generation into a seamless, visual, and highly maintainable part of your development process.

Ready to streamline how you ship your apps?

👉 Check out flutter_store_screenshots on pub.dev to see the full documentation, or dive straight into the GitHub example project to get started.

While the promise of using AABs via FAD—leveraging the Google Play Console's infrastructure—is appealing, the actual setup and testing experience is often frustrating, counter-intuitive, and requires far more configuration than anticipated.

In my opinion, the increased complexity and hidden obstacles make uploading standard APKs a far superior and faster way to start testing.

Here is a breakdown of the three major hurdles I encountered, followed by a guide on how to get it working and my final verdict.

1. The Setup: A Deceptively High Barrier to Entry

The official documentation suggests you only need to have your app published on "at least one track" (like the Internal Test Track) to link Firebase and the Google Play Console. This proved to be insufficient.

The Reality: You Need a Near-Complete Play Store Listing

Despite having multiple builds successfully running on the Internal Test Track, I constantly ran into the infamous error:

"1 linked app is not on a published track in Google Play"

This error persists unless you have completed a significant portion of the tedious Google Play listing configuration, including details that seem irrelevant for private test distribution (e.g., store graphics, privacy policy links, target audience, content rating questionnaires).

• The Cost: The "quick start" promised by FAD and AABs forces you to complete a substantial part of your production configuration just to distribute a test build. The threshold for simply beginning internal testing becomes unnecessarily high.

2. The Critical Misunderstanding: Signing and Service Keys

When you link Firebase to the Google Play Console, the expectation is that Play will handle the generation of APKs from the AAB and sign them using the same key as your production app (the Upload Key or the Play App Signing Key).

This is crucial for features dependent on the app's signing certificate, such as:

• Google Sign-In

• Google Maps API

• In-App Purchases (IAP) (Often tied to your Play Console configuration)

The Reality: Firebase Generates Its Own Signing Certificate

Upon the first AAB upload to FAD, Firebase creates its own temporary signing certificate to generate the necessary APKs for App Distribution testers.

• The Problem: This certificate is different from your production or developer keys. Consequently, any critical service (like Google Sign-In) configured to accept only your legitimate app signing fingerprint will immediately fail in the test build distributed via FAD.

• The Workaround: To make Google services work, you would have to register the temporary Firebase signing certificate fingerprint with Google Cloud Console, which is tedious and undermines the goal of seamless testing.

Contrast: If you upload a standard APK, you can sign it yourself using your true production/developer key (provided you don't use Google Play App Signing), ensuring all your dependent services work out of the box.

3. The End-User Experience: An Unacceptable Installation Flow

After finally conquering the setup and signing issues, the final hurdle was the installation experience for the tester using the recommended App Tester app.

The Reality: Developer Mode for Everyone

When a non-technical tester attempts to install the app via the FAD App Tester, they are met with a jarring and complex installation process:

1. They are prompted to go into their phone's Google Play settings.

2. They must press a specific item 7 times to activate Developer Mode.

3. They must enable a specific security check to allow the installation of the test app.

This kind of process is acceptable for a developer installing an app via Android Studio, but it is an absolute nightmare for non-technical internal stakeholders, marketers, or management testing a build.

• The Cost: This significantly increases friction and requires extensive hand-holding, defeating the purpose of a simple distribution tool.

💡 Final Verdict and Suggestion

Firebase App Distribution is an excellent tool, but the integration with Android App Bundles is flawed and requires too much upfront investment in Play Console configuration and forces the use of a non-production signing key.

My Suggestion: Upload Signed APKs

If your primary goal is fast, reliable, and flexible internal distribution for testers and stakeholders:

Skip the AAB integration with FAD and upload your locally signed APK files directly to Firebase App Distribution.

This approach allows you to:

1. Use your actual developer or production signing key.

2. Avoid the onerous Google Play Console configuration requirements.

3. Provide a simple, non-technical installation experience for your testers.

Hopefully, this information saves fellow developers the many hours of frustration I endured.

I chose to build a simple minesweeper game with hexagonal fields, calling it "Minesweeper Hex." Minesweeper felt ideal because it has a clear set of rules, so I could skip the step of designing a new game concept and dive straight into development.

Lessons from the Challenge

This experience taught me the importance of focusing on essentials. With only a month, I realized that extra features like multiple game modes, achievements, or even in-game ads could wait until later. Instead, I focused on creating a playable version and delivering a complete experience with core gameplay.

The challenge also influenced how I approached the game’s architecture. Given the tight timeline, I chose to go “back to basics”—avoiding complex architecture and abstractions. I relied directly on services and resources, using mainly ChangeNotifiers instead of external state management solutions. This simple structure kept development streamlined and allowed me to focus on getting the game functional.

Releasing the App: Not as Daunting as Expected

One surprising aspect was how smoothly the release process went. Initially, I saw it as a big mountain to climb—setting up store listings, creating screenshots, and filling out forms. But once I got started, I realized it wasn’t as difficult as I’d anticipated, and in a few days, everything was ready to go live.

Leveraging AI to Streamline Development

Throughout the project, AI tools like ChatGPT were incredibly useful. For example, ChatGPT helped me set up the base game logic and gave me ideas on implementing CustomPainter for the hexagons. Although the initial code needed adjustments, it was a great starting point. AI also helped me draft app store descriptions, allowing me to spend more time refining the game.

Final Thoughts

Completing "Minesweeper Hex" in just a month was a rewarding experience. The challenge of creating something from start to finish in a short period reminded me of the power of focusing on essentials. I’m excited to apply these lessons and continue taking on projects that feel achievable yet rewarding.

Download Minesweeper Hex

I’ve made Minesweeper Hex available on both iOS and Android.

The game takes place in a distant future, so I want the UI of the game to resemble this. I’ve done some searching on the internet and took inspiration of games and movies.

After playing around with some ideas, I came up with the following idea, I need 45-degree corners!

BeveledRectangleBorder

I already used some 45-degree angled corners in the game, like for items in the list of goals.

For this I used BeveledRectangleBorder which can easily be applied to Containers and buttons.

But just having beveled corners isn’t enough, I want more. So how can I do this?

CustomPaint

In short, by using CustomPaint you get full control over what you draw to the screen. You can use it to make very complex UI which is great for when the build-in widgets are not sufficient.

Then I realized that in my 6 years of using Flutter, I never used CustomPaint. I never felt like I needed it, but I’ve seen people do amazing things with them. One of them is Jeremiah Ogbomo. He showed off some cool UI in his saturdays-are-for-flutter series.

I’ve attended one of Jeremiah’s presentations and that made me think about using CustomPainter for my SciFiContainer.

Challenges

I’ve spend about 4 or 5 evenings on creating the SciFiContainer.

The biggest challenge for me was coming up with a nice API as I wanted it to be quite flexible in order to use it in multiple places without having all containers looking the same.

The other big challenge was calculating all the points and padding. The Size that is passed into the CustomPainter is determined on the child widget. But this is not the limit in which you can paint. If you want, you can ‘paint’ outside the given size.

This meant a lot of different cases to take into account. Like when the indent is negative. This means that all the points on that side has to move in the opposite direction to make it fit inside the ‘bounding box‘.

The configurations of the corners and the borders also affect the padding inside the container as it tries to keep the content within the border.

Eventually I got the hang of it and was I able to make it all work as intended.

There are still some things that can be cleaned up to create a more ‘safe’ API but as it’s mainly intended for my own use, I don’t want to spend too much time on it.

Result

Because quite some people on Twitter/X showed interest in this SciFiContainer I decided to share the code as a GitHub gist. But you can also view it below.

View on DartPad

If you like this kind of content, give me a follow on Twitter/X as most of the stuff I make will be shared there.

In this article, I’ll walk you through what Skinning is, why I prefer it over ThemeData, and how I implement it in my apps.

The Problem with ThemeData

When I first started using ThemeData, I found it bloated with hundreds of properties that were unnecessary for my projects. I often only needed to change a handful of colors or styles between light and dark modes. Trying to manage those changes through ThemeData made the theming process feel overly complicated. Additionally, ThemeData is primarily concerned with styling individual components, but what if you want to adjust both the behavior and styling in a unified way?

My Solution: "Skinning"

Instead of directly using Flutter’s components like ElevatedButton, AppBar, or Scaffold, I wrap them in custom widgets that encapsulate both behavior and appearance. This way, I have full control over how my components look and function, making global changes easier and cleaner.

Custom Widgets for Unified Behavior and Theming

For instance, when I need a primary button, I don’t use an ElevatedButton directly. Instead, I create a PrimaryButton widget that wraps the ElevatedButton internally, allowing me to manage both behavior and styling in one place.

class PrimaryButton extends StatelessWidget {
  final String label;
  final VoidCallback onPressed;

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

  @override
  Widget build(BuildContext context) {
    return ElevatedButton(
      onPressed: onPressed,
      style: ButtonStyle(
        backgroundColor: WidgetStateProperty.all(context.skin.primaryColor), // Using Skin for color
      ),
      child: Text(label),
    );
  }
}

This makes it easy to update all primary buttons by just modifying the PrimaryButton class. If I need to switch to an OutlinedButton, I do it once in the PrimaryButton class, and the change applies app-wide.

Skin: A Minimalist Alternative to ThemeData

To handle theming across light and dark modes, I use a SkinProvider, an InheritedWidget that provides two Skin objects: lightSkin and darkSkin. The app automatically switches between these based on the device’s theme configuration.

Here’s how the SkinProvider works:

class SkinProvider extends InheritedWidget {
  final Skin lightSkin;
  final Skin darkSkin;

  const SkinProvider({
    required this.lightSkin,
    required this.darkSkin,
    required Widget child,
  }) : super(child: child);

  static Skin of(BuildContext context) {
    final brightness = MediaQuery.of(context).platformBrightness;
    final provider = context.dependOnInheritedWidgetOfExactType<SkinProvider>()!;
    return brightness == Brightness.dark ? provider.darkSkin : provider.lightSkin;
  }

  @override
  bool updateShouldNotify(SkinProvider oldWidget) {
    return lightSkin != oldWidget.lightSkin || darkSkin != oldWidget.darkSkin;
  }
}

And here’s a basic Skin class:

class Skin {
  final Color primaryColor;
  final Color secondaryColor;

  Skin({
    required this.primaryColor,
    required this.secondaryColor,
  });
}

Instead of managing a large ThemeData object, I focus only on the properties that need to change between light and dark modes. In this example, I only define primaryColor and secondaryColor in each Skin, keeping it simple.

Extension Method for Easy Access

To make accessing the current Skin easier, I use an extension method on BuildContext. This allows me to quickly get the active theme in any widget with context.skin:

extension SkinExtension on BuildContext {
  Skin get skin => SkinProvider.of(this);
}

Now, in my custom widgets, I can easily access the current skin:

style: ButtonStyle(
  backgroundColor: WidgetStateProperty.all(context.skins.primaryColor),
),

This makes it easy to theme components based on the active light or dark mode.

Why I Use Skinning

• Unified Behavior and Theming: By creating custom widgets like PrimaryButton, I can manage both the appearance and behavior of my UI elements in one place. This keeps my code DRY and simplifies maintenance.

• Automatic Theme Switching: By providing both lightSkin and darkSkin via the SkinProvider, my app automatically switches between the two based on the device’s light or dark mode configuration. No extra logic is needed in each component to handle the mode switching.

• Simplicity: Instead of dealing with the complexity of ThemeData, I focus on a leaner Skin class that includes only the properties I need. This keeps the theming logic clear and easy to manage.

• Flexibility: When a design change happens, like switching all primary buttons from ElevatedButton to OutlinedButton, I only need to modify the PrimaryButton class. This change propagates across the entire app, reducing the risk of inconsistencies.

Conclusion

Skinning offers a simpler, more flexible approach to theming Flutter apps. By wrapping components in custom widgets and using a SkinProvider to manage both lightSkin and darkSkin, I can easily switch themes based on device configuration while keeping behavior and appearance tightly coupled.

This method has streamlined my theming process and allowed me to focus on what really matters: the specific styles and behaviors my app needs. If you’re looking for a more intuitive way to theme your Flutter apps, Skinning might be just what you need.

I'm currently developing a game where nutrition plays a vital role. The user has a nutrition level that decreases over time, whether the app is open or not. When the nutrition level drops too low, I want to notify the user, prompting them to open the app and consume food.

To achieve this, I need to periodically calculate the current nutrition level and send a notification if it's too low. This needs to happen even when the app is in the background or closed.

The Challenge: Isolate Communication in Flutter

Flutter uses isolates for concurrency, with each isolate having its own memory space. This means that isolates do not share data or instances of classes directly. The workmanager package allows us to run background tasks in a separate isolate. However, the challenge arises when we need to communicate between the background isolate (where the workmanager task runs) and the main isolate (where the UI is managed).

For example, if the background task runs while the app is closed, it can create its own instance of a NutritionService to calculate the nutrition level and send notifications. However, if the app is open, we want the main isolate to handle these calculations. The main reason for this is that the UI listens to the NutritionService instance on the main isolate, and using a separate instance on the background isolate won't update the UI.

Solution: Communicating Between Isolates

To handle this scenario, we can implement a communication mechanism between the background isolate and the main isolate. One approach is to use SendPort and ReceivePort, which are part of Dart's isolate communication API. Here’s a high-level overview of how this can be implemented:

1. Set Up a ReceivePort in the Main Isolate:

   • The main isolate should create a ReceivePort and pass its SendPort to the background isolate when initializing the background task.

2. SendPort from Background Isolate:

   • When the background task is triggered by the workmanager, it can send a message through the SendPort to the main isolate.

3. Handle Messages in the Main Isolate:

   • The main isolate listens to the ReceivePort and triggers the necessary UI updates or service calls based on the message received from the background isolate.

4. Conditionally Execute Code:

   • If the app is open, the main isolate performs the necessary calculations and UI updates. If the app is closed, the background isolate handles the notification logic independently.

Here’s a simplified code outline for this:

// Main Isolate
void main() {
  final receivePort = ReceivePort();
  IsolateNameServer.registerPortWithName(receivePort.sendPort, 'main_send_port');

  receivePort.listen((message) {
    // Handle message from the background isolate
    if (message == 'trigger_nutrition_check') {
      // Perform nutrition check on main isolate and update UI
    }
  });

  runApp(MyApp());
}

// Background Isolate Task
void backgroundTask() {
  final sendPort = IsolateNameServer.lookupPortByName('main_send_port');

  if (sendPort != null) {
    sendPort.send('trigger_nutrition_check');
  } else {
    // If the main isolate is not available, run the task independently
    checkNutritionAndNotify();
  }
}

// Example function to register background task
void registerBackgroundTask() {
  Workmanager().registerOneOffTask('uniqueName', 'backgroundTask', inputData: {});
}

This method ensures that when the app is open, the main isolate handles the nutrition check, thereby keeping the UI in sync. If the app is closed, the background isolate takes over the task and sends a notification directly.

By handling isolate communication this way, we can ensure that the app's state remains consistent, and the user experience is smooth, regardless of whether the app is open or running in the background.

It was not yet a very concrete idea, but more a collection of gameplay elements that I thought would go well together.

Therefore I decided to build a prototype app in which I would put these elements to the test and see if they're actually as fun as I imagined.

The first game-loop

About two weeks ago, I had finished my first full game-loop.

When the player starts the game, they have a nutrition count of 100%. The nutrition would lower by 3% every hour. When the nutrition reaches 0%, the game is over.

Players earn food by walking. Around every 1,000 steps, they are able to claim rewards, which for now would just be one of two types of food.

Consuming the food would refill part of the nutrition.

The goal is to stay alive as long as possible.

Because the 'game' was basically playable, I started testing myself.
I just started playing the game on a daily basis, and I thought it was already pretty fun.

Distributing to testers

I decided to go with the same approach I used for Scavenger Hunt Plus.

CodeMagic

I've been a long time fan of CodeMagic and for my pet projects they are my go-to for the CI/CD. They make it really easy to set it all up with incredible guides.

My distribution pipeline is triggered for every Pull-Request that gets merged into my develop branch. Every time I finish a feature, a new version is automatically distributed to the testers.

Specially if you're new to CI/CD, then you should definitely check them out!
Their free-tier has been more than enough for me and my pet projects over the years.

Firebase app distribution

For Android I use Firebase App Distribution. I prefer Firebase over using the Play Store Test Tracks for the following reasons:

1. Easier to switch between versions.

2. Easier to work with for testers.

3. No issues with having to increase build numbers for every release.

4. When you use build flavors for different environments (production, test), Google doesn't like it when you have two similar app entries in your Play Store account up to a point where they even remove your app (true story).

For iOS, Firebase is not really an option. While CodeMagic makes it easy for you to setup and deploy your iOS app, the experience for your testers to actually being able to access and download the apps is horrific.

I did try it for this current project, but non of my testers where able to complete the setup on their devices resulting in non of them being able to download the app.

TestFlight

Because Firebase didn't work out, I decided to go with TestFlight again. Unlike Google, does Apple not care about you having similar apps just for different environments.

TestFlight is pretty good and has similar functionality as Firebase. Users are able to download all the versions you've made available and they can easily download the app through the TestFlight app.

The mayor downside of TestFlight for me is that in order to make the builds available to external testers, is that it has to go to review.

Now the external testers review is often less strict than the review Apple does for production releases, but still you'll have to wait a bit until your testers get access to your latest build.

Google Play Test Tracks

While I'm still early in development, I am not using Test Tracks. But I will start using them again when I get closer to releases and I need tests to be done with the production environment.

Using Test Tracks just gives an experience closer to the production app, as it can be downloaded through the Play Store.

Conclusion

While I'm still just 'playin' around with my prototype, I'll keep using Firebase App Distribution and TestFlight to distribute the app to the testers.

Once I get close to a production release, I will start testing from Google Play Test Tracks as well.

To automate this process, I'm using CodeMagic which build and distribute a new version on every merge to my develop branch.

I need a way to track the step count for each day, as the progression should reset at midnight.

The tricky requirement

Just tracking the steps might seem easy, but while building this, I ran into a case that made it a bit more tricky. At least I needed some time to get to a proper solution.

Because the app should show the amount of steps from the current day, I need to keep track of the current day. So when the user is actively using the app and it becomes midnight, thus a new day starts, the app should reflect this so the player is not longer able to claim rewards from the previous day.

Pedometer 2

I started looking on pub.dev for a plugin that I could use to track steps. There are quite some plugins build by the community and most of them seem to be forks of each other, which made it really hard to find the 'right' one.

Eventually I went for pedometer_2, simply because I liked the documentation best.

Platform differences

It turned out that both platforms that I wish to support (iOS and Android), do not have the same capabilities.

• Get real time step count since a date (Stream) (Only on IOS)
  *Alternative for Android explained under

Getting real time step count since a certain date (start of today) sounded exactly what I needed, luckily there is an explanation for an alternative on Android!

Permissions

To get access to the step counter information you need to get permissions from the user. I will not cover it in this article as the documentation explains it very well here.

Creating the listener

Ideally we would want to use the .stepCountStreamFrom(...) method because it allows us to specify the period. But as the documentation clearly states, this is not supported on Android.

Luckily, the documentation mentions an alternative solution.

• (Android alternative)*Use a combination of the*getStepCount and stepCountStream. Example in the Example App

The .getStepCount used in the example app, supports a from and to argument, on both Android and iOS.

The .stepCountStream used in the example streams the amount of steps registered since the last system boot. When the user is actively walking, the stream will continuously emit new values.

By combining the two, and sprinkling a bit of rxdart magic, we can create the stream that we need.

final stepCounterService = StepCounterService();

class StepCounterService {
    StepCounterService() {
        // We listen to stepCountStream so we get new data
        // when the user is walking.
        // But we don't use the value as it gives us the total
        // steps since last device boot
        Pedometer().stepCountStream.listen((totalSteps) async {
            // Now we determine the periode for which we wish to
            // get the amount of steps, which is today.
            final now = DateTime.now();
            final startOfDay = DateTime(now.year, now.month, now.day);
            final endOfDay = startOfDay.add(Duration(days: 1));

            // Now we use this information to use the getStepCount
            // method to get the steps for today.
            final stepCount = Pedometer().getStepCount(
                from: startOfDay,
                end: endOfDay,
            );

            // And then we add this stepCount to the
            // _stepCounterController.
            _stepCounterController.add(stepCount);
        });
    }

    // We use a BehaviorSubject because it holds the last value
    // and emits it whenever a new listener subscribes.
    // This makes a Stream more useful to be used in the UI.
    final _stepCounterController = BehaviorSubject.seeded(0);
    final Stream<int> get todaysStepCount => _stepCounterController;
}

Great, we now get the amount of steps for today which is updated whenever the player walks.

However...

It's a new dawn, it's a new day

In the above code, we get the step count of today. But what if it is no longer today?

Our service initializes the stream when the app starts. It uses the current day, but when we reach midnight, we want the step count of the next day.

In other words, the periode should be dynamic.

More streams!

The rxdart package has some very useful utilities that we can use.

Let's add a dynamic way of managing the date to our service.

final stepCounterService = StepCounterService();

class StepCounterService {
    StepCounterService() {
        // We use CombineLatestStream, also from rxdart, to combine
        // two streams. The listener will be called whenever
        // one of the streams changes.
        CombineLatestStream.combine2(
            Pedometer().stepCountStream(),
            _todayController,
            (totalSteps, date) => date, // We only need the date
        ).listen((date) async {
            final startOfDay = DateTime(date.year, date.month, date.day);
            final endOfDay = startOfDay.add(Duration(days: 1));

            final stepCount = Pedometer().getStepCount(
                from: startOfDay,
                end: endOfDay,
            );
            _stepCounterController.add(stepCount);
        });
    }

    // We can use this to force the date to update.
    void updateDate() => _todayController.add(DateTime.now());

    final _stepCounterController = BehaviorSubject.seeded(0);
    final Stream<int> get todaysStepCount => _stepCounterController;

    // We use this to keep track of the day
    final _todayController = BehaviorSubject.seeded(DateTime.now());
}

We've now made the date for which the step count is requested, dynamic. By using stepCounterService.updateDate(), we're able to force the service to use the current date.

Updating the date

Now that we have a way to update the date, we need to determine when to call it.

When the app is opened, it will already initialize with the current date. So we should call our method when we reach the next day. For this we could use a background task, or even easier, a Timer .

void main() {
    // Schedule the first
    _scheduleUpdate();
}

void _scheduleUpdate() {
    // Force the service to update the date.
    stepCounterService.forceUpdate();

    // Calculate how long it takes till tomorrow.
    final now = DateTime.now();
    final tomorrow = now.add(Duration(days: 1));
    final startOfTomorrow = DateTime(
        tomorrow.year,
        tomorrow.month,
        tomorrow.day,
    );
    final tillMidnight = now.difference(startOfTomorrow);

    // Schedule this function again at the start of tomorrow.
    Timer(tillMidnight, _scheduleUpdate);
}

Now the _scheduleUpdate function will be called once at app startup, and then it will schedule itself again for every next midnight.

Conclusion

With some rxdart magic and some well timed (pun intended) function calls, we're able to overcome the platform limitations on Android and are able to get the daily step count as a stream.

During my time working on this project, I've learned a lot about how to 'manage' my side-project to help me to stay motivated up to a point that I'm close to releasing it.

In this article I will share these learnings.

1. Focus

Focus on shipping your app. Focus should be your main priority and you will see it being mentioned multiple times in this article. Every decision you make should raise the question: "How would this impact the shipping of my project?".

2. Stick to what you already know

It might be tempting to try some new tech, languages, tools or frameworks, but if your goal is to ship your project, you should avoid it.

Learning something means you will make mistakes, and mistakes cost time. Something we don't have enough of is time.

If you want to make progress, try to stick to the things you are already familiar with, preferably the things you use in a day-to-day basis, like during your day-job for example.

3. The Most Viable Product

Try to trim down your idea to the most minimal version of itself by removing features that can be added later with updates, till all you've left with is the core of your idea.

Focus on building that first.

When I started working on Scavenger Hunt Plus, the idea was to have an app that supports all kinds of geographical games, show analytical data, has different tiers, etc. I trimmed it all down to a 'simple' Scavenger Hunt app for the MVP.

4. Plan your time

Time is precious and we never have enough of it. When I started out, my intention was to work nights and weekends on my side-project.

Soon I realized that most of the time I planned in the weekend would be interrupted by family-related things. This would often leave me bummed out and moody because I was already mentally prepared to work on it. This would have negative impact on me and my family.

I decided that weekends are for family, friends, etc. So I only work on my side-project in the evenings, right after the kids are in bed. I will spend an hour or two which often allows me to do at least one 'task' while also giving me some time left to unwind before going to bed.

5. Managing your work

It sounds boring, but for me this was a great improvement on my productivity and motivation.

Create a list of todo's, or even better, a Trello board. Don't worry about it being incomplete. Just put down everything that comes to mind that has to be done for your project.

Start out by writing 'big' tasks, like "Create a login screen", avoid going into detail too early. Once you get to a task, you start breaking it up in smaller tasks, preferably small enough that they fit inside your 'work window'.

For example, I can spend 1 or maybe 2 hours in the evening to work on a task. So my Tasks should be short enough to be completed in this time frame. Why?, well for the following two reasons:

1. Easy to start
   Sometimes, after a long day's work, you might not feel like working on your project. If your todo's are big, it will be even harder to start.
   But if you have 1 hour or even half-an-hour tasks, it will make it easier to tell yourself, "Well let's at least do this small one...", that's progress baby!

2. A sense of accomplishment.
   Finishing a task works motivating! Just moving that task from doing to done feels awesome. I've had times that I felt tired and unmotivated to start working on my project. But after I've completed that 'easy half-an-hour task' I got kick-started with motivation and I almost always continue picking up the next one.

6. Parking work

Since we're now using a todo list, Trello board, or something similar to manage our work, it will become way easier to park incidental work.

Let's say you're working on a task. Then you realize this task need a new service of some kind. Instead of immediately starting working on this service, just create an empty class, with some hardcoded values. Then add a task to your list for later.

Now you can put it out of your mind a continue working on the task you had set out to do.

7. Share with friends/family/community

You know what is a great motivator? Compliments!

Share your work with the community, potential users, friends, family whatever!
It's a great way to get compliments as well as valuable feedback for your project.

Conclusion

These are my 7 tips on how to stay motivated for your side-project. I hope they will work for you too! Let me know if they do!

Happy programming for 2024!!!

Motivation

A few months ago, while working on a client project, I was building multiple pages in a row which all contained some kind of form, like a login-, registration- and personal details form.

I soon got annoyed with all sorts of things related to building these forms...

1. Each page had to be Stateful (StatefulWidget).

2. All the TextEditingControllers and FocusNodes had to be created manually.

3. We had to think about disposing these TextEditingControllers and FocusNodes.

4. The TextEditingControllers had to be 'connected' with our state management.

5. Validation ended up in several places, depending on if the validation was client- or server-sided.

All of this resulted in a painful amount of boilerplate code.

And I was not having it...

The Slider widget

A bit later, I had to create a form for my Scavenger Hunt app pet project. This form had only one TextField, but it also contained a Slider.

I realized the Slider was way simpler to work with. Its most important properties are: value and onChanged.
With value you tell the Slider its current value, and with onChanged you receive the value the user changed the slider to. No hassle of dealing with controllers.

So I was thinking, what if I could make a TextField that works the same way?

A Reactive TextField was born

After playing around with some ideas, I ended up with something that can be used like this:

ReactiveTextField(
  text: state.counter.toString(),
  onChange: context.read<CounterCubit>().setValue,
  error: state.error,
),

As you can see, there are no controllers to deal with. Its properties can be directly connected with the state management solution of your choosing.

Below you can see its implementation.

class ReactiveTextField extends StatefulWidget {
  const ReactiveTextField({
    super.key,
    required this.text,
    required this.onChange,
    this.error,
  });

  final String text;
  final void Function(String text) onChange;
  final String? error;

  @override
  State<ReactiveTextField> createState() => _ReactiveTextFieldState();
}

class _ReactiveTextFieldState extends State<ReactiveTextField> {
  // ReactiveTextField will hold onto its own TextEditingController and Focusnode,
  // which you otherwise had to create and maintain yourself.
  final _controller = TextEditingController();
  final _focusNode = FocusNode();

  @override
  void initState() {
    super.initState();

    _controller.text = widget.text;
  }

  @override
  void didUpdateWidget(covariant ReactiveTextField oldWidget) {
    super.didUpdateWidget(oldWidget);
    // This is an important part!
    // Without this check, there will be an infinite loop!
    if (widget.text != _controller.text) {
      _controller.text = widget.text;
     // We remove focus, because the value has been set
     // from a different source.
      _focusNode.unfocus();
    }
  }

  @override
  void dispose() {
    _controller.dispose();
    _focusNode.dispose();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    // ReactiveTextField simply wraps a 'normal' TextField.
    return TextField(
      controller: _controller,
      focusNode: _focusNode,
      onChanged: widget.onChange,
      decoration: InputDecoration(
        errorText: widget.error,
      ),
    );
  }
}

As you can see, it is very simple. The most 'tricky' part here is the didUpdateWidget section, which is needed to prevent an infinite update loop from happening.

This ReactiveTextField widget will manage its controller so the parent can remain a StatelessWidget. All you have to do as the user is set the current value and listen to the updates, THAT IS IT!

Full example

Check out this dartpad link for a full example!

Let me know what you think!

Well, we're just three weeks further, and I've made way more progress than I thought!

I've even "completed" my first feature!

Scavenger Hunt Drafts

When a user is still working on a Scavenger Hunt, they can save them to continue working on it at a later time. These Scavenger Hunts are saved as drafts.

I was able to "complete" the functionality to manage (create, update, delete) these drafts. I put "complete" in quotes because even though you can do everything, it still needs a little cleanup. More about that later.

Let's take a look at this feature in more detail:

Drafts overview

When you currently log in to the app, you will land on the 'drafts overview'.

Here you will see the Scavenger Hunts that you've created but have not yet published:

You can use the FAB (Floating Action Button) to create a new draft or select an existing draft to edit it.

It still looks a little empty, but that will eventually change.

Editing/Creating drafts

When you arrive on the 'draft detail' page, you will be presented with a simple form.

Here you can give your Scavenger Hunt a name, a description and you can manage the locations.

With the '+'-button under the locations-header you can add new locations. When locations are present, the screen will look like this:

This still needs to get some styling-love, but the basics are there. When you click on them you can edit them.

Locations

Creating/opening a location will open a full-screen modal.

Here you can give the location a name, set a position, set the range for the position and optionally, add an assignment!

Position

When you create a new location, the app will try to fetch your current position (using the geolocator package).

The position is drawn on a Google Map (google_maps_flutter). You can easily change the position by tapping on the map. So technically you can create a Scavenger Hunt without leaving the house 😅.

Range

The range will determine within what range the players will complete the position or unlock the assignment in case the location has one.

Adjusting the range-slider will update the map so the circle will represent the actual area.

Assignment

Locations can have assignments that need to be completed to unlock the next location. For the first release, the only assignment option will be a multiple-choice question, but more will follow.

An assignment can be added by pressing the "+"-button. This will allow you to configure a multiple-choice question by adding and removing answers and selecting the correct one.

This concludes the drafts-feature!

Firebase

And that's not all! I've also replaced the in-memory repository and implemented Cloud Firestore to save the data in the cloud.

It has been a while since I've used firestore so I had to do a little digging into the documentation, but everything considered, using firestore was a breeze.

I had to do some tweaking to reduce the number of reads, and I'm still not sure if I'm fully satisfied, but for now it will do.

The cool thing is that firestore supports offline out of the box, although I did have to alter my code a little bit to make it work as intended since I found out that updating/setting data will only complete the future when the data has been synced to the cloud.

The big cleanup

The feature is fully functional but I still need to cleanup some things. Although the itch to continue adding features is enormous, I feel like I have to do this first.

So what do I mean by 'cleanup'? There are still a bunch of things in the UI that can be improved upon, but also the technical side can use some love.

For example, the loading states in the app hardly show after I switched to firestore, mainly because the SDK will update the data very rapidly, and synchronizing the data happens in the background. I can probably get rid of some of loading-states.

Also, some of the views are just not pretty, the drafts-overview can hold a bit more information, as well as the locations list.

Buttons can be pressed to save data, even though nothing changed, and data can be deleted without warning, or you can leave a page without saving. This needs to be addressed.

I probably also want to start integrating localization and apply hints to TextFields and give it a more finished vibe.

What's next?

Well, I kind of explained that in the previous part. I will clean up this feature before continuing to the next, which will be adding the ability to try-out/play-test drafts!

Stay tuned!

This new focus was an improvement, but it still wasn't enough. I was still not getting any actual work done for this project. Therefore I've made yet another, drastic decision.

Focus on building the app

Last time I said I was still going to use Etos (my state management package) so I can develop it alongside this project.

This turned out to be tougher than I thought. Whenever I ran into a problem to solve I got sidetracked from the actual project and I would be spending time thinking about that particular issue, thus not making any progress.

For this reason, I decided a few weeks ago, that I would drop the 'learning' part from the project. This means I will focus on the development of the app.

I will achieve this by using things I already have experience with, instead of using new things.

Bye Etos, Hello Bloc

I've decided to replace Etos with (flutter_)bloc. I've worked with bloc professionally since the start of 2021. That same year I also migrated my very first Flutter app (Scrap Bandit) to bloc.

Because I've experience with it, it takes away the uncertainties I have with Etos, thus speeding up development.

Firebase

In the previous article, I stated that I would be using Firebase as the backend for my application. This is still the plan, for similar reasons as mentioned above.

I've released apps using Firebase, I have very good experiences with it thus why not use it again?

The project's progress

It's been about two or three weeks since I decided to fully focus on building the app, and I can say it already paid off.

In these weeks I've replaced Etos with Bloc and was able to add new features. Because you probably have no idea how far I was, let's take this moment to just show the current state of the application:

So what do you see in the video?

Drafts

I started with the functionality for creating drafts. Drafts are Scavenger Hunts that are still being worked on.

The idea is that, while a Scavenger Hunt is in draft, the user is free to make any changes to it as pleased. Once the user is satisfied and has tested the Scavenger Hunt, they can publish it.

In the video, you see an overview of Drafts, which can be edited by clicking on the FAB (Floating Action Button) to add a new draft or by clicking on one of the existing ones to edit them.

On the draft detail page you can add change the name and description of the Scavenger Hunt. At the bottom, you can add locations, or edit them when you already have one or more locations.

If you're editing an existing Scavenger Hunt, you can also delete it here.

Locations

A location is a point in the Scavenger Hunt that the players should try to find. When they get close enough they will unlock an assignment which will just be answering a question at first.

When you want to add or edit a location you can click the plus-button on the bottom of the detail page, or click on an existing location.

This will open a bottom sheet that allows you to set a name and a range (for now).

When you are editing a location, you will also get a delete-button.

Memory Storage

Because it has been a while since I used Firebase I decided to first implement my repositories with memory storage. It should be relatively easy to replace them with Firebase soon.

Theming

I have no idea if the current style will be the final one, but it looks nicer than the default one, so I'll go with it for now.

What's next?

I started keeping track of the features again in Trello. This helped me in my previous projects and it seems to work for this one as well.

The next goal is adding geolocation and Google maps to make it possible to set the position for the locations. I want to show a small map with the radius of that location.

I'm planning to make smaller iterations again on this devblog. I think that should be possible since I'm making more progress now.

Until the next!

A few weeks have passed and I've been playing with this in my head, and within my pet project. I had some new insights that I would like to share with you in this article.

But first, we need to make things clear

During the discussion, people were saying to me that Material Design is a good design system and it's not confusing to them.

And I agree that Material Design is a good system. It's well-documented and covers all varieties of devices and screen sizes.

So just to be clear, this article is not about criticizing Material Design. It's about how theming is implemented in Flutter.

The other thing that has been mentioned is that ThemeData is capable of implementing any design. This is also not something that I'm claiming Flutter is not capable of. But what we have to do to achieve it, is confusing to me.

New insights

In the last couple of weeks I've played around with theming in my pet project and I also started a new project at work.

Thinking about theming in both of these projects led me to new thoughts that might explain why it is confusing me.

Property overload (part 2)

In the previous article, I also talked about property overload. I talked about all these properties you have available to you in the ThemeData object, even though you might only need 1% of them.

People commented that why this is even a problem since I could "just not use them".

So I started thinking about this, and why it bothers me as much as it does. And I found the reason, which I will explain to you here.

Abstractions

First, we will have to talk about abstractions. Using abstractions is a common practice for us software developers.

We often use abstractions to make other people's code more our own and more specific to our needs.

Let's say we're building an app for our local swimming pool and they wish to show the weather forecast for the upcoming week.

We might want to use some 3rd party service like https://openweathermap.org/.

OpenWeather gives us a wide variety of endpoints and options to get weather data. But, for our use case, we only need the forecast for the upcoming week. So therefore we can make an abstraction of this service.

We could end up with a WeatherRepository. This repository only needs a single function, getWeekForecast(). It will call the OpenWeather endpoint for a forecast. The location can be hardcoded since it's always for the same location, which is the one of the swimming pool.

We have now made an abstraction of the OpenWeather API which is easy for us to use in our application.

Always ThemeData

In the example above I've described a common practice in software development about using abstractions to make other people's code our own.

So if we do it for other things, why not for theming?

Well, because you can't. Theming in Flutter is implemented in such a way that when you grab the Theme from context, it will always return a ThemeData object. And as we know, ThemeData contains all these fields, even though we don't need and use them.

In the previous article, I used the counter app as an example. Wouldn't it make the theme more clear if we could abstract away all the properties we don't use, and maybe give our texts a more describing name than bodyMedium and titleMedium in the process?

Why ThemeData

I've also thought about the existence of ThemeData. Why would they use it like this, and what is its purpose?

Global Theming

I realized that this is the only way to globally style the Material Widgets without wrapping them in a custom widget.

For example, it prevents us from having to put the same InputDecoration on every TextField.

Limitations

ThemeData is designed against the Material Design specifications.

And even though this can come across as flexible, it also is limited by it. You will especially experience this when you have to implement UI that is not (fully) based on Material Design.

An example. Material Design defines two types of text fields:

The first is called Filled, and the second is called Outlined.

So what if we have the following design:

With ThemeData you can go a long way, but to get that label above the TextField, you will have to create a custom widget to make it easily reusable since we don't want to place the Text widget above every TextField manually, right?

Earlier, I mentioned that ThemeData was necessary to globally style Material Widgets without having to wrap them. But since we just created a custom component, let's call it MyTextField, we've just created a wrapper.

So now we could also define the styling directly in the component. And because we reuse the component, we are globally theming our app at the same time. There is no need for an external way of defining a style for this component anymore.

Dark and light mode

Okay, the above statement was not completely true. Most modern applications support both dark and light modes. So MyTextField should change according to the active mode.

To support dark and light modes in Flutter you define two ThemeData objects. So technically, you would be able to create two completely different Themes that don't even look like the same app because it gives you access to every material property.

In practice, this is hardly the case. More often it's just a difference in colors. A white background becomes dark grey and the black text becomes white.

So what we need is a theme that just holds the values that change between themes, nothing more.

Theme vs component properties

So what if we would style our MyTextField directly inside the class? This makes it easier to maintain because you don't have to deal with two different ThemeData classes. When the design changes, it most likely should be changed in both light and dark themes anyway.

Now we only have to find a way to allow MyTextField to adapt to light and dark mode changes.

After taking another quick look at the design, the only properties that need to change are:

1. The color of the label

2. The color of the Input Text

3. The background color of the text field

So what if we could have a theme that just contains these kinds of properties?

NOTE: We could also check for the mode in the component but this is a bit ... mehh, IMO.

It would also limit to only dark and light modes while you might also want to support a special theme for people suffering from colorblindness later on.

Explicit theming

In the conclusion of the previous article, I dropped the term 'explicit theming'.

This is something I'm currently experimenting with in my pet project. It applies the things I mentioned in this article.

What I'm currently doing is breaking my app up into custom reusable components. These will ensure consistency across the app because they will contain most of the styling.

For the dark/light mode configurations, I'm creating a custom Theme class that only holds the properties that change when switching modes. In a sense, it is an abstraction of ThemeData that only gives me access to properties I use.

I'm still playing around with this but so far I like where it is going. If I'm a bit further with the development of my pet project and I'm still happy with it, I will dedicate an article to it.

Conclusion

I have a bit more understanding of why Theming in Flutter is confusing to me. I also have a better understanding of why ThemeData is 'needed'.

I'm still looking for a way of theming that fits me better and therefore I'm experimenting with something I'd like to call: 'explicit theming'.

Reactions to this tweet were pretty divided. Some people agreed with me, and some people thought the theming in Flutter was just fine.

In this article, I will try to explain exactly why I think theming in Flutter is confusing.

What is a 'theme'?

If I look up the definition online, this is one of the first I find:

A design theme is simply the overall look and feel of a website. The purpose of a design theme is to create unity across web pages through the consistent use of a color palette, fonts, and layout patterns

- Uizard Technologies

Using a 'Theme' in your app creates unity and consistency across your application. When an application uses the same theme across its different screens, it lets the user know they are still inside the same application.

Theming your Flutter app

Flutter allows you to 'style' elements in your app through the use of ThemeData objects which are provided by the Theme widget. All the Material Widgets in Flutter reference the ThemeData to cherry-pick its properties to be used as their default styling.

I say default because the Material Widgets also allow you to override the style of the component themselves.

What style is used where?

How ThemeData is used by the Material Widgets is the first thing that confuses me. Material Widgets sometimes access different properties from ThemeData, depending on whether they have been supplied or not.

Let's take the AppBar Widget as an example.
If we want to change the text style of the title, we have several options.

1. We can set the titleTextStyle property on the widget itself.

2. If that is null, it will try to get the style from ThemeData.appBarTheme.titleTextstyle.

3. If that is also null, it will get a more generic text style from ThemeData, ThemeData.textStyles.titleLarge.
   But, instead of using that style's color, it will use the AppBar.foregroundColor property.

4. If the AppBar.foregroundColor property is null, it will try to use the ThemeData.appBarTheme.foregroundColor.

5. However, if that is also null, it will use ThemeData.colorScheme.onPrimary for the color. Unless the theme's Brightness is set to Brightness.dark, because then it will use ThemeData.colorScheme.onSurface.

This is just for styling one part (the title) of one component (the AppBar).

Which style to use?

The next things that confuse me are the more generic style properties in ThemeData.

ThemeData contains a set of generic TextStyles located in ThemeData.textTheme. It contains a bunch of old and new Material Design-defined styles for texts. If we ignore the deprecated styles and focus on the ones defined in the latest Material Design version, we have the following set of styles:

Now I ask you, do these definitions make any sense to you? Where should they be used for?

Take a look at the image below. It's the well-known counter app...

Can you tell me which TextStyles have been used for the number and the text above it, without looking into the code. I bet you cannot.

It turns out the number is using ThemeData.textTheme.headlineMedium, and the text above it uses ThemeData.textTheme.bodyMedium. But why? Why these properties, why are these 'medium' sized? Why aren't they 'small' or 'large'? Why is the number a headline?

ColorScheme is very similar and has the same issues, so I won't cover them here.

'Theming' in multiple places

If theming is about having a consistent design across your app, then we have two options for achieving that in Flutter.

I've always had the feeling that Flutter pushed us toward using ThemeData. But sometimes we also make reusable components when ThemeData just isn't enough, like a type of ProductCard we use on both a Search and Favorites page.

By using reusable components, you technically are also 'theming'. The final result is often a mix of the component's configuration and the current Theme.

I always have to think about where which configuration should go, it just isn't clear to me.

ThemeData's rigid structure

The ThemeData class is rigid. It is not easy to add properties by extending the class for example. That's because when you want to use the Theme in your UI, the Theme.of() static function will return a Theme, meaning you will only see the properties Theme originally has.

There are some ways to work around this but they are a pain in the butt.

ThemeData also has a way to add ThemeExtensions (docs). This is just a list of classes that extend the ThemeExtension class which can be accessed by calling .extension<MyThemeType>() on a ThemeData instance.

My issue with this is, that if I just want to add a single TextStyle, let's say titleExtraLarge, I will have to add it as an extension. So, they will not be located in the same location as the other TextStyles, which again makes it confusing to work with.

Property overload

ThemeData by default gives you access to all these properties:

These are just the root-level properties, I even left out the deprecated properties that are still in there.

Let's do an extreme example. Let's think about the counter app again. Why would we need all these properties? If we want to add a dark theme, only a few of these properties will have to change.

Conclusion

I've tried to explain to you why I find theming in Flutter confusing. The way it's implemented and used across the Material Widgets doesn't make any sense to me.

I got a bunch of reactions with good suggestions on the tweet, and I also discussed this internally with my colleagues at Pinch on how to improve theming.

Both gave me ideas on how I want to try and handle theming differently. I'm currently running with an idea that I'd like to call "explicit theming" inside my pet project.

But it's too early to write something about it, so I'll let you know how that turns out.

Until next time!

Because I'm still struggling to find time to work on this project I decided to tune down the scope a little and made some other project decisions to make the project (hopefully) more manageable.

Why I've dropped FlutterFlow, again.

Let me start by saying FlutterFlow is an amazing tool. The way you can create UI, with a nice graphical user interface, is something I didn't know I missed this much.

Creating UI is smooth and fast. Just dragging widgets into place and adjusting some properties made it a very nice experience.

But then the UI also had to do something, for which we trigger actions. FlutterFlow contains a bunch of these actions to work with Firestore, navigation, local state and whatnot. If the action you are looking for doesn't exist, you can create your own.

Custom actions

This was the first hurdle for me. FlutterFlow is very Firestore-minded, meaning you often directly connect a screen with a Firestore query. But I wanted to work in the local state first without having to send write-requests on every change I made.

So, while there are plenty of actions to use to manipulate Firestore documents, working with the local state was lacking them. I ended up writing custom actions for them but that wasn't scalable. I had to write very specific actions for every DataType and every form of manipulation I wished to perform.

Not to mention the code editor has some weird quirks that sometimes just disable the analyzer. Also, I had to mark my actions as "not compile" because it broke the project.

Separated environments

As a Flutter developer, I'm used to having different environments for testing and production (or more). We don't want to experiment in a production environment, now do we?

Unfortunately, FlutterFlow has no support for this, which made me a little frightened for the future, after the initial release. How would I handle working on new versions without risking screwing up the production environment?

Testing the app

One of the biggest issues was not being able to test on real devices right from the editor.

I'm used to hookup any device to my MacBook and deploying my Flutter apps in seconds, allowing me to experience my app as close to production as possible.

With FlutterFlow you can run your app in the browser, but it has no access to sensors, which is kind of important for my Scavenger Hunts.

So is it over?

As I said, FlutterFlow is an amazing product but has a long way to go to match the capabilities of the vanilla Flutter experience.

I'm considering still using FlutterFlow for designing UI components since I'm not familiar with any other design tools. Other than that, I won't be using it, and I will not give it another shot for this project. All this switching also cost me valuable time. But it was a nice learning experience.

The future of the project

Working with FlutterFlow did give me some new insights into how I wish to approach this project. For example, in the way I want to store and handle data in the database.

Scope

My initial idea was to create an app that allowed the user to play different kinds of geographical games, Scavenger Hunts being one of them.

I decided to limit the app to just doing Scavenger Hunts. Hopefully, this will prevent me from trying to early-optimize.

Tech Stack

I might have partially mentioned this topic scattered over the previous devblogs, but this is the tech stack I will be using.

So I'm back to using vanilla Flutter for this project for the earlier-mentioned reasons.I will use Firebase as the backend, for things like Auth, Storage, Firestore, etc.

So actually, I'm back to what I initially started with...

Etos

I'm still going to use Etos, my self-created State Management package. I will develop Etos alongside this project to make it production ready.

Theming

Last week I triggered a discussion about theming in Flutter. I tweeted that I find theming in Flutter confusing. It seemed that I was not the only one.

While thinking about this topic, I came up with an idea, that I want to give a try in this project as well. If I like it, I will write an article about it.

What's next?

Last week I created a new project. Thus far, I've added flavors, added Firebase Auth, and added basic App State with Etos.

Next, I will work on the main page with the bottom navigation.

Until next time!

Well, it turns out FlutterFlow has added some very nice features last month, one of which made me reconsider FlutterFlow.

Together with a switch in mindset, I was willing to give FlutterFlow another chance.

What changed?

In February, FlutterFlow released a new update. The update addressed one of my major pain points.

The update adds the possibility to scope state to a page or component. Before the update, you could only use the global state. This became messy rather quickly when you had a lot of variables to store.

Having more control over your local state also allows you to be more conservative with your Firestore interactions, saving you money.

You can for example decide to first keep track of data locally, and only save to Firestore when the user explicitly presses save.

What about Directus?

Before I started using FlutterFlow again, I was working on authentication with Directus.

After I had set up the basic authentication flow, I started thinking about how to model my Scavenger Hunt data.

At that point, I concluded a document database like Firebase might be a better fit, at least for the game configurations.

Also realizing that I was spending a couple of hours a day for a few weeks just to get the authentication partially finished, made me see how easily Firebase was to set up.

Directus may still become a part of the project, but it will not be something I will focus on for now.

A different mindset

In my previous attempts to use FlutterFlow, I looked at it through the eyes of a Flutter developer. I tried to solve problems the way I would try to solve them in code.

In many cases, FlutterFlow will not be able to do so. If you're a Flutter developer, and you're going to give FlutterFlow a try, try to go in with a blank slate. Try to understand how FlutterFlow wants you to solve certain problems instead of comparing them to how you'd have done it in code.

Your Flutter knowledge will still come in handy. The way you build UI, with widgets, will be very familiar. While FlutterFlow comes packed with a lot of predefined widgets and actions, you're able to extend FlutterFlow with custom widgets, functions and actions. These are still written in Dart, so also here your Flutter developer skills have value.

My first custom action

For my project, I had to create a way to change the order of the destinations of a Scavenger Hunt. I could not find a built-in way to do this, so I decided to give a custom action a try.

The arrow buttons on the items in the list would swap the position with the item below or above it when pressed.

To create a custom action, you will have to define the parameters, and optionally a return type. You can then let FlutterFlow generate a template that requires you to fill out the body.

In my case, the input parameters were the original list of destinations and the index of the item that would be swapped. The result would be a new list of destinations. I decided to create two separate actions, one for moving the item of the given index up, and one for moving the item down.

We could write this code ourselves, but we can also tell FlutterFlow to write the code for us.

By describing what you want your custom action to do, FlutterFlow will provide a solution based on the parameters and return type that you defined for your action.

I told FlutterFlow to: "Swap the item with the given index with the item below it", and the code it generated was spot on, even handling the case where the index is that of the last item.

// Automatic FlutterFlow imports
import '/backend/backend.dart';
import '/flutter_flow/flutter_flow_theme.dart';
import '/flutter_flow/flutter_flow_util.dart';
import '/custom_code/actions/index.dart'; // Imports other custom actions
import '/flutter_flow/custom_functions.dart'; // Imports custom functions
import 'package:flutter/material.dart';
// Begin custom action code
// DO NOT REMOVE OR MODIFY THE CODE ABOVE!

Future<List<ScavengerHuntDestinationStruct>> moveDestinationDown(
  List<ScavengerHuntDestinationStruct> destinations,
  int index,
) async {
  // swap item from given index with item below

  if (index == destinations.length - 1) {
    return destinations;
  }
  ScavengerHuntDestinationStruct temp = destinations[index];
  destinations[index] = destinations[index + 1];
  destinations[index + 1] = temp;
  return destinations;
}

So now we can use this action on the arrow buttons like so:

The first action is the custom action. This action will return the updated list of destinations. The next action updated the Firestore document.

That's it! We created and used a custom action with the help of AI!

What's next?

I'm currently focussing on the functionality that allows users to create 'drafts'. Drafts are editable Scavenger Hunts which have not yet been published.

Users will be able to update and test drafts until they are ready to publish.

So far I've got an overview of the drafts, and a way to create a new draft or edit an existing one. So far you can only add and remove destinations for a Scavenger Hunt, so next will be editing functionality.

Hopefully, I will be able to show a bit more about the app itself.

Bye bye!

I made a little bit of progress on the project which also involved a rather impactful decision.

But first, let me tell you a bit about the other stuff that happened!

Flutter Forward Festival

The people from Flutter Netherlands, together with Pinch (the company I work for) organized a viewing party for the Flutter Forward Live Stream.

After watching the stream together, we would have a few presentations. I was asked to be one of the presenters which I accepted.

From Mental Model to App Architecture

My presentation was called "From Mental Model to App Architecture". I talked about how I came up with the architecture that I used for the last project I worked on, which struggles I had and what I did to overcome them.
So instead of a technical story, it was more about my developer experience, something I would usually write about on this website.

Etos

At the end of the presentation, I also made an introduction to Etos.
Etos is the state management solution I'm working on that is intended to make applying the architecture that I've come up with, easier.

I talked a little bit about this, without calling it by name, in an earlier devblog. I'm using this state management solution in this project, to see if it holds up in the real world.

When I'm satisfied enough, I will write an article about it.

Project Progress

As I said, it was a busy couple of weeks. However, I was able to make some progress. But first I made yet a 'drastic' change...

Bye Bye Firestore, and hello Directus!

In devblog 5 I mentioned I wanted to use Firebase (Firestore) for this project.
After several attempts of trying to model my data in Firestore, I realized that my brain doesn't like the unstructured nature of a NoSQL database.

Whatever I tried, I just was never really satisfied with the outcome. It was holding up the project and I was slowly losing joy.

Then I took a step back, and thought about why I choose Firestore in the first place, and if it was necessary to have a NoSQL database for this project.

I came to realize it was not.

A few years ago I experimented with Directus, I remembered being impressed by it. Directus is a headless CMS that wraps around your SQL database. It also automatically generates an API (REST and GraphQL) for you!

Since the first time I used it, Directus has come a long way. I read the docs and watched videos about it to see if this might be a good fit for me and my project.

It looked very, very, very promising!

So I decided to give it a shot. I created a FREE Directus project in their cloud service. It was set up in no time at all and I could quickly try it out.

Authentication

Because the free tier of the hosted instance doesn't allow for SSO services I had to make some changes in the authentication. I would no longer use FirebaseAuth for this and thus had to build this myself.

Luckily Directus also generates authentication endpoints that I could use. Unfortunately, I had to do a lot more work than what FirebaseAuth automatically gives you, but it was also a nice experience to learn a bit more about how authentication works under the hood.

What's next?

I think I will first focus on being able to create a draft scavenger hunt.
Hopefully, this will give me a feel for how to model the data in de the database.

There are still a few questions I need to think about, like:

1. Should it be possible to update a Scavenger Hunt after it has been published?

2. What is, and is not, allowed to be changed?

But I will take it one step at a time.
First I will focus on creating the drafts.

Well, I did, and at first, it felt like this was going to be a timesaver for sure!

However, after the simple crud-like functionality, I started running into the limitations of the platform.

In this devblog I will explain the issues I ran into, and why I decided to go back to vanilla Flutter for further development of this project.

Working with temporary state

After creating pages that showed the games, I started to work on pages that would allow users to create games of their own.

For this, I created a Form that had some Textfields for basic information like a name and description.

The next part was adding locations to a Scavenger Hunt. This is where the trouble started.

To show data you connect your page to a FireStore query. The main form shows the list of locations already added to the Scavenger Hunt. When the user clicks on the add button, a new form would open that would allow the user to create a new location.

But to update the list I would have to update the document, thus persisting the data. I wanted to wait for that to happen till the user pressed save so the user can easily decide to drop the change by not saving.

I found a way to work around this which was by using local state. But this felt kind of dirty because I would then be mixing the two and this is just not how I would do it if I'd code it myself.

Location picker

The key feature for adding locations to a Scavenger Hunt is picking the geographical position (latitude and longitude). Flutter Flow does have Google Maps integration but this is limited to showing one or multiple markers on a Google Map.

This Google Map doesn't support clicking on the map to get a location, it only allows to set actions for when a user clicks a marker.

I tried to work around it by adding a button that grabs the user's current location and uses that for the position of the Scavenger Hunt location.
This meant that the user had to get in the exact position to set the location. So when the location would be a landmark like a tower, a church or any other building, you would either get inside or set the position somewhere around the building.

Again, I was making compromises that I was not fond of.

Subclass Datatypes

Within Flutter Flow you have to define the collections that you are using. It's basically defining a schema for your Firestore Database.

Flutter Flow uses this to give you access to the right fields based on their type. So this got me thinking...

My initial plan is to support only Scavenger Hunts, but I'm also planning on adding different types of games.

So what I wanted was a collection of games that could hold different types (subtypes) of games. This is simply not possible with Flutter Flow.

The only way I could think of was to break things up into different collections and link them together or something. But again, this felt far from ideal and definitely not how I would do it if I would code this myself.

Testing

The app is all about geolocation and device orientation. Unfortunately, Flutter Flow only allows us to quickly test in the browser. It's a lot harder to get a good feeling about the functioning of the app if you cannot move it around in your hand.

While for the testing of the forms the web version was fine, for the sensory stuff, not so much.

In the original Proof of Concept, I would simply run the app on my real device and head outside to take it for a spin. I loved being able to do that.

Conclusion

So, even though Flutter Flow got me started quickly, I felt like I would lose all that saved time by having to work around its limitations.

This means I would eventually end up with a product in the same amount of time as when I build it in vanilla Flutter, but without full control over the code.

I think Flutter Flow is a very cool product, but not a good fit for me, mostly because I know how to code.

I ended up thinking: "I would do this differently if I build this myself." quite a lot and therefore don't feel I would benefit from using Flutter Flow as much as I hoped.

In fact, I've already started working on the vanilla Flutter version. I think both the first PoC and the Flutter Flow experiment have given me enough insight to work on an MVP.

More on this in the next blog!

Last week I've decided to give a tool I've tried over a year ago another try, and I must say, thus far, I'm really impressed!

This week I've also released a separate article about my approach of creating widgets.

FlutterFlow

If you're a Flutter developer you might have heard of a tool called FlutterFlow. Maybe you've even given it a try.

About a year ago a colleague and I at Pinch took a look at it during one of our 'hackatons'. We wanted to see if we could benefit from it as an app agency.

Long story short; we decided it wasn't for us.

However, after watching a bunch of tutorial on the James NoCode Youtube channel recently, I got really intrigued by how fast he was able to get stuff done. He showed some nice new features which were lacking at the time.

For someone like me that is creating a personal project and has almost no time to spare, this could be a game-changer.

What is FlutterFlow?

FlutterFlow was introduced at Google IO in May '21.

It's a no-code platform that allows you to build Flutter apps in a click-and-drag fashion.

You don't need an IDE, you just go to the web app (which itself is also build in Flutter!!!) and start building your app.

Why would I use FlutterFlow?

I can hear you think "Stephan, you know how to program, you are a wonderful full-time Flutter developer for almost two years! Why would YOU need a no-code platform".

And that's a fair thought! I also thought that no-code tools where for the 'normies' that don't know how to code.

However, some time ago I started following some so called "indie hackers" on Twitter and learned that even though most of them know how to code, they are also excessively utilizing no-code tools for their business.

And that's how I started feeling about this pet project as well. It's no longer just building an app. I'm planning to publish it, hopefully turn it into a success and earn some money. It's becoming more than just an app, it's becoming a business.

So I decided to give FlutterFlow another try. But this time looking through the eyes of an entrepreneur instead of an app developer.

Making some progress

After a periode of getting side-tracked I finally was able to get some progress done.

Last week I started creating the project in FlutterFlow.

As you might have read in earlier devblogs, I was working on a prototype that used GPS and the Compass to play a hard-coded scavenger hunt.

The next step was managing these scavenger hunts. Since users should be able to create their own hunts, we need authentication.

Firebase

FlutterFlow incorporates the use of Firebase very nicely. I think it's even harder to not use it. But since I already planned on using Firebase I wasn't worried about that.

Setting up the connection was amazingly easy. It's just a matter of minutes and you're good to go.

Login

We need users to login to be able to create games. FlutterFlow comes with a bunch of example login pages that have everything set up, from creating an account, to login in with social media accounts (for which you have to do some extra configuration).

Within the hour I had a login/registration page and a blank homepage that the user would see after login. 🤯

Listing games

Within FlutterFlow you are able to define your collections for your Firestore database. Based on your collections and configuration it can deploy the rules for the database for you!

Once I've had setup the collection I added a ListView to the Homepage and wired it up with my collection.

Once wired up I could layout the ListItems. FlutterFlow offers a lot of predefined components. So I just picked a card that I thought would fit with my app, wired up the fields with the data from the firebase documents and BAM! A working list of Scavenger hunts!

Adding Scavenger Hunts

Just listing scavenger hunts doesn't make sense if you can add any new ones right? Therefor I added a FAB (Floating Action Button) that would open a form for creating a new game.

It currently only adds part of the fields, like a name and description and you're even able to upload an image. But again, I've got everything working within an hour. Truly amazing!

Conclusion

I feel like I've made so much progress in maybe just 8 hours of FlutterFlow usage. Just think about what I can accomplish when I actually get good at it!

So far things have been pretty straightforward but I am curious how FlutterFlow will handle more custom use-cases, like when I'm going to build the game screen which relies on both GPS and the Compass.

I've also not been able to deploy to a real device since it requires you to get a paid subscription to do so. Currently I don't feel the need, but I think I will need it pretty soon to be able to really test the GPS and Compass integrations.

We'll see!

Now that I use FlutterFlow I'm not planning on dropping Flutter completely since I'm still a Flutter developer. I also think me actually knowing Flutter is super useful when using FlutterFlow since it allows for custom code and widgets. I Think it will allow me to benefit from both worlds.

How I build widgets

Last week I've also written another article. This time I wanted to share my strategy for building widgets. You can find the article here.

What's next?

For the upcoming weeks I want to continue working on the creation of Scavenger Hunts. Users should be able to add destinations by setting a location with a hint, maybe a range, a picture(?) and a question for when the user is within range.

This means I will probably have to integrate Google maps to show the location so the user can set/adjust it.

Exiting!

So, what do you think about me using FlutterFlow? Do you think it's a good idea? Would you use it? Why/Why not?

In this article I will share the 'guidelines' I use when I'm creating my widgets. They help me keep widgets clean and reusable.

This article is a more detailed version of tweet that I published a some time ago:

So without any further ado, let's jump right in!

Two types of Widgets

First of all, I distinguish two types of widgets. Both have different, clearly defined, responsibilities.

Destinations

Destinations are widgets that represent a page or screen in your app, a widget you navigate too. So if you find yourself using your widget with a Navigator call, than that's a destination:

Navigator.of(context).push(
  MaterialPageRoute(builder: (context) => const HomePage()),
);

In this example the HomePage is clearly a destination. I will often name them something ending with Screen, or Page like TodoPage or LoginPage, but also DetailsModal and OrderConfirmationDialog I consider to be destinations.

Destinations are very specific to the app. They orchestrate what the screen will look like, often based on some kind of state. They contain most of the logic on what to show on the screen:

// build function of TodoList.dart
Widget build(BuildContext context) {
  if(isLoading) {
    return Center(
      child: CircularProgressIndicator(),
    );
  } else {
    return ListView(
      // show loaded items
    );
  }
}

In the example above you can see that based on isLoading, a different UI is shown. This is what a destination widget does. It decides which other widgets should be used to represent the current state, which brings us to the component widgets.

Component Widgets

These are basically all the other widgets that I create and are not destinations. They follow a strict set of rules.

Don't pass domain objects

Unlike the destination widgets, the component widgets should be as app-independent as possible. When creating these kind of widgets, I will build them in such a way that they should be reusable in any app. They should mainly focus on the how to show the information on the screen.

To accomplish full independence we cannot rely on the domain of the app. This makes passing domain objects as parameters forbidden. In the following example I will show you what I mean.

Let's say we want to create a ProfileHeader widget that shows the user's profile picture, name and city. We could do that like this:

class ProfileHeader extends StatefulWidget {
  final User user;

  const ProfileHeader({required this.user});

  Widget build(BuildContext context) {
    return Column(
      children: [
        Image.network(user.profilePictureUrl),
        Text(user.name),
        Text(user.city),
      ],
    );
  }
}

Here we pass a User object and use its fields to build the widget. This causes this widget to be strongly coupled to the domain of this app. Not only that, it also makes this widget less reusable!

Now take a look at the next approach:

class ProfileHeader extends StatefulWidget {
  final String title;
  final String subtitle;
  final String imageUrl;

  const ProfileHeader({
    required this.title,
    required this.subtitle,
    required this.imageUrl,
  });

  Widget build(BuildContext context) {
    return Column(
      children: [
        Image.network(imageUrl),
        Text(title),
        Text(subtitle),
      ],
    );
  }
}

In this example we pass each of the values as primitives and therefor no longer rely on the domain of the app. Now we cannot only reuse this widget in other apps, but even within the app itself we are able to reuse the ProfileHeader for like a company or group page!

Avoid nesting

When I design my widgets I want to have them as close to the 'root' as possible. As mentioned earlier, destinations control which (component)widgets are shown so they should also tell those widgets what to display.

So, in able to allow for this, destinations should be able to access these widgets. When you are nesting widgets, you kind of delegate the responsibilities to the closest ancestor. However, I want to have control over them in my destination widgets.

So what does that look like? Imagine the following widget tree and code:

- ProfilePage // destination
  - LoadingIndicator // when data is loading
  - ProfileContent // when data has been loaded
    - Header
    - Bio
    - Address

// Our destination
class ProfilePage extends StatelessWidget {

  Widget build(BuildContext context) =>
     isLoading ? ProgressIndicator() : ProfileContent(user);
}

class ProfileContent extends StatelessWidget {
  final User user;

  ProfileContent(this.user);

  Widget build(BuildContext context) =>
     ListView(
      children: [
        Header(user),
        Bio(user.bio),
        Address(user.address),
      ],
     );
}

In this example we have a ProfileContent widget which is shown when the ProfilePage has loaded the data. This ProfileContent widget in its turn is divided in multiple 'sections' like a Header, Bio and Address. In order to pass all the data needed for these sections, we have to pass them to the ProfileContent widget. As you can probably tell, that could be a lot of properties. In these cases we would often pass-in complex objects (like a User object) and let ProfileContent figure it out.

However, that's against our rules!

So instead of the code above, I'd do it like this:

// Our destination
class ProfilePage extends StatelessWidget {

  Widget build(BuildContext context) =>
     isLoading 
      ? ProgressIndicator()
      : ProfileContent(
            header: Header(
              image: user.profileUrl,
              title: user.name,
              subtitle: user.city
            ),
            bio: Bio(
                text: user.bio,
            ),
            address: Address(
              streetName: user.address.streetName,
              houseNumber: user.address.houseNumber,
              ...
            ),
        );
}

class ProfileContent extends StatelessWidget {
  final Widget header;
  final Widget bio;
  final Widget address;

  ProfileContent({
    required this.header,
    required this.bio,
    required this.address,
  });

  Widget build(BuildContext context) =>
     ListView(
      children: [
        header,
        bio,
        address,
      ],
     );
}

In this second example, the ProfilePage is in full control over what is passed into the Header, Bio, and Address widgets. The way we achieved this is by having widgets as arguments for the ProfileContent widget. This could look familiar since the same approach is used for the Scaffold widget, where you have params like appbar and body. So now the only responsibility of ProfileContent is laying out the widgets we pass. This makes the widget so much more flexible and reusable.

Conclusion

So that was it for now. If you find this useful, please let me know so I can share more about my approaches for writing widgets!

Cya!