#1659 - App mode

Identifier #1659
Issue type Feature request or suggestion
Title App mode
Status Closed (duplicate)
Tags

Type: Mobile (custom)

Type: Performance (custom)

Handling member Chris Graham
Addon core
Description [I think this is largely not going to happen. Tapatalk will be our "out of the box" app. Composr Mobile SDK will be our high-end app framework. Composr itself will keep improving in terms of use of JS and responsive design (particularly on the forum and in galleries). HTTP will improve, e.g. shared dictionaries. So it will be more evolutional across the 3 Tapatalk/CMS-SDK/Web prongs.]

Implement an app-mode for Composr, that delivers the benefits of apps (speed, low bandwidth, offline support) even to normal web users. Therefore all users get all the benefits, optimisations are delivered universally, and mobile development costs are greatly reduced as there is one system for everyone.

Terminology:
- Server = PHP code
- Client = Javascript code
- RPC = Remote procedure call, a standard term for running a function on a separate machine. In our case, the server transfers page generation control over to the client after gathering the basic data the client will need to finish it. This transfer may be when a link is clicked, or set up in advance when a link is generated.
- PHP-JS = Code that can run via PHP and/or Javascript, depending if app mode is off or on.

Goals:
- Significantly reduce bandwidth draw by having templates generally run on the client rather than the server (hence only raw data is routinely transferred, not HTML + data).
- Significantly reduce loading times too, for the same reason.
- Reduce server load by offloading work to clients.
- Allow pre-transfer of resources to clients, in the case of compiled apps (images, etc). Transfers things all in one go over wi-fi, rather in inefficient chunks over mobile data.
- Allow running without network connectivity using pre-transferred or cached data.
- Allow focus on universal optimisations for mobile user experience, rather than spreading ourselves very thinly across many different app frameworks.

Limitations:
- Certain symbols in templates will be pre-evaluated, before those templates are sent to the client. For example, blocks and pages included directly into templates.
- For example, a menu block would be evaluated and embedded into the template that called that menu. It would still maintain the Tempcode dynamism, and be kept up-to-date via automatic decaching when the menu was edited. This is required as the client can't draw stuff from the database directly. It probably slightly improves performance anyway with little drawback, as there is less piecing of stuff together for each page execution.
- For example, certain Tempcode symbols that result in database queries on data the client does not know just would no longer be possible. These kinds of usages would need to be manually identified and code reworked so that they did not happen. For example, looking up another member's avatar via $AVATAR would not be possible, but code could be reworked so this was known in advance as a part of module code.
- In order to get good performance you will need to think with an app developer mindset, not a website mindset - you should tune your mobile mode to be very simple, with simple CSS and simple layout, and not a huge amount of HTML. Avoid having panels and blocks in mobile layout (put stuff on separate pages, and use a hamburger menu). This should apply anyway, and focusing our efforts allows us to invest the resources into ensuring this.
- This is a very sophisticated idea, so is hard to implement and will take considerable time to tune - it probably would cost roughly the same to develop iPhone and Android apps for any particular sophisticated client. However, over a longer term it should work out much cheaper.

Comcode pages:
- Comcode pages can be flagged as 100% client-side.
- 100% client-side pages will be loaded via a Javascript link, which tries to access via HTML local storage
- If the page is not in local storage, it will be downloaded normally, and saved (cached) into it
- There's a background process which gradually fills up local storage (i.e. precaches) when you're just browsing the site normally (so, don't mark too much as 100% client-side!)
- Use a 'last modified' style caching mechanism so out-of-date cached resources are detected

Module pages:
- PHP functions may be marked as "JS-friendly", in which case Composr will automatically convert them to JS-code and compile them into a JS version of the particular code file - allow large parts of our library code to do this. Use php.js (an existing JS library of PHP compatibility functions), and something new build ontop of our Code Quality Checker's PHP parser to convert Composr's PHP code. This is a process we do automatically, but in advance - it doesn't happen at run-time, it's a build process we go through when we are ready to make a release.
- Some library code, such as do_template, will be manually implemented in JS
- Allow a is_js() function that is statically evaluated during the conversion (and always false for PHP execution), to customise how code runs in JS-mode
- PHP modules may terminate with an "RPC" to one of the PHP-JS functions. This may pass a tempcode tree, or some simpler parameters - but the key principle is that JS finishes it off with the assumption any server-data needed to finish execution would have been included as a parameter in the RPC. Essentially we are splitting our PHP code into two -- a server-side data generator, and an HTML renderer that can run either server-side (PHP) or client-side (JS).
- The RPC is actually implemented by terminating with outputting a bit of JS code, rather than a normal XHTML screen - basically a bootstrapper for a local version of Composr running in Javascript (using the aforementioned PHP-JS library functions)
- Instead of "return do_template" at the end of a module, support "return do_template__appscreen" which automatically can pass off an RPC call (not as good as doing a full careful consideration of making a new RPC function, but better than delivering full HTML to the client)
- Dependencies such as template files will need to be downloadeable from the server on-demand by the client, and versioned using Last-Modified (perhaps have the client declare what they have across their whole cache, and let the server say what is outdated and needs re-retrieving)
- Have a tool to automatically verify that there are no unmet dependencies in the PHP-JS code we generate (i.e. function calls to PHP code that were never converted)
- Support declaring certain screens "inline", so the RPC call for them is injected direct into the link without an extra server call being needed. i.e. a link is clicked on the client and immediately the client can open it, as it already has the data and knows the JS target code intended.
- Allow screens to declare they allow an 'offline mode' using stale data from a previous RPC to that screen (perhaps doing a timeout so it is automatic if signal is weak - but inject a warning when this is happening. For example, viewing a calendar using the last known data for that calendar.

Native apps
- Have a Phonegap-based Composr compiler that bundles everything pre-cachable (JS, images, templates, pages, etc) into something we can distribute and version through app stores.
- We can therefore support native device feature, as and when is required (although HTML APIs for these are getting quite good).

Extra considerations:
- If we pass the tempcode tree to clients, we need to make sure nothing privileged is in there, and that there's not too much data we don't need. Currently in Composr it doesn't matter, as the Tempcode tree is never directly delivered through to the client.
- We need to remove server-side logic from templates, such as $IS_STAFF -- or, make sure there is a global state that includes each particular case we need. We will need to have such a global state as almost certainly we'll want to allow things like $USERNAME to run on the client.
Steps to reproduce

Funded? No
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".

Rating

Unrated