Cordova is a framework that allows you to use your existing Web Application code and wrap it in a system Webview to be deployed as a mobile application.

This week was spent mainly cleaning up and modifying the original app and testing it out on the Android tablets using Cordova. The importance of having a responsive layout was highlighted in this stage of development as the application showed apparent inconsistencies in the design when deployed on the tablet as opposed to the desktop website. This happened because of the difference in viewport between the two devices. Thankfully, Vuetify provides a decent level of responsiveness in its HTML elements out of the box and as such only minor adjustments needed to be made through CSS styling.

One major issue I came across during development this week was related to asynchronous operations in Javascript. I found myself in a situation where console logging an object, along with console logging one of its individual properties in the same line, would both give two separate values when the object would be expanded to show the property in the developer console. This behavior felt startling to me and after spending some time researching on how console logs work I discovered that when you console log an object its values are only evaluated when you expand on said object in the developer tools, rather than actually representing what the value was when the code was executed at that specific line. To find the value of the object at that specific line you need to destructure the object before printing it out.

I also added in a splash screen at the initial booting of the app to perform all asynchronous operations in the background so the user can only view the application from a stable state onwards. A JWT decoding library was also included to fetch the PUID from the QR code and verify the token with a secret stored in the database.

A major hindrance in development for this week came with pouchdb itself and how it was using IndexedDB to store data on the android device. During the initial replication process pouchdb would always collapse with an “IndexedDB went bad” error. After some debugging it was discovered that this crash occurs when replicating a document with an attachment of a sufficiently large size. Reducing the batch size and batch limit and retrying replication after the initial failure allowed the database to be replicated and used properly afterwards. This shows that the database error can be countered and further research will need to be conducted on my part to see how IndexedDB and pouchdb work together to store data.

Once this is done I need to reorganize my code by going through each individual component and analyzing how every single operation is being performed across the application to optimize the overall code structure. As Dr. Shawn frequently remarks to us, the difference between a good programmer and an average programmer stems from how well thought out and organized the structure of one’s code is.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.