Frontend-Development

How we created a room kiosk system with Vue 3 for Amazons Fire Tablet 7

Marcel Schepaniak

• 13 min read

In this article I want to explain how we created a room booking kiosk solution for one of our customers. I also want to give insights about challenges we encountered as well as talk about things we learned during this project. This will also summarize our thought process and how we finally came up with our technology decision for this project.

Our situation

Our customer has a facility with a variety of different rooms staff members can book via a system which was developed by us in the past. I would describe this system as basic room booking system. The user can open a mobile or a web app and select a timeslot as well as a desired room and then perform a booking. If the room is not occupied at the given slot the booking will be added to the system and be visible to all other users.

The client came up with the idea to equip each bookable room with a simple tablet device which should serve some basic information and also allow the user do perform some basic booking related actions. The tablet is supposed to be installed at a wall inside of the room. The primary purpose of these tablets were the following:

  1. Show whether the room is currently occupied
  2. If the room is empty allow adhoc bookings for 15/30 minutes
  3. Allow to directly stop the current booking of this room
  4. Extend the current booking for 15/30 minutes
  5. Show basic booking information like until when the room is booked or how long the room is not occupied as well as show a small timetable of todays bookings
  6. Set a background image for each tablet and it's room

All of the requirements basically serve the purpose to give the user who booked (or want to book) a room more flexibility and ease the related process. In case he recognizes that the meeting duration is far shorter or longer as expected he can easily stop or extend the current meeting. The user can also quickly and spontaneously book a room by just going into an empty room and press a button on the tablet.

Since the customer had a supply of Amazons Fire Tablets 7 left over the requirment was that the solution should run on these devices.

The requirements for the application itself were paired with some technical constraints the solution had to deliver:

  1. The tablet must not dim and the screen must not lock
  2. The app must not be closeable and be at the front at all time
  3. The app should be easily startable via the home screen of the tablet
  4. The app must be fullscreen

Initial outlaying of a possible solution and technology selection

Given the requirements mentioned above we were discussing different approaches on how to implement a solution. Quickly we found out that we need more information about the Fire Tablet 7 to be able to properly choose a technology to tackle the requirements. It was obvious that it was important that our solution had to be able to run in a kiosk mode. The focus had to be on the solution at all times and the user must not be able to close or hide it. We also were not exaclty sure what Android was running on the device and how heavily it got modified by Amazon and what exactly would be the implications of that modifications.

Some questions which came in our mind at that point primarly regarding the technical constraints were:

  1. How can we achieve the kiosk mode? Is that something we need to enforce through Android permissions? Can we run a web app in kiosk mode?
  2. Is the kiosk mode automatically solving the challenge that the device is not allowed to dim?
  3. How can we provide a good update and setup process for the app and tablets?
  4. Is this in general rather a web or mobile app case?

After digging a little bit into the tablet we found out that the Fire Tablet 7 had indeed a build in kiosk mode which allows you to pin an app to the foreground. It then is only able to be hidden by performing a certain tap combination as well as entering a pin code. That was really good for us.

Unfortunatly the dimming was not direclty related to the kiosk mode. For instance when pinning a certain app the tablet screen fades black after a certain amount of time (which you can set in the settings max. 30 minutes). Completly disabling dimming is not supported by the Fire Tablet 7.

Regarding the Android version it was indeed heavily modified and the only official way to get apps onto the device was via the Amazon App Store. How ever we found out that it was possible to simply install third party APKs on the device like for instance Chrome or even Google Play. That was a bit sobering because we wanted to avoid getting our potential app into the official Amazon store. That was basically because getting your app in such a store usually takes time and effort. Also depending on the store you are confronted with different bureaucracy obstacles. We still could deploy our app manually in that case but deploying a new version would be quite exhausting and time consuming.

At this point we were still slightly favoring the development of a mobile app due to the following reasons:

  • Full control of the device for future requirements
  • No hassle with the screen dimming
  • Native feeling of the app

But we still had some concerns:

  • How can we handle the update process? Does the client have to install the app from the Amazon App Store on each device? Is the update process automated?
  • What about app review queues in the Amazon App Store do they take long? What other requirements do we need to fulfill to get our app in there?
  • For our team creating a mobile app usually takes more time and effort than creating a web app. Would the extra effort pay off?

Especially the update process of the apps seemed like a big disadvantage for the development of a mobile app (regardless of using the app store or deploying manually). In case there is a bug or we quickly need to change something on the client side we would firstly be confronted with the Amazon App Store review queue and afterwards the client would have to go to each tablet seperately and update the app as soon as the update is available (at least in the worst case). Also we could not rely on something like fastlane to automate the deployment into the store since the Amazon App Store is not supported.

This led us to further research on how to solve this challenge by doing a web app. If we would do a web app we still had two issues to tackle though. Firstly how can we make sure that our web app is running in the kiosk mode of the Fire Tablet 7? Secondly how can we prevent the device from screen dimming without Android permissions?

