Bugs & Issues

Throughout the project a few notable bugs have popped up.

Api

Possibly the most annoying one to deal with was the API bug that broke the API when too many commands were sent to it at once. We ended up fixing that by creating a new API session for every received request. I have detailed more about this in my research paper.

SonarLint

Some other bugs were noticed by SonarLint, a code quality checking tool. One of the bugs had to do with the way the program checks serial numbers in saved orders. SonarLint detected an infinite loop and a memory leak in the for loops that I set up. The reason for that was me incorrectly incrementing a value. I likely did this because the naming scheme I used for the variable was not very good. It was a nested for look with two indexes named "i" and "i2". I changed this after I noticed the bug and the issue was resolved.

The other bug had to do with a method already returning the same value. After close inspection I did indeed return the same value in both outcomes of the if statement. A quick code refactor fixed this though.

Apart from bugs SonarLint also told me to make use of Loggers instead of printing errors and messages to the terminal manually, so I did that. It helped me clean out unused imports and write certain parts of code in less lines. Going through the code in this manner was also a perfect time to clean up some of the "Todo" tags I placed during development. A lot of them had already been done but some of them needed updating. In the future I plan to resolve all of them but for now there wasn't enough time.

Dagger2

Because this was my first attempt at a Dagger2 app, the start of development was very rough. I spent 2 days just getting the app to start up. There were various dependency issues with Dagger2 as it requires certain plugins. These plugins have to be the right version though or they won't be compatible with other plugins. It took a lot of puzzling things together but I ended up needing some additional libraries that weren't detailed in Dagger's documentation. Maybe this had to do with the fact that I was using Retrofit and RXjava at the same time. It cost me a lot of time and energy but in the end I can safely say it was more than worth it.

GPU profiler output before scaler was applied. Bars indicate frame time. Lower is better.

GPU profiler output after the scaler was applied. Bars indicate frame time. Lower is better.

Graphics & Performance

Ever since the start of the project I had some issues with performance. At the time I though the issues had to do with the drop shadows underneath every cardview. I though this because shadows are drawn by the graphics chip and the Zebra scanners all have rather poor GPUs.

At the end of the project I though to use Android Studio's built-in hardware profiler. When I did this I found out that both the login screen and the main menu suffered from poor frame rates, around 20 frames per second to be specific. You can see this as indicated by the bars in the screenshot on the left. If the bars are under the green horizontal bar the screen will be updating at 60 FPS.

Through the profiler I discovered that the brickx logo on the background has a massive resolution and not only that, also all the icons for each menu items had a resolution far greater than needed.

As a solution I decided to make a custom image scaler that takes a view's actual size in pixels and rescales the image to match the view's size. A snippet of the code can be seen below.

As you can see in the image directly to the left, the GPU profiler indicates that the app neatly stays above 60 FPS. This ended up improving the performance of the app by three times and it also managed to cut the power draw in half. Not too shabby!

Page updated

Google Sites

Report abuse