I have subclassed NSCoding and added my game specific stuff to it such as health etc. I have serialised the object I have subclassed however upon decoding and then adding the sprite to the screen via [self addChild:sprite], it fails to draw the sprite to the screen.
I am guessing this is because CCSprite needs to also implement the NSCoding protocol so my questions are:
1) Am I right about my assumption above (I don't want to waste time implementing this solution to only find out this is not the issue)
2) What is the best way to get CCSprite to implement NSCoding? Is it to use Categories or just subclass it and force the subclass to implement the NSCoding protocol?
LOL sorry it was late at night when i wrote that, i figured out the solution by early morning. The problem i had was i was sending a subclass of CSSprite from one process to another, i was confused as to why the sprite was not being displayed in the receiving process. I figured out not all of the sprite data was being serialised. The solution i implemented was to only send across information i needed such as coordinates,image name etc and just rebuild the sprite from scratch on the receiving end :)
Related
I'm trying to detect animations and other screen updates as they happen inside a UIWebView. I would like to get the rectangles of areas in the UIWebView that have been modified since the last refresh.
I think really what I'm looking for is for a way to "trap" the calls that UIWebView makes to setNeedsDisplayInRect. Is there a way to do that? Can I somehow subclass UIWebView's underlying CALayer object in a way that would allow me to catch those calls as they come in from UIWebView?
There's no good way of doing that. You can try grabbing a snapshot of the UIWebView's CALayer and comparing it to the previous snapshot, but I've had a lot of trouble getting reliable snapshots of UIWebViews.
Use an Objective-C category (#implementation CALayer (MyCALayer)) - like you're already doing based on your update - to trap the calls going from UIWebView to CALayer.
Then, use Method Swizzling to relay your category overrides to the original CALayer object.
Ok hopefully this is an easy question:
I have a main viewcontroller that is loaded by the app delegate at application startup.
This viewcontroller has some code in 'viewDidLoad' to create some non view type based objects (some sound/data objects). Aside from that it also loads a UIView.
The sound/data objects take a while to create, but the app is quite functional without them for a start - so I want to load these objects after the UIView has loaded, but can't seem to figure out how.
I have tried moving the appropriate code to viewDidAppear, but this is still called before the UIView actually appears on screen. Is there a function that is called after the viewcontroller actually starts displaying UIViews, or any other way to achieve what I want?
Any help would be much appreciated - thanks!
In case anyone else has a similar problem, I found a way to solve it: use NSThread to load things in the background without pausing everything else.
There's a good simple example here: http://www.iphoneexamples.com/.
I have been using Objective-C for a while and pretty much understand most of its features. However, the concept of delegates eludes me. Can someone please give a succinct and easy to comprehend explanation of what delegates are, how they are used in the iPhone SDK, and how I can best make use of them in my own code?
Thank you!
There are a couple main reasons to use delegates in Objective-C, which are subtly different:
Enhancing the base functionality of a framework class. For example, a UITableView is pretty boring on its own, so you can give it a delegate to handle the interesting bits (creating table cells, adding text to section headers, what have you). This way, UITableView never changes, but different table views can look and act very differently.
Communicating to parent objects in your dependency hierarchy. For example, you may have a view with a button that the user may push to do something that affects other views. The view will have to send a message to its parent view, or perhaps the view controller, so that it can create or destroy or modify other views. To do this you'd pass the parent object into your view, most likely through a protocol, as a weak reference (in Objective-C, an assign property). The view could then send any message declared in the protocol to the parent, or delegate, object.
This approach need not involve views. For example NSURLConnection passes event back to its delegate, which may be the object that created it, using this mechanism.
Essentially, all a delegate is, is an object that accepts feedback from another object. Put simply, when stuff happens to an object, it tells its delegate (assuming it has one).
For instance, lets say I have a UIViewController with a UITextView placed in the middle of the view. I set up my UIViewController to be the delegate of the UITextView. Then, when certain actions are performed on the text view (begin editing, text changes, end editing, etc), it tells it's delegate so it can do whatever logic it needs to do, like spell checking every time characters change, or dismissing the keyboard when it receives a return key press.
Delegate methods perform a similar function to callback functions in C.
Hope that makes sense :)
Best and simple concept I got from a Lynda.com Tutorial was: When you set a Delegate it means you have been given work to do. So, if you want to use methods that are written in a protocol method, you must implement them by searching in the Delegate Class Reference and using them. I hope it helped.
By the way, Delegates are excellents. They are your friends. They have been made to make your life as a programmer much easier.
I wrote the code of a card game .. but now it's time todo the graphic and Interface
What's the best approach to represent a card ??
a) CALayer
b) UIView
c) UIButton
Which one is best to animate and receive user touches???
What do you recommend??
Thanks in advance
GeekGameBoard is older Apple-provided example code for card and board games that implements the UI in CALayers. Another user modified it to run on the iPhone so it might be helpful code for you to look at. The modified project is on bitbucket.
as UIButton is subclass of UIView, there's no so much difference in both of them.
If you need only 'clicks' handling, you can choose button, if you will need to override touchesBegan/touchesMoved you should override UIView instead UIButton.
A UIView subclass would probably be your best choice. You can easily receive touch events from the user, and UIView allows you to do simple animations easily.
I've set up an Objective-C category for an iPhone app's UIImageView class. The category's mission is to help load URL-based images asynchronously with memory/disk caching.
Now, in UIImageView+Cache.m I have access to an NSOperationQueue so I can kick off a loading thread. I create an NSOperation-derived object, initialized with the image URL and the target UIImageView, and a selector to perform on the target once the operation is complete. In the selector method, we set our freshly-loaded image (or, if not found, we set an alternate placeholder image), and we're done!
This works fine, until a UIImageView happens to be removed before the NSOperation completes. For instance, I have a previous/next segmented control in my UI that causes these UIImageViews to be removed and added anew (they're part of a larger "item" that is being viewed in the app), so it's very easy to tap these in rapid succession.
So if you decide to start tapping away before all the images are loaded - KABLAM! Unhappy thread has an invalid object and doesn't know it. :(
The closest thing I can find to help mitigate this is NSOperation's cancel and isCancelled methods, except you can't keep track of which operation object to cancel within a Category, because - if I understand correctly - Categories can't add IVARs to objects!
Maybe that means Categories aren't a good idea here? (Whines: "But I liiiiike Categories! Waaah!")
Advisement appreciated!
I probably wouldn't use a category for this situation. Categories are useful, but are usually unnecessary. I'd only use a category if you have a really good reason to. What exactly are you putting in the category?
I think you could implement the whole thing in the NSOperation subclass, which would be the best solution. Put a retain on the image view so it doesn't get deallocated before the image is downloaded, and cancel the download if the view is not visible anymore. If that's not possible, then subclass UIImageView instead of using a category.
I would say there is no harm in moving this into your own UIImageView subclass. Sure, you may like categories - but if they don't do the job then why hesitate in moving to a design that does?
Are you retaining the UIImageView by the NSOperation? Otherwise the imageView might be freed before the NSOperation completes, leading to kablooi central. You should do a retain and then, once you've done the setImage, do a release.