UITableView on Andrew Bancroft

UITableView Swipe to Delete Workflow in Swift

Fri, 17 Jul 2015 04:00:18 +0000

Data management applications, by which I mean an app where you’re allowing users to add, edit, and delete bits of data as part of your app’s core function, very likely use a table view (or two) to visualize lists of information that users of the app can interact with.

Making changes to the information listed in the table view and signaling those changes in a fluent way becomes a top concern for these types of apps. How do we allow users to add or remove “records” to the system? Furthermore, how do we signal that those changes were effective and refresh the view of the data in the UI?

The primary concern I want to focus in on in this article is the ever-common paradigm of “swipe to delete” when using a table view. What could the workflow of deleting a row from the table view (and its data source) look like? How could it be implemented in Swift? Let’s explore…

Workflow

The workflow of “swipe to delete” that I typically use in my own applications is this:

Swipe a table view row and have the Delete button appear.
Press the delete button, which triggers a confirmation: “Do you really want to delete this?”
Based on the user’s response to the confirmation, delete the object from the data source and remove it from the table view, or cancel.

The confirmation step is atypical for iOS it seems. Swiping to delete an e-mail or a reminder or just about anything else in Apple’s own apps simply deletes the item right away.

There may be a good reason for this, but I like to give folks an out if they didn’t mean to do it. It’s fair enough to say, “Well, they went to the effort of swiping the row and pressing the button… surely they mean to do it!”. I still feel more comfortable if I get the opportunity to cancel something like a delete operation. Feel free to disagree there – for this article, I’ll assume you want to include that into your delete workflow, and will demonstrate a simple way to implement all three steps of the strategy.

Implementation

To demonstrate the implementation of this workflow, suppose that we’ve got a table view listing out all of the planets in our solar system (all of the news on Pluto this week has me thinking in this direction, so I just went with it). Feel free to grab the example project over at GitHub:

Resources

Swipe to Delete Example

The table view looks like this once its data source is all configured:

Swipe

What we want is to be able to swipe one of the rows and delete the planet from the data source and, consequently, remove it from the table view in a nice, fluid way:

To accomplish this, we need to do a couple of things.

First, your view controller needs to conform to the UITableViewDelegate protocol, because the swipe to delete functionality is encapsulated by one of the table view delegate methods. It’s a simple change at the class declaration:

class ViewController: UIViewController, UITableViewDataSource, UITableViewDelegate { ... }

