Code Cleanse
Case Study : HuntsReg App
Ben Martin is the founder and CEO of HuntRegsApp, a mobile app that caters to hunters by providing them with an easy-to-use tool to help them determine the regulations for their hunting location and track their hunting activity.
The HuntRegsApp has become increasingly popular among hunters across the United States, with its unique features such as the ability to track individual animals using observational data, and access to up-to-date information on hunting regulations for each state.
The app also includes features such as weather conditions and journaling, which help users to plan their hunting trips and keep track of their experiences.
As the CEO of HuntRegsApp, Ben Martin is dedicated to making sure that the app continues to evolve and meet the needs of its users. He approached us to ensure the product was sound. We're happy he came to us, there were a lot of problems we identified.
The issues found in the HuntReg application are summarized below, along with the recommended solutions:
Bugs in Regulation Data Download:
Problem: Regulations take too long to download, making the app laggy and most features unavailable. Downloading all states (which will eventually grow to 35+ states) is not sustainable, and downloading data for four states already takes up 80 MB of space.
Identified Issues: App data model is designed for offline use, leading to slow execution times due to downloading all data on every request. The large number of regulation records requested and inserted into the local database also contributes to slow execution times. The state filter is not working, and the app makes repeated calls to APIs in a loop.
Proposed Solutions: The app should be taken to offline mode by user action, e.g., starting a hunt, which will make everything available offline. The app should request only the required data by applying filters such as state and zone instead of fetching large data. The state filter in the backend API should be fixed, and repeated calls in the app should be fixed.
Issues with Subscriptions:
Problem: After subscribing, the app sends multiple requests to the backend, the user subscription state is lost upon launching the app, and there is no verification of successful payment from the backend to Apple. The app also charges separately for each subscribed state, which is a slow process. The app allows users to subscribe to states they are already subscribed to, which causes crashes.
Identified Issues: The app does not inform the backend that payment was successful, and the backend does not verify with Apple. The app should check the subscription state of the user at every next launch. The process of downloading data as part of the subscription process slows down the process, and the app crashes when an error is returned from the backend API.
Proposed Solutions: The app needs to inform the backend that payment was successful and the backend needs to verify with Apple. The app should check the subscription state of the user at every next launch. No data should be downloaded as part of the subscription process, and the app should always request from the backend unless the user is going on a hunt. Error states should be handled gracefully in the app.
Issues with Journaling:
Problem: Journal entries and graphing are unstable, and filters do not work correctly. Weather data is not always saved with journal entries, editing journal entries can cause information from the entry to be deleted or cause a crash, and when filters are applied, not all relevant journal entries are shown.
Identified Issues: Data is being ingested in two places in local storage and the backend, but there is no synchronization process and error handling. The weather request is made inside the app, making it prone to bugs, with no visibility on what parameters are going to the weather service and what data is coming.
Proposed Solutions: No data should be downloaded in online mode, and the app should always request from the backend unless the user is going on a hunt. The Weather API should be set up in the backend, and the app should request weather from there. A proposed new data model should fix these issues.
Ben ending up hiring a new developer based on our consulting and the product is now live & thriving.