August 24, 2016, Rolf Eckertz
Ninas Travel App is programmed in JavaScript - and the idea of dynamically adding or exchanging javascript code goes back to the begin of the internet and browser programming.
Meanwhile jQuery made it very easy to get JavaScript-code into an app. You can choose getting it from an ajax call or from a string. And you can supply the string however you want, from a file, a database oder code-generation - all these techniques have been developed long time ago.
Ninas Travel App is written using isomorphic code, that means: code can be used in the app, in the browser and in the node.js backend. This is done by a special kind of modularization that is state of the art in javascript-programming and impemented in a lot of libraries already.
I checked of lot of standard solutions like commonJS, requireJS and more. My opinion is that these solutions do force me into restrictions that I do not want. On the other hand a solution just based on jQuery and usage of IndexedDB in the App and MongoDB in the server-backend can be build easily and in a robust way - that's what I will do.
The backend has an update system based on openshift from red hat cloud, GIT does the source control an the deployment on the server an the restart of the server. This will also be used in the future. The browser-functions are delivered from the node.js backend, so the browser will not get dynamic updates as it will be up to date after every restart.
The core of the automatic software updates for hybrid apps is on node.js. There is a central updates-directory in which all the updates exist als sub-directories with the name-schema:
- update<Number><-optional comment>
The status of an update-subdirectory can directly be seen by the following files:
- if an upd-package.json file exists, then the developer has finished his work
- if an upd-release.json file exists, the the quality assurance has finshed work with release of the package, that means: no further changes may be done to the directory
- if an upd-transfer.json file exists, then apps on devices have requested and downloaded the update. This is documented in the file
So there will be the following components and functions:
- app modules are developed under Intel XDK
- when these modules are testet as app they are also tested as browser-modules
- the server gets the following functions as browser and backend-functions
- selection of modules (js-Files) for dynamic update
- show local directories
- select file
- upload file
- show control-list of uploaded files and update-directories in node.js
- special treatment of scrollbars for multiple lists on the screen with jQuery Mobile
- entry of documentation for the users
- set a release-timestamp for the uploaded modules
- storage of the selected modules into MongoDB with the release
- create a release.json-file documenting the release and a package.json-file documenting the contents in the update-directory
- the apps get the following new functions
- check if the server has new updates and download these updates into the local indexedDB (done by standard ajax-calls with access to MongoDB)
- check if the transfer of the updates was completely done and consistent
- set markers for the next start of the app
- give Information to the user to allow a restart of the app
- dynamically load the new js-files
- send feedback to the server that the update has been implemented for use
- in the server the upload of the updates is documented in the transfer.json-file in the update-directory and in MongoDB
- the server gets the following functions as Web-Services (AJAX)
- process and response to checkForUpdate Request
- process and response to getForUpdate Request (sends the code)
- process and response to feedbackForUpdate Request
No comments:
Post a Comment