The delegate method that causes the buttons to appear on swipe is called tableView(_:commitEditingStyle:forRowAtIndexPath

Its implementation for the example I’m working through looks like this:

 1class ViewController: UIViewController, UITableViewDataSource, UITableViewDelegate {
 2
 3    // ...
 4
 5    var deletePlanetIndexPath: NSIndexPath? = nil
 6
 7    // ...
 8
 9    func tableView(tableView: UITableView, commitEditingStyle editingStyle: UITableViewCellEditingStyle, forRowAtIndexPath indexPath: NSIndexPath) {
10        if editingStyle == .Delete {
11            deletePlanetIndexPath = indexPath
12            let planetToDelete = planets[indexPath.row]
13            confirmDelete(planetToDelete)
14        }
15    }
16
17    // ...
18}

So what’s happening here? The primary thing to notice is that we’re evaluating the editingStyle from the method’s parameter list. Comparing it to the .Delete UITableViewCellEditingStyle value is what allows us to know that the Delete button was tapped.

Since I have a confirmation step to take care of, I’ve chosen to store the indexPath of the row we’re wanting to delete in a class-viewable variable so that I can use it later on when we handle the deletion (if the user confirms it).

The final step of this function is to call confirmDelete(), which has its own explanation coming up…

Confirm

The next step is confirming that the user really wants to delete the particular planet they’ve initiated the delete action on:

How is this implemented? It all boils down to using iOS 8’s new UIAlertController:

 1class ViewController: UIViewController, UITableViewDataSource, UITableViewDelegate {
 2
 3    // ...
 4
 5    func confirmDelete(planet: String) {
 6        let alert = UIAlertController(title: "Delete Planet", message: "Are you sure you want to permanently delete \(planet)?", preferredStyle: .ActionSheet)
 7        
 8        let DeleteAction = UIAlertAction(title: "Delete", style: .Destructive, handler: handleDeletePlanet)
 9        let CancelAction = UIAlertAction(title: "Cancel", style: .Cancel, handler: cancelDeletePlanet)
10        
11        alert.addAction(DeleteAction)
12        alert.addAction(CancelAction)
13        
14        // Support display in iPad
15        alert.popoverPresentationController?.sourceView = self.view
16        alert.popoverPresentationController?.sourceRect = CGRectMake(self.view.bounds.size.width / 2.0, self.view.bounds.size.height / 2.0, 1.0, 1.0)
17        
18        self.presentViewController(alert, animated: true, completion: nil)
19    }
20
21    // ...
22}

We’re asking the user if they’re sure they want to permanently delete the planet using the .ActionSheet style.

The next step of the function is to create a couple of UIAlertAction buttons: one for Delete and one for Cancel, with the appropriate style (.Destructive and .Cancel, respectively).

Finally, we provide a function to each UIAlertAction instance. The handlers, of course, could have been implemented with closures, but I chose to built out a couple of named functions, just to be able to step through it with you, and to separate out the logic of the steps a little more. Feel free to do whichever seems most natural to you.

Delete or cancel

This is the final step! The following code snippet is an implementation of the two handlers specified for the initialization step of the UIAlertAction buttons, which were handleDeletePlanet and cancelDeletePlanet:

 1class ViewController: UIViewController, UITableViewDataSource, UITableViewDelegate {
 2
 3    // ...
 4
 5    var deletePlanetIndexPath: NSIndexPath? = nil
 6
 7    // ...
 8
 9    func handleDeletePlanet(alertAction: UIAlertAction!) -> Void {
10        if let indexPath = deletePlanetIndexPath {
11            tableView.beginUpdates()
12            
13            planets.removeAtIndex(indexPath.row)
14            
15            // Note that indexPath is wrapped in an array:  [indexPath]
16            tableView.deleteRowsAtIndexPaths([indexPath], withRowAnimation: .Automatic)
17            
18            deletePlanetIndexPath = nil
19            
20            tableView.endUpdates()
21        }
22    }
23    
24    func cancelDeletePlanet(alertAction: UIAlertAction!) {
25        deletePlanetIndexPath = nil
26    }
27
28    // ...
29}

Clearly, handleDeletePlanet() is the most involved. The essential process is this:

Call beginUpdates() on the table view instance to signal the start of UI updates to the table view.
Remove the planet from the data source using the deletePlanetIndexPath we set in the alert controller step.
Call deleteRowsAtIndexPaths() on the table view to remove the planet from the UI.
Reset the class-viewable deletePlanetIndexPath to nil.
Call endUpdates() on the table view instance to complete the UI updates.

There’s one gotcha, that I’ve tried to highlight by way of comment in the code snippet: Notice that within the call to deleteRowsAtIndexPaths (plural), I’ve wrapped the indexPath we’re removing in an array. It’s subtle, but this delegate method expects an array of indexPath instances, not a single index path instance. It’s simple enough, but it can catch you off guard if you’re in the mindset of removing a single row and come across this method, which is flexible enough to allow you to delete several at a time.

Wrapping up

Swipe -> confirm -> delete or cancel. Those are the steps we analyzed in this commonly needed workflow in data management applications.

Sync Table View Data: NSFetchedResultsController and Swift

Fri, 29 May 2015 03:20:54 +0000

Updated on September 23, 2015 – Swift 2.0

My goal with this article is to help you utilize the full power of NSFetchedResultsController.

This is a continuation on a series of articles I’ve written on Core Data and NSFetchedResultsController, so you may want to check out those previous posts to get an idea of where I’m picking up in this walk-through. Previously I touched on how to seed a Core Data database, and how to take that data and display it in a table view with an NSFetchedResultsController.

As with the previous posts, I’m providing an example Xcode project over at GitHub, so feel free to follow along with the live working example:

Resources

Sync Table View Example Project

In this installment to the series, I want to answer the question, “How do I update the rows in a table view when I add or remove objects from the Core Data database?” I will show how to implement the NSFetchedResultsControllerDelegate protocol, which is the key to automatically synchronizing changes made to your Core Data persistent store with a table view.

Examining the NSFetchedResultsControllerDelegate protocol

The NSFetchedResultsControllerDelegate protocol is the piece of the puzzle that helps us update a table view with changes made to the Core Data persistent store. There are five methods that we’ll be taking a look at:

controllerWillChangeContent(_:)
controller(_:didChangeObject:atIndexPath:forChangeType:newIndexPath:)
controller(_:didChangeSection:atIndex:forChangeType:)
controller(_:sectionIndexTitleForSectionName:)
controllerDidChangeContent(_:)

The two methods that are responsible for doing the actual updates to the table view’s structure are controller(_:didChangeSection:atIndex:forChangeType:) and controller(_:didChangeObject:atIndexPath:forChangeType:newIndexPath:). If some of the changes to the table view result in new sections being created, controller(_:sectionIndexTitleForSectionName:) will help give it an appropriate title (and make sure the other sections keep their appropriate titles as well).

controllerWillChangeContent(_:) and controllerDidChangeContent(_:) help inform the table view that changes are about to happen / just finished happening. Sandwiching the primary “didChangeObject” and “didChangeSection” protocol methods with these two methods allows the table view to animate in all of the changes to its structure in one batch.

So, the general structure of the NSFetchedResultsControllerDelegate section of your source file might look like this:

 1// MARK: NSFetchedResultsControllerDelegate methods
 2public func controllerWillChangeContent(controller: NSFetchedResultsController) {
 3    self.tableView.beginUpdates()
 4}
 5
 6public func controller(
 7    controller: NSFetchedResultsController,
 8    didChangeObject anObject: AnyObject,
 9    atIndexPath indexPath: NSIndexPath?,
10    forChangeType type: NSFetchedResultsChangeType,
11    newIndexPath: NSIndexPath?) {
12        
13        // implementation to follow...
14}
15
16public func controller(
17    controller: NSFetchedResultsController,
18    didChangeSection sectionInfo: NSFetchedResultsSectionInfo,
19    atIndex sectionIndex: Int,
20    forChangeType type: NSFetchedResultsChangeType) {
21    
22        // implementation to follow...
23}
24
25public func controller(controller: NSFetchedResultsController, sectionIndexTitleForSectionName sectionName: String) -> String? {
26    return sectionName
27}
28
29public func controllerDidChangeContent(controller: NSFetchedResultsController) {
30    self.tableView.endUpdates()
31}

controller(_:didChangeObject:atIndexPath:forChangeType:newIndexPath:)

This is the method that governs how we want to handle the rows in a table view when the synchronization would require inserting rows, updating existing ones, removing them, or reordering them.

I’ll give you the implementation and then point out a couple of “gotchas” and expound a little more. Recall that we’re working with a sample app named “Zootastic”, so if you see references to Animals in the example, you’ll know why. :]

 1public func controller(
 2        controller: NSFetchedResultsController,
 3        didChangeObject anObject: AnyObject,
 4        atIndexPath indexPath: NSIndexPath?,
 5        forChangeType type: NSFetchedResultsChangeType,
 6        newIndexPath: NSIndexPath?) {
 7            
 8            switch type {
 9            case NSFetchedResultsChangeType.Insert:
10                // Note that for Insert, we insert a row at the __newIndexPath__
11                if let insertIndexPath = newIndexPath {
12                    self.tableView.insertRowsAtIndexPaths([insertIndexPath], withRowAnimation: UITableViewRowAnimation.Fade)
13                }
14            case NSFetchedResultsChangeType.Delete:
15                // Note that for Delete, we delete the row at __indexPath__
16                if let deleteIndexPath = indexPath {
17                    self.tableView.deleteRowsAtIndexPaths([deleteIndexPath], withRowAnimation: UITableViewRowAnimation.Fade)
18                }
19            case NSFetchedResultsChangeType.Update:
20                if let updateIndexPath = indexPath {
21                    // Note that for Update, we update the row at __indexPath__
22                    let cell = self.tableView.cellForRowAtIndexPath(updateIndexPath)
23                    let animal = self.fetchedResultsController.objectAtIndexPath(updateIndexPath) as? Animal
24                    
25                    cell?.textLabel?.text = animal?.commonName
26                    cell?.detailTextLabel?.text = animal?.habitat
27                }
28            case NSFetchedResultsChangeType.Move:
29                // Note that for Move, we delete the row at __indexPath__
30                if let deleteIndexPath = indexPath {
31                    self.tableView.deleteRowsAtIndexPaths([deleteIndexPath], withRowAnimation: UITableViewRowAnimation.Fade)
32                }
33                
34                // Note that for Move, we insert a row at the __newIndexPath__
35                if let insertIndexPath = newIndexPath {
36                    self.tableView.insertRowsAtIndexPaths([insertIndexPath], withRowAnimation: UITableViewRowAnimation.Fade)
37                }
38            }
39}

