Strange custom delegate actions - iphone

Ok -- this one is weird. I have a singleton class that loads information from an XML file. I am using a delegate definition as follows (I define the delegate in a separate header file to make life easier):
#protocol ResourceClassDelegate <NSObject>
#optional
- (void)picturesDidStartLoading;
- (void)picturesDidFinishLoading;
#end
In the resource file, the delegate is defined correctly (I believe):
#property (assign) id<ResourceClassDelegate> delegate;
When using the delegate, the code in the resource class is as follows:
-(void)refreshPiecesOfHistoryWithOperation {
NSLog(#"Operation Started");
if ([delegate respondsToSelector:#selector(picturesDidStartLoading)])
[delegate picturesDidStartLoading];
self.picturePacks = [HistoryXMLParser loadPicturePacks];
[self.allPiecesOfHistory removeAllObjects];
// now lets put all of them in one big file...
for (PicturePack *pp in self.picturePacks) {
for (int ct = 0; ct < [[pp piecesOfHistory] count] ; ct++) {
[self.allPiecesOfHistory addObject:(PieceOfHistory *)[[pp piecesOfHistory] objectAtIndex:ct]];
}
}
NSLog(#"Operation Ended");
if ([delegate respondsToSelector:#selector(picturesDidFinishLoading)])
[delegate picturesDidFinishLoading];
}
Now... in the class that is listening to the delegate, it is assigned:
- (void)viewDidLoad {
[super viewDidLoad];
// now for the part that makes the loading all happen...
[[ResourceClass sharedResourceClass] setDelegate:self];
}
And in the listening class, the methods are defined....
#pragma mark ResourceClassDelegate
-(void)picturesDidStartLoading {
if (loadingActivity == nil)
loadingActivity = [[UIActivityIndicatorView alloc] initWithActivityIndicatorStyle:UIActivityIndicatorViewStyleWhiteLarge];
[self.view addSubview:loadingActivity];
[loadingActivity setCenter:[self.view center]];
[loadingActivity startAnimating];
}
-(void)picturesDidFinishLoading {
if (loadingActivity != nil) {
[loadingActivity stopAnimating];
[loadingActivity removeFromSuperview];
}
[self.tableView reloadData];
}
Now for the problem... every single time, in the listening class, the method (void)picturesDidFinishLoading is called. The method (void)picturesDidStartLoading never is called.
When I debug the code, in the resource class, the line
if ([delegate respondsToSelector:#selector(picturesDidStartLoading)])
[delegate picturesDidStartLoading];
never reaches the delegate method call - even if I remove the if statement. The line
if ([delegate respondsToSelector:#selector(picturesDidFinishLoading)])
[delegate picturesDidFinishLoading];
is always called.
any ideas?

Ok -- I figured it out....
The delegate was nil during the first call. The reason it is nil is because the function using the delegate was called in the source during the init method. The init method was not complete when the first test of the delegate was performed. At this time the delegate was nil because it is not instantiated until the the init method completes. The reason the second test of the delegate worked is because I submitted the process using an NSOperationQueue.
To fix the problem I have to move things around a bit... it's all about the timing!
Well now that was fun....

That's weird, try to remove #optional in the protocol declaration, and see if you get some warnings.
Try to print a log inside the method as well, other than that it looks fine.

Related

Method reCalling

im kinda new to iOS.
I know that a void method i.e
-(void) pressed {
}
can be called this way:
[self pressed];
and viewDidAppear
can be called something like this:
[self viewDidAppear:YES];
I was wandering on how to do it in this method below, or how to re-Call it:
- (NSUInteger)numberOfItemsInCarousel:(iCarousel *)carousel
{
return [images count];
}
You shouldn't call -(void)viewDidAppear:(BOOL)animated, it's part of the UIViewController lifecycle and it will be called automatically. As for the other one:
- (NSUInteger)numberOfItemsInCarousel:(iCarousel *)carousel
{
return [images count];
}
I never used iCarousel, but it seems to be a method from the Data source, and, as such, shouldn't be called directly as well.
That may me data source method... It is called from a controller.
//And it may be called in the controller as below where delegate is object of some class
iCarousel *iCarouselObj;
if(delegate && [delegate respondsToSelector:#selector(numberOfItemsInCarousel:)])
int items = [delegate numberOfItemsInCarousel:iCarouselObj];
//The below code is just to tell you how to call a method with arguments
iCarousel *iCarouselObj;
int items = [self numberOfItemsInCarousel:iCarouselObj];

App Crash on setting UITableViewCell:textLabel:text

I am creating a split-view iPad application. When the user presses the bar button item in the master view, a modal is presented. This modal has a textfield and has an IBAction to pick up keyboard returns.
On keyboard returns, a new instance of my Farm class is created (code below). This instance is then added to an array that is stored in my delegate. I then try to reload the MasterViewController's table. Upon this reload the application crashes on cell.textLabel.text with a EXC_BAD_ACCESS error.
Farm *current = [delegate.arrayOfFarms objectAtIndex:indexPath.row];
cell.textLabel.text = [current getFarmTitle];
If I ask the array within the delegate how many elements it has, it will indeed show the current amount, even. This is what is bizarre to me about this whole thing: the Farm instances appear to be in existence.
I have instances of AppDelegate in both my MasterViewController and my NewFarmNamingView classes. The instance in the Master is to populate the table. The instance in NewFarm is to add the newly created Farm to the delegate. Code below.
Segments from class NewFarmNamingView:
- (IBAction) keyboardDonePushed:(id)sender
{
// create a Farm and add it to the delegate
NSString *text = newFarmTextField.text;
Farm *newFarm = [[Farm alloc] init];
[newFarm setFarmTitle:text];
[[delegate arrayOfFarms] addObject:newFarm];
[newFarm release];
NSLog(#"Added farm: %#" , text);
// dismiss the view
[self closeView:nil];
}
- (void)viewDidLoad
{
[super viewDidLoad];
// initialize the delegate
delegate = [[UIApplication sharedApplication] delegate];
}
Segments from the class Farm
- (void) setFarmTitle : (NSString *) _farmTitle
{
farmTitle = _farmTitle;
}
- (NSString *) getFarmTitle
{
return farmTitle;
}
// NSCoding Methods
- (void) encodeWithCoder:(NSCoder *)aCoder
{
[aCoder encodeObject:farmTitle forKey:#"kFarmTitle"];
}
- (id) initWithCoder:(NSCoder *)aDecoder
{
farmTitle = [aDecoder decodeObjectForKey:#"kFarmTitle"];
return self;
}
// Initialization method
- (id)init
{
self = [super init];
if (self) {
// Initialization code here.
}
return self;
}
From the runtime reference: "objc_msgsend sends a message to the receiver and expects a simple return value."
I'll bet you anything that what you're returning (if you're returning anything at all) in that class method getTitleFarm is returning an incorrect value. It should be an NSString. Be absolutely sure it is returning an NSString, and not anything else.
If you need to use the respondsToSelector method to see if the class is being released, try:
if([current respondsToSelector:#selector(getFarmTitles)]) {. [current getFarmTitle];
}
else {
NSLog:(#"FAILURE!!");
}
EDIT: maybe you are not retaining or even creating this string at all. In it's initialization, wrap it in a retain]; message

initWithCoder: getting called by nib & NSCoding!

Ok, I'm having a lot of problems right now trying to get initWithCoder: to work right. I have a nib file that gets loaded, and in my app delegate, I call unarchiveWithFile: for the view controller that is associated with that nib, and now my app crashes. I can see that initWithCoder: is being called twice, presumably once from when awakeFromNib: is called, and then from when I call unarchiveWithFile: since the view controller conforms to NSCoding. But now either it crashes as soon as the view loads or when I press an IBOutlet. Any suggestions??
Edit: Here's the code for initWithCoder:
- (id)initWithCoder:(NSCoder *)coder {
[super initWithCoder:coder];
[[self mapView] addAnnotations:[[coder decodeObjectForKey:#"Annotations"] retain]];
return self;
}
All I'm doing is decoding an array of annotations for a map view, but somewhere along the line this method is being called twice and then it crashes.
Don't forget to put the nil check in your init methods. E.g. the method you posted would be more correct if you wrote it as:
- (id)initWithCoder:(NSCoder *)coder {
if (self = [super initWithCoder:coder]) {
[[self mapView] addAnnotations:[[coder decodeObjectForKey:#"Annotations"] retain]];
}
return self;
}
That's not the cause of your problem, however.
Is there are good reason for you unarchiving your view controller yourself? If you're not doing anything special, you can rely on the existing mechanisms to do it. The default implementation of init for a UIViewController looks for a nib with the same name as your view controller, and if it exists, it loads the nib (via initWithNibName).
If there is data which you need to archive in and out, it may be that it shouldn't be actually part of the UIViewController. Factor it out elsewhere perhaps?
you can try
- (id)initWithCoder:(NSCoder *)coder {
if(self == nil)
{
[super initWithCoder:coder];
[[self mapView] addAnnotations:[[coder decodeObjectForKey:#"Annotations"] retain]];
}
return self;
}

How to optimize callbacks from a NSOperationQueue-started thread

Consider this:
#interface SomeViewController : UIViewController {
SomeChildObject *child;
}
#end
#implementation SomeViewController
- (void) viewDidLoad {
...
child.delegate = self;
}
- (void) somethingHappened {
NSInvocationOperation *operation = [[NSInvocationOperation alloc]
initWithTarget:child
selector:#selector(doSomething)
object:nil];
[someNsOperationQueue addOperation:operation];
[operation release];
}
- (void) callbackA:(SomeData *)someData {
[self performSelectorOnMainThread:#selector(callbackAonMainThread:)
withObject:someData
waitUntilDone:NO];
}
- (void) callbackAonMainThread:(SomeData *)someData {
... do something with results in main thread, e.g UI feedback
}
- (void) callbackB:(SomeData *)someData {
[self performSelectorOnMainThread:#selector(callbackBonMainThread:)
withObject:someData
waitUntilDone:NO];
}
- (void) callbackBonMainThread:(SomeData *)someData {
... do something with results in main thread, e.g UI feedback
}
#end
In English:
I have a view controller running in the main thread with a child model object to do something (fetch data over network). The view controller is the delegate for the child, so the child can signal the results back with delegation. To perform the expensive work, I spawn the child.doSomething method with a NSInvocationOperation that launches the operation in a background thread. When done, the child calls the delegate's (view controller's) callbackA or callbackB with some results. Since (I think) these callbacks are invoked in the same background thread where the doSomething call was run, I need to call performSelectorOnMainThread to transfer control back to main thread.
This works fine, but I do not like having two callback-related methods for each callback. (There are actually more callbacks, so the real code is even more bloated.) Ideally, I would do something like this:
- (void) callbackA:(SomeData *)someData {
if (not_running_on_main_thread) {
[self performSelectorOnMainThread:#selector(callbackA:)
withObject:someData
waitUntilDone:NO];
} else {
// now running on main thread, work with the results.
}
}
Questions:
1) how do I do the "not_running_on_main_thread" test?
2) is there any other way to cut down the callbacks bloat?
EDIT: ok, I never read NSThread docs before posting :) looks like [NSThread isMainThread] is what I am looking for. But is there any other way to restructure or make this nicer still?
Just check for [NSThread isMainThread]. There's nothing more you can do if you need multiple callbacks which do different things.
Only one thing I do differently, my code looks like this:
- (void) callbackA:(SomeData *)someData {
if (![NSThread isMainThread]) {
[self performSelectorOnMainThread:#selector(callbackA:)
withObject:someData
waitUntilDone:NO];
return;
}
// now running on main thread, work with the results.
}
This lets me get rid of the whole-function-long else and make the code a little clearer. And you can save on one indentation level this way ;-)

"Swapping" a UIView Instance variable - cannot dealloc "previous" view

I want to organize somehow my iPhone game's level-views, but I simply cannot (without expanding Object Allocations). I made a really "skeleton" of my code (this game has 2 levels, the goal is to release the iPhone display). I just cannot dealloc the previous level, so Instrunments shows incrementing BGTangramLevel instances.
Please, take a look on it, I need some helpful ideas on designing (my 3rd question on it).
viewcontroller.h
#interface compactTangramViewController : UIViewController
{
//The level.
BGTangramLevel *currentLevel;
UIColor *levelColor;
}
//It is to be just a reference, therefore I use assign here.
#property (nonatomic, retain) BGTangramLevel *currentLevel;
-(void) notificationHandler: (NSNotification*) notification;
-(void) finishedCurrentLevel;
#end
viewcontroller.m
#implementation compactTangramViewController
#synthesize currentLevel;
//Initializer functions, setting up view hierarchy.
-(void) viewDidLoad
{
//Set up levelstepper.
levelColor = [UIColor greenColor];
//Set up "state" classes.
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(notificationHandler:) name:#"finishedCurrentLevel" object:nil];
//Attach level 1.
currentLevel = [BGTangramLevel levelWithColor: levelColor frame:self.view.frame];
[self.view addSubview:currentLevel];
[super viewDidLoad];
}
//Release objects.
-(void) dealloc
{
[currentLevel release];
[super dealloc];
}
//Notification handling.
-(void) notificationHandler: (NSNotification*) notification
{
//Execute level swap.
if ([notification name] == #"finishedCurrentLevel") [self finishedCurrentLevel];
}
-(void) finishedCurrentLevel
{
//Remove previous level.
[currentLevel removeFromSuperview];
//[currentLevel release];
//Step level.
if (levelColor == [UIColor greenColor]) levelColor = [UIColor blueColor]; else levelColor = [UIColor greenColor];
//Attach level 2.
currentLevel = [BGTangramLevel levelWithColor: levelColor frame:self.view.frame];
[self.view addSubview:currentLevel];
}
#end
BGTangramLevel.h
#interface BGTangramLevel : UIView
{
BOOL puzzleCompleted;
}
//Initializer.
+(BGTangramLevel*)levelWithColor: (UIColor*) color frame: (CGRect) frame;
//Test if the puzzle is completed.
-(void) isSolved;
#end
BGTangramLevel.m
#implementation BGTangramLevel
//Allocated instance.
+(BGTangramLevel*)levelWithColor: (UIColor*) color frame: (CGRect) frame
{
BGTangramLevel *allocatedLevel = [[BGTangramLevel alloc] initWithFrame:frame];
allocatedLevel.backgroundColor = color;
return allocatedLevel;
}
//Finger released.
-(void) touchesEnded: (NSSet*)touches withEvent: (UIEvent*)event
{
//The completement condition is a simple released tap for now...
puzzleCompleted = YES;
[self isSolved];
}
//Test if the puzzle is completed.
-(void) isSolved
{
//"Notify" viewController if puzzle has solved.
if (puzzleCompleted) [[NSNotificationCenter defaultCenter] postNotificationName:#"finishedCurrentLevel" object:nil];
}
-(void) dealloc
{
NSLog(#"Will ever level dealloc invoked."); //It is not.
[super dealloc];
}
#end
So what should I do? I tried to mark autorelease the returning level instance, release currentLevel after removeFromSuperview, tried currentLevel property synthesized in (nonatomic, assign) way, but Object Allocations still grow. May I avoid Notifications? I'm stuck.
You need to follow retain/release rules more closely. You definitely should not experimentally add retain and release and autorelease in places just to find something that works. There's plenty written about Cocoa memory management already, I won't repeat it here.
Specifically, BGTangramLevel's levelWithColor:frame: method should be calling [allocatedLevel autorelease] before returning allocatedLevel to its caller. It doesn't own the object, it's up to the caller to retain it.
You also need to know the difference between accessing an instance variable and accessing a property. Cocoa's properties are just syntactic-sugar for getter and setter methods. When you reference currentLevel in your view controller you are dealing with the instance variable directly. When you reference self.currentLevel you are dealing with the property.
Even though you've declared a property, currentLevel = [BGTangram ...] simply copies a reference into the variable. In viewDidLoad, you need to use self.currentLevel = [BGTangram ...] if you want to go through the property's setter method, which will retain the object (because you declared the property that way). See the difference?
I think your leak is happening in finishedCurrentLevel. If you had used self.currentLevel = [BGTangram ...], the property's setter method would be called, which would release the old object and retain the new one. Because you assign to the instance variable directly, you simply overwrite the reference to the old level without releasing it.
Calling [currentLevel release] in the dealloc method of your view controller is correct.