In my game I have a NSCoding-conforming Combat class, which also uses GameplayKit's GKGridGraph and GKGridGraphNode objects, which do not conform to NSCoding. Is there a way to serialize/unserialize these objects?
As you've noted, there's no NSCoding support in these classes. (That'd make a good feature request to send to Apple, though.)
It should be possible, however, to create your own serialized representation of a graph when encoding your classes, then read that in and initialize new GKGraph and GKGraphNode objects accordingly in your init(coder:) implementation. Note that when doing so you'll have to carefully walk the graph yourself to capture all the node connections.
Related
Examples that I have seen online only use custom objects.
Predefined objects by Apple do inherit NSCoding.
If it's possible how would one go about doing this ?
I tried using an extension and overriding the two functions defined in the protocol.
I had no luck.
Someone marked this as close because the question was unclear.
let me add more detail.
Object defined in MapKit MKMapCamera. Has a few properties, I would like to store this object in user defaults.
Articles like this one do this with custom objects: http://nshipster.com/nscoding/
Can anyone explain to me what a singleton object is? In many tutorials I found something like "create a sigleton object". Now I am working in iphone game development using cocos2d. I read "Create a singleton object to keep all the Game Center code in one spot" in raywenderlich multiplayer tutorial, and also he says:
+ (GCHelper *)sharedInstance;
This static method to retrive the singleton instance of this class. But I don't know what a singleton is, or how to use it.
A Singleton object is an object for which there is only a single instance for a given class. The Singleton pattern is used when you want to guarantee that a single instance of a class will be shared across clients in a system.
Check out the C2 wiki page for more information.
Here are some posts with examples of the use of singletons in objective-c:
Using the Singleton Pattern in Objective-C
Singletons: You're doing them wrong
A singleton is an instance of a class that is meant to be the only one of its kind. You usually have a class method that returns a pointer to this single instance or creates it if it didnot exist yet.
Some examples of singletons are:
NSFileManager defaultManager
NSUserDefaults standardUserdefaults
NSCharacterSet whitespaceCharacterset
Singletons are the generally accepted method to hold model data and code in a central place that you can access from everwhere in your other code. All you need to do is to add the header and get the singleton pointer via class method.
See here for a comparison of singleton versus global variables: http://www.cocoanetics.com/2009/05/the-death-of-global-variables/
Singleton object means there is only one object throughout your application. If you used any properties in a singleton class and you access this property using object of this class, which is also called singleton object, you will get the same value in you whole application until you change it manually. This concept is generally used to maintain some fix values that your application required like if your application has login process than may be you required logged in username to be carried in your application for use at any point of application.
I was wondering what the relative advantages of using custom protocols and delegates are when compared to other techniques for achieving bi-directional class communication?
Another solution for example is to have the following:
A associated to B
B associated to A
This way both A and B have access to each others information...
I kind of get an understanding that protocols allow for an increase in the modularity of the system design, but I'm not entirely sure why or how?
Custom delegate protocol is a great thing, it allows your object to not depend on the particular class. Any object that conforms to the given protocol can be the delegate. For example, any object can be the delegate for the table view if it implements NSTableViewDelegate protocol.
Otherwise, if you use direct association, you have to use object of the certain class.
With the delegate pattern (specifically the use of a protocol) the classes stay loosely coupled. This is significant when considering the MVC pattern. Delegate pattern allows the view to stay decoupled from the controller.
Also, "A associated to B B associated to A" would create a retain cycle. The delegate pattern codifies the memory management issues (i.e. a class should not retain its delegate).
This kind of bi-directional dependency is to avoid as at compilation level it mean that you have each include including the other's.
You are tying your classes too much when one the goal of OO programming is to reduce component coupling.
Even if you can do it doesn't mean it's good practice.
Good pratice would be to specify 2 protocols, one for for the server/object/producer/... and one for the client/delegate/consumer/...
Then A would implement one protocol, would talk to object implementing the second one.
B would implement second protocol.
In the end that mean you can replace B implementation in the future to match a new API/programming model/test-stub, etc.
Reduce coupling is a mean to help modulartity and testability of your code.
You don't have to, but you'll be happy when coming back on your code 6 month later from now :)
Usually there is no need for 2 objects to have a full bi-directional communication.
Usually in iPhone you initiate B from A (e.g. detailed view controller from a list view controller) and set A to be B's delegate so that it will receive direct notification on relevant events.
It is not right in terms of object oriented design/programming to connect 2 objects in a fully bi-directional connection.
You loose the encapsulation in this case.
Once you use the delegation design pattern your object don't really know each other but still can communicate.
In addition, this way any object that implements a certain protocol may be set as a delegate.
This way the objects also don't have to retain each other...
Is there anyway to add more fields (e.g. location and etc) to TTPhoto protocol?
I know that one way is to create my own protocol but that would require me to change a lot of stuffs in my view controllers. Is there any simpler way to achieve this?
Formal protocols are primarily a compile time conceit, to help you be more clear about your intentions. They're a relatively recent invention, before which all protocols were informal — they were part of the class documentation but not declared in the code. They have a runtime effect in that you can use some of the Objective-C runtime methods to query whether a particular class responds to a particular protocol (just as you can query whether a particular class responds to a particular selector), but no such testing will occur at runtime when you pass objects about.
Protocols are just a contract defining communications and don't specify behaviour. So there's no concept of inheritance. And there's no runtime list of the selectors included in a protocol, so the idea isn't particularly helpful.
Your best shot is to define an additional protocol that includes the extra functionality you want. Write your new objects to implement both protocols. Extend classes you don't want or have access to using category methods.
If you need additional storage to handle the new fields, then it's safest to subclass. You can actually add instance variables at runtime nowadays, but you'd need to drop down to the C interface to the Objective-C runtime and finding an opportunity to do so would require some hoop jumping.
In a game I have a bunch of objects and collections of objects, some of them include references to others. Is there a straightforward way to archive them - to save a game state - while maintaining those references? If I understood well, NSArchiver can do that, but it wasn't available on SDK 2, is it on SDK 3?
(I have sort of asked this question before (best way to save/load iphone game data) but SDK 3 has been released in the meantime, and I'd like to know if this topic has progressed.)
You need to make all of the classes you want to serialize implement the NSCoding protocol. After that, you need to encode them with the NSKeyedArchiver class. That class will recursively serialize your objects, and will deal with cycles. NSKeyedArchiver is available in all releases of the iPhone SDK. To decode your objects, you'll uses NSKeyedUnarchiver.
Check out Object serialization here:
Encoding/Decoding Objects (apple.com)
Basically, you have to make your classes Key-Value Coding compliant, to properly save all of your data; It archives them into binary property lists. After you write your initWithCoder: and encodeWithCoder: functions it's pretty much automatic!