Right away you’ll notice we enter a switch on the type parameter of the method. There are four options possible in the NSFetchedResultsChangeType enum: Insert, Delete, Update, and Move.

Beware of a few common gotchas with each case of the switch:

First of all, notice that first argument of the majority of the tableView methods takes an array of NSIndexPaths. Be sure to wrap your argument in [ and ] to create an array.
Pay extra attention to which index path parameter you’re referencing in each case. For insert, the goal is to add a row at the newIndexPath. For Delete, the goal is to remove the row at indexPath. Move will require a deletion of the indexPath and an insertion at the newIndexPath. Getting these mixed up will cause runtime errors, so pay close attention here!

controller(_:didChangeSection:atIndex:forChangeType:)

If your table view only has one section, you don’t need to worry with this one.

If your table view has multiple sections, you want to make sure and implement this protocol method – if you fail to do so and the change to the persistent store results in adjustments to the table view that can’t be handled, runtime errors can occur. For example, deleting all rows in a section would result in the section needing to be deleted as well, but without this protocol method being implemented, the update to the table view can’t be made and the app crashes.

Once again, I’ll throw the code your way and follow up with commentary:

 1public func controller(
 2    controller: NSFetchedResultsController,
 3    didChangeSection sectionInfo: NSFetchedResultsSectionInfo,
 4    atIndex sectionIndex: Int,
 5    forChangeType type: NSFetchedResultsChangeType) {
 6    
 7        switch type {
 8        case .Insert:
 9            let sectionIndexSet = NSIndexSet(index: sectionIndex)
10            self.tableView.insertSections(sectionIndexSet, withRowAnimation: UITableViewRowAnimation.Fade)
11        case .Delete:
12            let sectionIndexSet = NSIndexSet(index: sectionIndex)
13            self.tableView.deleteSections(sectionIndexSet, withRowAnimation: UITableViewRowAnimation.Fade)
14        default:
15            ""
16        }
17}
18
19public func controller(controller: NSFetchedResultsController, sectionIndexTitleForSectionName sectionName: String?) -> String? {
20    return sectionName
21}

