Tablet devices, particularly the iPad, have been described as “terrible computers with pretty decent graphics processors”. The hardware capability of your iPad is far less than what you’d find on the computer on which you are likely reading this post. That created a challenge when it came time to design CxAlloy TQ for tablet devices. The iPad seems pretty quick – icons slide around the screen as smoothly as you can swipe them. Even using CxAlloy TQ from Safari on iPad seems to operate similarly to using it from a desktop browser. So, it may seem like designing a tablet-oriented interface for the software would just be a matter of creating bigger, touch-friendly buttons, right? Not exactly.
Offline Changes Everything
With the CxAlloy TQ mobile web app we wanted to do more than provide a touch-friendly interface for the software. After all, the desktop software is already fully functional on an iPad. The primary purpose of CxAlloy TQ would be to work offline. This one feature, offline access, completely changed how the mobile app would function compared with the desktop version. It would be a challenge, but we knew we could tackle it. And we knew we had to – the benefits of being able to work in the field without an internet connection were just too great to ignore.
One of the biggest challenges was performance. So-called “native” apps – those you’d download from the App Store or Google Play Store – interact more directly with the hardware[footnote 1], while the web technologies upon which CxAlloy TQ is built operate at a higher level. Using web technology gives us more flexibility to fix bugs quickly and roll out new features as soon as they’re ready, but require us to more carefully optimize our code to ensure the app is fast and responsive.
You may think it can’t be that difficult since you probably visit lots of regular web sites on your iPad and they don’t have any performance problems. Perhaps you’ve even used CxAlloy TQ – the desktop version – from your iPad and found that it is pretty zippy. This is because of another advantage that traditional web apps have – servers. Most of the heavy lifting of searching through records and building pages is done by dedicated servers that were built to do just that. So, every time you visit a page in CxAlloy TQ, most of the work to create the interface in front of you was done by the servers and shipped down to your browser. But in order for the CxAlloy TQ web app to work offline, it can’t depend on the availability of the server to do the heavy lifting. It’s on its own to process data and build the interface. It has to do this with the iPad’s relatively meager resources.
Zombies, Workers, and Hardware Acceleration
So how do we manage to create a fast and responsive web app? Well, there are a few tips and tricks we can use to spread the work around and manage the device’s memory effectively.
For example, when the software syncs its data up to the server, it does it using a background process called a “web worker” which means that the main processor can spend its time making sure the interface is snappy while the background is busy chugging away sending records to and from the server.
Another trick is to utilize 3D technology to draw the interface in the mobile web app. This may seem odd seeing as how there aren’t any 3D graphics in the software, but by offloading certain interface elements to the tablet’s 3D hardware (which is surprisingly powerful), we can free up the main processor for data crunching while still keeping things sliding around smoothly on screen. Offloading something onto a dedicated piece of hardware is called “acceleration” and it’s a good name; graphics that are hardware accelerated are much, much faster than those controlled by the software itself.
Another challenge with offline web apps are zombies. Zombies are bits of code that seem to go away but actually hang around eating up memory (or “brains”, if you like) which slows things down. They also sometimes will pop back up, causing errors when you least expect it. Like most zombies, they are difficult to track down and dispose of and will generally ruin your day. On desktop web apps, zombies are cleared out every time you navigate to a new page, but since the page never really refreshes in an offline app, we have to be vigilant in order to not cause zombies.
A Nip Here, A Tuck There
Hardware acceleration, background processing, and zombie-hunting coding practices are good overall habits for making sure things are running as smoothly as possible, but unfortunately, there is nothing we can do to speed up the iPad’s hardware. Some actions are just slower on an iPad. In those cases we can employ techniques to make the software feel faster.
Recently, we removed a 300ms delay on tapping elements such as buttons in the app. By default, an iPad will wait 300ms after you touch the screen before it counts it as “tapped”. It does this just to make sure you aren’t holding your finger down in order to “press” something. We don’t have anything in our interface that needs to be “pressed” so we included code that doesn’t wait for this 300ms before declaring something “tapped”. The result is an almost imperceptible change than makes everything “feel” much faster even if we only cut out 300ms from a tap.
Another recent change that helps to make the software feel faster is the addition of a loader on a record’s detail view. When you load up the checklist section, for example, it has to not only load up the list of checklists, but it has to load up the first checklist in the list (or the last one you viewed), as well as all of the checklist lines for that checklist, images that have been downloaded, and issues. It’s a lot for a humble iPad and it takes some time. By adding a large loading animation we communicate to the user that their request was received, providing a visual indicator for what is happening. We also added immediate color changes to list items when tapped to confirm to the user that the software has received the action and is working instead of the user waiting to see if the software really did register their tap. Uncertainty over what the software is doing leads to discomfort. And discomfort is a slow feeling. It may seem a little “smoke and mirrors”, but the end result is a mobile web app that feels responsive and quick even as it is processing large amounts of offline data.
— footnotes —
So-called “native” apps – those you’d download from the App Store or Google Play Store – are created using native technologies that are translated (or “compiled”) to the binary code that computers can understand before they are sent to users. Web technologies upon which CxAlloy TQ is built is “interpreted” code, which means that it is translated to machine-readable binary code every single time you use the app. Interpreted code is much more flexible than compiled code, allowing us to fix bugs and address problems more quickly and easily as well as give us the potential for a cross-platform app. But, since interpreted code is converted when it is run, it is slower than compiled code.