I'm building a small offline application that requires a simple data table (a contacts list). Something I can save to and read from.
I've looked into a few libraries and they all seem to only store data for the current session, and not into a file e.g. a fake sql database.
Can anyone point me towards the right technologies to use?
I'm planning to interact with the data table with a basic html form and JavaScript.
EDIT: Would switching to a different technology like Java be more fitting for my needs? Still not able to find a workable solution to hook up to HTML other than setting up a vagrant environment and hooking up to a MySQL db with php.
Modern browsers contain localStorage, that can store data (permanently) inside user's browser (similar to COOKIES). Usually there is ~5MB (but may differ or may be completely disabled).
if (localStorage) {
db_data = JSON.parse(localStorage.getItem('db'));
//... modify db_data
localStorage.setItem('db', JSON.stringify(db_data));
}
(for JSON use JSON2 library: https://github.com/douglascrockford/JSON-js )
Related
I'm developing an Android application, typically with a fairly small database (hundreds to a thousand or so main entries, plus similar order of magnitude in joined tables) populated by the user. There is also a file associated with each main entry, but those are kept separate, and not part of this question.
In my current prototype, the structured data is stored in a SQLite database in the usual way, and synced between devices by uploading the file to an Application Folder on Google Drive. This allows me to avoid having to provide any user storage, which is something I hope to stick to.
Storing files here also has the happy side effect that I can access them via JavaScript code in a web page using the Google Drive API. But JavaScript interacting with a remote SQLite file is an incredibly ugly thing to attempt. (Downloading the database server-side and handling it there is another option which sounds not great either.) I am wondering if anyone has any recommendations of the best practice approach here, given I would like to have a web-based version of the app accessing the same data.
The obvious most sensible idea seems to be
Exporting from SQLite to some other structured format XXX (like XML, JSON, CSV, ...) first, uploading that XXX file to Google Drive, so that JavaScript can straightforwardly interact with it, and then on sync reimporting this XXX data back into SQLite.
though I'm happy to hear any criticisms/improvements on this idea.
I'm mainly interested in best-practice recommendations of efficient ways to approach these problems. Question: What file format XXX would be good; and do you have any recommended methods for (a) exporting and importing in Java from SQLite to XXX, (b) interacting in preferably client-side JavaScript with a remote Google Drive file in format XXX? (If maintaining server-side code to interact with XXX is substantially better practice do say.)
It depends on how many clients your app will manage
Exporting from SQLite to some other structured format XXX (like XML, JSON, CSV, ...) first, uploading that XXX file to Google Drive, so that JavaScript can straightforwardly interact with it, and then on sync reimporting this XXX data back into SQLite.
IMHO, this is quite a bad idea for quite a few reasons:
If multiple users try to change data at the same time, you will have a tough problem managing all those data entries and possible conflicts
Providing direct access to your data layer is ALWAYS a bad idea since any client can wipe out all your data
If you have very few users or are making it as a personal project, you can stick with SQLite.
Kripken, the developer of Emscripten (the C/C++ to Javascript LLVM compiler) has compiled the SQLite Library to Javascript to make the sql.js library. You can find it on GitHub. There's also a demo page of sql.js
But if you have a lot of users, you might want to use Firebase by Google. It gives you a database and a REST API to use it. There are libraries to access Firebase from different programming languages too.
Cheers!
I don't know much about databases, I've been asking a few questions about them lately to get a better understanding but I'm still a bit confused about what does and doesn't need one.
I'm making a simple application using HTML/CSS/JavaScript, it has a few quizzes and "tutorials" targeted towards children. I don't want the next tutorial/quiz to be unlocked until the previous one is completed.
So for that would I need a database so that it "saves" when one is completed? I don't need to save scores or anything like that, they just get to move on once they get a passing score.
Any other requirements such as saving to a profile or needing to persist between sessions (e.g. changing of device)?
Browsers have localStorage APIs now which allow you to save a lot of the data (and keep it for a set duration of time). There are also good'ol'fashioned cookies which allow you save pieces of information as well.
Keep in mind that both of the above mandate the user use the same browser and allow these mechanisms. Obviously using "private"/"incognito" browsing would also affect saving status.
It's up to what you feel the requirements are.
EDIT Just saw your mention of a mobile app. If you're planning on allowing the experience to transcend devices, you'll need a database. otherwise, you'll be relying heavily on if they use cross-device sync (like Chrome and Firefox do with bookmarks, passwords, etc.)
If you don't mind that people can do a "view source" on the webpage or use every browsers' developer tools to find out the answers or move on to the next tutorial or quiz, then you can use cookies to store the user's status. Or you can use the preferable Web Storage API.
You might want to look at Firebase. Using just simple JavaScript on the web browser, you can have users with logins (or just allow them to login via Facebook or other services) very easily. And then you can store and retrieve data very easily as well, like quizzes, tutorials and results. This way nobody can see the answers even if they're adept at analyzing the webpage.
When you don't use database, before any check, you have to load all data in your static page.
So My sloution: store students situation in a cookie. On each page check cookie status and then use Jquery remove() to remove (Client-side) those parts of page that he/she can not access.
EDIT
This wont work when JavaScript is disabled.
There seems to be a lot of ideas but no clarifying on the database subject.
TL;DR is: No.
Now for the specifics. A database is nothing more than a way to store information. While traditional "SQL" databases (it is pronounced "Sequel" as in "My Sequel" for MySQL) have concepts of tables, where you define columns with items to store and saves each row with its value, much like an Excel file, some databases like Redis store key-value pairs and others lide MongoDB store JavaScript Objects.
You can store information in the source code (As Variables possibly) or in a file. A database is a way to organize that information.
With that said, in your case, you probably need a backend or an API. An API is basically a means of communication with a server through AJAX (JavaScript in the browser asks for stuff). That would be your way to retrieve information from the server as needed, so that users wouldn't see the answers before they answer.
With that out of the way, there are some options. FireBase (As noted on other answer) and AppBase are easy ways to integrate this concept with little effort. But they tie you and your information to their system, and they are mostly targeting more resource intensive apps.
Since you are using JS and seem to be enjoying your learning experience, I would suggest you consider suing NodeJS and defining the data as either a JSON file or a variable in JS. You keep working on your problem but add options and get to learn some stuff.
If you decide to integrate a database and possibly do some neat stuff, you have most of the groundwork done already.
If NodeJS picks your interest, Mean.IO and KrakenJS are, in my opinion, the best places to start, though they may both seem overkill in your specific case.
Do consider though: A database is just a small possible piece in a puzzle, and it's mostly a horrible way to name some of the software that tries to organize your information. Consider first if you need to organize information, and what and how do you need to organize, then start thinking if databases are the best way to organize it.
I have a simple offline html5/javascript single-html-file web application that I store in my dropbox. It's a sort of time tracking tool I wrote, and it saves the application data to local storage. Since its for my own use, I like the convenience of an offline app.
But I have several computers, and I've been trying to come up with any sort of hacky way to synchronize this app's data (which is currently using local storage) between my various machines.
It seems that chrome allows synchronization of data, but only for chrome extensions. I also thought I could perhaps have the web page automatically save/load its data from a file in a dropbox folder, but there doesn't appear to be a way to automatically sync with a specific file without user prompting.
I suppose the "obvious" solution is to put the page on a server and store the data in a database. But suppose I don't want a solution which requires me to maintain apps on a server - is there another way, however hacky, to cobble together synchronization?
I even looked for a while to see if there was a vendor offering a web database service - where I could, say, post/get a blob of json on demand, and then somehow have my offline app sync with this service, but the same-origin policy seems to invalidate that plan (and besides I couldn't find such a service).
Is there a tricky/sneaky solution to this problem using chrome, or google drive, or dropbox, or some other tool I'm not aware of? Or am I stuck setting up my own server?
I have been working on a Project that basically gives you versioned localStorage with support for conflict resolution if the same resource ends up being edited by two different clients. At this point there are no drivers for server or client (they are async in-memory at the moment for testing purposes) but there is a lot of code and abstraction to make writing your own drivers really easy... I was even thinking of doing a dropbox/google docs driver myself, except I want DynamoDB/MongoDB and Lawnchair done first.
The code is not dependent on jQuery or any other libraries and there's a pretty full features (though ugly) demo for it as are well.
Anyway the URL is https://github.com/forbesmyester/SyncIt
Apparently, I have exactly the same issue and invetigated it thoroghly. The best choice would be remoteStorage, if you could manage to make it work. It allows to use 3rd party server for data storage or run your own instance.
What would be the best way to write some values into a xml file?
In the .html file i have a certain score that gets its values from a js file called jsfuncions.js
Tried looking on several sites for this but never found a clear and simple answer.
Do i have to place the writer into my index file with script tags directly?
Also do i have to use the var xml = new xmlwriter(); Or is there something more simple in jquery to fit this purpose?
Pretty sure i have to use var XML = new XMLWriter();
But there is simply nothing to be found about this funcion. Can anyone point me in the right direction for a simple writer?
Regards.
JavaScript can not update the XML file permanently. You will need to use a serverside language to make the changes permanent.
Browser security sandboxing will prevent a web page being able generate a file and save it locally.
The only local persistence you can use is cookies - you could look at JSON format for storing records with properties and values inside a cookie - limitations are the max size allowed of the cookie.
There's a new local storage mechanism arriving with HTML5 which some of the latest browsers support.
http://people.w3.org/mike/localstorage.html
It really depends what you want to do with the resulting XML. If you want to save information entered by users, then you'll need to use a server side technology for the save operation.
Examples of server side technology include ASP.NET, PHP, Ruby on Rails, Java and Node.js. If you have no experience with any of these technologies, this will be your biggest learning curve. Microsoft provide a fantastic free application called WebMatrix which will help you get started with a number of different frameworks, but excels at ASP.NET.
If you're only interested in persisting information for the use of an individual user, you'll not be looking at an actual XML file. #BobTodd's answer gives a list of most of your options, but I would say the choice comes down to Cookie vs. local storage. The choice will be made based on the volume of information you would like to save. Cookies are a lot simpler, but only allow a small amount of data to be saved.
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.