Welcome to medTimer Discussions!

[Futsch1]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[KaungJr]

Hello Florian Fetz,

We are a group of students from Iowa State University, currently studying Software Architecture and Design. As part of our course, we have adopted your MedTimer project as a case study to apply the concepts we are learning.

We chose your project because it offers a solution for managing medications. The app has useful features like medication reminders and a simple calendar view. Through our research so far, we’ve learned that the main goal of MedTimer is to help people keep track of their important medicine notifications concisely and easily without relying on the internet or wifi. We were particularly impressed by the app's security, which keeps all data on the user's device, and its simple, user-friendly interface.

As part of our course, we are exploring architectural concepts and how they apply to your codebase. If we identify any opportunities for improvement in the code or documentation, we will open an issue in the project and wait for your feedback to continue working on it. We hope to add useful features and squash bugs to help improve the quality of the app. Please let us know if that is the proper process.

We are excited about the opportunity to contribute and collaborate with you. This app seems very important to many people so we look forward to learning from this community and sharing our insights.
Thank you, and we look forward to working with you!

Best regards,
Michael Linker, Owen Wardyn, Adam Hopf, Kaung Son, Chris Smith

[Futsch1]

Hi guys,

this sounds great, love it that you chose this project. I indeed hope that this app helps those that use it and that it supports those uneasy with commercial applications managing very sensitive private data.

Also looking forward to your feedback and contributions, this is definitely welcome! If you guys aim to implement a feature already part of the issue list, make sure to pick one not yet assigned to a milestone, since I might be already working on it.

Talking about architecture... well, there is not an explicit one I fear. I concentrated on keeping the code fairly clean (using Codeclimate and SonarQube) and employed some design patterns, but not to a great extent. So there might be more to improve than to learn from, but give it a try! One thing I spent a lot of time with is the tests - both unit and Android tests. These would also help you when you do any kind of changes: If they still work chances are not too bad that nothing was broken.

Looking forward to hearing more from you!

[KaungJr]

Hi Florian,

Thank you for your response! We’ve been diving deeper into MedTimer’s codebase and have identified an opportunity for refactoring that aligns with SOLID principles, particularly the Single Responsibility Principle (SRP).

The issue we have identified is in the notifications.java class. We want to propose splitting the class into two separate classes (GetNotification and DisplayNotification) and stopping the SRP violation in the notification class. Each created class will handle one responsibility currently in the notifications class on its own and make the project follow the SOLID principles more closely by removing a breach of SRP. The GetNotification class will handle obtaining data from notifications, and the DisplayNotification class will display the notification on the UI for the user to see. We hope that by splitting up the responsibilities of the notifications class it will be easier to add features to notifications later because it is easier to figure out where to put the new feature.

We’d love to hear your thoughts on this refactor before proceeding further.. Do you think this aligns with the intended architecture of the project? We're open to any feedback you have.

Looking forward to your input.

[Futsch1]

Sorry for not replying earlier! The Notifications class could be improved from my point of view by extracting the creation of the notification using the builder pattern (refer to PendingIntentBuilder for example). This would improve the class significantly I think.

[Futsch1]

Guys, before you start this: I am currently implementing #419, which will result in major changes in the notification class. So better not start to work on this one right now.

[KaungJr]

Hi Florian,

We’ve been digging more into the MedTimer codebase and wanted to share some thoughts on how we could make it even smoother to work with. One thing that caught our eye is how the authentication logic in MainActivity.java is mixed in with the UI code. It works, but it could get tricky to manage as the app grows. We think it might help to pull those authentication functions out into their own AuthenticationService class. That way, MainActivity.java can stick to handling the user interface, while the new service takes care of all the login-related details. It’d make the code easier to follow and tweak down the road.
Another spot we noticed is in MedicineViewModel.kt, where the getFilteredEvents method juggles filtering reminder events based on tags. It’s doing a lot in one place, which could make it harder to update or debug later. We’re wondering if moving that filtering logic into a separate MedicineFilterService class would be more efficient. This would let the view model focus on managing medicine data while the new service handles filtering. Plus, it’d make the filtering reusable across the app if needed.
We’d love to hear what you think about these changes. We are excited to contribute to MedTimer.

[Futsch1]

Hi guys,

extracting the authentication service sounds like a good idea and is very easy to test. Go ahead and do it, create a PR and I'll review it.

Regarding the filtering, this is a bit more tricky I suppose. The idea here was that the view model fully encapsulates the filtering transparently for the view. Extracting the filtering from the view model is certainly feasible, but be aware that all the data is loaded asynchronously from the database and availability/readiness of data needs to be considered. But go ahead here as well and see what you are able to achieve.

Looking forward to your PRs!