During the development of the project there have been multiple times where I advised Brickx to do things differently or I shared some insight into problems with the API or the app. A summary of advice I have given can be seen below.

API Advice

Since the API was rather slow I suggested Ruud to look into the settings to see if the server gets stuck in some sort of sleeping state and is therefore less responsive.

During the upgrade from the old API servers to the new ones I did question him not using a more popular firm like Microsoft Azure. This way he could integrate his whole development environment into Azure which would make management easier as well. In the end it seemed a bit expensive though.

Security

While looking at the API I noted that it was very insecure. It uses API keys but these keys are sent along with every request and furthermore they never expire. This means a hacker can easily intersect a key using Wireshark and start grabbing data from the server. Ruud understood my point but noted that security is not the focus of the application. He also thinks the scenario I detailed would rarely ever happen but if Brickx ends up getting significantly more customers he will look into the issue.

I also noted that when he finally does overhaul the authentication, the users will no longer have to scan QR codes taped to the walls to log in anymore. Instead they would all have their own password and upon logging in with that, they'd automatically get a valid API key assigned to them.

The new WMS app

While looking at the old app's flaws I suggested a bunch of changes to be made so that the end user has an easier time navigating and using the app. The design language had to stay consistent in every screen. I suggested the use of card views. These cards could then be used to separate UI elements and split them into their own sections. I also advised the use of technologies like Dagger2, Retrofit and RX-java. Even though it would increase development time I advised them to be added in favor of future expansion and creating a more robust application overall.

I also advised the use of Java code instead of Kotlin. Kotlin is the new "standard" for Android development but despite that, a lot of developers still use Java. because I wanted a future developer not to get confused at the code the choice to use Java was eventually made.

I also added various small shortcuts in the app to increase quality of life. For instance, during order picking I noticed that the user sometimes has to scan hundreds of product by hand. So instead of having to scan the product code manually 100 times you can input a number on the touch screen or you can hold down the "+" button on the order picking screen to equal the requested amount to the scanned amount. You can see these two UI elements in the image on the left.

I also suggested the progress of every order pick to be saved in the database online so that when a scanner crashes or runs out of battery the user's progress won't be lost. Along with this I wanted to implement status codes for every order. These statuses would indicate if an order is currently being picked, free to pick or on hold. Ruud thought this idea would be really cool and started work on implementing them into the API but that hasn't yet been completed.

End of sprint advice

During the development of the application I kept track of burndown charts and sprint plannings using Trello. At the end of every sprint I came up with a report detailing the progress. You can see these reports under the "Retrospective" articles found here.

Sometimes I got a lot of work done and other times I would be behind. At some point during the COVID-19 outbreak I signaled to Ruud that I was starting to fall behind because of decreased motivation and the lack of direct feedback and contact. In light of this we decided it was a better idea for me to focus on setting up a solid basis for the app rather than rushing to get all the features in. I also had a lot of work left to do on the documentation so it was nice to ease down on the features for a while.

The future of the app

Overall I think the app should be maintained by someone who is familiar with the Android environment. This will ensure that the code quality that has been upheld so far will stay upheld. Because of the inclusion of a Dagger2, the complexity of the project has gone up so finding someone who's familiar with its workings is also a good idea. I personally have already offered to finish up the rest of the features detailed in the requirements after my graduation.

Furthermore I think this app can be expanded on with extra features. I know that Brickx has another app for instance which only servers to scan certain barcodes and does nothing else. Because of how I handle permissions in accounts, this feature could easily be implemented into the new app as well. There was also talk about implementing a POS (Point of Sale) cash register system into the app. I think that would be a really cool idea as well. I already looked into it and it seems pretty doable.