For this one, we’re only implementing code for Insert and Delete. The necessary information to insert a section or remove a section (ie, the sectionIndex) comes as a parameter to the method.

We utilize an NSIndexSet to wrap up the section that needs to be inserted or deleted and pass it to the table view’s insertSections() and deleteSections() methods, respectively.

Swift How-To: Setting up a Table View

Tue, 19 May 2015 02:31:38 +0000

Think of this screencast as the “Hello World” of creating a view controller with a table view. I cover organizing things in the Storyboard, Auto Layout constraints, and the implementation of the data source protocol methods for a table view.

Screencast

Screencast Transcript

[0:01]

Hi, I’m Andrew from andrewcbancroft.com.

I use table views fairly often in my examples, so I’ve decided to create a short walkthrough of how to set up a table view in Swift.

Think of this as the “Hello World” of creating a view controller with a table view.

[0:16]

In this walkthrough, I’m using Xcode 6.3.1, which has me writing Swift 1.2 syntax in a couple of spots.

[0:24]

To get started, I’m going to drop into the search bar of the Object Library, which is in the Utilities Pane to hunt for a table view.

Once I’ve narrowed the results and located the Table View control, I’ll click and drag one onto my Storyboard scene.

[0:41]

With the table view in place, filling the entire scene, I’ll control + click and drag up to the yellow View Controller icon to wire up my the table view’s dataSource… and delegate properties.

[0:56]

Now I need to connect the table view to my View Controller source file. To bring up the assistant editor, I’ll option+click the ViewController.swift file in the Project Navigator.

[1:06]

With the table view and the source side by side, once again, I’ll control + click the table view, and drag over to the ViewController source file to create an IBOutlet property for my table view.

[1:21]

Next up is to specify that my ViewController class will conform to the UITableViewDataSource protocol… and the UITableViewDelegate protocols.

[1:31]

Of course, at this point, I haven’t actually implemented any of the required protocol methods, so I get a compiler error saying so.

I’ve written up a handy UITableViewDataSource cheat sheet over at my website (andrewcbancroft.com). I’ll go grab that code and paste it into my View Controller.

[1:51]

Here I am at andrewcbancroft.com – I’ve searched for “UITableViewDataSource” and located my cheet sheet.

[2:02]

