Cole's Huginn

This tutorial picks up where our last tutorial on TableView Basics left off. Now that we have one, it’s time to start editing, deleting and moving things around. Again, we’ll have our starter project and our completed project downloads. For additional reading, you can check out the Apple guides on this.

First off, we can lose the button off the cell. Go to the storyboard and delete it. Move our label to the right a little bit, because we will need room for editing buttons later. Delete the button code we had in the delegate method in RootViewController.m:

Editing Mode

To do editing, you place the table view in editing mode, which is done through another UITableView delegate method:

Run the project, and select any row. You should see delete buttons for each row. We can try to delete all we want, but nothing will happen until we use another delegate method

Deleting

The default editing style of any cell is deleting, so we’ll start with that. Let’s add a new UITableView delegate method.

There are three important steps, identify the edit type, update the datasource array, then update the table view. Run the project, and delete away!

Inserting

Inserting is just doing the opposite, and of course, we need another delegate method. Alter RootViewController.m to the following:

Run the project and start adding. Real world projects typical use an add button and some kind of modal to add whatever you want to add to the data. Usually it’s a simple append, or it may get resorted. The best use of UITableViewCellEditingStyleInsert is if you want to insert data in between two particular rows. The point here is just to show the insert edit mode in action. To change it back to delete, simply comment out the entire

editingStyleForRowAtIndexPath method.

Moving

Another typical editing type is moving data around the list to reorder the items. To enable moving, we’ll add two more UITableView delegate methods.  Here’s the code:

First, we end up in edit mode by selecting the cell. The default for moving is NO, so we want to return YES instead. The moving of the items in the table view will happen on its own. However, we must update our datasource to show the reorder.

Notice we get a copy of the data in our array being moved, delete the object from the array, and insert the copy back into the array. Again we take ourselves out of editing mode at the end of the move. It is common to instead just stay in an edit mode and do many steps and have a “Done” button to stop editing. This method usually has a table view reload. It’s your choice. In our example, if you want to see the data changes, simply put a breakpoint in the

moveRowAtIndexPath method and observe the array.

Run the project. Once a cell is selected, the cell will show the drag handle on the far right of the cell. Hold this handle, and in a moment it will pop up slightly.

Conclusion

In order to edit a table view, simply put the table in editing mode. Then use the appropriate combination or UITableView delegate methods to control the editing.

In this tutorial, we’ll show how to pass data from a view controller to a popover, and have data passed passed back from a button click, as well as dismissing the popover. The benefit is that it allows you to programmatically save or alter data, and pass it back. This is in contrast to a popover being dismissed by merely tapping outside the popover area of the screen. These are typical elements that would be used together for an iPad or Universal project. Since popovers are not available to iPhone (as of iOS 6 anyway), this would be used with an iPad storyboard.

I’ve posted the project files for starting, and the completed final.

Starting Point

The project starts with an iPad storyboard. The initial view controller is a UIViewController called RootViewController. It already has connected IBOutlets for a UITextField and a UIButton. There is a another UIViewController called PopViewController, which is the popover. A segue has been created from the button in the RootViewController to PopViewController. There is a UITextField and a UIButton on the popover to send back to the root, which are connected outlets. The view controller class files have been created and connected in the storyboard.

Segue Identifiers

It’s important to always give a name to your segues, as it is common for one view controller to have multiple segues. When doing segue delegation, you want to manage which segue, and differentiate which code goes with what segue. In the storyboard, select your segue, and go to the Attributes Inspector. Name the segue “segPop.”

Setting IBActions

The first thing we want to do is create IBActions for the buttons. In PopViewController.h, add a new function at the bottom.

Now connect the button click to the IBAction. One way to do this is to go to the storyboard, select the button in the Document outline, and ctrl-drag to Pop View Controller. Select the inaction goBack.

You can always go to the Connections Inspector to see (or set) your connections.

Delegation

Delegation is a programming pattern that allows an object to work in coordination with another object. A delegate will receive event messages, or callbacks, from the delegating object. Using delegation is so common in iOS development, that understanding it is a requirement.

Creating a Protocol

In order to do a delegate callback function, you need to establish a protocol, which will outline what callbacks are available. In PopViewController.h, add some protocol lines.

It is good practice to name your delegate as “<classname>Delegate”, making it easy to understand to code. In protocols, methods can be required or optional. If your class implements a delegate protocol, and does not include a method to handle the callback, Xcode will give a warning that the implementation is incomplete.

Creating a Local Delegate

The calling object needs to set itself as the delegate in the delegation relationship. We’ll establish a property to hold this. Back to PopViewController.h:

The property is set to a weak reference, for ARC compliance, and good memory management. Because this property stores a reference from a different class instance, if t gets destroyed somewhere else, this instance can free the memory. Make sure to synthesize any properties you add, so in PopViewController.m:

Sending a Delegate Method

Now that we have a property to store the delegate, we can add the code to send a delegate event. We’ll do that in our IBAction of the button in the popover. Add a line to our goBack function in PopViewController.m:

This code is going to take the text of our UITextField and send it back to the delegate, which is our RootViewController. Remember that delegate is an id, or pointer, back to the RootViewController instance. This tells us where to send the delegate message.

Preparing for Incoming Data

In order to prepare to receive data from RootViewController, we want to add a string property to receive the data, as the segue will not have direct access to the UITextField. In PopViewController.h, add the following:

Make sure to synthesize in PopViewController.m:

Since PopViewController is a UIViewController, it is automatically able to do its own delegate methods. We want to add one to PopViewController.m:

Becoming a Delegate

Go to RootViewController.h, and add the following:

First, you must import the header file, which is how to reach the delegate protocol. This will help code completion make this easy. We want to be sign up for two delegate protocols. The second one is so we can receive callback messages from the popover. Second, we have an implementation in RootViewController.m to receive the callback:

This function allows us to capture and display the data string sent back from the popover via delegation.

Managing the Popover

We want to be able to send data to our popover, as well as be able to programmatically close our popover, so in RootViewController.h, add some properties:

Synthesize them in our implementation RootViewController.m:

Passing Data in a Segue

Since we signed up for the popover delegate protocol, we want to implement the prepareForSegue function. Add the lines:

In this code, we are looking to make sure that we have the proper segue, which is why we set its identifier property in the storyboard. Next, we want to keep a pointer to the popover segue, so we can dismiss it after we have processed the delegate callback data. We also want a pointer to the view controller that is the popover, because we set ourselves as the delegate. Without setting the delegate, the delegate callbacks would go nowhere. Lastly, we want to pass data into the PopViewController,which allows us a round trip of data back and forth from both objects.

Dismissing the Popover

As the final step, we want to add a line of code to our delegate callback function in RootViewController.m:

The final line uses our pointer to the segue, so we can have the popoverController dismiss or popover instance. Notice we do not send anything to the PopViewController instance. When we created a segue that was of type popover, a popoverController was automatically created for us, and that is what want to access to do the actual dismissing.

Using Data Passed via Segue

Now that we have data coming across the segue, we want to use it in our popover. In PopViewController.h, we want to add  In PopViewController.m, add the following UIViewController delegate function:

Conclusion

Run the project in the iPad Simulator, and you should be able to pass data back and forth between the text fields. The button on the popover should also dismiss the popover. Okay that was a lot of steps, but you can pass data from segues, delegate callbacks, and control your popovers, all at the same time.