iOS Updating text in a UILabel from the appDelegate

[l0uismustdie]

Hello. I am trying to display some text in a UILabel I have created. The situation is as follows: I have a viewController (AccountCreation) which is connected with a xib file and has a bunch of text input boxes and a button to connect to a server and attempt to create an account. What I am trying to do is display the result of the account creation (success or failure) in a label on this view. The way I have this set up is once the "create account" button is pressed my program heads to my appDelegate who launches the URL connection protocols I've established which then returns to my appDelegate (this is where I would like to update the label). Some code that might be relevant:

@interface AccountCreation : UIViewController {
	IBOutlet UITextField	*username,*email,*password,*confirmPassword;
	IBOutlet UILabel		*errorLabel;
	BOOL					moveViewUp;
	CGFloat					scrollAmount;
}
-(IBAction)createAccount:(id)sender;
-(void)scrollTheView:(BOOL)movedUp;
-(void)updateError;
@property(nonatomic,retain)UITextField	*username;
@property(nonatomic,retain)UITextField	*email;
@property(nonatomic,retain)UITextField	*password;
@property(nonatomic,retain)UITextField	*confirmPassword;
@property(nonatomic,retain)UILabel		*errorLabel;
@end

And in my appDelegate:

-(void)createAccountAttempt:(NSData *)data
{
	AccountCreation	*accountController = [[AccountCreation alloc] init];

	NSString		*accountResponse=[[NSString alloc]initWithData:data encoding:NSASCIIStringEncoding];
	NSString		*errorLog;
	NSRange			start,end;
	
	NSLog(@"account creation response: %@",accountResponse);
	start=[accountResponse rangeOfString:@"<error>"];
	
	//error with account creation
	if(start.location>0)
	{
		start=[accountResponse rangeOfString:@"<error_msg>"];
		start.location+=[@"<error_msg>" length];
		end=[accountResponse rangeOfString:@"</error_msg>"];
		errorLog=[accountResponse substringWithRange:NSMakeRange(start.location, end.location-start.location)];
//		NSLog(@"errorLog: %@",errorLog);
		accountController.errorLabel.text=errorLog;
	}
	
	[accountResponse release];
}

I've noticed that my errorLabel is null inside of here. I've tried creating a method in the viewController to update the label.

Thanks for anyone's help.

 

[dejo]

I think the problem is you've created a new instance of AccountCreation rather than trying to use the existing one.

 

[l0uismustdie]

You are definitely right...but I'm not sure the most effective way to fix this. What I just tried to do was declare an AccountCreation variable inside my appDelegate header file. Then when I am doing to present that view I initialize the AccountCreation variable and then hopefully could just use that throughout my delegate. However, this is giving me an error that I am trying to present a nil modal view. What I have changed:

In the app delegate header:

AccountCreation		*accountController;
...
@property(nonatomic,retain)IBOutlet AccountCreation	*accountController;

Then later in the appDelegate.m

[accountController init];
[viewController presentModalViewController:accountController animated:YES];

Previously I had accountController declared like this:

AccountCreation	*accountController = [[AccountCreation alloc] init];
[viewController presentModalViewController:accountController animated:YES];

Thanks for your help!
and this worked out to the point of displaying the view at least...

 

[ulbador]

Personally I would redesign the application a bit. Although you can use the application delegate as a sort of "central hub" for the application, I think it usually ends up complicating and confusing things.

I guess the question is why are you using/abusing the app delegate in this fashion?

Instead of:

Button clicked
App Delegate Does network stuff
App Delegate Updates text field in original view controller


Do:

Button Clicked
Create a custom object for network stuff
original view controller updates text field from custom object data

I know my first few apps (when I was just learning Objective C) abused the app delegate in this fashion. The end result is there is usually a way better way to do it. From what I see you are trying to centralize things a bit so you can reuse the code.

 

[l0uismustdie]

Haha...guess I am just an abusive programmer. So, this is my first iPhone app...and it's probably more complicated that a first app should be. The reason behind my abuse is that I have a number of callback functions associated with the URL connections that I originally thought should just be put in the appDelegate. So, there are 3 views total in my app (an initial log in screen, a create account screen, and a screen that displays results once you have successfully logged in).

What you are suggesting is putting all the callback functions inside the view controllers and updating the labels from there?

 

[ulbador]

