I noticed an odd-feeling error while playing with a frontend AJAX call from a localhost server that fetched data from a Google Sheet via a Google Apps Script middleware script.
Any time there was any kind of error in the Google Apps Script code. The JSON-P-based front end call was receiving this message (using the Chrome dev tools Console):
Cross-Origin Read Blocking (CORB) blocked cross-origin response https://script.google.com/macros/s/-yourScriptID-/exec?action=rd with MIME type text/html. See https://www.chromestatus.com/feature/5629709824032768 for more details.</code>
Technically, of course, it was a showing up as a CORS (Cross Domain Resource Sharing) or CORB (Cross Domain Read Blocking) error.
I had a chance to visit in April, 2018 and loved my overall experience.
It was like Ghost In The Shell themed VR laser tag.
Japan. It’s been on my list of place to visit for years. Decades at this point. I finally got to this Spring. On this trip, I got to experience a Live Events tech space that I’ve only previously seen and worked with in the context of pop up shop style one offs for concerts, sports tournaments.
If you’re in the US and you’ve heard of The Void. Perhaps, you’ve been there. I’m about to go check that out next week. VR Zone Shinjuku is a similar VR theme park. I got to play a 3 on 3 game of VR laser tag as a Ghost In The Shel themed operative whose mission is to take out “the terrorists” (the opposing team of 3 in our case).
The staff at VR Zone Shinjuku were naturally fairly tightlipped about specifics of how everything works behind the scenes. No photos were allowed inside, past the entrance.
However, they headset was HTC Vive, coupled with what looked like custom VR tracker shin guards, a gauntlet and body sensor belt that allowed for full range of motion wireless tracking. The ceiling had a ton of what looked like infrared sensors, pointed in every possible direction.
Each player had an MSI VR ONE Backpack PC strapped to their back.
The Vive headset had custom wireless trackers mounted on top of it as well.
These guys were very professional and on top of their game. I was very impressed. The team was highly knowledgeable on the complex gear up procedure and it seemed like everyone spoke at least 3 languages (Japanese, Mandarin and English). I deal with Brand Ambassadors at live events on a regular basis – the VR Zone Shinjuku staff were in my top 3 crews of all time.
First of all, why would you want to? Digital Signage isn’t always just a video playing in a loop, which can run off a built-in media player (like on a Samsung DM55E screen with MagicInfo S3 Digital Signage Software) or a BrightSign player with it’s overly convoluted content management system. Sometimes you have an HTML5 application that can run in Google Chrome as a full screen app, other times you have a complex Unity3D desktop app that also needs to run off more of a serious machine than a typical media player.
You’re certainly better off with a PC in this situation. Intel’s NUC and others now even allow the small form factor that Mac Mini used to rule.
Mac Minis weren’t originally designed for touchscreen displays, but what if you’re stuck with venue or client that has already purchased a Mac Mini and now you have to use that equipment because the budget’s been spent?
One option that works
Assuming there’s budget and you have some leeway in choice of touchscreens, rent an ELO touchscreen. Something like the 4202L 42″ Interactive Digital Signage. ELO does provide drivers for Mac that work with single touch (at least).
Note: ELO’s site provides drivers for lower versions of Mac OS / OS X and says “MAC OS X (10.12): Contact Tech Support for Max OSX 10.12”. Unofficially, their latest driver at the time – UPDD_05_01_1482.dmg – worked for me on Mac OS 10.12. Their tech support never got back to me, so keep that in mind.
If WiFi fails, your ajax call fails and your backup re-submit code fails, you may need a last ditch solution of physically grabbing your form data from inside your PhoneGap app, off of an individual iOS device.
Make sure the app is coded to save data locally using HTML5 localStorage API.
Once the localStorage functionality is tested and working, and you have your PhoneGamp / cordova app running on an iPad, you can use PhoneView to access the file system on your the iPad.
Install DB Browser for SQLite on your Mac. Under the hood, cordova saves your localStorage data as a simple SQLite database.
Retrieve the Data
- Connect your device to your Mac and open PhoneView Demo
- Go to Apps in the main nav on the left.
- Click on Settings in the top nav icons bar and you’ll see this dialog window:
- Check the “Show Entire Disk in Disk Mode” and “Show All Apps in Apps Mode (Developers Only)” boxes. You’ll get a warning confirmation popup, which you should accept by clicking OK.
- You’ll now see your custom cordova app listed under Apps:
- The folders you want is yourApp/Library/Caches/ and yourApp/Documents/Backups/. The file should be called something like “file__0.localstorage” in /Library/Caches or “localstorage.appdata.db” in /Documents/Backups. It’s essentially a SQLite file, and can be opened using an app that lets you view SQLite files.
- To open it, you need to first copy the Library folder to your Mac.
- Click the Library folder to to select it
- Click on Copy from iPhone button in the top icons navbar
- Choose a location to save it on your machine.
- Launch DB Browser for SQLite
- Open your recently copied “file__0.localstorage” or “localstorage.appdata.db” files from your Mac in DB Browser for SQLite
- Click on the Browse Data tab towards the top of the interface
- You should see your localStorage Key / Value pairs listed as a SQL table:
- If you stored your Values as Arrays, your actual data may be stored as a BLOB data type and not plain text
- Select your BLOB value in the table and look at the right side of the interface, under Edit Database Cell
- Make sure the Mode is set to “Binary”
- You should be able to see your data with very bad kerning
- Click the “Export” button above the cell content area
- Save your file as .txt and open the .txt in any text editor, like SublimeText, to access your data as plain text.
The issues this time were very similar, almost identical to what I’ve written about here. Meraki’s individual device page Activity Logs would show us the following error over and over again: “App… Already Scheduled For Management”. On the remote end, in a different city, an on-site event lead would be trying to install and getting the vague “Unable to install right now” popup message repeatedly.
We’ve tried everything from uninstalling all provisioning profiles from our iPads (via Settings > General > Profiles) to sending uninstall/reinstall signals from the Meraki dashboard, both from the individual device page and from the individual app page.
We eventually worked past our “Unable to install right now” message but then got stuck with grey stub icons for our apps that said “Waiting…” under the grey image.
Nothing worked until we did a full factory reset of each iPad, re-set up our Apple ID via the Settings app, re-downloaded the free Meraki app, re-registered with Meraki using our network ID.
Good times were had by all. Dinner was eventually served. Experiential / Live Events marketing + wireless technology = be prepared to have your tech guys on standby.
Here’s a quick example usage of the DC Metro’s real time train schedule API.
I’m pulling data for the Metro Center station.
Note: their feed tends to go down once per day. A good way to test if it’s down, is to check out the WMATA’s own version.
I’ve worked with Twitter, Instagram and Facebook APIs. Those are always a bundle of unpredictable joy/not, as APIs usually are. The WMATA (DC Metro) API is fairly easy to work with by comparison. They don’t have to worry about anyone’s personally identifiable information (PII), hence, less headaches for developers. They provide an adequate level of documentation and are reasonably responsive over email. All issues I had while working with this code were easy enough to resolve, using the ol’ Googley machine and common sense. A business lead I worked with was extra enthusiastic about the project, so he did email the API developers a few times and they responded on the same day.
The rate limit is 10 calls/second and 50,000 calls per day, which should work just fine for most uses. I’d pay extra attention here if you have multiple versions of the code during development (using the live end point) or, if you have a live version out and are working on changes, while using the live API (which is sometimes unavoidable, since there’s no dev end point).
In general, if you call it 3 times a minute or every 20 seconds, as the WMATA’s own real time arrivals web app does, you’ll be more than ok. Here’s a screenshot:
You can see their list of real time arrival stations here. It works rather well and uses their Real-Time Rail Predictions API, but one thing I’d certainly do differently – it’s literally reloading the whole page every 20 seconds to update the data. I’m guessing a backend developer put this together real quick, while working under several deadlines. A simple AJAX call can fix this (there are multitudes of examples of this on StackOverflow alone).
Note: if their app/API feed is down, their real time arrivals link just shows a mostly blank page:
Again, I’m guessing this was done in a hurry.