Im looking for a simple (if I can call it that) mapping tool for obj-c, that maps objects and their relationships to a sqlite database. Is there any out there that acts like db4o for java? I havent found anything on google, and I think its because Im not completly sure of where to look and what to look for.
Hope someone can help, because I dont want to write my own mapping tool to sqlite.
EDIT
it seems like entropyDb does the job. http://code.google.com/p/entropydb/. But Im not sure yet.
I dont quite understand this line: "One cannot store instances of Cocoa classes directly. Collections (NSArray, NSSet, NSDictionary) can be stored if they are instance variables of custom objects." I read it like I cant store arrays and sets if they are instance variables of a custom object.
You're looking for Core Data, which is part of the iPhone SDK.
Related
I am attempting to follow Apples developer documentation to use CoreData.
I have just started learning Objective-C and now trying to wrap my head around CoreData. I think I have the concept under wraps OO Database.
For the life of me I can't get it to work and all searches I've done bring back either the tutorials for iOS 9 and previous, or for Swift.
Any help or guidance would be appreciated.
Core Data - Developer.Apple.Com
If you want to keep things simple only deal with a single managedObjectContext. If you are using NSPersistentContainer this is the viewContext. Make sure to always read and write to core-data only from the main thread. You will find similar simple setups with a single managedObjectContext in many tutorials.
Once you have mastered that you should learn how to use NSPersistentContainer properly. It is not that hard there are a few simple rules to follow:
NEVER write to the viewContext
only write using performBackgroundTask.
Do not use any managedObjects or context from performBackgroundTask
Do not use any viewContext managedObject inside of performBackgroundTask - pass the objectID and refetch it inside the context.
don't use newBackgroundContext - it is useful only in very rare situations that you are unlikely to encounter.
discard all managedObject after a fetch. If you need to keep a point to a managed object use a fetchedResultsController - even if it is for just one object
I was talking to several developers which approach is best in objective C according to latest trends?
For example: if i am populating data from server in json form, which approach should i use?
I have seen my friends populating data into json objects in past as well as fewer of them in NSdictiory,NSMututable Dictionary, what apple recommends data structure wise?
any help would be appreciated.
I personally greatly prefer custom objects (or Structs for Swift) because it lets me more easily tell what properties the objects have. If you are just passing around dictionaries it makes it much harder (in my opinion) to remember what object you have, what keys it has, and maybe what nested objects it has too. Whereas if you have named classes (again, these ought to be Structs in Swift), then you (and the compiler) can easily know what properties they have. Plus you can easily create instance methods for your objects.
And if you don't want the pain of parsing them yourself there are frameworks that will manage parsing the server response into objects (e.g. RestKit https://github.com/RestKit/RestKit).
If you consider example code from Apple as a "recommendation" from Apple, you can see the way they make a data model in their "Start Developing iOS Apps" here: https://developer.apple.com/library/ios/referencelibrary/GettingStarted/DevelopiOSAppsSwift/Lesson6.html. Yes the example is for Swift but most concepts are comparable.
Apple also has "Cocoa Core Competencies" (https://developer.apple.com/library/ios/documentation/General/Conceptual/DevPedia-CocoaCore/ModelObject.html) where they define a modal object as "typically a subclass of NSObject or...a subclass of NSManagedObject."
I've recently reread the interesting tutorial from Mike Ash about How to create classes at Objective-C Runtime
I has been a long time I am wondering where to apply this powerful feature of the language. I always see an overkill solution to most of the ideas that come to my mind, and I eventually proceed with NSDictionary. What are your cases of use of creating classes at runtime? The only one I see is an Obj-C interpreter... More ideas?
There's some possible options I see, when someone need to create class in runtime
To hide information about it (It won't help in most cases, but... you can)
To perform multiple-inheritance (If you really need it :)
Using your own language(i.e. some XML-like), that can be interpreted by your program, writted in Obj-C (Something like NSProxy, but even better.)
Creating some Dynamic-Class that can change it's behavior in runtime
In general.. There is some possible usages of this. But in real world, in default service applications there's no need to do this, actually:)
It could be used for example along Core Data or any API related to a database to create new classes of objects unknown at compilation time. However, I doubt this is used often, it's mostly the mechanism the system uses itself when it runs a program...
KVO, in the Cocoa frameworks, is implemented by dynamically creating "notifying" versions of your classes. See http://www.mikeash.com/pyblog/friday-qa-2009-01-23.html
I am building a very simple app to store data on people like name, age, etc. I give the user the option of changing the data such as when a person has a birthday. I can't figure out the best way to store the data.
I have searched for a long time now and I can't find the simple answer that I am looking for. If I change the data in a mutable array will that data be changed permanently? I mean will that write over the existing code and change the data so that it will still exist when the app is closed and reloaded again?
So far I am not able to do that. I have experience in MySql and Sql server so I have a tendency to go that direction if possible, but I would really like to use a mutable array or mutable dictionary if possible. This may be such an elementary question, but I can't find an answer anywhere.
You have some misconceptions.
The objects you create are in memory. There's nothing permanent about them. You have to save them somehow or they are gone when you quit the application and come back.
If you want to save an array, you have a number of options.
If the array contains nothing but objects of type NSString, NSData, NSDate, NSNumber, NSArray, or NSDictionary, you can save the array using the system class NSUserDefaults.
NSArray also has a method writeToFile:atomically: that will save an array of data to a file.
If your array contains any objects other than the types I listed above, though, neither of those approaches (NSUserDefaults or writeToFile:atomically) won't work.
The other option is to use an NSKeyedArchiver to convert the contents of your array to data, and then write that data to a file. In order for that approach to work, every single object i your array, and all the objects in those objects, need to support the NSCoding protocol.
As others have pointed out, you could also use Core Data or mySQL to save your data, but that seems like overkill for just saving an array.
Take a look at Core Data. It is the easiest way to manage this kind of data storage requirement on iOS.
Take a look at my book, it got good reviews and is perfect for what you are trying to do: http://www.amazon.com/Pro-Core-Data-iOS-Professionals/dp/1430233559
If you want an easy way to get started, there are tons of online tutorials too. For example Ray has written some good stuff:
http://www.raywenderlich.com/934/core-data-on-ios-5-tutorial-getting-started
Mutable means you can change the data at any time, so no, it's not permanent.
Yes, it will be permanent in terms of what you are asking. Although because the array is mutable it means you can always change the data back, the initial data will be overwritten by this new data.
Edit: No, the information will not remain after closing the app. You will need to programmatically save it. I would use Core Data.
CoreData is the way data is normally persisted in Cocoa and Cocoa-Touch. It also gives you some nice extras like undo support. But it has a big learning curve.
If what you're doing is super-simple, look at NSUserDefaults. If you need a little more flexibility, you could always use NSArray's -writeToFile:atomically: and -initWithContentsOfFile: (there are also versions of both those methods that take URLs instead of file paths).
Anything more complicated than that, and it's probably worth the trouble learning CoreData.
I'm trying to create a subclass of NSCoder, but I really don't know where to start. Apple's documentation lists which methods are required, but not much else. Maybe my Google-fu is weak, but I can't find any examples of an implementation of, e.g. encodeValueOfObjCType:at:, anywhere. (Though I assume it involves a lot of cases.)
Anyone know of a sample subclass of NSCoder I can look at, or have an idea of what a case or two of encodeValueOfObjCType:at: and decodeValueOfObjCType:at: should look like?
I just open-sourced a NSCoder subclass here
It basically is a replica of the deprecated NSArchiver.
Should get anyone who stumble into this question started.
I've also been wanting to (ab)use NSCoder to generate simpler XML than what NSKeyedArchiver produces and have implemented some classes for it. The classes are called RWPlainXMLTreeEncoder and RWPlainXMLTreeDecoder, and I've written some test code for them too.
RWPlainXMLTreeEncoder assumes that the object graph you're encoding is a tree (in case the same object is encoded twice, the decoded tree will contain two different copies instead of one shared copy; if you try to encode a cyclic graph it raises an exception). Per encoded object it generates an XML element that looks roughly like the one for this example, an encoding of an array containing the string "A string":
<ROOT type="#NSArray"><NS.object.0 type="#NSString"><NS.bytes>4120737472696E67</NS.bytes></NS.object.0></ROOT>
I wanted to further improve the above by using a different method instead of the object's own encodeWithCoder: for objects such as arrays and strings, so that the above would become:
<ROOT type="array"><item.0 type="string">A string</item.0></array></ROOT>
I'm however not sure if I will continue working on this. My overall goal was to have a fairly generic, simple way of saving an object tree to a file that leverages of the encodeWithCoder: methods I've already written, while producing a file that is not as Cocoa-dependent as when using NSKeyedArchiver. This would allow others to write applications that open those files on other platforms.
But I've now come to understand there have been similar efforts which may already be more advanced anyway, and furthermore, with XML being a document markup language it may not be the best target format and some non-markup language might be better suited.
Nevertheless, if you want to continue with this or have some other reason to look at a fairly simple NSCoder subclass, feel free to use my code. You could also take a look at MAKeyedArchiver. Oh, and my code is covered by a BSD-style license (at least the version that is in SVN revision 424 is, I might change this for future versions). Improvements and feedback are welcomed.