On Jan 15, 2016, at 4:56 PM, Jens Alfke <j...@mooseyard.com> wrote: > >> On Jan 15, 2016, at 1:31 PM, Alex Zavatone <z...@mac.com> wrote: >> >> However, a good amount of app startup and config is triggered in the >> appDelegate, same as push notification, opening the app via URLs and other >> appDelegate related tasks would conflict with the appDelegate of the app >> using the framework. > > I think what you’re asking is how the framework can hook into the same calls > that the app delegate receives, even though it can’t provide an app delegate > of its own? > > Many of the UIApplicationDelegate methods are also posted as equivalent > NSNotifications. For example, there’s an > UIApplicationDidFinishLaunchingNotification that’s posted at the same time as > -application:didFinishLaunchingWithOptions:. (Well, it’s going to be either > just before or just after, but you shouldn’t rely on any particular > ordering.) It’s easy to have your framework observe those notifications once > it’s initialized. > > Some of them don’t have notifications because they need to return a response > or because it wouldn’t make sense to have more than one handler; for example > -application:openURL:options:. Here the only thing you can do (AFAIK) is to > define an equivalent method in your framework’s API, and have the actual app > delegate call that method in addition to whatever else it would normally do. >
Well, awesome. That’s just what I’m going to try out and verify. Thanks. >> Is there a set of standard operating practices that are available online to >> review for this type of app restructuring? > > Not that I know of. > > —Jens _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
