I'm currently working on a planning app, and I've ran into an issue. I can't find a way to store data without it being lost after restarting the app. I've tried cookies, window.name (despite the fact that that shouldn't even work to begin with), but neither of those work. The tasks (planned tasks) will be stored on the server, but seeing it's per person, having in input field for login everytime you start the app doesn't seem like the best plan. Any suggestions?
Related
I’ve looked at the storage api’s for both react-native and expo and I’m struggling to find a suitable way to structure my app.
I’ve made an app for my workplace in which we scan equipment and record the data. At the moment I’m using firebase to upload the data and store on their servers.
My boss has asked whether we can implement a way of storing the data locally if the user has no access to wifi and then upload the data upon internet reconnection.
I’m not sure where to start with this. I understand that I can use NetInfo and add an event listener to monitor the connection. However I’m not sure how I would persist any scanned data with the opening and closing of the app and such.
If anyone could help point me in the right direction, it would be greatly appreciated it.
Thanks
I have a question that might seem a bit vague and that is because Im not sure the best way to proceed.
I have a HTML page that I need to be able to run offline. I need it to collect and be able to edit/delete info from a database, and I need that database to be situated somewhere in the computers local network files. Im not sure which route to go down for this to work.
I have looked into saving the data as a .json file, but then the data cant be changed/deleted by the browser.
I have looked into using the browsers local storage but what I need is for when the database is updated on one computer using the local network, it needs to show the update on other computers connected to the same network. Local storage only works for one instance of the browser, as far as I can tell, the local storage cannot be shared to other computers.
I have looked into using SQLite, but I cant use php, because then I take it I need a testing server to be able to see the page. I could set up something like WAMP but Id prefer not to have to start that before the page can be opened. Also Im not sure if that can be accessed from other computers.
I have looked into using SQLite and access it with javascript using SQL.js. This is my prefered method at the moment, but it seems that it stores the database to system memory instead of within the local networks file structure, and I assume that cant be reached by other computers on the network.
Anybody have any ideas for a way to make this work?
I want to create a wipeout functionality for my windows store app so is there any way to uninstall Windows Store App programmatically in JavaScript ?
As others have already written, programmatic uninstall isn't available to Store-installed apps, by design.
That said, it sounds like the intention behind your question is that you want to offer your users a way to guarantee, for example, that any personal information is wiped from the device and perhaps also the cloud. Fortunately, because the app itself is the agent that would save any such data, you're also in control of clearing it out. Doing so would return the app to the state it was on first install.
Purging your appdata means the following:
Delete all files in the local and temp appdata folders.
Delete all local appdata settings in the settings container.
Clear out anything you put in the Windows.Storage.AccessCache.
Clear out any information you stored in the Windows.Storage.PasswordVault.
I didn't mention roaming appdata files and settings for a reason. If you use roaming appdata, that data will be automatically retained in the cloud for some period of time even if all instances of the app on a user's devices are uninstalled. This is done by design so if a user happens to uninstall all instances of the all and then reinstall within about a month, their settings and data are still there. (Imagine cleaning off a laptop and a tablet so you can sell those, and then getting some new ones.)
The upshot of this is that if you want to guarantee that data is wiped, then avoid using roaming appdata altogether. If you want to roam, then use another cloud service over which you have more control (e.g. tables in an Azure Mobile Service). This way you can specifically clear out all the data on user request.
By doing all this, then you're able to give the user a way to clear everything out just short of uninstalling the app, leaving the app in a clean state and protecting any sensitive information.
As an aside, you might be interested in this blog post of mine on the Windows Dev Blog, http://blogs.windows.com/buildingapps/2014/06/19/common-questions-and-answers-about-files-and-app-data-part-1-app-data/, and also the talk I did at //build 2013 called "The Story of State," http://channel9.msdn.com/Events/Build/2013/3-9118.
No. Neither in C# or C++.
And frankly I don't understand why one would need that when a user can uninstall the app from the start screen.
This is not possible because the user should always be in control.
My question is a follow-up to this topic. I love the simplicity and performance of Firebase from what I have seen so far.
As I understand, firebase.js syncs data snapshots from the server into an object in Javascript memory. However there is currently no functionality to cache this data to disk.
As a result:
Applications are required to have a connection when they start-up, thus there is no true offline access.
Bandwidth is wasted every time an app starts up by re-transmitting all previous data.
Since the snapshot data is sitting in memory as a Javascript object, it should be quite trivial to serialize it as JSON and save it to localStorage, so the exact application state can be loaded next time the app is started, online or not. But as the firebase.js code is minified and cryptic I have no idea where to look.
PouchDB handles this very well on a CouchDB backend. (But it lacks the quick response time and simplicity of Firebase.)
So my questions are:
1. What data would I need to serialize to save a snapshot to localStorage? How can I then load this back into Firebase when the app starts?
2. Where can I download the original non-minified dev source code for firebase.js?
(By the way, two features that would help Firebase blow the competition out of the water: offline caching and map reduce.)
Offline caching and map reduce-like functionality are both in development. The firebase.js source is available here for dev and debugging.
You can serialize a snapshot locally using exportVal to preserve all priority data. If you aren't using priorities, a simple value will do:
var fb = new Firebase(URL);
fb.once('value', function(snapshot) {
console.log('values with priorities', snapshot.exportVal());
console.log('values without priorities', snapshot.val());
});
Later, if Firebase is offline (use .info/connected to help determine this) when your app is loaded, you can call .set() to put that data back into the local Firebase. When/if Firebase comes online, it will be synced.
However, this is truly only suitable for static data that only one person will access and change. Consider, for example, the fallout if I download the data, keep it locally for a week, and it's modified by several other users during that time, then I load my app offline, make one minor change, and then come online. My stale changes would blow away all the work done in between.
There are lots of ways to deal with this--conflict resolution, using security rules and update counters/timestamps to detect stale data and prevent regressions--but this isn't a simple affair and needs deep consideration before you head down this route.
I'm working with a PhoneGap app that uses Safari local storage (SQlite DB) via Javascript:
https://developer.apple.com/library/archive/documentation/iPhone/Conceptual/SafariJSDatabaseGuide/UsingtheJavascriptDatabase/UsingtheJavascriptDatabase.html
On first load, the app creates the database, tables, and populates the data via a series of INSERT statements.
If the user closes the app while this processing is happening, then my app database is left in an inconsistent state.
What I prefer to do is deploy the SQLite DB as part of my iTunes App packaging so nothing must be populated at app cold start. However, I'm not sure if that is possible -- all of the google hits for this topic that I can find are referring to the core-data provided SQLite which is not what we're using...
If it's not possible, could I wrap the entire thing in a transaction and keep re-trying it when the app is restarted?
Failing that, I guess I can create a simple table with one boolean column "is_app_db_loaded?" and set it to true after I've processed all my inserts. But that's really gross...
I think this solution may work for you. which involves pre-creating the table, and copying it over when the app starts up.