Transition to Scalable State Management

Initially, our app architecture relied on "parameter passing" for state management, a method good for smaller applications but less suitable for our expanding project. This simple technique, however, was becoming cumbersome. To address this, I shifted to using Provider, a package that centralizes data access and facilitates state management within the application. This change not only improved scalability but also minimized the coupling between widgets, making them more independent and test-friendly. With Provider, only UI components listening to state changes needed to rebuild, enhancing performance.

Architectural Shift to MVVM with Provider

To fully leverage Provider's capabilities, I transitioned our application's architecture from MVC (Model View Controller) to MVVM (Model View ViewModel). This change complemented Provider’s design, which is geared towards efficient state distribution in Flutter. MVVM’s reactive programming style, supported by ChangeNotifierProvider, allows UI components to automatically update in response to ViewModel state changes. This architecture enhanced the separation between business logic and UI code, improving testability and maintainability.

Rethinking the Database Schema for Customization

The original database design in MongoDB centered around a "User" object. This object encapsulated essential information like email, password, and name. Additionally, it linked to other related objects such as Medication, Seizure_event, and Triggers. For instance, within the "User" object, a field named 'seizures' held an array of ObjectIDs, each pointing to a distinct seizure event. We utilized Mongoose on the server to enforce and manage this schema effectively.

Our preference for a NoSQL database like MongoDB was driven by its inherent flexibility. As our application was poised for continuous evolution, the ability to effortlessly add new fields or modify the existing schema was crucial. MongoDB's dynamic nature perfectly suited our needs for adaptability.

Customization for Individual User Needs

Given the specific requirements of a health application, particularly one focused on epilepsy, we recognized the need for greater personalization. A one-size-fits-all approach was insufficient, as each user's condition and triggers are unique. This became particularly evident with our first user in the pilot program, who reported specific triggers related to Fibromyalgia.

To enhance customization, we introduced the concept of user-defined types. While we had a standard set of triggers applicable to all users (like alcohol, sunlight, and heat), we also wanted users to have the ability to add specific triggers unique to their condition, such as Fibromyalgia. However, integrating this feature within the existing schema presented challenges.

Collaborative Schema Development

Working alongside the CTO and our machine learning engineer, we crafted a new schema that aligned with our vision of a highly personalized user experience. This revised schema included a collection named 'constants', consisting of 'type' and 'value' fields. For example, under a 'triggers' collection, a 'lookup_name' field would reference an ObjectID corresponding to a 'constant'. This constant would define a specific trigger, such as Fibromyalgia (type: Trigger, value: Fibromyalgia). This approach was also applied to other constant types like Journal Categories, Medications, and Chronic Conditions.

Our overarching goal was to create a mobile application that could provide tailored journal prompts, specifically catering to the individual user's condition. This revamped database schema was a pivotal step in realizing our ambition of a customizable and user-centric mobile health application.

Transitioning the Backend to TypeScript

A key decision in our development process was the transition from JavaScript to TypeScript for our NodeJS server. Recognizing TypeScript's growing popularity and its array of benefits, I saw our project's transitional phase as an great moment to adopt this technology. Given the relative simplicity of our server architecture, the shift to TypeScript was a smooth and straightforward process. For MongoDB schema implementation, we utilized Typegoose , which seamlessly integrated with TypeScript.

Key Benefits of Using TypeScript

Enhanced Developer Experience: The switch to TypeScript marked a significant improvement in our development workflow. TypeScript's robust type system provided improved autocompletion, more precise IntelliSense, and superior code navigation capabilities. These features not only streamlined coding but also reduced the likelihood of errors.

Increased Code Reliability: TypeScript's strict typing instilled greater confidence in the accuracy of our code. By ensuring type correctness, TypeScript substantially minimized common coding mistakes. This level of reliability was particularly beneficial for debugging, making the process more efficient and less prone to errors.

Conclusion

Working on the IDEA project at Edee Care has been the largest and most enriching project I've undertaken in my career thus far. Working in both Product Management and Software Engineering as an intern, I navigated new technologies and complex problem-solving, gaining invaluable skills. This project, significant in its impact on epilepsy care, not only sharpened my technical abilities but also deepened my insight into user-focused design and innovation.

Be sure to check out Edee Care for updates on their product!