My program saves a file on the device during runtime and reads/writes data from it during runtime.
Currently it gets saved in the SDCard. I want to know if saving it in device flash memory would be better than removable media. Does device allows us to write something in its internal memory?
Suggestions/Ideas?
Thanks
We check, if there's an SDCard available we store there:
if (((FileConnection) Connector.open("file:///SDCard/", Connector.READ_WRITE)).exists())
return "file:///SDCard";
else
return "file:///store/home/user";
EDIT: See more information on different locations
here
Support for an on-device file system is OS dependent. Most of the pre-3G devices don't have much internal memory anyway. If the amount of data is small (a few hundred kB) the best way is the PersistentStore. If it is larger than that, and you want to support the widest number of models then the SDCard is the way to go.
Related
I am interested to know if it is possible to allocate free disc space just for reading in an iOS app. The background of this question is a security issue.
Say you have an app A running in sandbox that stores user documents in its app private folder. This data uses some disc space that is only reachable from app A. Because of the sandbox an app B cannot access this user documents. If app A deletes the user documents there will be only deleted the inodes that references the documents. The disc space that is used by the documents are already there but nobody links to it and is so marked as free disc space. If app B now allocates the whole free disc space and reads bytewise the whole allocated space, where also the user documents are, app B can access the user documents. Theoretically.
To protect the user documents there are some ideas. The first is the encryption of the documents. By deletion they are still encrypted. But they are also still accessible. The next idea is to override the documents before deletion. But the disc space is a Flash storage what means that at the moment the data will be changed they are moved nondeterministically to other locations in the Flash. That means this does also not help.
I figured out that it is possible to allocate free heap space by using
UnsafeMutableRawPointer.allocate and read then bytewise the allocated space with UnsafeMutableRawPointer.load. I don't know if this is also possible for disc space. In this article I read that there are three options to access the disc space FileHandle, FileManager, and Data. But all of them, so I think, can only read files not bytes of disc space.
In the documentation archive from Apple, I can not find an answer, if this scenario is really possible or not. I hope someone else have a tip where I can find the information that I am looking for or maybe have an answer for my question.
Each file on the file system is encrypted with a unique key; even if a malicious app was to request a disk allocation and attempt to read the free space, it would not obtain any information since it would not posses the necessary decryption keys.
You can read more about this in The iOS security publication from Apple:
File Data Protection
In addition to the hardware encryption features built into iOS devices, Apple uses a technology called Data Protection to further protect data stored in flash memory on the device. Data Protection allows the device to respond to common events such as incoming phone calls, but also enables a high level of encryption for user data. Key system apps, such as Messages, Mail, Calendar, Contacts, Photos, and Health data values use Data Protection by default, and third-party apps installed on iOS 7 or later receive this protection automatically.
From current list of "Realm Limitations":
Any single Realm file cannot be larger than the amount of memory your
application would be allowed to map in iOS
Does this mean that if I check ProcessInfo.processInfo.physicalMemory and it is smaller than FileManager.default.attributesOfItem(atPath:realmPath)[FileAttributeKey.size] (plus a variable amount to account for fragmentation etc), I should not try to open the Realm?
If the Realm file is too big for mmap to map the file, you should get a Swift error. So all you really need to do is to try opening the Realm and catch any Realm.Error.addressSpaceExhausted errors.
The bigger problem is what to do once you know the file is too big. Our compaction on launch feature requires that the file be openable first, which rules it out (and is why we recommend that compact on launch be used to pre-empt this issue). We're working on ways to mitigate this problem.
mmap shouldn't depend upon the amount of free physical RAM you have (although some amount of RAM is required to map the file), nor is the limit that iOS imposes anywhere near the theoretical maximum. Finally, virtual memory limits operate on a per-process basis, meaning that the size of a Realm file you can open depends both on what other files have been mapped by that process and by how much memory that process is using for other things.
Is there any memory on the STM32F407VG that is retained when a new program is flashed onto the chip?
I want to store a serial number on the device that is tied to the device, not the program.
I am aware there is a hardware identifier stored on the chip, but I want to create a more relevant number.
As Etienne said in his answer, you can use the backup registers or backup SRAM but those imply having a backup power source. What I have done for the STM32F3, is use the Flash as an Emulated EEPROM. The drivers are on the ST website, you reserve a few pages of Flash as your 'EEPROM' and write whatever information you want there. On startup your device can read those values or modify them during program execution.
Described here: AN3969.(Application Note from ST, you can just google the ref. #)
A safety measure wold be to change linker file so those flash pages don't accidentally get overwritten if your code should grow larger.
You can use the backup registers (20*32bits), or the backup SRAM (4kbytes).
You can put this in the OTP area, which will keep the serial number for the life of the part.
I have got an iPhone application where I archive permanent data in the documents folder of the application (arrays, dictionaries). I read/write from and to the documents folder quite frequently and I would like to know whether this is considered a bad habit. Wouldn't it be better if I had a singleton class, read and write to arrays there and then, only when the application quits, write this data to the documents folder ? I do not see/feel any performance issues right now on my iPhone 5, but I wanted to know whether this is a bad practise.
FLASH memory has limited write capability - a long time ago it was rated in some increment of thousands. Not sure where it is today.
That said, if your app is using the standard file system APIs, then the system is using the file cache, and you might open a file, read it then change it many times without the file system ever writing to flash. The system may sync to flash occasionally, but that process is opaque - no way to really know when or why iOS does it.
The UNIX APIs allow for syncing the file system cache to the storage system (iOS this is FLASH), but if you are not using that then you are probably not doing much I/O at all given what you say above.
Given the lack of Apple discouraging developers from writing to the file system, I for sure would not worry about this.
But, if you said you were writing gigabytes of image data every few minutes - well - that might be a problem.
I am making a some complex app, in which every detail is imp. i have some questions
1. how much storage limit we have, if we plan to save big files on core data/cache.
2. Whats the RAM limit on iphone? Actually searching for some table that can give detailed info about IOS devices on this. Because i need to handle memory warnings and defend App crashes.
3. Its better to save images in cache or core data, assume you have a lot of images approx. 200-250.
Thanks
1) I am not aware of any storage limit. Obviously, you will never get 64GB or more - since no device is larger ;-). My wife's facebook app consumes >5GB at the moment... I suppose they did something wrong. The only important point is to fail gracefully (show a dialog, clean some space, ...) if the storage is full.
2) The RAM limit varies depending on the iPhone model and the currently running applications. Also there are some iPods with less memory in market. 30MB should be pretty safe. Total physical memory of the device can be retrieved as described here while retrival of the available RAM can be derived from that question.
3) Maybe this is a good starting point. I would always write image data to the file system and just store the file name inside the database, as suggested here.