I am using CoreData in iOS.
I have a modal AddViewController, with a RootViewController as the delegate.
Should I do the saving of the managed object context in the root controller, or in the actual modal controller itself?
I am seeing examples of passing the data back to the rootViewController, but can't see how this will work with data validation failures, or more complex scenarios that need the managed object context.
// AddViewController.m
- (void)save
{
[[self delegate] controller:(id)controller didFinishWithSave:(BOOL)save withName(NSString *)name;
}
// RootViewController.m
- (void)controller:(id)controller didFinishWithSave:(BOOL)save
{
if (save)
{
// save context
}
[self dismissModalViewControllerAnimated:YES];
}
As at the moment I am dismissing the modal using the delegate protocol.
Any advice on the best practices?
Thanks
I know this is a little late, but for others who come across this, I'd add a little more to Levend's answer.
Yes, you should have a separate manager class to handle the operations (possibly the class itself).
I would think that if your modal needed to handle validations, before calling on the delegate, it would validate the object. If it had an error, you could handle it right there. If it passed validations, then you could pass the valid object to the delegate. Thus the delegate can make the assumption that any object that is getting passed to it is a valid one.
As to which class you should save it, I think that is just a preference thing. But I would suggest you have a save method in the core data model itself.
Something I came across recently is the mogenerator which is supposed to help with managing CoreData classes. I haven't tired it yet, but it sounds good.
From an architecture point of view, you should create a separate manager class responsible for core data operations. From technical point of view, it isnt matter where you save(root, or modal VC) as long as you do it on the same thread where the data origins.
With MVC in mind I would let the M(odel) perform saving of the context as well as fetching data from it.
Related
OK, here is my situation and I'm really not sure on which design approach to use. So, I'd be glad to read some input on my particular case...
The scenario :
I've got a tab-based application
Initially we create an instance of NSWindowController (e.g. MyDocumentManager) which takes care of the tab creation/manipulation
Each tab contains (= is attached to) an instance of MyDocument
Now, I'm about to implement the menu actions.
For each menu there is a separate Menu Controller (actually a subclass of NSObject grouping all relevant functions), e.g. MyFileMenuController
File Menu's actions are linked to actions in a MyFileMenuController object, via Interface Builder
The question :
How is it possible that MyFileMenuController "knows" about MyDocumentManager (created in my AppDelegate.m), so that we can access current document details and perform all relevant actions? Any ideas? Which approach is preferable?
My ideas :
Passing object from class to class (not sounding that great)
Singletons (although I've honestly never used them, and do not know whether/how it could be my particular case)
Notifications & Notification Listeners
(Looking at it from the opposite side, though not sure) Delegate methods
OK (not sure if that's the best way to do it), but this is what I decided to do :
[[[NSApplication sharedApplication] delegate] MyDocumentManager]
So, as long as an object is part of my AppDelegate, this way I can access it from anywhere.
I would make an initial UIViewController linked to appDelegate.rootViewController.
In this new view controller (just call it "mainViewController") I would put my tabBar and the menuController.
I understand your interface is similar to facebook with a leftBarbutton which makes horizontal scroll and discover the menu. So in the selector for this leftBarButton I would call a method like:
- (void)discoverMenuForDocument:(MyDocument*)document {
// Set menu configuration for specific document
// Make animation to discover menu
}
Where document could be something like:
self.selectedViewController (<-- You cand make this in several ways depending on your code...)
Realize that (MyDocument*) is not an object but just a reference, so in my opinion there isn't any problem doing this.
Good luck!
I am building a core data application that checks for a saved user login upon launch and sets up the model, store, coordinator and context afterwards. The only problem I have is that as soon as the user clicks on any view in the interface, the application tries to get the managedObjectContext causing an exception seeing as I haven't created the stores yet.
Is there any way to stop it from doing this?
Cheers.
If you're using the Coredata boiler plate stuff provided by Apple, you will notice the managedObjectContext object is loaded lazily when its property is accessed.
Simply tell your view controller to access the context via its property (i.e. self.managedObjectContext) instead of accessing the variable directly, and the context, object model and persistent store coordinator will be created appropriately.
PS: This is just a guess as you didn't post any of your related code here.
Why are you showing views that depend on the managed object context without either creating it already or arranging for it to be created on access?
The usual pattern is to have your managed object context getter look something like this:
- (NSManagedObjectContext *)managedObjectContext {
if (!_managedObjectContext) {
// create context, and store it in _managedObjectContext
}
return _managedObjectContext;
}
(in this code, _managedObjectContext is an ivar in the class to hold the context). That way the context gets created automagically when needed. Apple's standard sample code does just this for you.
I'm having trouble referencing one view controller from another. The code works but I get warnings which makes me think I'm going about it wrong. I'm trying to reload the data in a tableView whose controller is in a NavigationController.
What's wrong with a message like this:
From the AppDelegate:
[self.tabBarController.selectedViewController.topViewController.tableView reloadData];
Although this works, I get the warning request for member 'topViewController' in something not a structure or union because Xcode doesn't know that the selectedViewController will return a navigationController. So I could do the following:
UINavigationController *myNavigationController = self.tabBarController.selectedViewController;
[myNavigationController.topViewController.tableView reloadData];
But then I get this warning: incompatible Objective-C types initializing 'struct UIViewController *', expected 'struct UINavigationController *'
How far do I have to go with this? The first line works. To get to the "right way" is it gonna take 8 lines of code?
A major code smell here, IMO. You're trying to do action at a (great) distance. It's not exactly clear what you're trying to accomplish, nor why you need to do this action from the app delegate. I have seen some developers treat the app delegate like a giant catch-all global lump of mud, and I think this is an anti-pattern that should be eliminated from iOS development.
Back to your question: you're trying to force a table view controller, inside a tab view controller, to reload its data. I'm assuming this is in response to something happening. Why not have the view controller in charge of that table watching for that event instead of the app delegate? That way, the thing that owns the table view is directly controlling it -- which is the entire point of the MVC pattern. This is a much better approach than having the app delegate drill down through a hierarchy to find a table view... in terms of complexity, readability, and brittleness.
If, for some reason, you can't or won't have that view controller observing for the event directly (hard to fathom why offhand), you could always have the app delegate post an NSNotification and let the view controller in charge of the table register as an observer for it. Not as good as direct observation, but definitely better than your current approach.
You can't use dot-notation unless the compiler knows what type of object you are using it on, and that that object type can receive a message with that name.
You can use dot-notation with a bunch of type-casts (which in this case, is hideously ugly):
[((UITableViewController *) ((UINavigationController *) self.tabBarController.selectedViewController).topViewController).tableView reloadData];
Or you can break it up into discrete steps:
UINavigationController *navController = (UINavigationController *) self.tabBarController.selectedViewController;
UITableViewController *tableViewController = (UITableViewController *) navController.topViewController;
[tableViewController.tableView reloadData];
Note that I'm assuming that your top VC is a sub-class of UITableViewController.
You really shouldn't be accessing the .tableView property externally - you should encapsulate that behaviour with a reloadData method on the View Controller itself. Even if all it does is call reloadData on its .tableView, you should encapsulate it. This will make your code more modular (which makes it easier to understand for you and others), and make it easier to expand on and add complexity to your View Controller down the track.
Without knowing exactly how this app is structured, I would guess that you're probably better off using notifications or observers to get your VC to reload its data. If you have some global event that requires a UI refresh, an NSNotification is a good way to make the UI layer get the message while keeping your code nice and modular.
Can you refer to the sender of a message without passing the sender as a parameter?
This is simplified code for the sake of discussion:
// mainTableViewController.m
[dataModel loadData]; //Table is requesting data based on user input
// dataModel.m
-(void) loadData{
// I want to store the sender for later reference
sendingTableViewController = ???? ;
}
- (void) connectionDidFinishLoading:(NSURLConnection *)connection {
// Web data is loaded. Ask the sending tableViewController to
// reload it's data.
[sendingTableViewController.tableView reloadData];
}
I'm still getting used to how to refer to methods and properties that are the responsibility of another object. I want to send a message to dataModel to load some data using NSURLConnection. But I don't just want to return the data because I don't want to sit around waiting for the data to load. I want to send a message to the mainTableViewController once connectionDidFinishLoading is called.
Since the loadData method may be called from any number of tableViewControllers I can't just say [mainTableViewController reloadData].
Follow-Up Question
Great Information! I love the no-judgement nature of StackOverflow.
So the mainTableViewController would be the Delegate of the dataModel?
Would it be correct to say that the dataModel class defines the informal protocol?
I currently instantiate my dataModel class from within my mainTableViewController. So I could change my code like this:
// mainTableViewController.m
dataModel *myDataModel = [[dataModel alloc] initWithDelegate:self ];
// Does this method need to be defined in the mainTableViewController header file
// since I will already have defined it in the dataModel header file?
-(void) dataDidFinishLoading {
[self.tableView reloadData];
}
// dataModel.m
-(id) initWithDelegate:(id)aDelegate{
self.delegate = aDelegate;
}
-(void) connectionDidFinishLoading:(NSURLConnection *)connection {
[self.delegate dataDidFinishLoading];
}
Is it bad that my TableViewController is instantiating my dataModel, cause then my dataModel is owned by the TableViewController? Should I really instantiate the dataModel from the AppDelegate instead?
Thank You!
I daresay this isn't the correct way to think about the problem. Architecturally, by giving the data model knowledge of the table view controller, you are coupling your model layer to your controller layer. Violating separation of concerns is a bad thing.
In Cocoa, the use of delegate objects is used all over the place. A delegate object is an object that implements a particular protocol with callback methods that can be called when things or events (such as data loading from a remote location, in your case) occur. I recommend that you create a delegate property in your data model, have an interface that mainTableViewController (or any other class, really) implements, and assign that class as the delegate. Then, when the data is finished loading, call the appropriate method on self.delegate. In that callback method, you could then call [tableView reloadData].
Again, you do not want your data model to be coupled (meaning aware of) the existence of your controller classes.
Edit
I just re-read the last part of your question, about having multiple table controllers needing to listen for notification of the data being finished loading. For that, I suggest you use the Observer pattern in Cocoa by using NSNotificationCenter. You use use the notification center in the data model to send notifications to observers (you don't care who is observing; the notification center handles those details) and you'd also use it in your table controllers to subscribe to the notification. Delegates are a nice, simple solution if you only need one object to be directly called when something happens. Notifications are more complex and have more overhead, but give you the flexibility to have an arbitrary number of objects "listening" for a notification to be posted.
Follow-Up Response
A class doesn't define an informal protocol; the developer does. You could also define a formal protocol in a separate .h file and have the controller implement it if you want an enforceable contract. With a formal protocol, you can also use #optional on methods that don't have to be implemented by a class conforming to the protocol.
It is also not at all bad to instantiate the data model from within the table view controller. In fact, this is one very correct way to do it. Since the data model exists to encapsulate data that (presumably) a controller will want to display later, you can think of the controller as owning the data model. You may even consider making an instance variable (and perhaps a property, too) to store your data model. Besides that, your rewritten code looks good to me!
Do you mean the keyword self?
-(void)canHazCheeseburger:(BOOL)canHaz
{
if (canHaz) {
self.cheeseBurger = [[[CheeseBurger alloc] init] autorelease];
[cheeseBurger onNomNom];
}
}
I have a MainViewController in my Cocoa Touch app which shows a status view containing a UIProgressBar view.
From the MainViewController, FlickrImage model objects are created and iterated over. the FlickrImage objects themselves interact with the Flickr API, which takes time which is why I want the user see the progress bar. The challenge (at least to me it is ;) now is to interact with the UIProgressBar (send progress messages) from the FlickrImage objects. Do I do this using a NSNotificationCenter or can I just declare the MainViewController as a forward class in FlickrImage and interact with the UIProgressBar directly?
The best way is to not have the model call anything at all, but use KVO to observe the model, and then react to the message you get when the model updates. This is because the point of having a separate model layer is that the model shouldn't have to know anything about how data is presented to the user.
So create a class that keeps track of the loading of all the images (most likely you already have such a class) and do something like:
[imageManager addObserver:self forKeyPath:#"progress" options:nil context:nil];
Make sure that the data manager class has a declared property called progress (ideally with values ranging from 0.0 to 1.0) and when you update the value in the manager, you must use the dot notation: self.progress = newVal;
This is much cleaner than sending notifications from the model class. An alternative would be to register the view as a delegate on the manager. There is no clear-cut rule of thumb for when you should use delegates and when KVO is better, although there might be slightly less overhead in using a delegate protocol. Apple uses both approaches but there is a tendency to rely more on KVO, which in my opinion is a good thing.
I prefer NSNotificationCenter, MainViewController register as observe and update the UIProgressBar.
keeping the object MainViewController in FlickrImage and updating UIProgressBar from FlickrImage which make handling UI from model(you are violating MVC)