The app will initially support one type of geo-game, which will be a scavenger hunt. Users of the app will be able to create and play these with the app.

Last time I've explored the tech that I thought I would need to be able to create this. You can read about it in the previous blog.

This week I've looked a bit deeper into the data that I would need for a scavenger hunt.

The Scavenger Hunt game

The scavenger hunt that will be in the initial release will be very basic. There are tons of variations of a scavenger hunt and maybe I will add different options regarding on the demand of the users later, but for now, I'll keep it basic.

My idea is that the player has to find locations and answer multiple-choice questions when they reach it. Once answered, the new location will be available and the player continues their journey.

At the end of the scavenger hunt the player will see their result based on the given answers.

What happens with the result is still something I have to decide. Thats a problem for later.

The ScavengerHunt entity

I started by creating a simple ScavengerHunt object. I gave it the properties I thought it would need, like a name, id and a list of objectives.

The objectives represent the locations the players have to find. So these also have a bunch of properties like the location, the question, answers (I think multiple choice will be easiest for now).

I've hardcoded an example of a scavenger hunt and updated the prototype in such a way that it shows all the locations. The arrow will point you into the direction of the first and once you've reached it, it will mark it as completed (no questions yet). Then the arrow will point towards the next.

App structure

Now I started creating the real app code I had to start thinking about my structure. I've build a bunch of apps (professionally and personally) now so one would think I already know exactly how to do this.

But with each project I see improvements that I want to apply in the next project. And since this is my personal pet project, where I'm 100% in control, I can apply these any way I want! Even if they seem a bit experimental.

Folders

Usually I try to use a feature first approach, but to be honest, I'm never really satisfied with it.

When I make feature folders, I want to make them in such a way that I'm able to remove the folder to get rid of a feature, without too much hassle. But I've never really been able to realize this since almost everything is connected somehow.

So I decided to just separate by type this time.

Clean architecture

My last projects all implemented a form of clean architecture, where I would create three projects. These projects represented the three layers 'domain', 'data' and 'presentation'.

I've gotten really used to this approach and it has shown me lots of benefits while developing my projects. Even for my smaller personal projects. Why?

By separating these layers I could clearly create small tasks for myself that implement only the portion that's part of a single layer. For someone that only has a few hours (1 or 2) to spare a few evenings a week this is great. You'll be able to finish tasks which give you the feeling you actually accomplished something, instead of going to bed with an unfinished task.

However, many claim clean architecture is overkill for most apps. And I get where that's coming from. I'm also writing interfaces for repositories that eventually end up with a single implementation for example. So is this really necessary? Could I safe time and maintain the benefits I love so much? I guess I will find out!

This project I will start out with just a single project and take it from there. Of course I will still be doing some layering/separation but not in the way I used to do.

State management

Last few months state management was yet again a hot-topic in the Flutter community on Twitter. There are many solutions to choose from. Since I've started working with Flutter back in 2018 I first only used StatefulWidgets, then started using provider. Then in my first Flutter job I worked with bloc package and recently I worked on an app that used Redux.

Bloc became my favorite for a long time, but I also liked certain things Redux does. So then I started experimenting and coming up with my own solutions to look for my personal holy grail. I often ended up combining features from different solutions or tried to add features I missed in existing ones.

I'm really fond of my recent solution and I want to give it a proper test run (It does have some example projects but that's just not the same). So for this project I will give it a try. (Yay for personal projects!)

If I'm pleased enough I will share it and turn it in another package. But first see if it can hold up.

Freezed

For my state objects I need copyWith and object equality and while I'm used to use the equatable and copyWith generator package, I wanted to give Freezed a try. I have worked with it in a project, but never implemented it in my own projects.

I must say I love what Freezed handles for you but I also find the way you configure your objects not very intuitive. Hopefully it will become more easier the longer I use it.

What's next?

As you've just read did I start writing 'real' project code. So from now on I will be transforming the POC into a real project bit by bit.

In the upcoming week(s) I want to work towards a more playable prototype. I will just hard-code the Scavenger hunt for now, but I want to make a screen in which it can be completely 'played'.