My app HookMeUp is now deployed on the PlayStore, feel free to download it HERE!
I wanted to share the process I used from idea to actually releasing the app.
Today I will share my experience in implementing the HookMeUp app from scratch.
If you read my previous article, you know that at this point I already had some design screens to start, so now is the time to actually build the app. I had to make some choices beforehand, and I will detail all of them.
My requirements for HookMeUp are the following:
- have a blast building the app
- be able to build Android and iOS in a decent period of time
- have a good user experience in terms of performance
- do not build a dedicated backend
The mobile framework
For the mobile framework, I had no hesitation at all. I chose Flutter for those reasons :
- Flutter is cross-platform (iOS, Android, and almost Web)
- I know Flutter
- Flutter provides great developer experience
I could write all day claiming why Flutter is so awesome, but the best way to convince you would be.
The state management pattern
This is probably the hardest part for me. I had the opportunity in the past to try some different architectures for Flutter apps. My favorites remain BLoC and Provider architecture. Those 2 are the ones Google is recommending on Flutter projects at the moment.
Bloc and Provider provide utilities to implement state management on your app. State management is a key concept to implement great mobile apps, whether it is Flutter, or native Android, or native iOS.
Describing BLoC or Provider could be an article by itself (I may do it someday), so I will keep it simple.
BLoC stands for Business Logic Components. A Bloc is a logic brick between data and UI layers. It manages every change of state of your app by receiving events from UI and emitting states as a stream to the UI layer. Bloc's layer is responsible for the business logic of the app. You can learn more about BLoC HERE
The provider is a simpler pattern, but still very useful. Your data models must implement a ChangeNotifier. When your state changed, you add a
notifyListeners() call. Any widget (Flutter UI component) that changes behavior based on this state should subscribe to this ChangeNotifier by implement ChangeNotifierProvider. This way, your UI gets rebuilt every time the state change, creating successful state management. You can learn more about Provider HERE.
My choice between Provider and BLoC
After trying both, I decided to use Provider because it is simpler.
In my opinion, BLoC is a great package to work with a team. Indeed, it provides the necessary skeleton to make sure everybody can contribute in the same project without any issue.
However, BLoC has a decent amount of boilerplate, which is annoying when you are working alone on a project.
Since I was the only developer on this project, I decided to go for Provider, with less structure but quicker to implement.
The choice: Cloud Firestore
The idea was not to use any backend for this app, because this project does not have authentication, and it takes a lot of time not much to build a backend for this.
This led me to choose a cloud database, and my choice went directly to Cloud Firestore for these reasons:
- linked to Firebase (lots of tool for a mobile app)
- free to use for lots of requests
- online GUI
- filled all my needs
My app requires only one entity, so Cloud Firestore fits my needs perfectly.
I am overall pretty happy with Cloud Firestore. In terms of setup, it was very easy to use, and it took me only a few hours to finalize the database connection.
Here are the drawbacks I found for Cloud Firestore:
- no import from .csv or JSON without implementing a script
- no complex queries (like find an entity by combining multiple fields!)
- necessary translations for field formats such as date
I am pretty happy with the result overall in terms of implementation.
I set a lower standard in terms of code quality for this project, compared to my previous projects. The idea was: build it, ship it, and let's see.
The result is that my architecture is very basic, I have one file by screen, one file by model, one for database connection, one for local storage connection, and that's it.
This structure was part of my strategy for this project, but what I did not expect is that my main screen would be so dense. Indeed, with that kind of simple app, most of the features are linked to the main screen, and you end up with a massive file for this screen.
Considering I wanted my code to remain private, I am fine with the result.
It is an interesting approach to try to find the cursor between quality and time, and I highly recommend trying it to learn more about how to make products.
The good part is that I managed to finalize the project in a very small amount of time compared to the result and the functional scope. It feels good to actually finish a personal project, while I tend not to finish those because I set myself too high standards in terms of quality of code.
I shipped HookMeUp, without any tradeoffs, and I am happy I managed to do it!
I hope you liked the final part of my journey.
In the meantime, do not hesitate to give a try to HookMeUp HERE
Thanks for reading!