I developed an application for Android with Ionic2 framework. I used Local storage functions to handle data.
Now, I want to replace local storage by database with some API calls.
And before switching to my API, I wish to extract the application data in order to no lost them.
Q1: That why, I wonder where is the path for the local storage data? In other words, where can I find the file with my stored data?
Q2: If retrieving my data isn't possible. I was wondering: If I modify the application with a extract function, when I reinstall it, will it delete my data or leave it as it is? (and so extract my data easily)
Thanks for your help!
I hope I gave enough information.
Local storage doc: https://ionicframework.com/docs/building/storage/
Which use localForage: https://github.com/localForage/localForage
Related
I have a flutter application that is meant for collecting data on road usage, and I would like to carry out analysis after collection of data.
I've saved the file and I am able to read the file via readAsString and writeAsString to
'data/user/0/com.example.flutter_example_app/app_flutter/fault_report.txt'
How can I access the data quickly and easily without having to integrate too much stuff [For instance, opening an API and writing to cloud and etc]?
The app is supposed to be just a collection method and all analysis will be carried out afterward.
It depends on how ofter you would like to retrieve your data. If you only want to get the data once in a while, you can use File Explorer, Bluetooth file sharing, Cloud Drive or etc. to retrieve your data. But if you want to retrieve data more often, making some simple api will not take too much time.
I must provide a solution where user can upload files and they must be stored together with some metadata, and this may grow really big.
Access to these files must be controlled, so they want me to just store them in DB BLOBs, but I fear PostgreSQL won't handle it properly over time.
My first idea was use some NoSQL DB solution, but I couldn't find any that would replace a good RDBMS and elegantly store files together. Then I thought on just saving these files in HD somewhere WebServer won't serve them, name them their table ID, and just load them on RAM and print them with proper content-type.
Could anyone suggest me any better solution for this?
I had the requirement to store many images (with some meta data) and allow controlled access to them, here is what I did.
To the cloud™
I save the image files in Amazon S3. My local database holds the metadata with the S3 location of the file as one column. When an authenticated and authorized user needs to see the file they hit a URL in my system (where the authentication and authorization checks occur) which then generates a pre-signed, expiring URL for the image and sends a redirect back to the browser. The browser is then able to load the image for a given amount of time (as specified in the signature within the URL.)
With this solution I have user level access to the resources and I don't have to store them as BLOBs or anything like that which may grow unwieldy over time. I also don't use MY bandwidth to stream the files to the client and get cheap, redundant storage for them. Obviously the suitability of this solution will depend on the nature of the binary files you are looking to store and your level of trust in Amazon. The world doesn't end if there is a slip and someone sees an image from my system they shouldn't. YMMV.
I'm using Core Data to store some sensitive information. So far, I've applied hardware file encryption to the SQLite file used by the Persistent Store Coordinator. I've done this by setting its file Attributes (NSFileProtectionKey to NSFileProtectionComplete).
I'm storing some image data as Binary Data in the Core Database and I've checked off the "Allows External Storage" and "Store in External Record File" to prevent bloating of my SQLite datastore and to improve performance.
I'm presuming that the data files automatically stored outside of the SQLite database by Core Data will NOT be encrypted and that I need to encrypt these files myself. Does anyone know if this is correct?
Thanks
luckman777,
Every version preinstalled of iOS will hardware encrypt every file when the user uses a screen lock. With respect to your question about external Core Data storage, why don't you just look at the files? It is quite straightforward to move the data from the phone to your dev system. Then try to open one of the external files. I expect that it is encrypted. (If not, that is a rather big and obvious hole in Core Data's encryption policy. I doubt that it exists.)
Andrew
Hidden, but not encrypted!
The folder it currently (iOS 11.2) holds the data is under Documents/.SingleViewCoreData_SUPPORT/_EXTERNAL_DATA
There, you can see all the files, without their extension in a token-name. However, the data is all there unchanged. You can view any file by simply adding the file extension or using the right App.
Yes, the device data is encrypted when the screen is locked, but connected to Xcode, you can very easily download the container and access all the data. If your app holds sensitive data, the 'device is encrypted' will simply not hold.
Only the SingleViewCoreData.sqlite file seems to be encrypted.
I am developing an iPhone app which retrieves information via NSUrlRequest and displays through UIWebView.
I want to hold initial data (such as HTML pages, images) as a cache so that users of my app can access to data without network costs at the first time.
Then, if data on my web server are updated, I would download them and update the cache.
For performance issues, I think it is better to store data on file system than on core data.
Yet, I think it's not possible to release a new app writing data on disk.
So, I am about to store initial data(or initial cache) at Core Data, and when users launch my app for the first time, I would copy the data to disk (like /Library folder).
Is it, do you think, a good approach?
Or,...hmm, can I access to Core Data using NSUrlRequest?
One more question,
I might access to file system using NSURL, which is the same as to data on the Web. (right?)
My app would compare version of the cache with version of data on my web server, and if it's old, retrieve new data.
and my app will access only to file system.
All data are actually HTML pages including script, and images. And, I want to cache them.
could you suggest a better design?
Thank you.
Is it, do you think, a good approach? Or,...hmm, can I access to Core Data using NSUrlRequest?
No.
One more question, I might access to file system using NSURL, which is the same as to data on the Web. (right?) My app would compare version of the cache with version of data on my web server, and if it's old, retrieve new data. and my app will access only to file system. All data are actually HTML pages including script, and images. And, I want to cache them.
Yes.
But you could also be more clever. And by "more clever" I mean "Matt Gallagher." Take a look at his very interesting approach in Substituting local data for remote UIWebView requests.
Im really confused when thinking about my requirement to store data locally for offline viewing.Now i have two options,DOM storage and HTML5 Local storage.
As im a complete newbiew in this particular topic,i need some help of SO Experts and Gurus.
Whats the Advantage and Dis-advantage of these two.?can any one compare these one.,so that i can understand deeply or give some reference links?
DOM Storage or Web Storage is the collective name given to the following types of client storage options available in HTML5. It includes:
localStorage
sessionStorage
Local storage is persistent meaning the stored data will still be there when you close and re-open the browser window.
Session storage is temporary and is available as long as the page session lasts.
There is really no comparison between the two since technically they both are the same.
Try to have a read here http://blog.sebarmeli.com/2010/11/22/understanding-webstorage/, you can easily understand the two objects, their methods, event attributes and their possible use.