Devblog 6: Swimming against the current

Devblog 6: Swimming against the current

If you've read the previous blog you know that I wanted to give a shot at using FlutterFlow.

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.


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.


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!