Scrolling down, I find the code I need, switch the code snippet plugin to “raw” mode, select everything, and copy.

[2:12]

Switching back over to my Xcode window, I paste the code snippet in.

[2:16]

As I mentioned in the beginning, this walkthrough can be thought of as the “Hello World” of table view setup. With that in mind, for now, I’ll create a dataSourceArray with some dummy data in it, just to get things compiling and displaying data.

[2:31]

Now that I’ve got the data source geared to go, I need some cells to display data in.

For this task, I’ll close the assistant editor…

Next, I’ll click to open the document outline. I find that working with the view hierarchy is much easier to manipulate using this outline, rather than clicking to try and select the right thing in the Storyboard Scene.

[2:55]

I’ll select the table view, and open the Utilities pane to get access to the Attributes inspector.

[3:01]

I’m going to configure this table view to have one kind of prototype cell.

[3:06]

Increasing the Prototype Cells count added a new node to the document outline’s view hierarchy.

I’ll expand the Table View and click on the Table View Cell to do a bit more configuration.

[3:19]

I’ll set the Style to Basic…

Then I’ll give it an identitifer of “BasicCell”.

I need this “BasicCell” string for one of my other data source proocol methods, so I’ll select it, and copy it.

[3:37]

Back in my ViewController.swift source file, I’ll paste that “BasicCell” string as the argument to dequeReusableCellWithIdentifier.

[3:48]

The last step to get things wired up is to set the cell’s textLabel.text property.

I’ll use the dataSourceArray’s values here.

Simply indexing into the array at the indexPath.row value that’s currently being rendered in the table view will grab the string out of the array and assign it to the textLabel.text property of the cell.

[4:13]

When I run the app and observe the table view’s behavior, I’m not quite satisfied with it. The status bar overlaps the rows and makes the text hard to read.

Additionally, the table view doesn’t extend all the way to the bottom when I run it in the iPhone 6 sized simulator.

[4:30]

I’ll stop the app and make an adjustment in the Storyboard.

[4:34]

Selecting the table view from the document outline will allow me to grab the top edge and drag the hight downward slowly until it “snaps” into place where the bottom of the status bar would appear to be.

[4:48]

Next, I’ll set some constraints. Within the document outline, I’ll control + click from the Table View to the View and set constraints for “Top Space to Top Layout Guide”, Center Horizontally, Center Vertically, and Equal Widths.

[5:17]

Running the app one more time gives me the behavior I want!

[5:31]

Thanks for watching – I have other resources r elated to Swift and iOS development at andrewcbancroft.com, and you can find me on Twitter: @andrewcbancroft

Displaying Data With NSFetchedResultsController and Swift

Thu, 05 Mar 2015 15:14:53 +0000

The combination of an NSFetchedResultsController and a UITableView provides a powerful way to integrate Core Data with a user interface. The greatest benefits of using NSFetchedResultsController come when we use it to automatically update a table view when objects are added, updated, or removed from a Core Data data store. First things first, though…

With a Core Data data store seeded with data, the next logical step is to display that data somewhere other than the console. This post will be devoted to figuring out how to set up an NSFetchedResultsController to display data inside a UITableView.

A follow-up post has been published to help you keep the table view in sync with the data as it changes in your persistent store, so once you’re finished here, you might check out that next step!

Final goal

NSFetchedResultsController will help us accomplish two things:

