Hi Thomas,

Lianja has an offline data store available. Eventually, soon, it will provide transparent offline operation and subsequent online updating.

PWA, of course, stores the app files on the device and can work offline. I haven't test that in Lianja yet, but have used pwa: the load time is greatly diminished.

Hank

>>Hi Thomas,
>>
>>PhoneGap is dead (per Adobe). Progressive Web Apps (PWA) are the replacement, in general -- not just for Lianja.
>
>Both have "offline first" as part of their DNA. Cordova was able to use SQLite queries directly on the file system, PWA have IndexDB or RO file system access - then perhaps reading a SQLite DB flle via EMScripten as WASM or JS compile target or AlaSQL- Dunno if it is still valid, but early on filtering could NOT e done at "query file read" but table was mirrored in memory first.
>
>>
>>Lianja, for the past 2 or 3 years, has support for PWA (Progressive Web Apps). Fill in 4 or 5 values in a JSON string already created for you and brought up by a sidebar button in the UI development interface, and you have an app that will deploy as a PWA. That's the modern way to create phone/tablet apps, and it works. It seems too easy, as I thought the first time I used it, and that's all that is required.
>
>I doubt such a PWA could hold the offline data necessary to appraise damages after a car accident for example - which is tablet based today. How does Lianja work offline - IndexDB as basis for cursors usually fed from backend server when online ? What triggers replication with server when online again and how is it executed or what options to resolve possible conflicts exist ?
>
>>There are 2 ways to call a .py program in Lianja.
>>
>>One way, from any supported language, is to use execpython(), using vars as needed from the current context, whatever language.
>>
>>The other way is to put the .py name in the app's exports.conf file. Once done, from any of the supported programming languages, a function that uses that filestem can be fed var's from the current context, as though one were in a Python program.
>
>@John: that sounds as if it could be a great benefit to apps running as client instead of a browser.
>Depends a lot of how "chatty" such Python marshalling happens from current / rewritten GUI.
>The old "write chunky, not chatty" still better IAC, but old running program is a value in its (battle-)tested form.
>
>At least a fast way to get ported version running both local client and (mobile/web) with the option to port only those .Py calls really hurting perf to JS to always run client side.
>
>>If the call is made from JavaScript running in a web browser (a mobile app of whatever kind), the call is ferried to the backend and the result ferried back, with no extra programming by the developer. So, e.g., from the web/tablet/phone UI you can make a Python R library call to do some analysis based on parameters the user has just entered and get the results back. The back-and-forth is all handled for you, of course. So in my apps I often make VFP calls to the backend to do backend chores (e.g., insert/modify a record or records on the backend (Lianja DBF's, SQL Server, etc.) and return the result if any.
>
>RPC slow, but the only really secure call - if the biz case needs it
>
>>The Javascript that runs in a web browser that the user inputs are triggers for "events" in the UI. All the coding required for creating the display of the UI is done for you. Your code can make adjustments to the UI, can do things with data as needed, etc. Code that works locally has to be JavaScript. Code that requires the backend can be in any of the supported languages. The UI can also have CSS inserted where needed to get particular effects not already made part of the Lianja UI options.
>
>But controls still bind to cursors - but those are JS cursor objects, totally built in memory? SQL/xBase calls and filters possible on those cursors ? For instance a single table feeding listboxes via listbox name as row filter ?
>
>>For me that is the big benefit of Lianja: I can work on what the app does with data, leaving the minutia of the UI to the Lianja infrastructure. If the Lianja infrastructure were to change what it uses underneath, that's their concern, not mine. They regularly look at other frameworks as to whether this new thing or that would be an improvement in user experience. Because making the UI work is a sunk cost, their evaluation is based on whether changing what is used underneath would benefit the user experience. That contrasts with a developer working directly with a framework. In that case, starting from scratch on a new project, the developer looks to see what will streamline their development process best -- and then has to decide whether to bite the bullet and sink more development time into getting familiar with a new framework.
>
>I look at the use case, existing implementation (including client HW and client wishes), central data store and when, how often and how optimized data transfer (disk to GUI via VM) happens.
>
>Widespread WAN TCP/IP access benefits CouchBase CouchDB pattern of direct TCP/IP calls, reactivity of MongoDB is probably unparalleled (in you are selling super bowl tickets) as it is close to a JS "reactive backend, GraphGL does a nice job of eliminating lots of "chatty" calls back into the server caused by dumb ORM, while for most sub-50 concurrent users ANY multi-user SQL backend is good enough ;-)
>
>Body is getting old, so I have to keep mind at somewhat up2date on current data&query tech ;-)
>
>thx + best regards
>thomas
>
>(and if Barry compiles a native client for Android, shoot a msg...)