I need to save some data in my j2me application using RMS, but I'm not sure about what happens to this data if I shutdown the phone or if the it runs of out battery. Next time I start the phone, will the data be still there??
Just one more question, do you know where the data persisted with RMS goes(phone memory or a memory card)?
Thanks in advance.
This might answer your question:
A class representing a record store. A record store consists of a collection of records which will remain persistent across multiple invocations of the MIDlet. The platform is responsible for making its best effort to maintain the integrity of the MIDlet's record stores throughout the normal use of the platform, including reboots, battery changes, etc.
Source.
Data stored in RMS is persistent. In other words, it stays there even after removing the battery, just like the installed apps stay there.
RMS data is stored in phone memory.
Related
I came across uuidgen from watching a video to study for the redhat 8 exam but I had a question about it's usefulness and did not find any other thread nor did the manpage mention it. So I understand that each device has an UUID and the UUID can be used for multiple purposes - the purpose in the video was creating new mountpoints and the UUID was used to associate a new partition (/dev/sdb3) with a new mountpoint. Here they pointed out that you can generate a new UUID for that device using uuidgen.
My question is why/when would you use uuidgen in a production environment with live servers to relabel a partition? What would be the point of relableing the UUID for a currently existing mountpoint? Is there a sort of attack that target UUID of a system? Or is the sole purpose for uuidgen just used to create random UUIDs for others things like web links?
Thanks
Say you have a system with several disks, one partition each, and you need to play "Musical Data" with some of them.
If you start by copying, at block level via e.g. dd, the entire GPT-partitioned disk, then you will have, as a result, a duplicate UUID. This is fine if one of the duplicates is going to be blown away before the next time the OS needs to mount one of them. If, for whatever reason, this can not be ensured, then whichever copy you don't want the OS to pick up anymore, needs a new UUID. Enter uuidgen.
I'm assuming you're talking about GPT partition UUIDs, which are stored all together in each GPT that contains the identified partitions; if, instead, you're talking about filesystem UUIDs, which are stored inside the metadata for that filesystem and thus are copied whenever dd'ing that filesystem, then the above scenario still holds and more scenarios become plausible.
I am working to understand the impact of different workloads on the load weight and WALT (ravg) in the linux scheduler. Specifically, I am working on the Android Kernel.
Currently, I am logging all of this data in an internal struct from inside the kernel. For the particular workload, I write the aforementioned data into the struct every time the pick_next_task is called.
As one would expect, the size of the logged data increases significantly within a short time period. Hence, I flush the data by writing it to file after the size of a log increases to a certain value.
I wanted to ask if there is another, better, way to log this time series data?
If not, then what would be a good way to stop the size of the log from exploding? Is there an alternative to writing the data to file? Would using debugfs be a better alternative?
Any help would be greatly appreciated.
Thank you!
I'm working on an Embedded linux running on ARM9.
The filesystem is ext4 type (rw, sync, noatime, data=writeback)
I implemented a process that writes/reads to a SQLite3 database in a Write-Ahead-Loggin (WAL) mode, with unsync enabled. When a powerloss is happening, I have around two seconds to save all data by syncing and checkpointing the DB. But, still, I see that sometimes the DB is being corrupted which is really not good in my case.
I would like to write a new DB engine for my purpose, In a similar way to SQLite, where the DB will be hold in one file. But in this case, I'm thinking of writing the header data to one sector and the rest of the data at least two sectors after , so the size of the DB will be larger but when writing the data, It will not ruin the header of the file, which holds the indexes and etc. That way, only the last data will be corrupted and not all the file, as SQLite behaves.
My question is if my approach is right?
you can use ping pong technique.
In ping pong technique you use 2 separate files and write alternatively to one and another. If a power loss occurs in the worst case you have at most 1 single corrupted file and you can safely use the other one. In the best case none of them is corrupted and you can continue using the latest one.
A corrupted file is easily detected if you use hashing functions or other CRC schemes
Obviously this scheme doesn't save you from write-cache or other disk caching mechanism which could be working under the hood.
Alternatively, you can use a journaled file system which features data integrity protection on it's own
Be aware that ping-pong and journaling schemes ensure only data integrity. Data loss could still occur. Data integrity and data loss are two completely different things
I am new in J2ME. In my Application, I have to store a large amount of data in Database and have to access it.
But with the limitation of RMS in J2ME, I can't store large amount of data.
Is there any way to access database file from External Storage(SD card)?
I am partially agree with funkybro, i.e. you can not save your RMS in to SDCard.
You can also use Files to store your data. but should be last option.
Here i am suggesting you an another option, i.e. install your application on SD-Card and then user. This way your RMS will be created on Memory card, so no space issue will arise. But the problem you may face shall be if you are using this application on s40 Series device then your heap memory will be limited to 2MB. Your application may crash during execution. If you are using s60 series device, it will work fine.
I also want you to look at my this answer for more information.
If you are really asking "can I make RMS save to the SD card", the answer is NO you have no control over where the device persists RMS data.
You would need to use JSR-75 to save data on the SD card in your own format.
I'm writing a MIDlet using LWUIT and images seem to eat up incredible amounts of memory. All the images I use are PNGs and are packed inside the JAR file. I load them using the standard Image.createImage(URL) method. The application has a number of forms and each has a couple of labels an buttons, however I am fairly certain that only the active form is kept in memory (I know it isn't very trustworthy, but Runtime.freeMemory() seems to confirm this).
The application has worked well in 240x320 resolution, but moving it to 480x640 and using appropriately larger images for UI started causing out of memory errors to show up. What the application does, among other things, is download remote images. The application seems to work fine until it gets to this point. After downloading a couple of PNGs and returning to the main menu, the out of memory error is encountered. Naturally, I looked into the amount of memory the main menu uses and it was pretty shocking. It's just two labels with images and four buttons. Each button has three images used for style.setIcon, setPressedIcon and setRolloverIcon. Images range in size from 15 to 25KB but removing two of the three images used for every button (so 8 images in total), Runtime.freeMemory() showed a stunning 1MB decrease in memory usage.
The way I see it, I either have a whole lot of memory leaks (which I don't think I do, but memory leaks aren't exactly known to be easily tracked down), I am doing something terribly wrong with image handling or there's really no problem involved and I just need to scale down.
If anyone has any insight to offer, I would greatly appreciate it.
Mobile devices are usually very low on memory. So you have to use some tricks to conserve and use memory.
We had the same problem at a project of ours and we solved it like this.
for downloaded images:
Make a cache where you put your images. If you need an image, check if it is in the cachemap, if it isn't download it and put it there, if it is, use it. if memory is full, remove the oldest image in the cachemap and try again.
for other resource images:
keep them in memory only for as long as you can see them, if you can't see them, break the reference and the gc will do the cleanup for you.
Hope this helps.
There are a few things that might be happening here:
You might have seen the memory used before garbage collection, which doesn't correspond to the actual memory used by your app.
Some third party code you are running might be pooling some internal datastructures to minimize allocation. While pooling is a viable strategy, sometimes it does look like a leak. In that case, look if there is API to 'close' or 'dispose' the objects you don't need.
Finally, you might really have a leak. In this case you need to get more details on what's going on in the emulator VM (though keep in mind that it is not necessarily the same as the phone VM).
Make sure that your emulator uses JRE 1.6 as backing JVM. If you need it to use the runtime libraries from erlyer JDK, use -Xbootclasspath:<path-to-rt.jar>.
Then, after your application gets in the state you want to see, do %JAVA_HOME%\bin\jmap -dump:format=b,file=heap.bin <pid> (if you don't know the id of your process, use jps)
Now you've got a dump of the JVM heap. You can analyze it with jhat (comes with the JDK, a bit difficult to use) or some third party profilers (my preference is YourKit - it's commercial, but they have time-limited eval licenses)
I had a similar problem with LWUIT at Java DTV. Did you try flushing the images when you don't need them anymore (getAWTImage().flush())?
Use EncodedImage and resource files when possible (resource files use EncodedImage by default. Read the javadoc for such. Other comments are also correct that you need to actually observe the amount of memory, even high RAM Android/iOS devices run out of memory pretty fast with multiple images.
Avoid scaling which effectively eliminates the EncodedImage.
Did you think of the fact, that maybe loading the same image from JAR, many times, is causing many separate image objects (with identical contents) to be created instead of reusing one instance per-individual-image? This is my first guess.