My application takes data from a server and saves it to an SQLite database. This works fine in the 9550 (BlackBerry Storm 2) simulator, but when I run this in any other simulator it gives me this error:
file system not ready
Code snippet:
URI myURI = URI.create("file:///store/MyDataBase.db");
Why is this happening?
Richard is right. You need to check for the existence of the filesystem root "store". There is an extra wrinkle for using SQLite, though. RIM only supports SQLite on eMMC storage. So even if "store" exists, it will only work if the underlying storage is eMMC. Notably the BlackBerry Bold 9650 device, AKA Bold2, has "store", but it is not eMMC, so you can't put an SQLite database there.
I'm not aware of any direct way of finding out whether a filesystem is using eMMC. I asked RIM and was told to check the filesystem size. If it's over 1 GB, then it is eMMC. That wasn't a very satisfying answer for me. I ended up checking for the filesystem "system". It is a read-only filesystem, but it is only present for eMMC storage, and if it exists, you can write a database to the "store" filesystem root.
Via the SQLite developer guide overview:
You can use the SQLite API, provided in the net.rim.device.api.database package, to store application data persistently to eMMC memory or a microSD card.
It may be that store is not a mounted and available file system root on the 9550. You should use javax.microedition.io.file.FileSystemRegistry.listRoots() to get an Enumeration of currently mounted file systems.
Related
Sorry for my english.
I have developed a mobile application that needs its own local data store. I chose Realm as the database management system. In the process of studying the Realm documentation I had no problems with the database design, it's normalization, the CRUD-operations and everything that is related directly to the code.
I was confused following. I test my application in the simulator. I did not create the local database. I’ve just done it as it is written in the documentation of Realm. Realm created by itself its database and I did not specify any settings. The location of my file with database is given below:
/Users/macbookpro/Library/Developer/CoreSimulator/Devices//EFECD945-285C-494F-8C1B-950D9AA05147/data/Containers/Data/Application/8D71FF0A-60D2-4875-96BB-36955E80D505/Documents/default.realm.
I quite inconvenient to apply each time this path for the analyzing of records in the database. The file is stored at this path is inaccessible for Realm Browser, because I need root privileges. I have seen that people store their .realm-files in project directory. Answer me please - how can I do it? Would it be the right alternative?
I have repeatedly seen the code, where paths to the database file appeared. For example, here: https://github.com/pietbrauer/CarthageRealmUploadFailureExample/blob/master/Carthage.checkout/realm-cocoa/examples/ios/swift/Migration/AppDelegate.swift
I'm not sure if it's the right direction.
As a result, I want to:
1) have on hand a database file and be able to quickly refer to it;
2) know the algorithm - how to set own path to the Realm-database
file;
3) know what realm configuration must be on a real device, to
ensure security and data integrity.
Thank you very much to all!
When you don't specify a path for the default Realm in your app, Realm will automatically create one named default.realm in the Documents directory of your app. On apps running in the iOS Simulator, this will save the Realm file in the appropriate Simulator folder, but you are correct in that it's not very intuitive to find it.
In response to your questions:
There is a cool utility called SimPholders that lets you inspect the Documents folders of apps in the iOS Simulator. This is the best way to get at any Realm files the Simulator has generated very quickly.
When creating an instance of a Realm object, you can supply a Configuration object to customise it. You can explicitly set the file path of the Realm file by setting the path property of that Configuration object.
iOS supplies an automatic layer of file encryption on disk, that makes files unable to be read when the device is locked. If you want additional security, then it's possible to set the encryptionKey property of a Realm Configuration object to have a Realm itself encrypt that Realm file on disk.
I hope that helped! Let me know if you need any more clarification!
1) and 2) does have very small effect on security and data integrity
3) if you are worry about security of you data, use Realm-level encryption like here
I have a WP7 application which downloads some files from a server. Now I am saving these files to isolated storage. Is there any option to save these files in a location other than Isolated Storage. No problem for accessing these files from outside the application.The reason is that I need to open these files and show them to the user.
Is there any option to store outside Isolated Storage? If yes, how?
These are the ways you have to persist information in Windows Phone:
Save to a file in Isolated Storage (with the IsolatedStorageFile)
Save in the Application Settings (with the IsolatedStorageSettings)
Save to a database (that will be in turn saved in Isolated Storage)
Send the info to some Internet webservice/remote storage
If it is a picture file, you can save it to the Pictures Library (with the MediaLibrary - sample)
There is no other access to storage in Windows Phone right now!
Where exactly is the IsolatedStorage on the android devices. I would have expected it to be in the /mnt/sdcard/Android/data/[packagename]/ location, but it is not. I used the File Explorer (from eclipse) to try and find it, but I can't.
If I can somehow load a html page into the WebView or play a video from IsolatedStorage, then I won't need this actual path. But, I don't want to copy the movie to a temporary location in order to play it, I might as well just store it on the SD Card.
The reason I am using IsolatedStorage is to minimize the custom code across the platforms, I am developing for the Windows Phone, which only allows for IsolatedStorage.
To determine the directory in which your "isolated storage" aka internal storage is kept, use the GetFilesDir() method. This method is part of the Activity base class. It is to be used for files you do not want other applications to have access to.
Other useful methods
GetFilesDir():
Gets the absolute path to the filesystem directory where your internal files are saved.
GetDir():
Creates (or opens an existing) directory within your internal storage space.
DeleteFile():
Deletes a file saved on the internal storage.
FileList():
Returns an array of files currently saved by your application.
See the android developers documentation for more details
I found that IsolatedStorageFile points towards internal memory only.
I used the Context.GetFilesDir() and the Context.GetExternalFilesDir() depending on the user's selection.
I'm a bit confused. I'm including in the bundle a Core Data file that will not be modified by the user. Apple rejected my app after I started copying the file to /Documents (due to the new iCloud requirements), so I now I copy the file over to /Library/myprivatedir/
The question is why do I need to copy over to /Library in the first place. What's wrong with it staying in the Bundle after all?
There's nothing wrong with opening a CoreData store from within the bundle. Just be sure to pass the NSReadOnlyPersistentStoreOption as part of the options to -addPersistentStoreWithType:configuration:URL:options:error:
Skimming the docs for iOS Data Storage Guidelines (apple id required) I found this
... Data that can be downloaded again or regenerated should be stored in the <Application_Home>/Library/Caches directory. Examples of files you should put in the Caches directory include database cache files and downloadable content, such as that used by magazine, newspaper, and map applications.
Because it is easily regenerated they may have taken issue with it.
A couple of points down may be useful if you did have a read/write database scenario
... Use the "do not back up" attribute for specifying files that should remain on device, even in low storage situations. Use this attribute with data that can be recreated but needs to persist even in low storage situations for proper functioning of your app or because customers expect it to be available during offline use. This attribute works on marked files regardless of what directory they are in, including the Documents directory. These files will not be purged and will not be included in the user's iCloud or iTunes backup. Because these files do use on-device storage space, your app is responsible for monitoring and purging these files periodically.
I need to store some data files for my blackberry app. These are usually small png files that I download and store locally for performance reasons. Also I need to store an xml file locally.
My question is where are these files supposed to be saved on a blackberry? Is there such a thing as an application's home folder or settings folder in the blackberry filesystem?
What would be the path to such a folder?
This is for blackberry os 4.7 or later.
Thanks!
If it's not a huge amount of data (and by the sounds of it, it's not), take a look at the PersistentStore mechanism. You can store many types of data including native types (String, Integer, etc.) and even byte[] data (for images) using PersistentContent. The nice thing about PersistentStore is that it doesn't require any sort of filesystem access -- it doesn't leave files hanging around -- and if you include a custom class in the persistent store for your app (even a simple subclass of an existing persistible class such as Hashtable), it will automatically delete your persisted data if the app is deleted.
There's no official home folder for your application. In blackberry you can basically read/write just about anything/anywhere (well, you might get a SecurityException/IOException if you'll try do change some files).
You can write to the SDCard/Internal memory using the paths described here.
If you're worried about someone seeing and altering your data there's not much you can do except setting your files and directories as hidden using FileConnection.setHidden(true) but this is very lame since they can still be seen even from the native BlackBerry file browser if the user chooses to show hidden files from the menu.
Edit: You could of course encrypt/decrypt your data but this won't prevent someone from deleting it.