I am writing an app that uses multithreading and cache. Quite similar to Apple's TopSongs sample code. Upon startup, I need to grab the value of an object in a JSON feed.
Now I am afraid doing so would ruin the workflow of the app, and block a thread or something if I use NSURLConnection. Can I just download that JSON feed (it only has one object) without using NSURLConnection's delegate methods? If I implement the delegate methods in my delegate file, then the app will finish up applicationDidFinishLaunching:application method and THEN go to
connection:didReceiveResponse:
connection:didReceiveData:
connection:didFailWithError:
connectionDidFinishLoading:
How can I avoid that? I need to get the timestamp (stored in that JSON file) right at the beginning of applicationDidFinishLaunching:application as the rest of that method depend on that timestamp.
Thank you,
There are two ways to achieve this:
Use the sendSynchronousRequest of NSURLConnection, but this will block until a response is received
+ (NSData *)sendSynchronousRequest:(NSURLRequest *)request returningResponse:(NSURLResponse **)response error:(NSError **)error
or (the preferable option)
Move the code which relies on the JSON to a seperate method. Use the asynchronous + delegate methods of NSURLConnection as normal, but in your applicationDidFinishLaunching method display some sort of HUD to inform the user of what's happening and then in the connection:didReceiveResponse method or connectionDidFinishLoading method call your new method which relies on the JSON (and will now have the JSON) and dismiss the HUD.
I'm not sure I understand what you mean when you said "the app will finish up applicationDidFinishLaunching and THEN go to
connection:didReceiveResponse:
connection:didReceiveData:
connection:didFailWithError:
connectionDidFinishLoading:"
Could you explain that a little more?
As for the point about the method depending on the timestamp that you need to get from the JSON file, I would suggest that you need to review your application design and what you are doing in your methods.
Related
i have to write some code that initialize my data app. This must be made before the app the app is loaded. In my opinion the best way is to write this code in app delegate. Am i right?
p.s. : the code download some xml from the net and parse a lot of data and put in core data.
Depending on the exact context you can also implement a + (void)initialize method in your class.
YES friend if you write on applicationDidFinishLaunching method in appDelegate ..then webservice get called before the app launch and you have all that data when you start your application . for that you need to set connection by AsiHTTP connection DElegate and parse using NSXmlParserDelegate..
Yes , its right to call xml parsing in appdelegate so that you had data , before your app first view loads.
Very new to programming for iOS and Cocoa so please take it easy on me as I try to wrap my brain around the following. I'm trying to display a tableview populated from an XML feed as the opening screen of my app. I've tried to consume the XML from inside my AppDelegate using the ApplicationDidFinishLaunching method (and then making my AppDelegate a delegate for the XML parser which I access using a NSUrlConnection and its delegate methods) but I can't figure out how to take the parsed XML file and pass it to a tableviewcontroller which can then use it as the datasource for a tableview. When I do try, I always get a blank tableview.
I've written the code a few times and nothing seems to work.. I'll post what I have here to show what I've got so far but I'm afraid its mostly vanilla AppDelegate with a few parser methods thrown in.. any pointers in the right direction would be super appreciated.
Thank you in advance!
Hmm, probably a bad idea to do the network call in the AppDelegate. Try to put all that code at the view controller level. Here's a brief structure of what I do (Since it's very similar)
View Controller listens to button events
Use ASIHTTPRequest to talk to your web service. Handles network really well, you can skip the NSURLConnection stuff.
Try to load your data source (an array?) with static values and see if they come up on the table view.
Parse the response from ASIHTTPRequest using NSXMLParser, and load the data you want into the static array you were using. More here.
Call [tableView reloadData] once you're done and the changes will reflect.
Did you specify a UITableViewDataSource for your table view and implement the two required methods?
tableView:cellForRowAtIndexPath:
and
tableView:numberOfRowsInSection:
http://developer.apple.com/library/ios/#documentation/uikit/reference/UITableViewDataSource_Protocol/Reference/Reference.html
When I get blank tables, this is what it is; I've forgotten to specify the data source
Is anyone else having this problem with ASIHTTPRequest? It seems that when I perform an async request from within a background thread with delegate set to the instance I can run into trouble as the delegate can be freed before the request (which is put into an NSOperationQueue) returns a callback.
It seems that ASIHTTPRequest doesn't retain it's delegate - on the other hand Apple's NSURLConnection does retain the delegate ("NSURLConnection retains its delegate when it is initialized. It releases the delegate when the connection finishes loading, fails, or is canceled.").
Should I make sure to perform synchronous ASIHTTPRequests in background threads to make this work (instead of async requests)? Or maybe I should dump ASIHTTPRequest? Or am I just crazy?
Assuming you're using a very recent version of ASIHTTPRequest, the correct way to work with it (and avoid crashes) is that:
The delegate should retain the request (and the request should not retain the delegate)
The delegate should do the following when the delegate is destroyed (or when you want to cancel the request):
[request setDelegate:nil];
[request cancel];
[request release];
You shouldn't get any crashes this way. (I rewrote the delegate handling in ASIHTTPRequest a few months ago exactly to avoid some of these issues, and I checked with the folks from Apple that this was a correct way to handle things before doing so. My changes are all in the official ASIHTTPRequest repository on github, though there hasn't been an official release since - ie. these changes aren't in the v1.7 release, so with v1.7 or earlier you could still see crashes when following the above advice.)
I don't know if ASIHTTPRequests doesn't retain the object, but did you try to retain it when performing and the releasing it at the end ?
I never had a problem yet with this very good wrapper ^^
Here's the issue – I followed along with the Apple lazy-load image sample code to handle my graphical tables. It works great. However, my lazy-load image tables are being stacked within a navigation controller so that you can move in and out of menus. While all this works, I'm getting a persistent crash when I move into a table then move immediately back out of it using the "back" button. This appears to be a result of the network connections loading content not being closed properly, or calling back to their released delegates. Now, I've tried working through this and carefully setting all delegates to nil and calling close on all open network connections before releasing a menu. However, I'm still getting the error. Also – short posting my entire application code into this post, I can't really post a specific code snippet that illustrates this situation.
I wonder if anyone has ideas for tasks that I may be missing? Do I need to do anything to close a network connection other than closing it and setting it to nil? Also, I'm new to debugging tools – can anyone suggest a good tool to use to watch network connections and see what's causing them to fail?
Thanks!
Have you run it through the debugger (Cmd-Y)? Does it stop at the place where the crash is happening? That should show you in code where the issue is happening. I'm betting the issue has to do with over-releasing something rather than cleaning up connections. Are you getting EXC_BAD_ACCESS? Check any delegates and make sure they are nil when -viewWillDisappear gets called. That way, if anything tries to call back to a delegate, it will just be a no-op.
You may also want to try enabling zombies (NSZombieEnabled) which will tell you when an object that has been released is being accessed again. It's very helpful in finding over-released objects.
Ah ha... after a large zombie hunt (thanks, Matt Long), I discovered that the issue stems from an error in Apple's LazyTableImages sample code. That example provides the following implementation for canceling all image loads, which I turned into a general-purpose stopAllImageLoads method...
From RootViewController.m in LazyTableImages sample code:
- (void)didReceiveMemoryWarning
{
[super didReceiveMemoryWarning];
// terminate all pending download connections
NSArray *allDownloads = [self.imageDownloadsInProgress allValues];
[allDownloads performSelector:#selector(cancelDownload)];
}
There is in error in the last line of the above method where performSelector is called on an array of objects. The above implementation calls the selector on the array itself, rather that on each object in the array. Therefore, that last line should be this:
[allDownloads makeObjectsPerformSelector:#selector(cancelDownload)];
Once that line was changed, everything else fell into place. It turns out I wasn't calling my stopAllImageLoads method where I meant to – I had disabled it at one point because it was causing an error. Once that was back in place, the memory issues cleared up because image loads were successfully canceled before the table delegate was released.
Thanks all for your help.
If you're doing ANY asynchronous function (network requests, Core Location updates, etc), you run the risk that your view controller that is the delegate of that action is deallocated by the time the async function returns. i.e. you back out of the view and take the delegate target away from the background process. I've dealt with this several times.
Here's what you do. Use the ASIHTTPRequest library (which you should be doing anyway--it's brilliant). Create a synthesized property to hold your request. Then in viewWillDisappear, call -cancel on your request. To be safe, I also set its delegate to nil, but that should be unnecessary.
Here's a sketch of what you want to do. Note I typed this right here, haven't syntax-checked it or anything.
#implementation MyViewController
#synthesize req //this is an ASIHTTPRequest *req.
-(void)viewDidLoad
{
//make an NSURL object called myURL
self.req = [ASIHTTPRequest requestWithURL:myURL];
self.req.delegate = self;
[self.req startAsynchronous];
}
-(void)viewWillDisappear
{
[self.req cancel];
}
-(void)requestFinished:(ASIHTTPRequest *)request
{
NSString *string = [request responseString];
}
I have created a library which can download JSON data which is then placed into an NSDictionary. I wrap this class with a simple Twitter engine which allows me to pull my friends timeline, post an update and post an update with my GPS location. From my limited experience with Objective-C the way to connect everything is with delegation. I set a delegate property which calls back the asynchronous result to either a selector or a method signature. I can even create an optional or required interface on the delegate which will allow Xcode to assist me a little with implementing the delegate. To learn about using delegates in Objective-C I created this simple project.
http://www.smallsharptools.com/downloads/ObjC/Delegates.zip
It defines a Worker class which allows you to initialize the class with a delegate. When the work is done with the doWork method it looks for a method signature on the delegate to send a message back to it. It uses the following code.
if([[self delegate] respondsToSelector:#selector(workFinished:)]) {
NSString *msg = #"That's it? Easy!";
[[self delegate] workFinished:msg];
}
It looks for the workFinished: method to pass back a message. I declared this method signature as an optional interface with the following code in the header, Worker.h.
#protocol WorkerNotifications
#optional
- (void) workFinished: (NSString *) msg;
#end
You can see the rest of the project from the download for all of the details. But these 2 code snippets show how this delegation pattern works. But with the Twitter class I need to know the context of the method which started an asynchronous action which leads to a callback to a delegate method. If I call the sendUpdate method more than once from the calling class, how I am supposed to know the context of the callback?
Normally with a language like JavaScript, Java or C# I would create an inline closure or anonymous class which would have access to the starting context, but that is not possibly currently with Objective-C on the iPhone. I found that this question was already asked and answered on StackOverflow.
Anonymous delegate implementation in Objective-C?
So what I have done is skip the optional interface and instead passed in a selector which the Twitter class will call when the asynchronous action is completed. A call to start this action looks like...
CMTwitterEngine *engine = [[CMTwitterEngine alloc] initWithDelegate:self];
[engine setSendUpdateFinished:#selector(sendUpdateFinished:)];
[engine setSendUpdateFailed:#selector(sendUpdateFailed:)];
[engine setParsingSendUpdateFailed:#selector(parsingSendUpdateFailed:)];
[engine setUsername:TWITTER_USERNAME pass:TWITTER_PASSWORD];
[engine sendUpdate:statusUpdateText.text];
This code first initializes the engine reference with self as the delegate. To attach the callbacks I send in selectors which I originally had on the sendUpdate method signature but the method calls got pretty long. I opted to simply set properties of the selectors. This all works but I am not sure I like how this is working since it only partially solves my problem.
To complete this example, I finish the asynchronous work and eventually call a method internally which looks for the given selector and calls it if it is defined.
- (void)sendUpdateFinished:(NSDictionary *)dictionary {
if (self.sendUpdateFinished != nil) {
[self.delegate performSelector:self.sendUpdateFinished withObject:dictionary];
}
}
I can pass in the status message to send as a Twitter update but I still do not have the context of the originating call. What if I want to call sendUpdate more than once and the first asynchronous call is still running? And what if the second call finishes first? They will both have self as the delegate so I would have to either track the context somehow or pass them to a different selector to distinguish them, which also does not satisfy my needs. What happens if I have 3 or 4 or 5 asynchronous calls? I need to know which ones were sent successfully and when they are complete.
It appears the only way that I can do all this is to create a class which holds onto all of the properties needed for the context, have that class act as the delegate for the call to the asynchronous Twitter method and then report back to the parent class which is likely UIViewController. I would take this approach but I have not read about this approach or seen any sample code yet which does this.
What would you do? How would you handle multiple asynchronous calls going out which could end in a different order than going out and then process them with context upon completion?
I think your situation is a great place to use NSNotificationCenter
http://developer.apple.com/iphone/library/documentation/Cocoa/Reference/Foundation/Classes/NSNotificationCenter_Class/Reference/Reference.html
I have to second (or third) the previously posted answers in that NSNotificationCenter is probably what you're looking for here.
Essentially one typically uses notifications when there are potentially many delegates all of which need to do something in response to a single action or event that has occurred. Think of it as a one-to-many sort of delegation or an implementation of the observer pattern. The basic things to know are:
NSNotifications have a name that you define which is just an NSString. Notifications can be posted by name and objects register to receive notifications by name.
When a notification is posted a notificationSender object and/or userInfo dictionary can be provided. The notificationSender is the direct way of determining who posted a given notification when it is being handled by the receiver. The userInfo is an NSDictionary that can be used to provide additional context info along with the notification.
So, rather than forcing all of the workers to adopt to an informal protocol and messing around with reflection style calling-methods-at runtime you just register instances of the workers with NSNotificationCenter. Typically the registration with the NSNotificationCenter is done in an init method of each worker class. Instances of each type of worker are then typically set up as "freeze dried" objects in a NIB or can be programatically instantiated in the app delegate so that they get registered with the notification center early on in the app's life.
When the thing occurs you post a NSNotification to the NSNotificationCenter (which is essentially a singleton) and then everything else that has registered to receive that particular type of notification will have the method called that was specified to handle that type of notification. When done these methods can then call a common method back on the sender (obtained via NSNotification's object method) to tell the sender that they've completed their work.
Once each known worker has checked in the the common method on the sender can then go on to whatever post-worker-completion code is to be performed.
One thing to consider is using Notifications instead. Simplifies code, couples things less tightly.