Tutorial on Andrew Bancroft

Beginner’s Guide to Event Kit in Swift – Requesting Permission

Thu, 14 May 2015 20:37:52 +0000

Updated on October 26, 2016 – Swift 3.0

EventKit provides a set of classes for accessing and manipulating a user’s calendar events and reminders. In the tutorial that follows, my goal is to walk you through the first steps of setting up an app that utilizes EventKit. I will demonstrate how to request permission to the user’s calendar and show a couple of examples for how to handle the user’s response (for when they grant access, or deny it).

Note: Code in the main article below is written in Swift 3.0, but code examples for Swift 2.3 are found in the example project.

Example scenario

Let’s start by proposing a basic scenario to serve as this tutorial’s example.

Suppose that we’re building an app that, for now, has a single View Controller. We’d like this View Controller to display a list of calendars if the user grants us permission to do so. If they deny permission, we’d like to show a message to them that indicates that our app can’t function without this permission, and we’ll allow them to click a button to grant us permission in the Settings of their device.

I’ve created such an app as an example – jump over to GitHub to grab the code and explore. Read on for an explanation of some of the finer points of the setup and code.

Resources

Example Xcode Project (Swift 2.3 | Swift 3.0)

Storyboard setup

One of the first things you’ll deal with in EventKit is the need to set yourself up with a UI to handle the different responses that the user can give you on that first application launch when you ask, “Can we access your calendar?”. We’ll get to the particulars of how request that permission shortly. But first, let’s dissect how we might arrange a Storyboard with some views that do the right thing for a given response to that permission prompt.

The user can either grant permission, or deny permission to interact with their calendar or reminders. We need to be prepared for either scenario.

Tableview for the calendar list for when access is granted

I’m feeling optimistic today, so let’s begin with the case where the user grants us permission to their calendar from the get-go.

When the user grants us permission, we’d like to list out their calendars inside a table view. We’ll worry with setting up the data source later in the tutorial. For now, we’ll drag over a table view from the Utilities pane.

To get the table view to fill the whole screen, I do a couple of things. Usually, when you drag one out from the Utilities pane, the table view will fill the whole scene in the Storyboard. From that layout, I drag the top edge down until it “snaps” to the line where I’d expect the bottom of the status bar to be positioned. Then I set the following constraints:

Center X
Center Y
Equal width to Superview
Top space to Top Layout Guide for height.

I’ve created a short screencast on setting up a table view if you’d like a complete walkthrough:

Resources

Here’s a detailed view of the constraints, along with a visual of what the Storyboard Scene looks like with the table view installed:

As a final note, I’ve set the hidden property of the table view to true in the Storyboard. I’ll toggle the table’s visibility based on the user’s granting or denying of the calendar access later, but I thought it was worth pointing out that the initial state of my table view in the example is hidden.

“Need permission” view for when access is denied

There will be times when a user denies access to the calendar before realizing that doing so essentially stops all the functionality provided by your app. If your entire app, or even just a portion of it requires access to function, you need a way to inform the user of this, and provide them a way to navigate to settings and grant access manually if possible.

The way I did this in the sample project was to organize a new View onto the Storyboard Scene which contains a label with some instructions, and a button that takes the user to the Settings page for our app when they tap on it.

Once again, some constraints are involved in getting things to appear correctly at run-time. I won’t go into the details of this here, since it’s likely that every implementation of this will be slightly different.

One thing I will point out though, is that the View’s alpha has been set to 0 so that I can perform a nice fade in transition if the user denies access. Here’s a look at the Scene with the invisible “NeedPermissionsView” installed:

The role of the Event Store

At the heart of EventKit is the EKEventStore. EKEventStore is the central “thing”. Creating an instance of EKEventStore provides developers with an API for performing various read/write operations on the user’s calendars and reminder lists.

A View Controller that interacts with the calendar should hold a reference to an EKEventStore instance. It’s easy to create one – here’s an example:

1class ViewController: UIViewController, UITableViewDataSource, UITableViewDelegate {
2
3    let eventStore = EKEventStore()
4
5    // ...    
6}

Checking for calendar authorization

Once we have a reference to an EKEventStore instance, we can use it to do things like check whether or not the user has granted us permission to use their calendar. From there, we can make decisions about whether or not we need to request permission, and subsequently figure out which view to show (the table view or the need permission view).

