0

window.caches in BrightSign HTML project always returns null cache

I'm working on an HTML project that is targetting BrightSign. It's something that needs to be tolerant to the loss of an Internet connection. I decided to test to see what local caching options I had. I used the following, which just checks to see if the necessary objects exists. 

 

   function main() {
     $('#supportsServiceWorker').text((navigator.serviceWorker)?'supported':'not supported');
     $('#supportsIndexDB').text((window.indexedDB)?'supported':'not supported');
     $('#supportsLocalStorage').text((window.localStorage)?'supported':'not supported');
     $('#supportsCache').text((window.caches)?'supported':'not supported');
   }
 
The results looked promising.  I tried testing the serviceWorker by pointing the BrightSign to a simple web app that calculates sderal time and from what I see the serviceWrorker, while the object shows as existing on the window, is never actually instantiated. You can see it at https://siderealtimepiece.firebase.com
 
I tried to instantiate a cache object and add something to it myself. 
 
var cache;
function cacheTest() {
    if(!window.caches)
        return;
    window.caches.open('cache1')
        .then(function (returnedCache) {
            cache=returnedCache;
        }
}
 
 
If I run this on my computer's local browser to validate the code it works fine. When it runs on the BrightSign I find that windows.caches is not null, I am  able to make a call to window.caches.open and the promise is fulfilled, but instead of returning a cache object a null object is passed instead. 
 
What's going on here? The presence of a non-null window.caches object with an open method suggest that cache is something that I can use on BrightSign. But the outcome of the above suggest that I cannot?
 
I am running this on an XT 1143 with firmware version 7.1.65
 
One of the support pages says that this firmware version is based on Chrome 45. When I look at the CanIUse page for this version of Chrome both serviceWroker and cache are shown as supported. Is there something additional that I must do to make them work?

4 comments

  • 0
    Avatar
    Joel Johnson

    BTW: I looked further at localStorage

     

    I've found that localStorage appears to work at first, but it works more like sessionStorage; as soon as the device reboots the contents in localStorage are lost. 

  • 0
    Avatar
    Ben Hoad

    have you had any luck getting service worker registration happening? It's something i've been trying to solve on and off for months now, some public test pages show it's available and others fail to register. I'm not sure if there's a setting missing or just something outright blocked due to the weird flavour of chromium that's used by brightsigns. 

  • 0
    Avatar
    Joel Johnson

    No, I am afraid not.

     

    The best I can tell cache and some other features are just plain not implemented. I understand that the BrightSign units are using a stripped down version of Chromium. Having worked with the Chromium source code before (it isn't easy to navigate or compile) my guess is that rather than completlye remove the classes cleanly they removed the implementation for the classes. In the general case I can kind of understand this; the devices are primarily viewed as having read-only memory and are serving up some light weight HTML. More advance HTML features were probably seen as less of a need. 

     

    I've had to implement a workaround for my scenario. The only form of persistence that I've been able to make use of is from enabling the Node features for HTML views and then directly writing to the file system the node fs object myself. Juxtaposed to how things work when you do have access to the cache and service worker objects this solution feels very much like reinventing the wheel. But it gets things done. 

     

     

  • 0
    Avatar
    Ben Hoad

    damn... it looks like this will be the path we'll have to take too. Thanks for responding so promptly! :D

Please sign in to leave a comment.