A milestone: Thali running Little Outliner, syncing between the Java hub and the Android hub

Developer
Apr 4, 2014 at 6:29 PM
Coordinator
Apr 7, 2014 at 12:41 AM
tl;dr - Your demos should run in KitKat!

Now, why KitKat?

I'm glad you asked!

I spent a good chunk of this week trying to get test.js to run in JavaFX. That eventually failed because it turns out that JavaFX doesn't support indexed db or websql, just local storage. Now this problem is potentially solvable because there is work to polyfill indexed db over local storage but that's a thing and I didn't want to tackle it.

So per our conversation I decided to switch to Android. That also turned into a mess because it turns out that WebView in Android doesn't let you open more than one WebSQL DB at a time. Which is just a silly pain. I suppose we could have worked around it but it's the sort of contortion that makes you do bad things to your code.

Now the good new is that there is an officially blessed solution which is a Cordova plugin that supports WebSQL and makes PouchDB run all bright and bushy tailed. But this would mean bringing Cordova into the picture. In the long term that's a happy thing. In fact I'm hoping we can get Cordova to put in decent support for the desktop and then use Cordova as our officially blessed multi-platform Thali app solution. But for now Cordova doesn't support the desktop and using it is a 'thing' and I really didn't want to complicate my life.

But I read that KitKat uses Chromium for its WebView and my guess is that it should run, well. So after a bunch of silliness I got the full test.js demo running just fine in WebView using KitKat!!!! Tomorrow I'll stick together a project you can use to pour your demos into. So we should be able to demo on Android by this Friday! Combine that with our Chrome code and we are good!

Note, btw, that you will need to update your x86 code to the 4.4RC1 release to make this work in the emulator.

Also note that there is a seriously awesome feature supported by Chromium WebView, you can actually debug remotely via Chrome! I tried it out and it works. It's not quite as slick an experience as just writing the code in Chrome directly but it's close. See here for debugging details.

The next step is obviously to get us a story for Java. We don't need this for the Friday demo but I REALLY want code people can download and run!!!!! In Android that is good to go. But what about Java?

We have two choices there that don't require herculean effort.

One is to just package up and create an installer for our Chrome extensions. If we are going that route I'd probably want to switch out the proxy from .net to our Java code so I can use the same code base on KitKat and desktop.

But another possibility is to try and embed Chromium in our Java code. That would be much cleaner. There is a project that has releases for 64bit Java for Windows, OS/X and Linux. But they admit that they are pre-release quality (aren't we all?) and the docs are non-existent. But the code does look pretty straight forward.

I'm honestly not super duper sure which of the two 'Java' choices are really best. I kind of like just building installers for our Chrome extensions since that is an extremely well trodden and officially supported in release quality product path. But it does mean we have to tell everyone to install Chrome. But, well, that doesn't appear to be much of a barrier. So I suppose we should probably just package up for Chrome.

I'm really not sure. What do you think?
Coordinator
Apr 7, 2014 at 12:44 AM
Actually there is a pretty strong argument for using the Chromium for Java code path. If we go with Chrome then outside of 'developer' mode we can only distribute via Google's App Store. And developer mode basically means doing what we are doing now! So um... no. So I guess that pretty much settles it, don't you think? I should at least try the Chromium in Java path first.

But I am getting ahead of myself. First we have to get the demos running in Android!
Developer
Apr 7, 2014 at 12:49 PM
re: x86 update: http://sourceforge.net/projects/android-x86/files/Release%204.4/android-x86-4.4-RC1.iso/download (just recording the URL so I don't have to look it up again)

re: install vs embed: Which (if either) gives us <script src="foo.js"> and <link href="bar.css" rel="stylesheet">? We talked about sourcing everything from database but won't that require gymnastics to do those things? A conventional webapp that uses PouchDB should just drop in and work.
Coordinator
Apr 7, 2014 at 3:11 PM
In terms of install and embed there is no difference. In both cases the developers experience is that they have a directory with their files and they go. In the case of Chrome we would probably require them to copy their directory into some magic directory on the machine. In the case of embed they would pass the location of their directory via the command line when they start.

I am not worrying about app distribution models at the moment. Yes, eventually, we should have a way to distribute files via CouchDB synch but that will probably be via some protocol we layer on top that makes sure we don't get into some messy state. See here for a diatribe on the details of app distribution.