In my mobile app I have an object implementing PropertyBusinessObject which contains numerous other objects also implementing this interface. This object structure is populated by JSON data I am getting back from my server. When I try to write this object to Storage with writeObject() I get the above error. The stacktrace shows it originating in the com.codename1.io.Util.writeObject() method where it is writing UTF-8 (limited to 64k). The developer guide does not reference any potential issues with Storage and recommends it over FileSystemStorage. My question is, is there a workaround/update for this? Would I have to revert to writing out the object structure to the filesystem? Thanks.
If you have a ridiculously long string e.g. to represent the contents of the file I would suggest rethinking that. Strings are inefficient in Codename One since we need to copy their representation into the iOS native layer. Also writing them to UTF is very wasteful if what you need is a binary representation. I suggest using a byte array.
Serializing to storage is a simple approach. It works great for small objects. If you have larger objects you might want to store them individually. You can also serialize to/from JSON so your storage data is readable.
Related
I don't know what kind of format is inside the JSON-LD, but it needs to be converted into a well-defined object.
My question is I don't know what kind of JSON-LD data is uploaded by the client and I don't know if it is possible to convert such data into some object with a well-defined format.
Do you have a solution yet?
If you don't know the structure of the object beforehand, you will probably have to use some generic structure to hold the data in Java. If you use a library like jsonld-java, it will do exactly that. You will work with Maps and Lists and it should be able to accommodate basically any JSON-LD data.
If you did know the target structure (for example, if it were one of several types for which you have a Java class), you could use a library like JB4JSON-LD to load it into an object of that class.
Disclaimer: I am the author of the JB4JSON-LD library.
I want to serialize all of the data in my realtime document to a string with which I can later initialize a new realtime document. I want to do this so my users can make copies of their drive files, save different versions, etc, and I can re-initialize the relevant realtime documents from the string.
I see I can call document.getModel().getRoot().toString() to get a string representation of the root CollaborativeMap, but I don't see any easy way to load that string back IN to a CollaborativeMap. Also, the string returned is not JSON, so I can't easily use JSON.parse to turn it back into a normal JS object and iterate from there.
I can make this work by hand. Is there any easy automated way?
You can do that on the service side using the realtime.get() and update() methods:
https://developers.google.com/drive/v2/reference/realtime
I working on a project in a microcontroller and I need to persist some settings. Pretend this is an iPod. I need to save various settings like CurrentSongPlaying, CurrentVolume, etc. so that when I turn on again I can restore those settings. The trouble I'm running into is that makes sense to store all my Non-Volatile Settings in a single struct that I can serialize/de-serialize from memory but I can't find a way to make that happen without the class doing the serialization/de-serialization from non-volatile memory including every class that contains a setting that will need to be saved for size/type information. Is there some sort of design pattern that will allow me to persist all these settings to memory without having to know about what I'm saving?
Looks like you just need an associative array. An associative array (or map) is a container that allows you to map different values to unique keys. It can have a fixed or dynamic size depending on the implementation. Coupled with a proper serialization mechanism, it allows you to save and restore its state without having to know its content in advance.
However, C does not provide this data structure out-of-the-box. Look at this question for a few implementations. The most common implementation is the hash table, also called a hash map.
OOP and classes are not easy to implement in C.
If using C is a must, I would write the struct to file.
Then I would read them and parse them during initialization upon reboot.
You can think of this as serializing your structs yourself.
I'm parsing a XML-file into objects but I'm wondering why,
I would haven't choosed an Array Parser instead of an Object Parser?
Does it have more pro's than an Array parser or less contra's?
is it more flexible and expansible?
Kind regards
I think it all depends on the input data. If you application needs a lot of simple configuration files storing the state/setup of a single object, then there would be less overhead in handling the parser's output if you use ObjectParser.
But once you have a scenario when you need to store actual object collections (e.g., a list of independent GUI controls to be attached somewhere) and you read such collections often enough, then, if you still use ObjectParser you would have to invent a "collection" class and convert this list to the actual array.
I'm working on a basic editor application. It uses an array of varying size that I want to store to disk. This will eventually be in an AIR application, but for now it's just an AS3 project in Flex.
I want to store the array in a file. The application edits the data, so it doesn't need to be human readable. I want it to be in whatever format will be quickest to store and load back into the array when I need that data again.
Any recommendations?
Edit: It strikes me that importing/exporting in such a way that it can be immediately cast as an Array() would probably be the cheapest thing rather than some sort of iterating - if that's possible. Another obvious option is getting the data as a simple comma delineated string and using the String.split() function to get an array. Though again, the question is what would be cheapest - and I'm not quite convinced that's it.
I'll also add that it needs to be in some sort of permanent file, so a shared object - while possibly the fastest, isn't really a long term solution.
I think the fastest and easiest way is to use a shared object. It stores native objects, so there is no serialization / deserialization steps involved. Just assign the value and read it back.
Performance wise, probably the fastest route as well. If you are looking for a large dataset and are sure it's an AIR app, you can use AIR's db, but that will definitely take much more work.
First, take a look at this answer.
As for saving the contents of an Array, consider JSON using the export tools provided by Adobe.