Regarding the first point we chose a simple approach namely building a progressive web app (PWA). We could easily install the PWA by visiting the website and install it to the home screen. From there we hoped to simply use the build in kiosk mode with the PWA. This would ease the installation and update process enormously. It would not feel as native as a self written Android app but we could make it feel snappy with some extra work. The solution to go for a PWA later on turned out to be not well thought out and would cause some trouble.

For the second challenge we found out that it is possible to prevent the screen from dimming for web apps by an API. Some browser support something called a Screen Wake Lock API. We quickly created a proof of concept (PoC) and could validate that the API works under Chrome. A plain implementation is pretty straight forward:

// Create a reference for the Wake Lock.
let wakeLock = null;

// create an async function to request a wake lock
try {
  wakeLock = await navigator.wakeLock.request('screen');
  statusElem.textContent = 'Wake Lock is active!';
} catch (err) {
  // The Wake Lock request has failed - usually system related, such as battery.
  statusElem.textContent = `${err.name}, ${err.message}`;
}

Taken from the Mozilla developer site

At this point we only had to make sure that Chrome was running on the tablet instead of Amazons default browser Silk. Since we were able to install APKs on the tablet that was quite easy. I also can recommened this site which shows what web apps are currently capable of in what browser.

We were pretty sure that a PWA pinned to the app home screen would be most beneficial for us. We would have a deployment process which was not too effort consuming. Also we could benefit from our web app development expertise and create the app a little faster. The screen dimming would also be no problem due to the Wake Lock API. The benefits of an Android app seemed very minor at this point. Since it is a PWA we would also have no URL bar inside the browser and the app would be fullscreen. So we decided to go for a web app in form of a PWA.

The next question we had to answer was what frontend technology we would use. Our backend is mainly written in Python and Django. So we were playing around with the thought to embed the solution directly in our project and use server side rendering (SSR). How ever we felt like having an official API for this case could be useful and more flexible in the future. Furthermore using a frontend framework would ease the development and result in well a structured solution. I know that there are ways of integrating frameworks like Vue and Angular with Django but the integratrion effort did not seem to match the benefit.

Since we used Vue in the past and felt like we should decouple these systems and have an API we went for a single page application (SPA) with Vue3. In my opinion you could have also gone with plain HTML & Javascript or any other frontend framework at this point. It is rather a matter of taste.

The development

I do not want to get in too much detail regarding the development process itself since it was pretty unspectacular. We were quickly setting up a Vue3 project and started programming. We prefered the composition API over the options API since we felt more comfortable with it. As state handling solution we chose Pinia. As build tool we chose Vite instead of traditional Vue CLI. Both Pinia and Vite felt really good and I can just recommened them both.

Regarding the Wake Lock integration to prevent screen dimming we chose a dependency which would ease the integration and use a little bit. This worked also really well.

What was not as easy as we hoped was the creation of the PWA itself. We found out that Vite's plugin system supports PWA. You can find it here. The setup was good but I felt like the documentation was at some points a little bit unspecific. We managed to set everything up as said in the documentation how ever the required service worker did not register successfully. If you are experienced with PWAs this would be probably a no brainer for you but our issue was that we did not know that it is not enough to simply generate a service worker but we also had to implement a callback like the following in our app to register it and make it working:

registerSW({
  onOfflineReady() {},
})

We did not need this functionality so we thought we could spare it. But without it Chrome would not see our app as PWA.

After we got this issue figured out we could finish the development. I have to add at this point that I feel like PWA development is not that much refined. We were struggling with spamming hard reloads, installing and uninstalling the PWA as well as server restards to always have the latest changes we made inside our app. This might be an issue with our development setup but I thought it is worth mentioning here in case anyone else runs into trouble with this. When developing a PWA make sure you are testing the right version of your app and not some old cached version from the browser.

Testing and encountering a major issue in our plan

During development we tested mainly on our computers with the aspect ratio and dimensions of the Fire Tablet 7. We also had a staging with we could navigate to from the Chrome browser of the tablet. Since the PWA functionality was the last thing we implemented we simply opened the site and tested the app beforehand via the browser of the tablet.

This was a major issue during our development process. After finishing the PWA functionality and testing everything locally we wanted to test the PWA things on the tablet itself. Unfortunatly we found out quickly that the Fire Tablet 7 does not support PWAs. That was major issue for us since it was a requirment to pin the solution to the home screen as well as run the solution in fullscreen. We had not especially tested the PWA functionality on the device since we thought that it is surely supported. That was a major misassumption and since development was nearly completly finished and we had not much time left until a prototyping phase should start we felt like we might be ahead of some extra crunch.

