Devblog 9: Can we still be friends?

Search for a command to run...

No comments yet. Be the first to comment.
Follow my journey of developing Local Explorer, an app that allows people to create and play position-based games!
In an earlier devblog I wrote about having tried FlutterFlow and why I decided to not use it for my pet project. Well, it turns out FlutterFlow has added some very nice features last month, one of which made me reconsider FlutterFlow. Together with a...
As Flutter developers, we love the efficiency of writing code once and deploying it everywhere. But when it comes to the very final step of launching or updating an app, generating App Store and Play

If you're looking for a streamlined way to distribute your Android test builds using Firebase App Distribution (FAD) with the modern Android App Bundle (.aab) format, you might want to pause. While the promise of using AABs via FAD—leveraging the Goo...

Last month, I set myself a new challenge: to build and release a small app from scratch within a month. This decision came after a realization I had while working on my previous project. That project had so many uncertainties and things left to do th...

Using Flutter's CustomPaint to create futuristic looking widgets.

Last year, I wrote two articles about theming in Flutter, sharing my frustrations with ThemeData (part 1 & part 2). While ThemeData is powerful, its extensive properties can be overwhelming, especially when many of them are rarely used. After experim...

If you follow me on Twitter, you might already know, but I'm giving up on FlutterFlow once again. While I think FlutterFlow is an amazing tool, I also think it has a long way to go. For the last couple of weeks, I kept running into hurdles that slowed down my progression. In this article, I will give you some of the details.
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.
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.
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.
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?
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.
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.
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.
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.
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...
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.
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.
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!