In detail view controller I have formlist. after fill that form I'm storing into array after Save Button click then I'm passing that array into MasterView and Showing Count Of Forms.
You should take a look on design patterns. In your above case delegation would be preferred. Notification is another option but it should be used for broadcasting a message.
objects receiving notifications can react only after the event has occurred. This is a significant difference from delegation. The delegate is given a chance to reject or modify the operation proposed by the delegating object. Observing objects, on the other hand, cannot directly affect an impending operation
You can read more about on design pattern and viewcontroller interaction:
How do I set up a simple delegate to communicate between two view controllers?
http://www.informit.com/articles/article.aspx?p=2091958
http://blog.shinetech.com/2011/06/14/delegation-notification-and-observation/
Related
I'm having a model that holds a bunch of items and sends an update notification when an item was modified. In this case there are two view controllers listening for this modification notification in order to update their state/(table-)views.
The problem is, that if one controller modifies an item it also receives the update notification and reloads it's content. But I don't want the controller who made the changes to be updated instantly, because it would interrupt the changes animation that the controller performs (because it knows what has changed).
Is there a good solution to only receive updates that weren't made by a specific controller? Or am I on the wrong path altogether?
Thanks!
You could try 2 different approaches:
First one is to use the "object" or " user info" information that you can add to a NSNotification object, send the view controller pointer and react on the notifications only when the object or user info is different than the object reacting to the notification.
The second approach is that you could remove your view controller from the NSNotificationCenter before performing the change, and adding it again afterwards.
In my application there are two view controllers that navigate to a DetailsViewController.
Right now, when the DetailsViewController appears, I fetch data from the server and display it on the UI. I dislike this because the UI is blank while the network request is going on. What I want is that the data be loaded in the previous view controllers and then passed to DetailsViewController.
Now the problem is that I have the exact same "load-data-and-then-push" code in two view controllers and I'm not sure what the most sensible way is to remove the repetition.
One idea is to have the two view controllers inherit from a common superclass which contains the loading/pushing method. I don't like this strategy because, supposing I have more ViewControllers like DetailsViewController down the line, I wouldn't like to write a loading superclass for each one.
Another idea would be to define a static method in the DetailsViewController which the two view controllers can invoke but this method contains UI related code (specifically, code to show an HUD Progressbar and a UIAlertView in case network fetch fails) which makes me uncomfortable.
I am very new to iOS and Objective-C so I might be missing something simple and obvious.
My favorite would be in this case to create a new class which handles the loading of the data (like http-request, etc.) and to create a delegate protocol for this class. This delegate callback might then be implemented in your two viewControllers which would then perform the push segue to your DetailsViewController when called. Delegation is a very nice and powerful feature, check out the documentation here: Delegation
Well, I'd better write it in the comments, but I have no reputation for that.
Imagine you are reading a json with several students information (name, year, etc.)
you can create a student object with the property that will be read and an object that will have a method that will run in the background that will be responsible for accessing your WS (JSON or whatever it is) and record this information to the student object. So if you have 10 students you will have an NSArray containing 10 students. This array is what you will for your next viewcontroller.
It is a lot of code, but you think examples easily.
If you use Storyboards you can use prepareForSegue: sender: to pass your data/model class to your DetailsViewController. If you use xib's you can do the same after instantiating the DetailsViewController and before pushing it.
If you need to load subsequent data from your server you should write a class that does this network stuff for you.
If DetailsViewController needs to load some additional data, you can use something like a loading view like Andy suggested. This is a widely used method.
I have an app that has a containerView that changes its view based on the clicking of one of three different tabs. Each tab contains different pieces of contract data.
It's now come the time for me to get ALL of the data from those tabs but I'm not sure the best method. Delegation is 1:1 and therefore I don't think would work as I can't be sure that each tab has been loaded. Same goes for the NotificationCenter as each has to register as an observer.
I've considered iterating through each and passing the message "view", this will verify each has been loaded, then firing off a Notification or while inside of each view calling a method to get me the data I need so that I'll end up with one large dictionary of values.
Any other ideas or commentary on my possible solution?
Let me know if more details are needed, this was a poor design from the start but I was required to implement it like this as the clients had approved the design BEFORE I started at this company and it took them several weeks to approve anything.
I've solved the issue of every subchild not being visible by calling [subviewName view] to assure that viewDidLoad was fired. Inside viewDidLoad I register for the notification, now I've assured that each view can create a dictionary and pass back it's information to the parent.
As an exercise I am working on a simple drawing app for the iPad.
I am using UISplitView, with the drawing view as the detail view. In the master view controller I present (in a table view) a list of the shapes drawn so far.
The user can edit or delete any shape from the master view controller, and also select and edit a shape by touching it in the detail view controller.
To notify each of the view controllers of the changes made by the other, I thought of using delegates, but I am not sure if this is the right pattern to use.
First, as I understand it, delegates are supposed to be used when a certain object encounters an event which they don't know how to handle. in that case they pass all the information to the delegate and let it handle the event. This is not the case here since both view controllers need to do something with the information. Using delegates here can cause code repetition.
Another reason I am thinking not to use delegates is that in the future I might want other view controllers to get the information of changes in the drawing. I can use multiple delegates (is it good practice in general?) but I'm not sure this is a good solution either.
Are there other solutions I should consider?
On the contrary, I think delegates might be the right pattern to use here - you don't necessarily delegate only when you can't handle an event (though that might be one situation where you would delegate).
Instead, consider delegates a way of getting information to or from another object, when you simply don't know what that object might be. For example, Apple uses the delegate pattern when working with UITableViews; in that delegate protocol, the table view knows perfectly well what to do in each situation, but still notifies your code when certain actions are about to happen. I think that's an excellent parallel for your situation. (Note that a parallel to your question's assumptions also exists, in the UITableView "data source," where the table view does require some bits of information.)
Another technology you could consider using, if you're really dead-set against delegates, would be to use notifications. You can have each controller subscribe to particular notifications, then have your shape (or detail view controller) post instances of NSNotification when observable changes happen. That way, you still get to handle events happening in a different controller, but without needing to maintain a delegate list.
As for code duplication, just consider refactoring as you start encountering situations where you would duplicate; maybe you should design a single delegate or notification subscriber object for the common code, then only do class-specific things in each of the other controllers?
I have been learning about Delegation and Data Sources for iOS programming and need to ask, is there any differences that you need to do when you make a data source protocol than a delegate protocol?
Also how can I implement a delegate for many same objects in one delegate? Example one object with many unique custom alerts.
--Edit--
An example for the second part:
One object that has four different alerts each with different buttons. Since object needs to dictate how each button works by being a delegate for the alerts. How would I set the delegate methods to determine each alert?
Both types of objects more or less behave the same way, it is a matter of what they do that is the question.
A delegate type object responds to actions that another object takes. For example, the UITableViewDelegate protocol has methods such as didSelectRowAtIndexPath for performing actions upon a user selecting a particular row in a table.
Whereas a data source type object gives data to another object. For example again, the UITableViewDataSource protocol has methods such as cellForRowAtIndexPath and numberOfRowsInSection dictating what should be displayed in the table.
There is no hard difference between the two in terms of compilation, it is simply a coding style to make what objects do what very clear to the user of the code.
EDIT:
To answer your second question: if you want each alert to respond differently, you will need to write a different delegate for each alert. For example, if one of your alerts is a save confirmation alert (perhaps you are going to overwrite a file, and it pops up to confirm thats what the user would like to do), you would have an object such as:
#interface SaveConfirmAlertDelegate : NSObject<UIAlertViewDelegate>
#end
And in the #implementation for SaveConfirmAlertDelegate you would implement the proper save feature depending on which button the user pressed in the alert.
When you create an alert view, you specify what the delegate object should be, this does not have to be self. You could have your four delegates stored as different objects and set them on the alerts as necessary.
I hope this clears things up