We tried to set the browser to fullscreen mode and put a bookmark to the site on to the home screen of the tablet. But the Fire Tablet 7 neither supports one of it. Our first guess was that we had to create an Android app and embed a webview to our site to it. But that felt so wrong at this point because we consciously decided against creating an app. That would have mean we would get the worst of both worlds. So we kept researching if there is not a more charming solution.

Bubblewrap - our rescue

After some time we stumbled over something interesting called Bubblewrap. The description from the GitHub repository is quite accurate so I will just put it here:

Bubblewrap is a set of tools and libraries designed to help developers to create, build and update projects for Android Applications that launch Progressive Web App (PWA) using Trusted Web Activity (TWA).

That was so fitting to our current situation since we had a working PWA but it was simply not supported by the Fire Tablet 7. We were a little bit hesitant at first because from experience those solutions tend to break some functioanlity or cause some other issues.

A TWA is described as the following:

Trusted Web Activity is a new way to open your web-app content such as your Progressive Web App (PWA) from your Android app using a protocol based on Custom Tabs.
Note: Trusted Web Activity is available in Chrome on Android, version 72 and above.

Our biggest concern at this point was whether the Wake Lock would still be working. We were especially skeptical since the Fire Tablet 7 default browser was Silk. Also PWAs were not supported. If we would use a TWA it would internally probably use Silk to launch it which would mean that the Wake Lock API probably is not supported. How ever as described in the documentation the following behavior is used by a TWA (keep in mind that we had installed the newest Chrome version manually on the tablet).

A Trusted Web Activity will try to adhere to the user's default choice of browser. If the user's default browser supports Trusted Web Activities, it will be launched. Failing that, if any installed browser supports Trusted Web Activities, it will be chosen. Finally, the default behavior is to fall back to a Custom Tabs mode.

We set up Bubblewrap like explained in the setup guide (which was surprisingly easy) and started the process with the following command:

bubblewrap init --manifest=https://my-twa.com/manifest.json

That obviously enforces that you have a version of your website live and running so that Bubblewrap can access your PWA manifest. I'm not sure if Bubblewrap also supports local PWA manifests. We had to fill in some information during the process and everything worked on the first try. After that we simply ran:

bubblewrap build

Et voilà the product was indeed a functional APK file which we could simply install on the Fire Tablet 7. Everything was working like in the PWA. Even the use of the Wake Lock API (probably because the TWA was launched in Chrome and not in Silk). We were really a bit surprised at this point because it did not take more than half a hour to convert our PWA to an APK.  One thing which might be a bit tricky and you should definetly watch out for is the digital asset link between your app and your website. If not set up correctly your app will display a costum browser UI at the top.

Afterwards we simply deployed the APK to the tablet and could easily run updates to our site which were visible after a reload of the TWA. No need of deploying a new APK was neccessary.

Learnings & Conclusion

Finally I quickly want to discuss the takeaways for us of this story.

  1. Perform full early tests of your possible technology choice on your target device

Our biggest mistake obviously was that we assumed that a PWA was definetly running on the Fire Tablet 7. If we would have tested that within the PoC our development process might have changed. To make early unverfified assumptions on a unfamiliar system is not good - be sure to verify it.

  1. Vue3, Vite & Pinia were a good choice

The technology choice itself felt really good for our use case. We had a small encapsulated and expandable system created with an up to date technology. I definetly can recommend this technology choice for a project at this scale.

  1. Amazons Fire Tablets are very limited

This one probably speaks for itself, right? It is not possible to disable screen dimming. By default you only have access to the Amazon App Store. The systems base browser is Silk which is quite unknown and might behave different compared to state of the art browsers. No PWAs or website bookmarking on the home screen is supported.

It is also worth mentioning that after some research it seems like these are not only limitations for the Fire Tablet 7 but also apply to more current versions of the Fire Tablet series. Be sure to double check!

  1. Bubblewrap and TWAs seem really good

For our use case and situation we owe the people at the Google Chrome Labs a thank you. The technology worked really well. Of course I can not speak for more complex projects but for our usecase this was really good. The setup and the CLI were charming. We will defenitly keep an eye on it and evaluate more usecases.

  1. PWA development felt a little bit clonky

I think this is heavily opinion intensive but the development of the PWA itself did not feel so convincing. This may correlate with a little bit of inexperience in that field but creating the manifest and registering the service workers felt very error prone. If you managed to set up everything correctly the debugging and working with the PWA can also be quite frustrating. It results in some work to reload everything properly after some changes, uninstall and reinstall the app. I think this is also quite error prone. How ever this might be related me not having that much experience in developing PWAs.

In the end we were quite happy with the way how things worked out. I think in the end we would have achieved the same result directly developing an app. How ever the installation and update process would be costly for the client. If you have access to the PlayStore or Apple Appstore I think things could be a bit easier. Learnings were big in this one for us and we were really pleased to see how well the deployment through the TWA finally went.