Attendance Tracker Project Proposal
As part of the project we received the original teams proposal and final documentation. Which was to then allow us to understand the project to an extent and allow us to write our own proposal of what we would do to continue the application’s development.
Original Team’s Proposal
For the original team they had proposed that they would develop an app based of the the specific requirements put forth by the client to best fit their current work flow.
Current Work Flow
The current work flow being that students at the beginning of the semester would receive an email from the client asking them to generate a QR code containing their first and last name in a specific format. Such as last name,first name.
Then at the beginning or end of a lecture the client would set up a tablet that the student’s would then scan the QR code on. This acting as the confirmation and record that they had attended that lecture.
The app that the client used would then export a text file containing all the contents of the QR codes scanned. With each QR code’s contents being on a separate line. This file would then be used to create a master attendance sheet like the following.
| Last Name | First Name | Days Attended | Date 1 | Date 2 | Date 3 | … | Date n |
|---|---|---|---|---|---|---|---|
| Doe | John | 3 | 1 | 1 | 1 | … | … |
| Adams | Samuel | 2 | 1 | 0 | 1 | … | … |
| Doe | Jane | 1 | 1 | 0 | 0 | … | … |
Objectives
With that information in mind the team that build version 1 concluded they needed to be able to import a list of students and their corresponding emails. Afterwards the app would then give the client the ability to generate the Unique QR codes for the students and then send them through email.
This app would then also replace the app the client was currently using for QR scanning. And allow for the master attendance sheet to be generated from the attendance data stored within the app.
With the app also needing to provide the ability to add individual students to a class list at any time in the event that they were added late for one reason or another. Each class list would also be stored separately as well.
Constraints
The original team of course couldn’t just do this any way they saw fit and where given a few other constraints by the client. The major ones being that it must be written as an Android app in Java.
Original Team’s Final Deliverable
The original teams deliverable for version one contained some of the functionality proposed in the original proposal. Along with other functionality that lend itself as useful to the user. With this being accomplished using 9 class files according to their final documentation. These class files being the following.
| Class Name | Description |
|---|---|
authenticationActivity |
Activity indented to be used to allow the user to log in to the app using Google Authentication which was requested by the client after the original proposal. Was not working as intended as of the writing of the original teams documentation. |
ClassListAdapter |
Adapter class used to create the list displayed in SectionViewActivity. And added the functionality that allowed for students to be removed according to the documentation. (It was later found that a bug in the layout received from the previous team hid this functionality from the user. Which is why there is no removal button in the screenshot below.) |
MainActivity |
Intended to be initialized from authenticationActivity upon the user successfully logging in. Which was not fully implemented at the time the original team wrote their final documentation. The activity would display a list of semesters available to the user which could be selected. Also provided the ability to add and remove semesters from the list. |
RecyclerViewAdapter |
Adapter class used to display the list of semesters in MainActivity as well as the list of classes in SectionListActivity. As well as providing the ability to select or remove those items from the list which would be triggered in their respective activities. |
SectionListActivity |
Initialized through the selection of a semester in MainActivity to display a list of classes within that semester. While also giving the user the ability to interact with the list by adding to or removing classes from it. |
SectionViewActivity |
Initialized through the selection of a class in SectionListActivity to display the list of students within that class. It allows the user to add students individually as well as in bulk. (Not documented within the final documentation but the source our team later worked with did not having the import function working.) |
SettingsActivity |
Initialized from a menu found in MainActivity and allows the user to purge the database. |
StudentDetailsActivity |
Initialized through the selection of a student in SectionViewActivity with it only displaying the student’s name and generated QR code as of the writing of the original teams final documentation. |
TinyDB |
As mentioned in the final documentation this was found on GitHub. And was used to store all the data used within the app. Including semesters, classes, and students. |
Images Of Original Final Deliverable
Login Screen
Login Screen
List of semesters
List of semesters
Menu in the list of semesters
Menu in the list of semesters
Settings screen
Settings screen
List of Classes within a Semester
List of Classes within a Semester
List of students within a class
List of students within a class
Adding an individual student.
Adding an individual student.
Menu in the list of students
Menu in the list of students
Student Details Screen
Student Details Screen
Tools Original Team Used
The original teams final documentation also made mention of using some other tools. Some of which where expected given it was an android app such as Android Studio.
What came as a bit of a surprise and wasn’t mentioned elsewhere in the document was that they made use of Firebase.
After some investigating it was found that the previous team was actually making use of both Firebase and TinyDB for the storage of data. Though TinyDB was clearly the more polished implementation. With all the information being presented to the user coming from there. Along with there being no method of syncing the two databases.
Making it so that while Firebase was written to and deleted from. It was never read from. Which we found strange but concluded was likely a result of them planning to use TinyDB for testing with the intention of transitioning to Firebase. Though due to lack of documentation we could not confirm this.
Beyond that they also used ZXing “Zebra Crossing” for the generation of QR codes within the Student Details screen. And other than that the other tools listed included TinyDB, GitHub, and Android Studio AVD Manager. With these tools allowing easier collaboration as well as the ability to emulate an android device.
Our Proposal’s Objectives
With all of this in mind the Objectives of our proposal where as follows.
Generate and Distribute QR Codes
The original implementation found in the project worked as a demonstration. But unfortunately did not provide all the functionality required to meet the client’s requirements. So one of our main objectives was to make this functional. Another part of this objective was to fix the importing of students. Which in the original resulted in an error.
Implement QR Scanning
Another item that the client had requested and wasn’t complete in the original project was the ability to scan QR codes. So this was another one of our objectives in order to provide a more functional app. There would also be an option to manually mark student’s as present if the QR scanning failed.
Implement an Attendance History
A major portion of the original project that did not appear to be implemented was any sort of record of attendance for students. So we planned on implementing that along with the ability to view a student’s attendance record within the app. As well as provide the ability for the client and future users to export the attendance record of a class in the form of a CSV file.
Implement Authentication using OAuth
And finally we planned on implementing Authentication using OAuth to sign in with Google. This would not only allow us to prevent unauthorized users for accessing the student records. But also allowed us to more easily make use of Firebase. Allowing us to give specific users access to there own data and not others.
This would also later allow us to make it possible for a user to view their data across multiple devices making use of the online database to sync between devices.
Conclusion
And that overall is what we originally received for our project and our proposal on how we would continue it. There are some other details that I have left out though for a few reasons.
Either way it was certainly the beginning of an interesting project.