I have a fairly complex Core Data database with many entities, attributes and relationships.
I need to take an NSManagedObject subclass object (or its data) and export it to another instance of the app. This other instance needs to then import it into its local database.
I have figured out how to attach files to emails however I am not sure if I should serialise the object to XML or if I should encode it using dictionaries.
It seems like a huge job either way, does anyone have any suggestions?
I dont know much about this but using dictionaries seems a better option to me as you will spare yourself xml writing and parsing, since you are using the same structure why bother with writing xml and parsing.. hope this helps.
update:
see this link.. https://stackoverflow.com/a/1375120/919545
Related
I have already done that in Java using ObjectOutputStream and ObjectInputStream classes. Now I want to do this with Dart. I have no idea about what I should use. I have also researched on google but I only found something for serialization of objects and saving them with json. But I am looking for something without json, like in Java.
I'm not english, sorry if I made some mistakes in writing.
Thank you for your time.
I guess you want to store and retrieve your objects to save some important information.
For fastest setup you can use HIVE pub.dev/packages/hive.
Other options are
Serializing your object to son string and saving it to shared preference. https://pub.dev/packages/shared_preferences
Use an orm like moor to store and query large amounts of data. https://pub.dev/packages/moor_flutter
I am at a real loss.. For the past two weeks I have been working on fine tuning the way data is parsed, displayed and held in my app.
I have two view controllers, the first has four tables that when selected load a uitableview full of data that is parsed from an xml file. each xml file is different but have key fields that relate to each other. I need to speed up the way I display this data in the uitableview as when I do my second search when I check my ManufactureID against every single modle avalible to all manufactures.. it take a considrible amount of time to load.
I would like to do this behind the scenes before the view is even about to load and I have heard the best way to achieve this will be to use core data.. but I am not sure how to get this to work with the way I am doing things now.
If you have any examples, suggestions or anything that might help me I could seriously use someones input right about now as I am just abit stuck. For instance how do I get the data that are in my .xml files into the coredata? how to I create the relation ship ID's? etc.
First off, is there any reason to keep the information in XML files? Everything will be a lot easier (and faster!) if you just move it all to a CoreData datastore from the start instead of parsing/preloading everything to an in-memory store at launch (or whatever).
As to how to model your relationships, you could always set your CoreData model to exactly match your XML data. So, say, one Entity per file and one Attribute per record in said file. There's no reason you have to use CoreData Relationships to model the relationships in your XML. If you have IDs in the files already, just make an Attribute called xmlId or something and fetch based on that just like you were doing a SQL query. You'd miss out on a lot of automatic ORM-ness of CoreData, but if you've been dealing with XML this whole time, I doubt you'll notice.
If you really want to set up the relationships between your CoreData-managed objects, you'll have to somehow match up objects by their IDs in the XML either by importing the IDs into CoreData and then doing the math, or by somehow taking care of this when you parse. Hard to give any specific advice here without knowing more about how your data are modeled.
There's some sample code that does half of what you want (it reads XML into a in-memory CoreData store, but doesn't model any relationships). Check out TopSongs (http://developer.apple.com/library/ios/#samplecode/TopSongs)
I'm learning Core Data and trying to parse XML from some web service and save it into data storage.
Is it the best practice to save data from XML directly into managed objects? Or there are some better ways to do this operation?
Thank you!
You should be convert your data into something that is useful for the application and not just store the raw tagged data when parsing the XML. That way you only do the conversion once in the XML Parser and not every time you want to use the value elsewhere in the code.
For example, an integer stored in an XML file is always going to appear as a string at first, so using [NSNumber numberWithInt:[string intValue]] in the XML parser once is far better than having that extra bit of code peppered throughout your application.
I think you didnt understand what i mean. If i want to parse some musical album info from XML and save it into Data Storage should make something like Album* album = [NSEntityDescription insertNewObjectForEntityForName:#"Album" inManagedObjectContext:context]; to create object where i will save data from XML or i have to create some another Album class not inherited from NSManagedObject to work with it while parsing
I don't think there's a direct way do convert an XML document into a managed object. I use NSXMLDocument to do exactly what you want to do but you will have to do a little parsing.
I would create your objects directly from your parsed XML. In other words, just use your NSManagedObject derived classes. No intermediate class hierarchy is necessary. Also, if you're not already, you should use mogenerator + xmod for re-generating your data object classes automatically whenever your model changes.
I have a list of objects that can sometimes change, and I want to keep a persistent cache on the device whenever the app is closed or move to the background.
Most of the objects in the list will not change, so i was wondering what is the best way to save the list. I have two major options i think about:
Using NSKeyedArchiver / unArchiver - This is the most convenient method, because the objects i'm serializing hold other custom objects, so this way i can just write a custom encode method for each of them. The major problem is that i didn't find on Google how to serialize only the changed objects, and serializing the entire list every time seems very wasteful.
Using SQLite - this is what i'm currently using, and the worst problem here is that adding \ changing properties of the objects is very complicated, and much less elegant.
Is there any way that i can enjoy the convenience of NSKeyedArchiver but only serialize the changed objects?
Like Adam Ko I would suggest using Core Data:
This kind of problem is what it's really good at, after all!
If your cache items are independent from each other, this could be achieved by simply wrapping your cache-items by a thin layer of NSManagedObject (i.e. you could benefit from Core Data with only minor changes to your app).
This wrapper entity could store an archived version of a cache item in an attribute of type NSBinaryDataAttributeType and provide access to the unarchived object through a transient property.
See Non-Standard Persistent Attributes for an example.
I have a few Moose objects and some other simple hash objects (hashes, arrays) I'd like to serialize.
At first, I used a simple
my $obj_store_file = nstore($obj);
and
my $obj = retrieve($obj_store_file);
This worked well.
Later, I found about MooseX::Storage and KiokuDB. I tried using them to enjoy some benefits they have, but:
MooseX::Storage seemed to recreate objects that are referred multiple times. For example, one of my serialized objects contains a few attributes, which each of them refers to the same instance of another object. Before serialization, all of these reference are obviously the same -- they all point to the same object. After serialization/de--serialization using MooseX::Storage, this once single object is duplicated and each reference points to another instance of the object. I was told that MooseX::Storage is not appropriate to represent object graphs and that I might want to try KiokuDB.
I did, although I felt KiokuDB is an overkill for my needs. I don't need all the fancy stuff a DB can offer. Unfortunately, since one of my objects is really large and choaks on memory when serialized using defaults, it seems I have to write a custom serializer or store its 'data' portion separately then write a costume KiokuX::Module... again, quite an overkill.
So, I'm back to plain ol' Storable or YAML. My question is simple: yes, there are some benefits for KiokuDB (especially the fact it maintains an object graph) and perhaps also for MooseX::Storage (although I couldn't really find any for the latter). But, given these benefits are not really of use to me, is there any reason not to use Storable or YAML?
In other words, is there anything wrong with storing a (Moose) object this way? Is it 'illegal'?
My experience is that it depends on why you're serializing data. I like Storable for program state including things like window size/position. I prefer YAML for configuration data or anything you might want to exchange with another copy of the application. (i.e. share between users -- a Storable file might not be readable by a user with a different version of Perl or Storable.) Storable supports object graphs (assuming that the freeze/thaw is done correctly). I'm not sure about YAML.