Long time reader, first time poster here.
I'm creating a test app that creates a NSURLConnection and then displays the result on an UILabel.
I am presently using a Notification Center observer, which fires a notification from within connectionDidFinishLoading to wait for the connection to complete successfully, before I look for the result.
However, what I am struggling to conceptualize is where to store the response data so that I can access it from my View Controller and post the result to the UILabel. (Or from anywhere other than an instance of my Connection Class, for that matter.)
I don't want to post directly to the UILabel from connectionDidFinishLoading. I need a way to decide what I will do with the response later - so my Connection Class stays generalized.
I need a better way to save the response data somewhere, where I can reference it after the instance of the Connection Class has terminated.
Ideally, it should be somewhere that I can have multiple instances of the Connection Class open, and access each response in turn as I need them. This eliminates the potential to just create a variable in my View Controller or somewhere else more global and dump the response to it.
Any ideas on what design patterns could/should be used here would be greatly appreciated!
My suggestions for you to start with are :
Make a singleton class. I will have a property NSDictionary * info or NSArray *infoList; You will have acces to the same data from wherever the app. Update the property, post the notification, access the property from the viewController.
Store the info into a plist/file. Serialize the information, or save plain stream. Whatever you like.Thus after you finish writing to the file, post the notification, read from the file from anyplace within the app.
In both cases if you want multiple connections i suggest going for the factory design Pattern.
Related
I'm working on an app for iphone where I load a JSON from a php server, parse it with a library and create an object with this data. My code works fine but the way I do it seems wrong to me:
A viewController shows to the user a loading view. Meanwhile the ViewController makes the get request and receive the data.
The VC parse the response and get a dictionary
The dictionary is send to a "creator class" who returns a object created from the dictionary
I do two times this operation but I think it's a bad design:
Should a View Controller do a http request? Don't shoud be a "objectLoader"? The main method of creation class makes a big bunch of if/else spaghettis, like:
for(NSString key in dictionary){
if(key isEqualToString "a key"){
perform action
}
else if(key isEqualToString "an other key"){
perform action
}
....
}
Any idea to solve that? I was thinking about make a dictionary of keys/selectors to solve it and do something like:
for(NSString key in dictionary){
[self performSelector:[selectors getObjectForKey:key]]
}
But I don't know if I can reference a selector in a dictionary...
Finally the other option that comes to me is send the parsed dictionary to the object with a class method like: [ClassName createObjectWithDictionary:parsedDictionary]. That's a good way to do it?
I know the question is a little ambiguous but I'm a little lost in what Design patterns I should apply and who is responsible of what in this story
the best way is to use MVC pattern and have model with data that has methods to push and remove some data inside it and a list of delegates (derived from UIViewController) which are notified in case of changed model data.
Controller (not UIViewController) is something that initiates fetching data from server and handles results.
And all of UIViewControllers handles data changes and user interaction.
For now, write some RequestController (singletone or not, doesn't matter) that handles request routines and stores all necessary data to trigger events in controller.
You can use blocks or NSNotificationCenter to handle request's completion.
After getting necessary data through RequestController from request, your Controller can create necessary parsers and push parsed data into model.
Personally, I would NOT let the ViewController do the HTTP request. I always write service classes in my apps, that do the low level stuff and inform the caller (e.g. a view controller) via delegation on any received result.
So the control flow in that case is:
-> ViewController locks screen with loading message
-> calls service with itself as delegate - the service does the work and receives the answer -> the answer is processed and the result passed to the delegate
-> the ViewController takes the response, removes the loading message and does whatever is necessary with the response.
Concerning your second question: yes, it is possible to dynamically chose a selector out of a dictionary - e.g. by storing the selector's name in the dictionary and then use
SEL selector = selectorFromString(#"doWork");
to create the right selector to call.
How would you solve this? When the app starts, four objects of a class are created. These objects have names you know because you named them yourself. From a viewController you can access these objects and call a method (which they all got) which creates a UILocalNotification. (So in the end you've got four notifications running.)
Two questions:
How do you name the notifications (differently)? As far as I know is it not possible to access the object name to use the string as name when creating the notification? (Which would be the best solution?)
When the notifications are fired, how do you access/cancel them from another viewController when you don't know the names?
Thank you!
Set tags for all objects, and set same tags for notifications, they generate.
I have some NSManagedObject subclass in my app, and I'm trying to understand when and how to save changes.
I will try to explain myself, for example class A is NSManagedObject subclass.
During app life cycle I do:
App launched
...
Create an instance of class A
...
Change some properties of A instance
...
App go to background
...
App becomes active again
...
Change some more properties of A instance
...
App terminates
When do I need to call [context save:] ??
Do I call it after every change in A instance? Or maybe I call it only when app go to background?
Should I call it after creation or deletion of any A instance?
A nice approach is place UIManagedDocument in your AppDelegate. Then you can call [context save] whenever some change occurs in the app (like a crash). The order I like to follow is something like:
Create UIManagedDocument object (in application did load or wherever)
and assign it to a property
Setup the document (check whether it exist on disk or is already open, etc.. and respond accordingly)
Pass the UIManagedObjectContext to the initial UIViewController in your app (from there you can pass the context to other view controllers)
UIManaged document will save the context for you.
Take a look at the UIManagedDocument documentation to configure persistent store options (you send an NSDictionary of options to your UIManagedDocument instance, see the first example through the link below).
UIManagedDocument documentation:
http://developer.apple.com/library/ios/#documentation/UIKit/Reference/UIManagedDocument_Class/Reference/Reference.html
Also see the CoreData lecture and demo (lectures 13 and 14) of the iPhone and iPad application development course with Paul Hegarty available free on iTunesU (Fall 2011).
The data will not be saved to the persistent store until you call save. So, it depends on what you want in your app. If you want it to be able to recover the last value it ever had, then you should save after each modification.
Easy change is to just save after making modifications.
You could do something a bit more fancy, like only save after some set amount of time, so many changes are grouped together... and catch any event that will put your app in the background and then save...
But, that's what UIManagedDocument does automatically for you, so you could just use that instead.
Depending on the amount of changes that you make and the volume of data that needs to be saved with each change, yo can choose to save a little or a lot. If you are just saving a string or a number or a bool, then go ahead and call save: on your context as soon as the changes were made.
If it is a lot of data, you may want to coalasce your changes and then save it on a background queue so that you are not blocking the main queue. This way you are not waiting to go to the background to perform your saves.
Tim
I've successfully implemented a NSDocument class in my Cocoa App which is also able to save data properly. But I have problems when it's about opening files.
This is my basic setup:
NSDocument MyFile ==xib File=> MyFile.xib
NSObject FileClass as processing class
FileClass is a class that compresses/decompresses files and is connected to the window's textfield in MyFile.xib. Saving is done via the default NSNotificationCenter. The data needs to be processed in this class because it does not contain raw NSStrings.
Let's say I have three documents that need to opened I have three NSDocument instances that now send their data via the NSNotificationsCenter. Because I have three NSDocuments I have three windows and three FileClass instances. Now it's just luck if the correct FileClass receives the data because I have no possibility to filter whether the received data is proposed for this window. A random FileClass now processes the file and sets the text of its associated Text View. So Window 1 could show the data that were thought to be shown in Window 3.
The data flow:
NSDocument => readFromData => NSNotificationCenter => random FileClass => associated TextView.
To narrow it down: How do I route the data to its correct window and how/where do I include FileClass in this construct?
Thanks in advance!
Paul
It's an indication for a major design flaw if you have to force your document data through the notification center to your viewing classes. Why do you have to do that? What issues are you trying to circumvent?
I'm working with a document-based core-data OS X application. The problem I'm having is that whenever I edit any field on the document, after I press tab or click to something else (i.e. I finish editing/change focus), the document is marked as clean and undo is reset. When I try to save the file, however, the resulting document opens without the data I entered. What might be the problem, or, any pointers on where to look to fix this? Here's some stuff I know and things I've already tried:
I know it's not somehow saving because it never stops at the breakpoint in my overridden writeSafelyToURL:(NSURL *)inAbsoluteURL ofType:(NSString *)inTypeName forSaveOperation:(NSSaveOperationType)inSaveOperation error:(NSError **)outError and it also never sends an NSManagedObjectContextDidSaveNotification.
The documents are packaged in an NSFileWrapper directory with the core data store inside (and also some other files). I access the entities through an NSObjectController and a couple NSArrayControllers. It happens with both core data properties and manually registered changes in the rest of the file wrapper.
Update: At the suggestion of Martin, I tried NSUndoManager's notifications, and all I can seem to glean from it is that more than one undo manager is in play. If I add an observer for NSUndoManager, it won't post if I specify an object, and then if I don't, the notification object is not equal to [self undoManager]. I added updateChangeCount to my category on NSPersistentDocument, and it never gets called. setDocumentEdited basically confirmed that something about losing first responder is passing NO into that method. What could be causing this, and how can I fix it?
You could break on the method setDocumentEdited: of NSWindow to see which operation updates the change status.
In addition updateChangeCount: of NSDocument might be a place to take a look at.
NSUndoManager also posts several Notifications which can give additional hints what to look at.
The answer is actually pretty silly considering how long this stumped me. I was working on some objects on load, and I accidentally set [[self undoManager] disableUndoRegistration] at both the points where I should disable and enable. It was a little more than that, though. A related element in Interface Builder needed to be checked Prepares Content. When I had done both those things, the problem vanished.