My Android application is in the Google Play Store. It's not a hit, it's not rocking anyone's world, and it hasn't had any marketing behind it. This was a simple pet project to keep my mind active and expose me to other aspects of the development process from the perspective of the users I have managed in my working life.
As I mentioned in my last journal entry (https://blog.macleod.systems/blog/learning-to-program-with-flutter), I wanted to evolve my app and add community features. I wanted to explore cloud-based DB deployments, user registration, and verification—I wanted to add value to my app.
The Next Steps...
While the local database of the application was valuable (and Android actually provided database backup for the app by default), I wanted to allow users to sync their recipes to the cloud to implement a sharing mechanism with ease. My first step was to learn how to work with Google Firebase, my chosen cloud solution, since I built an Android app using a Google framework. Let's go all in with the big guy.
I researched and determined how I could map my Hive database to a Firestore database (also NoSQL) fairly quickly. All I had to do was implement the logic to synchronize these details to the Firestore database when saving and editing recipes—simple enough, right? Well, I was getting ahead of myself. First, I needed to create user profiles so that data could be saved specific to each user.
User Registration and Verification
Firebase provides a variety of registration and login methods for your application. I decided to go with the simple email solution to avoid limiting my users to Google or Apple at this time, as I may ultimately create a web app for iOS rather than purchasing expensive hardware and licensing.
This involved a lot of research and leveraging ChatGPT to gain quick insights and suggestions (but remember to understand what you are implementing). One resource I found to be amazing was Mitch Koko, an Android developer who uses Flutter and Firebase for his solutions. He provides excellent guides and information—check him out!
When having an app with user registration in the app store, you must ensure that users can delete their data and account if needed. Keep this in mind for your own solutions.
Firebase Authentication provides a complete registration, verification, and password reset process, which really simplifies everything. I had this up and running with UI changes within a few days.
User Data Storage and Syncing
Now that I had user profiles set up, I could move on to the fundamental storage and synchronization of data. As I mentioned previously, this was a fairly simple process of mapping my Hive recipe models to their Firestore equivalents.
Synchronizing the data depended on modified dates. I ordered the data by the latest modification and checked recipe timestamps, which I structured to an accuracy of seconds (using milliseconds caused some issues). I then determined if there were updates to and/or from the Firestore database that needed to be synchronized.
Community Sharing
Now that I had my data in the cloud, I was able to implement sharing of recipes with a community. I updated the UI to create a whole new tab for community recipes. The structure was very similar to the basic recipe tab, so I could reuse a lot of my code. I had to update my recipe model to support a sharing parameter—you might not want to share all your recipes, as you might have some family secrets you want to keep. The Community tab could then be coded to show all recipes from all users where the share parameter was set to true. Simple enough.
Considerations:
Allowing users to download recipes: We need to prevent duplicate downloads.
Preventing duplicate sharing: If a user downloads a recipe to their local database, they shouldn't be able to share it as if it's theirs. We don't want duplicate recipes in the community either.
Tracking downloads: We should track downloads so that we can show recipe popularity.
Taking it to Production!
After extensive testing on web, android, android emulator with a small group of users I was able to deploy my updated app to the store... I have a few users sharing recipes which makes me happy, but at the end of the day the goal was to continue to lear and challenge myself! I had fun creating the app...and there is still a whiteboard of ideas that I can implement.
Final thoughts...
As with every step of development, I found opportunities for scope creep. You have to reel these items in where appropriate. I wasn't on any organizational timeline, so I got to add what I wanted, no matter how large the scope creep. However, my general advice here, from a personal perspective, is to take small steps and release often.
I made sure that with each production push of my app, I was able to support the migration of existing user data without loss. This is something to keep in mind while defining your Hive/Firestore models and user profiles.
I was conscientious of my app's calls to the Firestore DB. Since this was a free app, I didn't want to incur high costs when I wasn't making any money. As a side note, I did implement advertising in case I need to recoup storage and query costs for Firestore. However, Google's free tier should be sufficient for the activity I am currently seeing.
Consider noramilzing your data as much as possible, for the purpose of searching e.g., lowercase recipe names, split recipe names into seperate strings to allow searching on any part of a recipe name.
Complex searches for Firestore is going to require third party services (like Elastic), for example I found it difficult to create a filter for community recipes based on ingredient - I kept hitting a wall when trying to create a query with several isEqualTo conditions.
