Suppose I want to reset an object to its initial state. It seems like the natural thing to do would be to run it through its init method -- but Apple guidelines are that I only want to do this once.
Creating a new object is not a satisfactory solution, because I need to preserve pointers to the object from elsewhere.
The object is part of a large class hierarchy. I will probably want to be able to reset most anything in the hierarchy.
Suggestions?
Create a reset method. This method could then in turn be called by init and if it is in a hiearchy all classes should implement it and call super reset.
Related
Background
I'm working on an iOS game in Swift which has realtime theme updates. This basically means that SKSpriteObjects change their color when a the theme changes. As I'm implementing it, I'd like to do it in a way that is good OOP practice, and good for scalability (lots of objects doing this at once). I've got two ideas for achieving this:
Method One: Notifier/Observer + Singleton
-Register all updatable SKSpriteObjects as observers for the key "updateTheme"
-Create a singleton called GameState with the current theme colors
-When the "updateTheme" notification is fired, each of the observers will reach out the the singleton for their new colors.
Method Two: Notifier/Observer + passed object
-Register all updatable SKSpriteObjects as observers for the key "updateTheme"
-The object that fires the notification "updateTheme" will create and attach an object to the notification that contains the current theme attributes.
-When the "updateTheme" notification is observed each of the observers will unwrap the object, and then access the updated colors from that unwrapped object.
Question
Although I think that passing an object around in a notification is a better OOP practice, I'm imagining that all the unwrapping going on won't be the best idea for speed. So with that, I'm more inclined to go for the singleton approach. What are your thoughts? Perhaps there's a better way that I didn't think of to massively update all the objects in my game.
Never to a singleton.
Or, to put it in different words:
Whenever you have two options, and one of them involves a singleton, pick the other option.
My recommendation would be to first write your game properly, then see if it suffers performance wise, and if and only if it does, then worry about performance. And what usually tends to happen is that you will find a few places where you can provide nice and neat algorithmic optimizations that will make your game perform better, instead of tweaking and hacking all over the source code to save clock cycles here and there.
That having been said, consider one more alternative: it is a common pattern with event observers to pass to them as their first parameter a reference to the object issuing the notification. So, why not have the observable pass a reference to itself to the observers, so that the observers can then obtain whatever they need from the observable?
Say I am switching Views via a segue and I know that most of the data I want to pass to a new VC will get passed to multiple other VCs in later segues. I am pretty new to swift/cocoa development, but as far as I am concerned, the standard way of passing this data would be via the prepareForSegue function. This seems to be pretty repetitive though, as I am passing the same data over and over again. Wouldn't it be easier to have some kind of singleton class to store that data and manipulate it with the current VC? I'm pretty sure Apple has a better solution for this though.
Is it ok to use singletons for this kind of scenario or is there a better way?
Singletons can be accessed directly from anywhere in the app. Singletons introduce coupling in your code and make your objects hard to test.
There are two ways to pass data forward.
Passing data when a segue is performed
Passing data when a transition is performed through code
Both could be boring but I think there is no way except them.
I'm still new to Objective C, and I feel this might be a probably a basic concept I don't know.
I'm working with OpenGL and I have the method GLKView of the viewcontroller, is called when "the view needs to be updated". From this method, I call another method, but I don't want the second method to be called at a rate that I specify.
How would I go about accomplishing this? I understand that viewcontroller.preferredFramesPerSecond can be set, but I only want this ONE specific method to work on a different timer..
Is this even the right way of going about this?
Sounds like you might want to use NSTimer
The reason I ask is because I have separate domain objects which I map from the NSManagedObject subclasses so as to keep my data access logic separate.
But I think its going to be a problem for updating.
I wouldn't say that NSManagedObject subclasses must be passed to a controller object: In theory you could do what you're describing, and build a "front end" layer that sits between your Core Data model and your controllers – you're creating a lot more work, of course, and it might be just as easy to throw out your old model and start over, if and when you ever do decide to stop using Core Data.
You may also have to put more effort into keeping your model objects separate from your controller objects, what with a middle layer that could easily become a hodgepodge of both. It sounds like you've already gone down this road, though, so the question is probably more about the best use of your time and resources, and whether it's more cost-effective to phase out the middle layer or maintain it.
If you mean should you pass MySubclass vs NSManagedObject; it does not matter. The instance is what it is, your subclass. You can call it anything in between id and MySubclass.
So you can set up your controller to accept just an id or NSManagedObject you can pass it your subclass without an issue. If you want more exposed control to the subclass then you can pass around the subclass.
If that does not answer your question then I suggest you expound upon your question with an example.
Been researching how to send data from one child view to another child view. The application has several views, where one is kind of real-time Settings view. Changes in settings should effect stuff inside other views.
NSUserDefaults seems to be popular, but I don't want persistent data nor automatic saving into database/file. Looks like potential slowdown, which I want to avoid.
Second popular thing is passing a reference to some common top level object into each child view. Just haven't found any tutorial, which would show me in detail how to do this... Most likely so easy, no tutorial is needed - after you figure it out once! Would appreciate, if you can point me to right direction (URL)!
Question: I'm thinking about using one "singleton object" to store "global data", access it from everywhere anytime. What could wrong with this? If I create it at e.g. appDelegate.m it should exist before anyone tries to access it, right?
I'm looking at this sample code.
I would recommend using delegates and/or notifications.
Instead of creating a new singleton in the app delegate, add the necessary data (or, even better, references to the data) in the app delegate and have the views have references to the app delegate.
You can also set up notifications so that your views can keep track of changes to the data that they display.
The beauty of a singleton is that it is automatically created when you first access it via some [singletonClass sharedInstance]. So you don't need to "create" it while launching. If it is global data that needs to be accessed from any view singleton might be the right way of doing this.