It will fetch data from the Core Data data store
It will use some of the data we fetch to populate various pieces of the UI (table view section headers, cell “title” and “subtitle” text. Here’s what we’re going for:

Setup and resources

I’m continuing my “Zootastic” example that I used to write about using Swift to seed a Core Data database. In fact, I’ve simply branched the project on GibHub and added the things we’re exploring in this post.

Resources

Example Xcode Project

For this entry, we’ll still be dealing with our three primary NSManagedObject subclasses: Zoo, Animal, And Classification:

Storyboard

Zootastic is a single view application. The Storyboard contains one view controller with a table view filling the Scene.

The table view is using one prototype cell with an Identifier of “Cell” (for simplicity). The Style of the prototype cell is set to Subtitle.

MainViewController.swift

MainViewController.swift is where the action is happening. Here’s a quick outline of what we need to accomplish in this class:

public class MainViewController: UIViewController, UITableViewDataSource, UITableViewDelegate, NSFetchedResultsControllerDelegate {

    // maintain a reference to NSManagedObjectContext instance

    // create and configure an NSFetchedResultsController instance

    // Implement UITableViewDataSource methods
}

As you can see, MainViewController is a class concerned with being the table view’s data source and delegate. Additionally, it will serve as the NSFetchedResultsControllerDelegate. For this post, we won’t actually need the fetched results controller delegate functionality to display data. Those methods are particularly useful for synchronizing things when data changes.

With the class declaration out of the way, we’ll investigate the class implementation one section at a time.

Maintain NSManagedObjectContext instance reference

public class MainViewController: UIViewController, UITableViewDataSource, UITableViewDelegate, NSFetchedResultsControllerDelegate {
    
    public var context: NSManagedObjectContext!

    // ...
}

You may be asking, “Where will you set this NSManagedObjectContext reference?”. I’m employing a pattern that I’ve found successful in the past: I assign it when the finishes launching through the AppDelegate’s application:didFinishLaunchingWithOptions method. More on this, shortly…

For now, know that we’re counting on that later step to take place, since context is defined as an implicitly unwrapped optional.

Create and configure NSFetchedResultsController instance

Next, we need to create and configure an NSFetchedResultsController instance. Here’s a bit of code with comments to follow:

 2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

                        If you’ve not read  1 language-swift" data-lang="swift">public class MainViewController: UIViewController, UITableViewDataSource, UITableViewDelegate, NSFetchedResultsControllerDelegate {

// ...

lazy var fetchedResultsController: NSFetchedResultsController = { let animalsFetchRequest = NSFetchRequest(entityName: "Animal") let primarySortDescriptor = NSSortDescriptor(key: "classification.order", ascending: true) let secondarySortDescriptor = NSSortDescriptor(key: "commonName", ascending: true) animalsFetchRequest.sortDescriptors = [primarySortDescriptor, secondarySortDescriptor]

let frc = NSFetchedResultsController( fetchRequest: animalsFetchRequest, managedObjectContext: self.context, sectionNameKeyPath: "classification.order", cacheName: nil)

frc.delegate = self

return frc }()

// ... class="p">}

rhardt">Colin Eberhardt’s Swift Initialization and the Pain of Optionals post, I highly recommend it. His post is a fantastic analysis, and the final option of using lazy stored properties initialized by a closure expression is what I’ve chosen to do here. I won’t repeat his analysis here, so feel free to jump over to his post to figure out what’s going on there.

Within the closure expression, I’m setting up a fetch request with some sorting applied. All that’s left is to initialize the NSFetchedResultsController, set its delegate and return it.

viewDidLoad()

Once the view has loaded, the idea is to perform the NSFetchedResultsController instance’s fetch request so that it has data to use in our UITableViewDataSource methods. This is how to do it:

public class MainViewController: UIViewController, UITableViewDataSource, UITableViewDelegate, NSFetchedResultsControllerDelegate {

    // ...

    override public func viewDidLoad() {
        super.viewDidLoad()
        // Do any additional setup after loading the view, typically from a nib.

            do {
                try fetchedResultsController.performFetch()
            } catch {
                print("An error occurred")
            }
    }

    // ...

}

UITableViewDataSource methods

The final step in implementing MainViewController is to set up the table view so that it pulls data from fetchedResultsController. I’m implementing the standard UITableViewDataSource methods here, along with tableView:titleForHeaderInSection. Take a look:

public class MainViewController: UIViewController, UITableViewDataSource, UITableViewDelegate, NSFetchedResultsControllerDelegate {

    // ...

    // MARK: TableView Data Source
    public func numberOfSectionsInTableView(tableView: UITableView) -> Int {
        if let sections = fetchedResultsController.sections {
            return sections.count
        }
        
        return 0
    }
    
    public func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
        if let sections = fetchedResultsController.sections {
            let currentSection = sections[section] 
            return currentSection.numberOfObjects
        }
        
        return 0
    }
    
    public func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
        let cell = tableView.dequeueReusableCellWithIdentifier("Cell", forIndexPath: indexPath) 
        let animal = fetchedResultsController.objectAtIndexPath(indexPath) as! Animal
        
        cell.textLabel?.text = animal.commonName
        cell.detailTextLabel?.text = animal.habitat
        
        return cell
    }
    
    public func tableView(tableView: UITableView, titleForHeaderInSection section: Int) -> String? {
        if let sections = fetchedResultsController.sections {
            let currentSection = sections[section] 
            return currentSection.name
        }
        
        return nil
    }

    // ...

}