Where we check for calendar authorization is important. My recommendation is to check each time the view appears (ie, in viewWillAppear(), because it’s completely possible that the user could grant access at first, switch to settings, and deny access. Our app would need to respond appropriately.

In the example project provided with this article, I’ve created a function named checkCalendarAuthorizationStatus(). Here a peek at what it does:

 1class ViewController: UIViewController, UITableViewDataSource, UITableViewDelegate {
 2
 3    // ...
 4    
 5    override func viewWillAppear(animated: Bool) {
 6        checkCalendarAuthorizationStatus()
 7    }
 8    
 9    func checkCalendarAuthorizationStatus() {
10        let status = EKEventStore.authorizationStatus(for: EKEntityType.event)
11        
12        switch (status) {
13        case EKAuthorizationStatus.notDetermined:
14            // This happens on first-run
15            requestAccessToCalendar()
16        case EKAuthorizationStatus.authorized:
17            // Things are in line with being able to show the calendars in the table view
18            loadCalendars()
19            refreshTableView()
20        case EKAuthorizationStatus.restricted, EKAuthorizationStatus.denied:
21            // We need to help them give us permission
22            needPermissionView.fadeIn()
23        }
24    }
25
26    // ...
27}

The key function here is EKEventStore's authorizationStatus(for:) function. Passing in EKEntityType.event is what corresponds to the user’s calendar. If we wanted to check for access to their reminders, we’d use EKEntityTypeReminder.

The possible EKAuthorizationStatus enumeration values are simply switched over – the logic to be performed is encapsulated in separate functions for ease of readability.

Let’s step through each of those functions one by one…

Update Info.plist for iOS 10 support

Apple now requires us to have a key/value pair in Info.plist that provides a description to the user as to why our apps need access to their calendar.

To set this value, open your Info.plist file, and add a new key for “Privacy – Calendars Usage Description”:

The value that you provide for this plist key ends up being displayed in the alert that’s displayed when you request access.

Requesting access to calendars

As the title of this tutorial suggests, all things start here. Whenever our application loads and we call authorizationStatus(for:), the status that will be returned is notDetermined. It’s at this point that we’d like to request access to the calendar.

To do so, let’s dissect the requestAccessToCalendar function:

 1class ViewController: UIViewController, UITableViewDataSource, UITableViewDelegate {
 2
 3   // ...
 4   
 5    func requestAccessToCalendar() {
 6        eventStore.requestAccess(to: EKEntityType.event, completion: {
 7            (accessGranted: Bool, error: Error?) in
 8            
 9            if accessGranted == true {
10                DispatchQueue.main.async(execute: {
11                    self.loadCalendars()
12                    self.refreshTableView()
13                })
14            } else {
15                DispatchQueue.main.async(execute: {
16                    self.needPermissionView.fadeIn()
17                })
18            }
19        })
20    }
21
22    // ...
23}

Our EKEventStore instance provides a function called requestAccess(to:). Once again, passing in EKEntityType.event is what signals that we’re requesting access to the calendar. The rest of the interesting parts are found in the completion closure that we provide.

There are three main things to note with this portion of the implementation:

The two parameters that are passed in to the closure is a Bool indicating access was granted (true) or denied (false). The second is an NSError.
We need to call dispatch_async() and indicate that we want to jump back over to the main queue to execute our UI refreshes.
self.needPermissionView.fadeIn() utilizes a UIView extension from my post, Fade In / Out Animations as Class Extensions in Swift.

Access granted! Load calendars and refresh table view

When access is granted, we can call the eventStore instance’s calendarsForEntityType function and pass it EKEntityType.event to grab an array of the user’s calendars to display in our table view. Here’s a look:

 1class ViewController: UIViewController, UITableViewDataSource, UITableViewDelegate {
 2
 3    // ...
 4
 5    var calendars: [EKCalendar]?
 6
 7    // ...
 8    
 9    func loadCalendars() {
10        self.calendars = eventStore.calendars(for: EKEntityType.event)
11    }
12    
13    func refreshTableView() {
14        calendarsTableView.isHidden = false
15        calendarsTableView.reloadData()
16    }
17
18    // ...
19}

Access denied – Show needs permission view

When access is denied, we need to unveil the “Needs Permission View” we created in our Storyboard Scene.

Recall that in that view, there’s a button to direct the user to the Settings page for our app so that they can easily grant access to the calendar from there. That button is wired up to an IBAction. Here’s an example implementation of that IBAction:

 1class ViewController: UIViewController, UITableViewDataSource, UITableViewDelegate {
 2
 3    // ...
 4
 5    @IBAction func goToSettingsButtonTapped(_ sender: UIButton) {
 6        let openSettingsUrl = URL(string: UIApplicationOpenSettingsURLString)
 7        UIApplication.shared.openURL(openSettingsUrl!)
 8    }
 9
10    // ...
11}

Wrapping up

That pretty much completes the setup process for working with Event Kit! The remaining cases for the checkCalendarAuthorizationStatus() function simply re-use the functions I just dissected when exploring the requesting permission process.

I encourage you to head over to GitHub and dive into the code for yourself as you get started with utilizing Event Kit in your app!

Fundamentals of NSNotificationCenter in Swift

Wed, 08 Oct 2014 18:27:47 +0000

Updated on September 19, 2016 – Xcode 8 & Swift 3.0

The goal of this post is to help you grasp the fundamentals of using NSNotificationCenter in your Swift iOS app. The topic isn’t necessarily new, and there’s no difference except syntax between Objective-C and Swift implementations involving NSNotificationCenter. Even still, I’m hoping to add to the understanding of this useful tool by giving a fully-working example on GitHub (Swift 2.3 and Swift 3.0), and by sharing the insight that’s clicked in my own brain as I explain the example.

Note: Code in the main article below is written in Swift 3.0, but code examples for Swift 2.3 are found in the example project.

First things first: What is this thing?

When I first heard NSNotificationCenter, I thought “push notifications”. However, NSNotificationCenter has nothing to do with sending or receiving push notifications in iOS. Rather, it is a communication tool internal to your app. It provides a way for one instance of a class/struct to notify one or more other class/struct instances about something. The goal in doing this is to enable those 1+ other class or struct instances to take appropriate action based the communication they receive. An common analogy comes to mind: think “radio tower”. NSNotificationCenter is the central hub that acts as a broadcaster of notifications. If that still seems vague, hang tight – seeing the example below should help it all come together for you.

Should I use it?

Before diving into the basic workflow, it’s worth asking, “Should I use NSNotificationCenter, or is there some other option that’s more appropriate for my app’s internal communication needs?”

It is often the case that there is more than one way to solve a problem in software development, and it’s no different with NSNotificationCenter. There is more than one way to accomplish instance-to-instance communication at run-time. I’ve written about two such forms of communication in my post titled NSNotificationCenter vs Delegation – An Analysis. It may be worth reading up on, just to make sure you’re using the right tool for the right kind of communication.

Basic Workflow

NSNotificationCenter.default is at the center of it all when it comes to this discussion.

The basic workflow of using NSNotificationCenter goes something like this:

Since `NSNotificationCenter` is in the business of broadcasting notifications, the first thing to do is to specify a way to uniquely identify a notification. This is most easily accomplished by defining a constant string value (using `let` syntax in Swift) at a globally-visible scope. The string constant you define here will serve as a “notification key”. If you have several notification keys that you need to define, perhaps creating a new .swift file called “NSNotificationCenterKeys.swift” is a clean way to do this.
Steps 2 and 3 of the workflow go hand-in-hand. Without implementing the one, implementing the other doesn’t make much sense… Step 2 is to post a notification to `NSNotificationCenter.default` identified by the key that was created in step 1. In radio terms, the class or struct instance desiring to post a notification asks the default notification center to broadcast the notification key defined in step 1… this class or struct instance chooses the right situations to request that the notification key be sent out based on business logic specific to the project’s requirements.
Step 3 is to set up 1+ class or struct instances to be listeners, or more properly, observers of a particular notification. Such an observer will be able to tell that it’s “heard” the notification, because it will be “listening for” a notification that uses the same key that was created in step 1, which is the key used in step 2 to post the notification. In radio terms, the listener is tuned in to the default notification center’s station that’s identified by that special key defined in step 1 and posted in step 2. So you see now why steps 2 and 3 go hand-in-hand. With no posts to the notification center on that station, tuning in will do no good. Likewise, posting a notification but having no listeners accomplishes nothing.
Finally, what should the observing instance do once it’s detected the notification? Well, when signing up to be an observer, the instance must also specify the name of a function that will be called upon receipt of the notification it’s listening for. Whatever action or routine is appropriate to perform at that time is what that function’s implementation should contain.

Visualizing NSNotificationCenter by Example

If you’re like me, you need less talk and more example, so I’ve created a simple Xcode project that you can grab over at GitHub (Swift 2.3 and Swift 3.0). Running the project will allow you to click through a series of tabs in a tab view controller, post a notification, and see the results. It looks much like this:

Working back through the basic workflow with this example you can find the following key aspects of implementing a NSNotificationCenter solution (lines of code to pay special attention to will be highlighted).

Steps 1 and 2:

I’ve chosen my FirstViewController class to be the one that defines the global constant with a unique notification key and tells the default notification center to post that notification when the “Notify!” button is tapped:

 1// 1. Globally define a "special notification key" constant that can be broadcast / tuned in to...
 2let mySpecialNotificationKey = "com.andrewcbancroft.specialNotificationKey"
 3
 4class FirstViewController: UIViewController {
 5    @IBOutlet weak var sentNotificationLabel: UILabel!
 6    
 7    override func viewDidLoad() {
 8        super.viewDidLoad()
 9        NotificationCenter.default.addObserver(self, selector: #selector(FirstViewController.updateNotificationSentLabel), name: NSNotification.Name(rawValue: mySpecialNotificationKey), object: nil)
10    }
11
12    // 2. Post notification using "special notification key"
13    @IBAction func notify() {
14        NotificationCenter.default.post(name: Notification.Name(rawValue: mySpecialNotificationKey), object: self)
15    }
16    
17    func updateNotificationSentLabel() {
18        self.sentNotificationLabel.text = "Notification sent!"
19    }
20}

Steps 3 and 4:

Both of these steps are implemented in very similar ways in my SecondViewController and ThirdViewController classes. The code should speak for itself:

 1class SecondViewController: UIViewController {
 2    @IBOutlet weak var notificationLabel: UILabel!
 3    
 4    override func viewDidLoad() {
 5        super.viewDidLoad()
 6
 7        // 3.  Observe (listen for) "special notification key"
 8        NotificationCenter.default.addObserver(self, selector: #selector(SecondViewController.actOnSpecialNotification), name: NSNotification.Name(rawValue: mySpecialNotificationKey), object: nil)
 9    }
10
11    // 4.  Implement function to act on that notification
12    // The name of this function must match the selector argument you specified when you called addObserver()
13    func actOnSpecialNotification() {
14        self.notificationLabel.text = "I heard the notification!"
15    }
16}
17
18
19class ThirdViewController: UIViewController {
20    @IBOutlet weak var notificationLabel: UILabel!
21    
22    override func viewDidLoad() {
23        super.viewDidLoad()
24        NotificationCenter.default.addObserver(self, selector: #selector(ThirdViewController.actOnSpecialNotification), name: NSNotification.Name(rawValue: mySpecialNotificationKey), object: nil)
25    }
26    
27    func actOnSpecialNotification() {
28        self.notificationLabel.text = "I heard the notification, too!"
29    }
30}

Finally, to reiterate the explanation in visual form and for easy reference, I’ve annotated a screen shot taken from the project’s code:

Removing an observer

One final requirement for working with NSNotificationCenter is to remove an observer when it no longer needs to listen for notifications. When might this situation arise?

When the observer is no longer referenced and thus deallocated from memory, it should tell the default notification center that it can be removed
When some condition occurs in your application that renders it no longer relevant for an instance to listen for notifications

The first situation is the most common, and is for sure the scenario that we want to protect against, so that the default notification center doesn’t continue to manage observers that are no longer capable of actively listening. To satisfy the requirement of removing an observer when an instance is deallocated, we could provide something like the following deinit method:

1deinit {
2    NSNotificationCenter.default.removeObserver(self)
3}

For the second bullet point, you can simply write the same line of code that’s highlighted in the above snippet, wherever it makes sense for you to tell the default notification center when it’s appropriate to stop sending messages to the instance in question.

Summary

NSNotificationCenter is particularly useful when there are multiple class or struct instances that need to take action based on something that happens elsewhere in your application. For this type of scenario, NSNotificationCenter can be a great tool to wield as you develop apps in Swift for iOS.

Create Sound Clips from iTunes

Tue, 19 Jun 2012 00:48:38 +0000

Open iTunes.
(optional) Import any songs you’d like to make clips for.
Select (click) the song that you’d like a sound clip for so that it’s the only one selected.
Right-click that song and select “Get Info”.
A window will appear – Click “Options” to access the screen to set your start and stop times.
Check the boxes next to “Start Time” and “Stop Time”.
Enter a start time in the text box next to “Start Time”.
Enter a stop time in the text box next to “End Time”.
Click “OK” to make that change to the song effective.
Right-click that song again and select “Create AAC Version”.
In the iTunes song list, you will now see two identically named songs. The key differentiator between the two is the length of time the song is. The sound clip you created will be less than or equal to the full-length song that it came from, but probably just less than if you truly created a sound clip.
One last time, right-click the original song (the longer one), select “Get Info”, click “Options”, and uncheck the “Start Time” and “Stop Time” check boxes. If you don’t do this, the song will only play the timespan you specified every time you play it in iTunes.
(optional) Rename the sound clip with an appropriate clip name.
- Right-click the sound clip and click “Get Info”.
- Click the “Info” button this time to access the “Name” field.
- Type in an appropriate clip name in the “Name” field.
- Click “OK” to make that change effective.
(optional) If you don’t want the sound clip to appear in your iTunes library, you can move it to another folder and remove it from the library so that it’s not junking up your normal song list.
Right-click the sound clip.
- Click “Show in Finder”
- In my opinion it’s always easiest to get the file somewhere that’s easy to find and work with it from there. You can use the Desktop for this purpose if you’d like. In Finder, you can press and hold the Command key, click the sound clip, and drag it to Desktop on the left. The combo of Command+click+drag+let go on Desktop effectively moves it to that location.
- Close Finder so that you’re back on your iTunes window.
- Click the sound clip.
- Press the delete key and click “Delete Song” on the warning window. This will remove it from your iTunes library.

Done!