Haha...guess I am just an abusive programmer. So, this is my first iPhone app...and it's probably more complicated that a first app should be. The reason behind my abuse is that I have a number of callback functions associated with the URL connections that I originally thought should just be put in the appDelegate. So, there are 3 views total in my app (an initial log in screen, a create account screen, and a screen that displays results once you have successfully logged in).

What you are suggesting is putting all the callback functions inside the view controllers and updating the labels from there?

The scenario you mention is EXACTLY why in my first few apps I did what you did.

Basically, you would move all your networking code into a custom object. Then you have two choices.

The "proper" and "clean" way would be to use protocols and delegates. This would tell your networking object to use the callback methods in whatever view controller created the object, instead of the local ones. The nice part about this is that the callbacks for say, the Account Creation ViewController can be completely different and do different things than the callbacks for the Account Update ViewController.

You basically define your networking callbacks in a centralized location, but do the full implementation a different location. This is probably pretty complicated especially since you said you are new, but once you do it once and understand it, you will be lightyears ahead of many other Objective C programmers.

http://iphonedevelopertips.com/objective-c/the-basics-of-protocols-and-delegates.html

The probably easier way for you is just just use NSNotificationCenter. Basically, when your networking code hits the callbacks, you post a notification. Before your view controller calls the networking code, you tell it to listen for this notification.

http://iphonedevelopertips.com/cocoa/basics-of-notifications.html


Although I'm sure 1000 people will point out the flaws of this, I am of the belief that the application delegate should be as minimal as possible. If you still do need a sort of "global" variable like that, you can use singletons.

 

[l0uismustdie]

Right on. I will look over those sources a little later. This portion isn't critical to my application right now. But I currently do have a separate URL object that handles all my URL connections and so on. For example when I am making a call to the server to create an account I do the following:

-(void)createAccount:(NSString *)URL
{
	URLRequest *rq = [[[URLRequest alloc]init]autorelease];	
	[rq data:self requestSelector:@selector(createAccountAttempt:) withURL:URL andMethod:@"createAccount"];
}

Where createAccout: is run when a button in the AccountController view is pressed. This function is defined in the appDelegate but there is no reason I couldn't move this to the AccountController along with the createAccontAttempt:.

This might help I think...I will try that out in a little bit and read through some of those sources. Thanks for your help!

 

[dejo]

And your networking code doesn't necessarily have to even be in viewControllers. You could set up a whole custom class to handle it, if you wanted to.

 

[l0uismustdie]

Hmmm...I'm not sure what you mean by that. But putting everything in my view controller works perfectly. I just moved all my URL connection functions into the view controller and go back to the app delegate only to dismiss the modal view. This is a much better strategy.

Later in the code I am doing some really horrible things where I created a textView and to update the text repeatedly I append some stuff to a textLabel associated with the view, dismiss the modal view controller, then display it again (awful) but I can now use this same strategy there too.

Thanks so much!

 

[dejo]

Hmmm...I'm not sure what you mean by that.

Okay. Which part confuses you?

 

[l0uismustdie]

I'm not sure what you mean by having a custom class to handle my network stuff. I thought that's what I was doing. I have a URLconnection class that handles all the connection stuff. Is that what you mean?

-(void)createAccount:(NSString *)URL
{
	URLRequest *rq = [[[URLRequest alloc]init]autorelease];	
	[rq data:self requestSelector:@selector(createAccountAttempt:) withURL:URL andMethod:@"createAccount"];
}

This is running from my AccountController...URLRequest is my custom URL class...

 

[dejo]

This is running from my AccountController...URLRequest is my custom URL class...

Sorry, had a brain fart. Thought you meant NSURLRequest. I'll just move along then.

 

[l0uismustdie]

I have some more thoughts about this topic that you guys will likely be able to answer. When I am calling my URL class to make it's connection I am also having it do some work on some of the variables from my view (for example concatenating the email and password and doing an md5 hash of them). So, to manipulate the things that are currently in the view I am storing them in instance variables in my appDelegate and accessing them like that from the URL class. Some relevant codes:

This is in the AccountController