Apart from a bit of if let ___ = ___ syntax, there’s not an awful lot of surprising code here if you’re familiar with working with table views. I’ve highlighted the relevant code related to fetchedResultsController. Without using NSFetchedResultsController, you’d probably supply data to the table view from an array or a dictionary or both. The fetchedResultsController code simplifies the data display dilemma when you’re using Core Data.

Once the UITableViewDataSource methods are implemented, the implementation of MainViewController is complete for this example.

AppDelegate.swift

There’s one final thing we need to do in order to get things rolling. In the “maintain NSManagedObjectContext instance reference” section of this post, I mentioned the strategy for assigning the NSManagedObjectContext instance in the MainViewController. Here’s how I do it:

class AppDelegate: UIResponder, UIApplicationDelegate {

    // ...


    func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {
        // Override point for customization after application launch.
        
        let dataHelper = DataHelper(context: self.managedObjectContext)
        dataHelper.seedDataStore()
        
        dataHelper.printAllZoos()
        dataHelper.printAllClassifications()
        dataHelper.printAllAnimals()
        
        let rootViewController = self.window!.rootViewController as! MainViewController
        rootViewController.context = self.managedObjectContext;
        
        return true
    }

    // ...

}

Note: With iOS 13, the code to assign the managedObjectContext to the root view controller needs to go in your app’s SceneDelegate.

The portion new to “injecting” the managedObjectContext into MainViewController is highlighted. I simply grab a reference to the rootViewController (which in our example is the MainViewController) and cast it to the appropriate type. Then I set the context property to the managedObjectContext that’s created in the AppDelegate via Xcode’s auto-generated Core Data stack setup.

Wrapping up

If you’re using Core Data in your iOS application, the combination of an NSFetchedResultsController and a UITableView provides a powerful way to integrate data from your data store into your UI. We’ve explored how to display data in a table view using NSFetchedResultsController. Feel free to grab the GibHub project for further investigation and to see Zootastic in action.

Custom UITableViewCell for Text Input in Swift

Thu, 12 Feb 2015 13:00:50 +0000

The need to collect data via text input is a common in many applications. This walk-through showcases how to create a custom UITableViewCell for accepting text input within a UITableView.

Table Views for Data Entry?

Table views provide nice, built-in styles that present a form-like view for collecting data from your users. They also have inherent scrolling capabilities. Finally, there is some handy keyboard handling, such as auto-scrolling to avoid covering up a data entry cell, or hiding the keyboard when the user scrolls the Table View. Both of those are challenging to get right if you were to do implement a data entry form some other way.

Many of Apple’s own UIs utilize table views to collect data from the user (think Settings, Calendar, Reminders).

For those reasons, I think a table view is a really convenient choice for collecting data from a user.

Step by Step Walkthrough

Resources

Example Xcode Project

Drag a table view to Storyboard

Assuming that you have a View Controller already on the Storyboard design surface, drag a table view onto the Storyboard scene.

Wire up table view data source and delegate

For this step it’s helpful to have the document outline pane visible. Selecting the Table View from the document outline and subsequently Control + Click + Dragging to the View Controller icon on the Storyboard scene will allow you to link the table view’s dataSource and delegate properties to the View Controller.

Note that you’ll need to perform the Control + Click + Drag maneuver twice to set both the dataSource and the delegate.

Configure keyboard dismissal for table view

With the attributes inspector selected in the utilities pane, scroll down to the Keyboard option and set it to “Dismiss on drag”.

This can be helpful if you’d like the keyboard to automatically hide itself when the user scrolls the table view.

Set constraints, increase prototype cells count

Use the document outline to set constraints. With the attributes inspector selected in the utilities pane, select “Dynamic Prototypes” for the Content property, and set the Prototype Count property to 1 (or more, depending on your needs).

Configuring constraints on the table view will ensure that it displays properly on all device sizes and orientations.

In this particular example, there’s only one kind of prototype cell that I want the table view to display. If I had multiple prototypes, I’d increase the prototype cells count to match the number of prototypes I had.

Drag text field to cell, increase text field width

Drag a text field into the cell’s contents and use Xcode’s blue guides to adjust the width so that it takes up the whole cell.

Now comes the customization of the prototype cell itself. Since we’re designing it for text input, we’ll use a text field as the contents of the table view cell prototype.

Configure Text Field Constraints and Border

Use the document outline to set constraints for the text field. With the text field selected, and the attributes inspector selected in the utilities pane, set the Border Style property to the style you prefer.

