Hi Hank,

>The result, in all 3 cases, is (as of the current build in beta) able to be packaged in PhoneGap/Cordova, and (with the push of a button) pushed to the Adobe Build Service, without having to create the Android or iOS build environments. PhoneGap apps can, of course, run on any desktop, through the ChromeOS plug-in built into the Chrome browser, and available for IE and FireFox.
>

Is the cursor object in/on the mobile front end
- a disk or SQLite based cursor or
- a shim using JS array/object structures through one of the JS-LinQ variants or
- something like AlaSQL (SQL middle/munging thingie for lots of different data structures, but still with growing pains) or
- SQL.js (LLVM translation of SQLite sources into JS)
- dependant on WebSQL support remaining in Webview even after WebSQL being deprecated from HTML5
- a server based shim with REST/oData offered though HTTP/Websocks under the cover via controller/routing call?

The Phonegap API AFAIR had only support for [local] SQLite forward-skip only cursors, not scrollable cursors like in Android Java API, which are defined quite high in the interface chain on .Cursor, which would be good enough for me ;-)

>Coming down the pike: native apps using the QT framework, which sits underneath the desktop application. These will use VFP code to run the native apps on the mobile device, with offline data and synchronization capabilities.

Saw that on the roadmap now for end of 2015, and that runtime being often pushed back in the roadmap was the main reason for my abrupt stop of testing long time ago:
customers said clear NO as without that feature Lianja had not enough technical benefits compared to other approaches like Xamarin or Phonegap or Java/Vanadin/GWT-stack.

Now Nativescript has entered the fray and Node is trying for building a stack by including a Webview based front end to create pure Web apps without the need to run in browser sandbox - although Webview itself might stifle some avenues by building other borders.
>
>To put it mildly, I don't experience any limitations in what Lianja can do. There's a lot to learn how to use effectively, because there is an awful lot available to use. That's a good problem to have. :)

Only if there is customer willing to pay for the learning, even at reduced rate. But back then the plug was pulled on that area for me :-(

Dunno if I can rekindle interest, now it is more on Webview GUI through thin fwks possibly with hooks into native surrounding: dunno if including Lianja in that stack will be possible, even when arguing that Phonegap/Webview targeting could be agreed upon approach to implementation in Lianja - not from technological, but budgetary reasons a bit and to a larger degree Lianja being closed source. Telerik trying to cash in on the development/build ease while offering Nativescript sources on Git has less risks of developer blackholing like in the vfp-Dotnetcompiler case. Times have changed on customer side quite a bit as well ;-)

Is there a beta program for Android native already ?

rgds

thomas