EDIT#2 - The replies until now (after 2 days) are personal opinions and preferences and not an analysis of the various options that an offline-phoneGap app has to store simple data easily across all relevant devices. As such I haven't accepted any answer, but I am following this question.
I am a little confused about which format of persistent data I should be looking into for a PhoneGap web app I'm building. I've been researching this but things are not clear given my mediocre requirements.
The app is an educational app with about 100 or so multiple choice questions and some memorization games attached.
The app once downloaded can remain offline.
It is for all phonegap supported devices.
The only data that I want to read and write is the user's performance, number of times wrong in total, per card etc and any high scores for games.
This is all very basic information and could be held in very simple js objects.
I would like it to be a fairly simple solution and very easy to maintain/repeat.
What would be my best option? The phonegap file api? json/lawnchair? local-storage? cookies? Would there be a way to 'update' the app and keep it as an object in the javascript? websql? sqilite? Storage API?
Some of these seem overkill.
EDIT
Are there differences in devices and I should do some device detection and use different technologies?
I personally like localStorage. It's straight forward and works great for most situations.
If you are just recording the data you mention above, localStorage would be perfect. I would just seralise your data objects by turning them into a string using say JSON.stringify(), then when pulling it back in use JSON.parse() to turn it back into a useable JS object.
How about try out my library http://dev.yathit.com/ydn-db/getting-started.html backed by IndexedDB (excellent performance, query by index scan), WebSQL (good performance, SQL query) or localStorage (fair performance, no query, get by key, 2.5 MB limit).
db = new ydn.db.Storage('test-store');
db.put('store1', {test: 'Hello World!'}, 123);
req = db.get('store1', 123);
req.done(function(record) {
console.log(record);
});
High performance while still go easy.
Don't like library dependency, take raw source code at https://bitbucket.org/ytkyaw/ydn-db
It looks like these are good ones, though I haven't tried them.
localForage
PouchDB
If you're using the ionic framework which uses AngularJS, I like ngStorage. This one I have tried and it's awesome.
I use localStorage to keep my persistent data, but it is somehow not reliable. I have seen some data lost, but I don't know why. But my persistent data usage is not that critical so I don't mind these inconsistencies.
But your case seems more important. I would store my persistent data in Documents folder, with File API.
Phonegap has local storage support for SQL Lite
http://docs.phonegap.com/en/2.2.0/cordova_storage_storage.md.html#Storage
Sorry I don't have more info. I was interested in this topic and happened to come across it.
Related
I'm still new to web development. To learn more about JavaScript(JS) and web development, I am thinking of writing a simple web app which pulls and records time-series data (say, the price of a stock) periodically and draws a live chart showing the historical data. In addition to price data, I would like the app to record/maintain some user-related info such as the ticker of the stock(s) associated to each user.
Ideally, I would like to keep the app light-weight and portable/standalone (meaning, reduce the dependency as much as possible, and the end user hopefully doesn't have to do a lot of configuration/install of dependencies). The issue that I cannot figure out is where to store the historical data. I looked around for database solutions which will allow the app to write data directly from the browser (that is, using JS) to the client's machine. LocalStorage and IndexDB are non-persistent as far as I understand. Some suggested using PouchDB, but upon looking at it closer, it seems like the user need to install CouchDB or some compatible DB (say, SQLite). But that means I cannot share my app with users who aren't technical enough to install and configure CouchDB or SQLite on their machine before using my app.
If anyone could share some insights as to which DB might allow a JS-based app to write persistent data to the client's machine (if such thing even exist), that would be greatly helpful. If there is no such DB solution, please feel free to let me know alternative solutions that would allow the goal of building a simple, portable, JS-based web app. Thank you!
I think the best solution is to use Electron.js. The whole idea of this framework is to create web apps that can reside on client machines. You could package up any DB option you want, or even better, just include an API to your backend through the web app and it will work on your client machine like I think you want it to.
As for DB options, there is a great thread on S.O. that talks about what is possible. It looks like knex.js is your best bet (full disclosure - I haven't used knex).
I'm building a relatively complex and data heavy web application in AngularJS. I'm planning to use php as a RESTful backend (with symfony2 and FOSRESTbundle). I have spent weeks looking around for different solutions to on/off line synchronization solutions and there seem to be many half solutions (see list below for some examples). But non of them seem to fit my situation perfectly. How do I go about deciding which strategy will suite me?
What issues that might determine “best practices” for building an on/off line synchronization system in AngularJS and symfony 2 needs some research, but on the top of my head I want to consider things like speed, ease of implementation, future proof (lasting solution), extensibility, resource usage/requirements on the client side, having multiple offline users editing the same data, how much and what type of data to store.
Some of my requirements that I'm presently aware of are:
The users will be offline often and then needs to synchronize (locally created) data with the database
Multiple users share some of the editable data (potential merging issues needs to be considered).
User's might be logged in from multiple devices at the same time.
Allowing large amount of data to be stored offline(up to a gigabyte)
I probably want the user to be able to decide what he wants to store locally.
Even if the user is online I probably want the user to be able to choose whether he uses all (backend) data or only what's available locally.
Some potential example solutions
PouchDB - Interesting strategies for synchronizing changes from multiple sources
Racer - Node lib for realtime sync, build on ShareJS
Meteor - DDP and strategies for sync
ShareJS - Node.js operational transformation, inspired by Google Wave
Restangular - Alternative to $resource
EmberData - EmberJS’s ORM-like data persistence library
ServiceWorker
IndexedDB Polyfill - Polyfill IndexedDB with browsers that support WebSQL (Safari)
BreezeJS
JayData
Loopback’s ORM
ActiveRecord
BackBone Models
lawnchair - Lightweight client-side DB lib from Brian Leroux
TogetherJS - Mozilla Labs’ multi-client state sync/collaboration lib.
localForage - Mozilla’s DOMStorage improvement library.
Orbit.js - Content synchronization library
(https://docs.google.com/document/d/1DMacL7iwjSMPP0ytZfugpU4v0PWUK0BT6lhyaVEmlBQ/edit#heading=h.864mpiz510wz)
Any help would be much appreciated :)
You seem to want a lot of stuff, the sync stuff is hard... I have a solution to some of this stuff in an OSS library I am developing. The idea is that it does versioning of local data, so you can figure out what has changed and therefore do meaningful sync, which also includes conflict resolution etc. This is sort-of the offline meteor as it is really tuned to offline use (for the London Underground where we have no mobile data signals).
I have also developed an eco system around it which includes a connection manager and server. The main project is at https://github.com/forbesmyester/SyncIt and is very well documented and tested. The test app for the ecosystem will be at https://github.com/forbesmyester/SyncItTodoMvc but I have yet to write virtually any docs for it.
It is currently using LocalStorage but will be easy to move to localForage as it actually is using a wrapper around localStorage to make it an async API... Another one for the list maybe?
To work offline with your requeriments I suggest to divide problem into two scenarios: content (html, js, css) and data (API REST).
The content
Will be stored offline by appcache for small apps or for advanced cases with the awesome serviceworkers. Chrome 40+.
The data
Require solve the storage and synchronization and It becames a more difficult problem.
I suggest a deep reading of the Differential Synchronization algorimth, and take next tips in consideration:
Frontend
Store the resource and shadow (using for example url as key) into the localstorage for small apps or into more advanced alternatives (pouchdb,indexdb,...). With the resource you could work offline and when needs synchronize with the server use jsonpath to get diffs between the resource-shadow and to send it to server the PATCH request.
Backend
At backend take in consideration storage the shadow copies into redis.
The two sides (Frontend/Backend) needs to identify the client node, to do so you could use x- syn-token at HTTP header (send it in all request of the client with angular interceptors).
https://www.firebase.com/
it's reliable and proven, and can be used as a backend and sync library for what you're after. but, it costs, and requires some integration coding.
https://goinstant.com/ is also a good hosted option.
In some of my apps, I prefer to have both: syncing db source AND another main database. (mogno/express, php/mysql, etc..). then each db handles what's its best with, and it's features (real-time vs. security, etc...). This is true regardless to sync-db provider (be it Racer or Firebase or GoInstant ...)
The app I am developing has many of the same requirements and is being built in AngularJS. In terms of future proofing, there are two main concerns that I have found, one is hacking attempts requiring encryption and possible use of one time keys and an backend key manager and the other is support for WebSQL being dropped by the standards consortium in preference to indesedDB. So finding an abstraction layer that can support both is important. The solution set I have come up with is fairly straight forward. Where offline data is is loaded first into the UI and a request goes out to the REST Server if in an online state. As for resolving data conflicts in a multi user environment, that becomes a business rule decision. My decision was to simplify the matter and not delve into data mergers but to use a microtime stamp comparison to determine which version should be kept and pushed out to clients. When in offline mode, store data as a dirty write and the push to server when returning to an online state.
Or use ydn-db, which I am evaluating now as it has built in support for AWS and Google cloud storage built in.
Another suggestion:
Yjs leverages an OT-like algorithm to share a wide range of supported data types, and you have the option to store the shared data in IndexedDB (so it is available for offline editing).
I am developing a JavaScript SPA using DurandalJs and BreezeJs as main technologies in the client side. I would like to know what libraries I can use to do my application support different languages. I have been doing a little of searching and I have found that JED.js (http://slexaxton.github.com/Jed/) can be a good option for this task.
However I am not very sure, can somebody recommend nay library for this task, or give me some opinion about JED.js.
Also I would like to ask about some library for store information in the browser. Can somebody recommend me one? I have thought in amplify.js, it gives good functionality for doing request to the server and caching this information. But in my application I am using breezejs, so this part is not needed. I only need to store some data like the username and some little information.
Very thanks.
MY SOLUTION:
I have implemented my system using amplify.storage for storing information in the browser and i18next (http://i18next.com/) to make my application avaliable in different human-languages.
I am not much help on the first part of your question. I'm quite interested in the response myself!
I do have some thoughts on local storage. AmplifyJS is really three independent libraries. One of them, amplify.store, is dedicated to the local storage issue and is worth looking at. You might look at lawnchair. Finally, look at the Breeze DocCode sample for examples of storing full and partial entity caches in browser local storage; it's primitive but gives you hints.
I am looking at writing a mobile web application with offline support, and would prefer to use the HTML5 offline capabilities instead of something like phonegap.
A requirement of the app will be that it store 2 collections of different types of objects (lets call them Books and Authors) which, when online, it will download from the server. If it didn't need to be offline then I'd be using some flavour of SQL tables or (preferably) a document-based DB to store these items, but having done some basic investigation I haven't found anything that feels "right" that works offline.
My question is: what is the best strategy to store those items? What I have considered so far:
HTML5 localStorage - Seems to have relatively wide support but is limited to key value pairs, which would mean a slightly unpleasant data structure - maybe having a total-authors key and then a series of author-1....author-n key-document pairs. This feels wrong to me - like I am trying to work around the intent of the storage.
CouchDb - I've worked with CouchDb quite a bit in the past so would love to use it or an equivalent, but "proper" CouchDb would require a native app (with which I have no experience), and the 2 in-browser equivalents I have seen don't quite seem to do the trick: Lawnchair doesn't seem to add much to the localStorage option and BrowserCouch doesn't appear to have had much activity recently (which always makes me wary).
WebDb - Looks like it would be perfect...except it seems to be officially discontinued and doesn't look to be widely supported
Gears - Discontinued
IndexedDB - Limited browser support for now (at least according to caniuse)
I'm convinced there must be something out there that does what I want, and I've just managed to somehow overlook it. Can anyone suggest the way this ought to be done (as opposed to a way it could be done)?
There's no browser-native simple solution as far I know; you'll have to either go with localStorage or develop for both WebDB and IndexedDB.
But non-native you could use a abstraction layer like lawnchair (uses localStorage by default, plugins available for indexeddb, webdb, ...) or the one SO-user Gatapia wrote for picnet (uses indexeddb & webdb & gears) that you can find on github.
I would like to see a decent example of a mobile web app using the Sencha framework with a client side DB accessed with SQLite. I'm currently digesting JqTouch and kinda get the binding method used there from reading Jonathon Stark's "iPhone apps" book, but cant find any examples of accessing Senchas features ie listed elements with SQLite. The DB will be small; 30 records, with about 5 fields, mostly numeric, a few of them calculated. All the math is done in javascript and I have that part working (in dash code). I need to add, delete, and edit the records.
Any pointers or examples would be very much appreciated. I'm an old dog trying to learn new tricks. Thanks
Sencha is client-side Javascript, so your application actually runs on top of Safari. That means you can forget about accessing (or installing) your own SQLite database from within the browser sandbox.
Having said that, you want to learn some new tricks, so why dont you read up on localStorage and DOM Storage. Basically the HTML5 specification allows for offline database storage based on SQLite (imagine relational database cookies). There is 1 per domain and they can be up to 5MB in size. I believe the iPhone supports this as well.
Here are some links: Introduction some API Information and a nice little blog entry by a chap called Ben Lister
Your client side code (i.e. Sencha/Javascript) would not access the SQLLite database. It will either need to read JSON or XML from the server. You'll need server side code to read the data from the database and format it in a way that your Sencha data readers will understand.
What are you using server side? If it's PHP you should look into MDB2
I had very good experience integrating Lawnchair library with Sencha Touch. Take a look at their guide, it's very easy.
Looks like there is a SQLite proxy available for sencha 2 now. http://market.sencha.com/addon/sqliteproxy-
Check out this thread on the Sencha Forums - it's a user created proxy for SQLite which I've successfully used to put data into a SQLite DB. The proxy comes with an example, but I might try and make a slightly more complicated one at some point.
Sencha's local storage doesn't take advantage of SQLite via the JavaScript API in the browser, but does use local key:value storage and has it's own way of referencing data to make it pseudo relational. This is still part of the WebDB spec, which is probably still SQLite under the hood if I had to guess. It's more persistent than a cookie or session, regardless.
You can also receive XML/JSON from a server over JSONP or Ajax if you're on the same domain, create a model to handle that data as well and bind it to a local store so that your data is available offline.