Right now the Thali Device Hub runs happily on Android and Windows.
Our demo code is based on
We have a good web client hosting solution for Android KitKat where we have a phonegap/Cordova style framework that takes our PPNET demo code (remember, all HTML/JS/PouchDB) and wraps it up as an Android app.
Where things aren't so good is on the PC for the client. We have a super fragile extension for Chrome where we can run the demo. But we really want code we can share with other people and the Chrome extension is too fragile to share.
Because it was easy I've been looking into what it would take to support JavaFX 8.0's WebView. The problem there is that their WebView code while nominally HTML 5 is really old and missing basic features like IndexedDB and WebSQL. This is a problem because
the PPNET demo needs a local PouchDB instance.
Now I thought we had some good news because the latest release of PouchDB includes an IndexedDB polyfill that runs on HTML 5 local storage which Java FX 8.0's WebView supports.
I spent today testing this functionality out and the results weren't pretty. The really good news is that I fully expect PouchDB to succeed in using the polyfill. The really bad news is that it's clear that the PouchDB folks have literally never tested this
code on a platform like JavaFX. When I realized that even the
didn't work (e.g. the thing that tells the adapter if it can turn on) I knew we were in trouble. I've run into other issues like problems with
allDocs and then()
. There are also issues with
PouchDB's eventing framework on JavaFX
Now the good news is that all these bugs are really minor. So again, the probability of success is good. But the bad news is that we are going to be their first customers on a framework the PouchDB folks have been very clear is experimental. I'm kind of used
to that (anyone remember the early days with Couchbase?) but here's the thing - We really don't want to run on JavaFX.
JavaFX has a dated WebView and no plans I've seen to update it. Furthermore nobody in any of the communities we travel in seem to be using it. So we are really out on our own. It seems much more reasonable for us to invest in something like Chromium as our
PC based execution environment. Lots of people use Chromium and this would mean that our web code was reasonably consistent across both Android and the PC. But unfortunately Chromium is in C++ and we use Java so we would have to use the Chromium Extension
Framework to get access to Chromium and looking at the bugs it's clear that the Java Chromium Extension Framework is still in its very early days.
And did I mention we want to do a demo at the end of the month?!?!? We are supposed to be at HTML 5 in SF. I really don't like the idea of taking a completely new platform I've never touched before that uses JNI to boot and getting that ready by the end of
So we have a couple of options that seem reasonable to me:
- This was Jon's extremely reasonable idea. Everything works client side on Android. So we could just do the demo using two Android devices. This makes me sad because we have done a ton of work to get things working on the PC and
I really want people to understand that Thali is more than just a mobile play. But of all the options this is by far the least risky as it uses PPNET as is.
- We could choose to be first in and just go the JavaFX route. This works well with the Android Only option as, if we get it working, the code should 'just work'.
- Right now PPNET runs by using local PouchDB to talk to a remote server. It's beyond easy to throw in a Hub as the server, the problem is the local PouchDB. Local PouchDB works like a champ on Android but as explained ad nauseum
above it doesn't work very well on JavaFX. But it wouldn't be brain surgery to re-write PPNET to exclusively use the remote hub and not use local PouchDB at all. In return for this our code should run just fine on JavaFX and Android. The only real work items
for performance reasons. But still, the hub would be local so this isn't too bad.
Dual head on localhost
- This idea is a variant on
. The idea is that we can run in a completely normal browser (at least on a PC). The way things would work is that we would put the app in a directory on the file system. The user would call a Java app inside of that directory. That Java app would generate
a bearer token and save it in a .js file in the directory with the app (which means no global installs but I can think of ways around that limitation in the long run) and then call the default browser with a file URL pointing to the index.html file in the
directory. This would launch the browser who would get the bearer token by doing a relative reference to the .js file in the same directory. All the browsers, I believe, will allow this. The browser would then load the index.html which would be completely
normal HTML. No magic. No Java bridge. The only interesting thing it would do is pull in the bearer token from the local .js file. We would then put a second head on the Thali Device Hub to listen to local host. It would also expose the CORS headers so we
wouldn't have cross domain issues. It would only honor requests that have an authorization header that contains an authentic bearer token. I'm using a header instead of the URL (as I did in the proposal linked above) because we are using a normal browser and
one should never, ever, put a bearer token in a URL that is going anywhere near a normal browser. This means that the app can only talk to the Thali Device Hub via PouchDB (where we would set the authorization header as a config option). The upside is that
this would work with the local browser. The downside is that it only allows the local browser to talk to the local Thali Device Hub and nothing else. So, for example, the current PPNET demo takes a shortcut and uses a single Thali Device Hub for both devices.
That won't work in this scenario. Well, sorta. The Android client could use our existing infrastructure so if we ran the single Thali Device Hub on the PC then the Android client could come in through the mutual SSL auth head (which is network accessible)
and the browser based client would come in through localhost. So yeah, I guess it would just work.
Try for Chromium
- This is really a variant on the Android Only option. We would assume that we would only demo on Android but I would spend my time getting Chromium up and running. If I can get it going fast enough then we would demo on the
PC with Chromium. From the demo perspective literally not one line of code should have to change between Android and Chromium so it either works or it doesn't. What I like about this option is that I suspect we want to end up in Chromium in general. JavaFX's
WebView just isn't getting any love. What worries me about this option is that we have another demo coming up in June and in order to get that demo I need to have QRCode support. In theory we have enough time to get both Chromium and QRCode support for June
but it would be tight and it could threaten our demo there. Now, to be fair, the worst case we will be in London. It's just that we might get a key note if we have QRCode support and we won't get the keynote if we don't. But, to be fair, we might not get the
keynote even if we have QR Code support. So there you go. :) Do note that JCEF (the Java Chrome Extension Framework) is not exactly super solid. Looking at the bugs it's clear that the thing isn't exactly production ready and it doesn't present itself as being
so. Which makes me wonder if it's the right dependency to take. But if we want a web hosting solution that can use our Java code on the PC we don't have many options.
Package up Chrome
- Our Chrome extension actually works reasonably well. The main problem with it is that it needs an installer that needs to do things like mess with the registry (this is required by Chrome). Also the thing is a huge stinking
security hole and it would take real work to get it to package up in a non-insane way. Basically we would have to create an installer installer (yes, seriously) to create custom installers for each app so they can all create their own separate security domains.
And then we can only distribute the installer via Google's store. There is no side loading. Which is not very peer to peer friendly.