I'm not really sure about this, as I'm new to using remote notifications. But reading the documentation gives me the impression that the userInfo dictionary has an aps dictionary inside with the values.

So the RemoteNotification's init should actually look more like this:

public init?(remoteNotification: [NSObject : AnyObject]?) {
    guard let remoteNotification = remoteNotification as? [String : AnyObject] else {
        return nil
    }

    let apsKey = "aps"
    let aps = remoteNotification[apsKey] as? [String : AnyObject]

    alert = aps.flatMap(Alert.init(remoteNotification:))
    badge = aps?[badgeKey] as? Int
    sound = aps?[soundKey] as? String
    contentAvailable = aps?[contentAvailableKey] != nil
    categoryIdentifier = aps?[categoryKey] as? String
    remoteNotificationDictionary = remoteNotification

    var customFields = remoteNotification
    customFields.removeValueForKey(apsKey)

    userInfo = customFields
}

At least that seems to work for me, what do you think?

If a notification is received when the app is not in foreground, the app is then launched, notification center is opened and a notification is tapped, the notificationOrigin is marked as .DeliveredWhileInForground.

I noticed that in that case, the following is true: applicationIsInForeground && application.applicationState == .Inactive

I propose that we look for that case and return .UserTappedToBringAppToForeground instead. Something like this:

    let notificationOrigin: UserNotificationOrigin
    if applicationIsInForeground {
        notificationOrigin = application.applicationState == .Inactive
            ? .UserTappedToBringAppToForeground
            : .DeliveredWhileInForground
    } else if application.applicationState == .Background && remoteNotification.contentAvailable {
        notificationOrigin = .DeliveredWhileInBackground
    } else {
        notificationOrigin = .UserTappedToBringAppToForeground
    }

Hi. We are in need of the following delegate calls for analytics as well as some core data handling:

Transitioning to the foreground:
- applicationDidBecomeActive(_:)

Transitioning to the background:
- applicationDidEnterBackground(_:)

Transitioning to the inactive state:
- applicationWillResignActive(_:) (Called when leaving the foreground state.)
- applicationWillEnterForeground(_:) (Called when transitioning out of the background state.)

Termination:
- applicationWillTerminate(_:) (Called only when the app is running. This method is not called if the app is suspended.)

Hence, I propose some sort of LifeCycleProtocol, maybe LifeCycleAware, in order to retrieve those delegate calls.

protocol LifeCycleAware {
  func transitionedToForeground()
  func transitionedToBackground()

  func transitioningToBackground()
  func transitioningToForeground()

  func terminatingApplication()
}

Cheers!

As mentioned in the title, building the app fails in file SuperDelegate+LocalNotifications.swift on line 22.

Error: No such module 'UserNotifications'.

My Podfile:

platform :ios, '8.0'

target 'NewProject' do
    use_frameworks!
    pod 'SuperDelegate'
end

Cocoapods version 1.0.1

This branch / pull request represents v0.9 of SuperDelegate. v0.9 is a breaking change from v0.8, and has the following new features:

• Adoption of Swift 3.0
• Adoption of Swift 3.0 naming conventions

See issues for outstanding/known issues in v0.9.

Contributing

• Discovered a bug UIApplicationDelegate that we haven't addressed?
• Want a feature that does not exist?
• Found a bug?
• Dislike our take on Swift 3.0 naming conventions?
• Something else?

We want to hear from you! Please follow our contributing guidelines by filing an issue before submitting a PR. If you have a comment on a line in this PR, please file an issue with a link to the line number. Thanks!

I suggest to move the method testing_resetAllData() from Sources to Tests. Without having deep dived into that, I guess that we could also add this functionality via extension :).

Any plans on using optional protocol requirements? Sometimes you only need one specific function to be invoked instead of all.

Of course, you can easily ignore the others. But wouldn't it be nicer to just use the necessary protocol requirements a specific use case demands?

Unfortunately there's some SDK's that require the launchOptions directly. Maybe there could be an addition to have an optional protocol method that has these unedited launchOptions. I could not find any other built in work-around for this issue.

Adjust sample project to emphasize UIApplicationDelegate protocol requirements.

In the current example project window is defined as:

  let window = UIWindow()

If I am using some libraries like SVProgressHUD which access the current UIWindow via the following selector UIApplication.shared.delegate?.window they all crash as this invocation returns nil.

Hence, I propose to update the sample project to meet those protocol requirements.

It also worked before in our project, but as I am trying to help out regarding #3 and #5 I migrated my locally checked out project. Hence, here is small PR. The CLA was filled out beforehand.

This branch / pull request represents v0.9 of SuperDelegate. v0.9 is a breaking change from v0.8, and has the following new features:

• Adoption of Swift 3.0 [RFC]
• Adoption of Swift 3.0 naming conventions [RFC]
• Adoption of iOS 10 SDK [in progress]

See issues for outstanding/known issues in v0.9.

Contributing

• Discovered a bug UIApplicationDelegate that we haven't addressed?
• Want a feature that does not exist?
• Found a bug?
• Dislike our take on Swift 3.0 naming conventions?
• Something else?

We want to hear from you! Please follow our contributing guidelines by filing an issue before submitting a PR. If you have a comment on a line in this PR, please file an issue with a link to the line number. Thanks!

Swift 4.2 introduced a bunch of churn around imported UIKit interfaces. The result is that SuperDelegate fails to build with Swift 4.2 entirely.

I'm happy to do the work to update the library for 4.2, but before I do: how have these updates been handled in the past. Do we want to maintain backwards compatibility, or do we want to bump the version number and only support 4.2+?

Closes #14

Just grabbed the low hanging fruit and adjusted the deployment target as well as the removal of settings the bounds to UIScreen.bounds programmatically.

It also worked before in our project, but as I am trying to help out regarding #3 and #5 I migrated my locally checked out project. Hence, here is small PR. The CLA was filled out beforehand.

When setting UIWindow's bounds to UIScreen.main.bounds it breaks apps on iPads with iOS 9 and higher. This is caused because of the multitasking feature introduced in iOS 9. Setting those bound make the app appear under the status bar. Having just makeKeyAndVisible results in correct behavior.

We should be able just use currentUserNotificationSettings. Not re-requesting will reduce noise on the API, and more over currentUserNotificationSettings is known to be more reliable than the notification settings passed down into application(_:didRegister:).

Our re-request is a holdover from iOS 7, e.g the days before currentUserNotificationSettings existed.