During the development of the app I have done research into the Brickx API and the BrickX software. During this process I discovered some weaknesses which I will detail below:
The security of the API is lackluster at best as it uses tokens that never expire. Tokens are also sent in plain text to the server with every request so it's super easy to grab one with a WireShark and completely blow the whole network open. I addressed this to my mentor and he replied by saying that no one would ever do that since the app isn't used by that many people yet and that we can fix it later but it does not have priority as of now.
The Brickx API was missing a couple of features. One of which was a function to return user data to a client so that you can display a user's name and possible permissions. This is especially helpful since some user's aren't allowed to use certain features of the app. These features will now be removed from the main menu accordingly which saves some headache.
The speed of the API was often lacking. Sometimes a request would take less than a second to come through but other times it would take up to 10 seconds. We did some testing to see what was the cause of this huge difference in speed. We ended up finding a couple of problems with the API. Inside the Microsoft IIS manager we changed the service to always keep alive instead of "falling asleep" every 5 minutes. We also upgraded the servers to SSD storage which massively improved response time.
In the new app I tried to circumvent the speed problem by splitting up API calls into smaller portions. For instance I now make a separate call for images and data and request both of those asynchronously so the user doesn't have to wait for responses too long.
We also split up and optimized some models. For instance, there was an old model that was used for order picking information. This model held a duplicate of the same data twice. One for a legacy dto and one for the new one. So we removed the duplicate effectively cutting in half the required processing time and data required.
The API had a problem where it would return an SQL error for duplicate keys. This happened when you send multiple requests to it on the same user in quick succession. This ended up being a synchronization problem between the app and the API. It turns out that with the threading used in the app with Retrofit was sending the requests so fast that it caused problems in the API where two indexes were reserved at the same time. We solved this issue by creating a new API session for every request that it got.