Configuring constraints on the text field will ensure that it displays properly on all device sizes and orientations.

Depending on your taste / needs, you can change the border style from rounded to none, or whichever other border style is most appealing for your app.

Create new TextInputTableViewCell class

Add a new .swift file named TextInputTableViewCell to your project. Create a new class in that file called TextInputTableViewCell which inherits from UITableViewCell.

Create an IBOutlet between the text field and the TextInputTableViewCell class

Use the document outline to Control + Click + Drag and IBOutlet to the TextInputTableViewCell class.

Implement TextInputTableViewCell class

An example implementation with a function for configuring the text field’s properties might look something like this:

 1import UIKit
 2
 3public class TextInputTableViewCell: UITableViewCell {
 4    @IBOutlet weak var textField: UITextField!
 5    
 6    public func configure(#text: String?, placeholder: String) {
 7        textField.text = text
 8        textField.placeholder = placeholder
 9        
10        textField.accessibilityValue = text
11        textField.accessibilityLabel = placeholder
12    }
13}

Change cell class in Storyboard to TextInputTableViewCell

Use the document outline to select the Table View Cell. With the identity inspector selected in the utilities pane, change the Class property to your TextInputTableViewCell class.

Set reuse identifier

With the Table View Cell still selected in the document outline, select the attribute inspector in the utilities pane and change the Identifier property to “TextInputCell” (or some other string that’s easily remembered).

Implement table view data source and delegate methods

In the View Controller, specify that it adopts the UITableViewDataSource and UITableViewDelegate protocols. Implement the appropriate protocol methods.
I’ve written a cheat sheet for this, but I’ll also provide the following sample implementation of the mai ViewController class:

 1import UIKit
 2
 3public class ViewController: UIViewController, UITableViewDataSource, UITableViewDelegate {
 4    public func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
 5        return 1 // Create 1 row as an example
 6    }
 7 
 8    public func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
 9        let cell = tableView.dequeueReusableCellWithIdentifier("TextInputCell") as TextInputTableViewCell
10        
11        cell.configure(text: "", placeholder: "Enter some text!")
12        return cell
13    }
14}

Lines 9 and 11 are of most importance. Notice that I’m dequeueing a TextInputCell, which is what I set the reuse identifier of my cell to be. I’m also casting the dequeued cell as a TextInputTableViewCell so that it can be configured (line 11)

Run in simulator

Wrapping up

In this walkthrough, my goal was to show how to take advantage of a table view’s inherent styles, scrolling capabilities, and keyboard handling to make form-like text input easier. We created a custom subclass of UITableViewCell to accomplish this task. Take a look at the example published to GitHub to dive in further and explore the walkthrough in more depth.

Swift UITableViewDataSource Cheat Sheet

Mon, 24 Nov 2014 22:04:28 +0000

iOS developers will quickly recognize that there are a set of methods that always tend to get implemented when dealing with UITableViews . The problem I consistently face is remembering that set of methods that belong to the UITableViewDataSource (and UITableViewDelegate ) protocols. I find myself option-clicking the protocol name to remember the method signatures I need, since Xcode doesn’t have a way to stub out the methods involved with a protocol (C# developers working in Visual Studio like myself are spoiled!).

I’m sure cheat sheets like this already exist, but I thought, “Why not have one that I can reference from my own blog?”… In fact, I’ve gone ahead and turned the code below into a snippet in Xcode, but just in case I ever lose that, I’ve got this post, which stubs out dummy implementations of the three most common UITableViewDataSource protocol methods.

I’d be delighted if it helped my readers as well, so without further ado, here’s my UITableViewDataSource cheat sheet, which should allow you (and me) to copy and paste directly into our UITableViewDataSource class for a quick start:

 1func numberOfSectionsInTableView(tableView: UITableView) -> Int {
 2    return 1 // This was put in mainly for my own unit testing
 3}
 4
 5func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
 6    return dataSourceArray.count // Most of the time my data source is an array of something...  will replace with the actual name of the data source
 7}
 8
 9func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
10    // Note:  Be sure to replace the argument to dequeueReusableCellWithIdentifier with the actual identifier string!
11    let cell = tableView.dequeueReusableCellWithIdentifier("ReplaceWithCellIdentifier") as! UITableViewCell
12    
13    // set cell's textLabel.text property
14    // set cell's detailTextLabel.text property
15    return cell
16}