-
Notifications
You must be signed in to change notification settings - Fork 1
IMT3673report
See Readme for done/todo/taiga board
The majority of the code base is documented, there are some exceptions. We cannot guarantee that all the MVC view components or MVC controllers are fully documented. Classes implementing interfaces should not necessary include documentation, but rather have it in the interface.
Since this application contains a lot of views, unit test percentage is low. The argument for this is that views are prone to a lot of change. Since the development of this system will not conclude after the project submission, this has been put on hold, as well as the obvious time constraint. Timesheet generation and utility methods is unit tested.
The activities are build with the MVC pattern.
- Controllers - Responsible for updating its model, and view. This is the class which implements either Activity or fragment.
- Views - Hold all GUI components, interacts with the user. Supplies the controller with updated information.
- Models - Database entries and physical modelling
The idea behind the networking and authentication was that we offer a interface or abstract class, and then different implementation may be made, thus keeping our inner workings functional either way. For networking this is true, however for authentication the time got a bit short, meaning that the interface is still too aimed at Firebase. Another issue is that we did not get the time to actually create a classloader/config manager. Meaning that the concrete implementations is still referenced in the internal system.
- Adaptors - Custom ListView adapters with
- Authentication - User authentication, contains a wrapper interface and a Firebase implementation
- Consts - Globally accessible values
- Exceptions
- Models
- MVCControllers
- MVCView
- Network - Contains abstract network logic and a Firestore implementation
- Observers
We got the idea pitched from an third party, so a lot of the brainstorming around the idea was already done. The application was originally shaped around the third party's use cases. Project management was done through Taiga, where the authors added user stories and what not. Issues in Github to highlight bugs or enhancements.
We had two protected branches (develop and master) meaning that nobody was able to push directly into them. All code contributions had to be pushed to a separate branch, reviewed, pass build tool, and then be merged into develop. We also had one author writing from his own fork, this meant that build tool was not ran at PR, to combat this we had a staging branch dedicated for this. In this branch changes, which passed review, where merged, and then a separate PR into develop ensured us that all contribution passed the builder system.
The nice thing about this project is, especially in our case, is we could apply prior knowledge gained through the bachelor thesis. Since we had a mobile front-end, some hurdles had already been conquered.
One unforeseen issue was the excel creation, this is usually done through Apache POI, but Android lacks the support for it. We did find a workaround though.
Time wise this project was thoroughly hindered by being in the middle of the last stages of the bachelor. As a consequence, most of traditional software engineering process where thrown right out of the window. In a sense the project where done in a extreme agile fashion, to the point where we could draw parallels to XP.