> 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. > 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
