This project was used for the final project in CSCB07 at the University of Toronto. I have shared the GitHub link to the code with the instructors. If you happen to come across this code, do NOT use this for your own project. You are free to look at the code (I cannot stop you), and learn from it but do not copy-paste any of the code here. As a piece of advice from one student to another, plagiarism is not the answer no matter how much you are struggling, the instructors will find out through their own plagiarism checks.
This was a group project here is the contact info of my fellow collaborators and myself:
- Makrod, Saad (saad.makrod@mail.utoronto.ca)
- Bhattacharya, Anindro (anindro.bhattacharya@mail.utoronto.ca)
- Ou, Denise (denise.ou@mail.utoronto.ca)
- Liao, Mario (mario.liao@mail.utoronto.ca)
- Maqbool, Nimra (nimra.maqbool@mail.utoronto.ca)
Please vist the Individual Contributions section to see how the work was distributed between ourselves.
Furthermore, the images used were taken from Google Images.
This project was developed by using Android Studio and Firebase Realtime Database.
A demo can be seen at https://youtu.be/gmhzkBnsJZ0. Note that there is no audio it is just a quick demo to show how to interact with the app and the database updating.
This project was developed for the final project of CSCB07 at the University of Toronto. We used Agile methodologies to develop this software, specifically we used Scrum. An in depth documentation of our Scrum meetings can be seen at "CSCB07 Project Documentations.pdf" in the repository.
When developing this app we followed user stories for both the patients and the doctors. Here are the user stories:
Patient Goals:
- As a patient I want to log in so that I can see the patient screen.
- As a patient I want to see a list of doctors and be able to filter through them so that I can find a doctor that meets my needs.
- As a patient I want to be able to click on a doctor and see their availabilities so that I can book appointments and see my upcoming appointments updated accordingly.
Doctor Goals:
- As a doctor I want to log in so that I can see the doctors screen.
- As a doctor I want to see my schedule for the week so that I can see when I have appointments.
- As a doctor I want to be able to see patient details when I click on an upcoming appointment.
Additionally we had a list of minimum requirements to complete. Here is the list of requirments:
Requirements:
- Database of doctors: each doctor has a name, a gender (in case patients are
searching for gender-specific doctors), weekly availabilities (which should
change when patients book appointments), specializations (for patients looking
for a specialist), and a list of patients who have visited them so far.
- Database of patients: each patient will have a name, a gender, date of birth,
a list of previous appointments, a list of upcoming appointments, and a list
of doctors at the clinic that they have previously seen.
- Login page for patients, and one for doctors.
- When patients log in they should see their upcoming appointments as well as a
"book appointment" button. When they click that button, they should see a list
of doctors. There is a filter option for filtering on doctors' gender and
specialization. When they select a doctor, they should see the doctor's
availabilities for the upcoming week. They should be able to select a timeslot
and book the appointment. This action should update their upcoming appointments
as well as the doctor's upcoming appointments lists.
- When doctors log in, they should see their upcoming appointments too. They should
be able to inspect the patients and see their info, along with a list of previous
doctors this patient has seen. They should also be able to view their own schedule
and see which patients have booked when, as well as which time slots are still available.
- When an appointment time passes, the patients' upcoming and past appointments as
well as the list of doctors they have seen should be updated accordingly, and the doctor's
upcoming appointments and patients list should be updated.
- The program must be implemented such that if any doctor leaves the clinic or new doctors
join, it should be easy to include them in the scheduling system. Also, when new patients
sign up to use the app, it should be easy to include them as well.
We have implemented all the features listed above.
| Name | Contributions |
|---|
| Saad Makrod |
- Setup the GitHub repo and added everyone as contributors
- Did a demo on how to use GitHub on the command line and set up the repos on your own pc
- Original patient app design (i.e. I made the original plan for the interfaces, abstract classes and classes (can be seen in the first commit) - we updated this as a team as we went along)
- The UIDesign and ImplementationNotes in the notes folder on github (this was only for the patients side we just followed a similar thing for the doctors, the UI design was updated to what we felt as a group worked better)
- PatientBookDoctorActivity - Allows the patients to view doctors based on the selected filters and then move to PatientDoctorAvailabilitiesActivity. Anindro showed me how to use an ArrayAdapter
- PatientDoctorAvailabilitiesActivity - Lists the selected doctor’s availabilities and when the user selects one it updates the database accordingly. It uses the patient and doctor classes developed by Mario
- DoctorAvailabilitiesActivity - I worked with Anindro and I did the addAvailabilities method, so I implemented the feature that allows doctors to add new availabilities and it updates the database accordingly
- Redid the Login Module to MVP design - Nimra implemented the original design and Anindro helped debug the issue. Nimra successfully did the MVP approach but there was an issue with the login button needing to be pressed twice before logging in. I thought of a different way to do it so I controlled Nimra’s screen via Zoom remote control and developed the Contract interface and implemented the model, view and presenter interfaces so that the Login Module followed the MVP. It seemed to work so we went with that. I later updated it so that it read data only once to avoid a recurrence of toasts
- Had meeting with Anindro and Mario to talk about the database implementation and how we wanted to structure the data (since our activities worked with it specifically)
- Tested code before pushing (as per working agreement)
-
Helped debug code in our group sessions
|
| Mario Liao |
- Created a UI design for the app, but did not ended up being used for final UI design for the app
- Earlier in the project, figure out the reason why we weren’t able to access (read/write) from the database which was because our rules for the firebase initially had read and write set to false
- Implemented the patient class, along with it’s update_appointment and book methods to be used in the PatientMainActivity and the PatientBookDoctorActivity. Book method will add an upcoming appointment for the patient in the database, and update_appointment method will not only remove upcoming appointments in which the data has passed, but will also send the doctors that have been visited to a list of doctors that the patient has previously visited via the database
-
Worked with Saad and Anindro to figure out how we want the database to look like and how we want the structure in the database to be (so things like where should the data for upcoming appointments be located for the patients, and what should be the key value pair be, etc)
- Implemented and created the UI for the PatientMainActivity so that it shows all the upcoming appointments for the patient (Anindro helped out here so that it shows the doctor’s name instead of username). Courtesy of Saad for the implementation of the back button in the PatientMainActivity . Also added buttons: log out (log the users out), book (brings the patient to the book activity), doctors (shows the patient the previous doctors they have already visited), refresh (refresh the PatientMainActivity activity so that it will update the upcoming appointments, if any appointments has passed, or any appointments been added, etc)
- Implemented and created the UI for PatientPreviousDoctorsActivity so that it shows the patient all the doctors they have previously visited in the clinic
-
Implemented the doctor class along with the interfaces used for it, along with it’s update_appointment and book methods to be used in DoctorMainActivity and the PatientBookDoctorActivity, so that whenever a patient books an upcoming appointment with a doctor, the doctor will also have that upcoming appointment booked for themselves, and update appointments will remove the upcoming appointments for the doctor which the date has passed and also send the patients that have been visited to a list of patients that the doctor has previously visited via the database
- Extensively tested all my code before committing and pushing to the repo
- Helped debug code in meetings
|
| Anindro Bhattacharya |
- Created a rough outline of the UI design for the app (which was eventually not used after a joint team consensus)
- Implemented the AppointmentMeeting and UpcomingAppointment classes which were planned to be used for updating a patient’s list of upcoming appointments. After learning more about Firebase’s asynchronous nature, our team decided to refactor the design such that the database is directly updated. Thus, these classes were no longer used in the final submission; however, logic from these implementations are integrated in the current code.
Helped Nimra push her implementations for the PatientDB, MainActivity and PatientLoginActivity classes to Github. Commit on August 1st, 2021 at 6:39 PM contains her implementations.
- Implemented the FilterDoctorsActivity which allows the patient to filter the gender and specialization of a doctor in order to get a tailored list of doctors to fit their needs in the next Activity. Saad implemented the Back Button at the top of the screen to allow for the user to go back and forth between activities.
- Added the functionality in PatientDoctorAvailabilitiesActivity that after a patient books an appointment with a doctor, that appointment slot is deleted from the doctor’s list of availabilities. This is to ensure that a doctor is not double-booked.
- Implemented the backend and UI for the DoctorMainActivity which is the page that a doctor sees upon login. This activity displays a list of the doctor’s upcoming appointments in a scrollable TextView and spinner from which the user can click an appointment after which they will be directed to the ViewPatientInfoActivity. There is also the ‘Availability Manager’ button which directs the user to the DoctorAvailabilitiesActivity, the ‘Log Out’ button, the ‘Refresh’ button as well as the ‘Leave Clinic’ button which directs the user to the DeleteDoctorActivity (implemented by Denise).
- Implemented the ViewPatientInfoActivity on which doctors can view a patient’s information (i.e., personal information and previous doctors visited) after having clicked on an upcoming appointment in the DoctorMainActivity.
- Began implementing the DoctorAvailabilitiesActivity. I helped list out the doctor’s availabilities on the screen. Saad had later added the functionality on this activity to allow the doctor to add availabilities to the list.
- Wrote all the Mockito unit test cases for the Login modules. In order to do so, I had to refactor one of the methods in the LoginData class (i.e., the Model class). These test cases have achieved 100% coverage in the LoginPresenter class.
- Helped debug code in group sessions.
- Extensively tested my code before pushing it to the repository.
|
| Denise Ou |
- Brainstormed and created a possible prototype for the UI design using Adobe Xd. I included images and a background (which is the current background for the app that we decided to use) to make it more realistic. Recorded short clips of navigating through the prototype to show the group during our meeting where we all shared our ideas for designs for the UI. Did not end up using my design due to complexity.
- Implemented the MasterList classes for both doctors and patients, which contained methods to add, search, and remove a doctor/patient from the master list. Originally, we planned to use the MasterList class to create a master list to keep track of all the doctor and patient users, in order to let us quickly search for them and perform operations such as booking appointments. However, we learned that it was not possible to keep this master list constantly updated and it would be lost after the app is closed. Therefore, as a group we decided to take out the MasterList classes and not to push the code to the repository, as it was no longer needed.
- Implemented PatientSignUpActivity and created the UI for it. This activity allows patients to sign up and user input is validated through regex. It would throw errors to let the user know that they need to provide a valid input.
- After integrating the code for PatientSignUpActivity with the backend classes, there was an issue with writing to the database. Worked with Nimra to try to resolve this issue. Nimra helped to identify what was wrong and she was able to fix the code so that it was able to write to the database. Then she sent me the edited file so that I can fix the remaining issues such as the error message for a username having less than 6 characters was not showing on the emulator screen.
- Implemented DoctorSignUpActivity and created the UI for it. This activity allows doctors to sign up and user input is validated through regex. It would throw errors to let the user know that they need to provide a valid input.
- Decided to add DoctorSelectSpecializationsActivity as the original plan was to have the doctors type in their specializations into a textbox. However, after considering possible ways to validate this input through regex, it seemed that this way was prone to spelling mistakes or doctors entering different variations of the same specializations, therefore it would be harder to validate the input.
- Implemented DoctorSelectSpecializationsActivity and created the UI for it. Created a layout with a scroll view to allow doctors to check off their specializations from a comprehensive list of specializations that I researched. Then the chosen specializations would be displayed on the DoctorSignUp screen in addition to a toast of the chosen specializations.
- I had a meeting with Anindro to debug the code together for DoctorSelectSpecializationsActivity as while I was testing my code I was not able to get to that activity through clicking the button and the toast messages were not showing up. Anindro helped and provided advice to help fix those issues, such as making sure that the activity was listed in the AndroidManifest.xml file and to delete/re-add the activity as sometimes it could be an issue with Android Studio.
- Implemented DeleteDoctorActivity and created the UI for it. This activity has two buttons that lets the doctor dismiss (if they accidentally clicked the leave clinic button) or confirm deleting their account. When the doctor deletes their account, it would delete any upcoming appointments they have on the patient’s side as well, before the doctor’s data is deleted from the database. This ensures that a patient would not have any upcoming appointments with a doctor that has left the clinic.
- Helped debug code during our group meetings.
- Thoroughly tested my code for the classes and activities that I implemented before pushing the code to the repository.
|
| Nimra Maqbool |
- Created a rough idea of the UI design for our app (which was not used because of the complexity in my design)
- Initially implemented the PatientEntryActivity but I asked the group if I could incorporate the part on Patient LoginActivity to avoid having many activities and the group agreed to it so deleted that class.
- Implemented the PatientDB for the patient user stories (access the database to add patient/doctor and search patient/doctor in the database)
- Implemented the backend and UI of the MainActivity which is the main page of the app that shows the title and doctor and patient button.We can navigate to Doctor signin/patient sign in using the buttons
- Implemented the backend and UI of PatientLoginActivity (Added the logo, also added the password view feature that enables the user to view the inputted password. PatientLoginActivity checks for the username and password from the database and redirects you to PatientMainActivity once login is successful)
- I was having issues with pushing on git, so Anindro helped me push implementations for the PatientDB, MainActivity and PatientLoginActivity classes to Github. Commit on August 1st, 2021 at 6:39 PM contains my implementations
- PatientSignupActivity was not writing to the database, so helped Denise fix the errors with validating input and writing to the database on PatientSignupActivity (and sent the file to Denise through discord so she can continue working on her Activity)
- Implemented the DoctorDB class for the doctor user stories. (access the database to add patient/doctor and search patient/doctor in the database)
- Implemented the DoctorLoginActivity class and created the UI for it (Added the logo, password view feature. Added the logo, also added the password view feature that enables the user to view the inputted password. DoctorLoginActivity checks for the username and password from the database and redirects you to DoctorMainActivity, once login is successful)
- I Refactored the login module according to the MVP approach. I implemented the PatientLoginActivity and DoctorLoginActivity using the MVP approach. But there was an issue with the login button needing to be pressed twice before letting the user log in. Anindro and Saad tried to debug but couldn’t fix the error. Saad thought of another way to do the MVP, so he controlled my screen using the zoom remote control feature and the group decided to go with this method
- Anindro pushed my androidmanifest.xml file and MainActivity on git on Aug 8
- I forgot to push my res file that contained the doctor logo, so I sent the image to Saad, so he added it to the working copy before pushing it on github
- Helped debug code during our meetings
- Tested extensively before pushing the code to the repository
|
The app is straightforward to use. All you have to do is sign up and as either a Doctor or Patient and you can use the app. Please see the demo to see some functionalities of the app.