-(void)createAccountButton:(id)sender{

	vmAppDelegate *appDelegate=[[UIApplication sharedApplication]delegate];	
	
	//these will be used to check for availability and create user in URLrequest
	appDelegate.uName=username.text;
	appDelegate.email=email.text;
	appDelegate.pWord=password.text;
	appDelegate.confirmPWord=confirmPassword.text;
	
	//SUBJECET TO CHANGE BASED ON ACTUAL ADDRESS OF SERVER!
	URLRequest *rq = [[[URLRequest alloc]init]autorelease];	
	[rq data:self requestSelector:@selector(createAccountAttempt:) withURL:@"http://apt403.homelinux.com/iphoneproject/create_account.php" andMethod:@"createAccount"];
}

Then from the URL class I would do something like this:

if(method==@"createAccount")
{
     vmAppDelegate	*appDelegate=[[UIApplication sharedApplication]delegate];
     NSString		*newURL=[NSString stringWithFormat:@"%@",url];
     NSString		*passwordHash=appDelegate.pWord;

     //hash concactination of password + email address
     passwordHash=[passwordHash stringByAppendingString:appDelegate.email];
     passwordHash=[self md5:passwordHash];
		
     //add on email, hashed password, and username
     newURL=[newURL stringByAppendingString:[NSString stringWithFormat:@"?email_addr=%@&",appDelegate.email]];
     newURL=[newURL stringByAppendingString:[NSString stringWithFormat:@"passwd_hash=%@&",passwordHash]];
     newURL=[newURL stringByAppendingString:[NSString stringWithFormat:@"user_name=%@",appDelegate.uName]];

    theRequest = [[NSMutableURLRequest requestWithURL:[NSURL URLWithString:newURL]]retain];
}

It seems like I am wasting some active memory by having these instance variables but I can't think of an easier way to do this.

 

[dejo]

This is in the AccountController...

And by AccountController you are referring to the AccountCreation class, correct? Accuracy is important in getting help and, especially, in the code itself.

 

[l0uismustdie]

Yup.

 

[dejo]

I have some more thoughts about this topic that you guys will likely be able to answer. When I am calling my URL class to make it's connection I am also having it do some work on some of the variables from my view (for example concatenating the email and password and doing an md5 hash of them). So, to manipulate the things that are currently in the view I am storing them in instance variables in my appDelegate and accessing them like that from the URL class. Some relevant codes:

This is in the AccountController

-(void)createAccountButton:(id)sender{

	vmAppDelegate *appDelegate=[[UIApplication sharedApplication]delegate];	
	
	//these will be used to check for availability and create user in URLrequest
	appDelegate.uName=username.text;
	appDelegate.email=email.text;
	appDelegate.pWord=password.text;
	appDelegate.confirmPWord=confirmPassword.text;
	
	//SUBJECET TO CHANGE BASED ON ACTUAL ADDRESS OF SERVER!
	URLRequest *rq = [[[URLRequest alloc]init]autorelease];	
	[rq data:self requestSelector:@selector(createAccountAttempt:) withURL:@"http://apt403.homelinux.com/iphoneproject/create_account.php" andMethod:@"createAccount"];
}

Then from the URL class I would do something like this:

if(method==@"createAccount")
{
     vmAppDelegate	*appDelegate=[[UIApplication sharedApplication]delegate];
     NSString		*newURL=[NSString stringWithFormat:@"%@",url];
     NSString		*passwordHash=appDelegate.pWord;

     //hash concactination of password + email address
     passwordHash=[passwordHash stringByAppendingString:appDelegate.email];
     passwordHash=[self md5:passwordHash];
		
     //add on email, hashed password, and username
     newURL=[newURL stringByAppendingString:[NSString stringWithFormat:@"?email_addr=%@&",appDelegate.email]];
     newURL=[newURL stringByAppendingString:[NSString stringWithFormat:@"passwd_hash=%@&",passwordHash]];
     newURL=[newURL stringByAppendingString:[NSString stringWithFormat:@"user_name=%@",appDelegate.uName]];

    theRequest = [[NSMutableURLRequest requestWithURL:[NSURL URLWithString:newURL]]retain];
}

It seems like I am wasting some active memory by having these instance variables but I can't think of an easier way to do this.

What you are running into is a common need of what basically boils down to "sharing values between objects". There are a number of approaches to solving this including: storing those values in the appDelegate (not usually recommended, though), storing them in NSUserDefaults, using a singleton, creating properties for them in the destination class and setting their values prior to calling any methods in the destination class. (There's probably some other approaches I've missed). Hope that helps.