On Jun 4, 2016, at 3:14 PM, Quincey Morris wrote: > On Jun 4, 2016, at 12:44 , Alex Zavatone <[email protected]> wrote: >> >> I'm wondering if (man, I detest the term) method swizzling of the app >> delegate would work or possibly modifying the methods of UIApplication at >> runtime to pipe the methods to a class in the framework? >> >> Initially, i'm going to add them to the UIApplication but I'd like to have a >> nice little self enclosed framework that is able to handle them. > > So, in effect you want to perform a code injection attack on the app which > you don’t control?
Well, that's what I'm asking! Do I? Or is there a better method? It's not an "attack", it's a feature. > > Why not provide some initialization methods for the framework that are given > the results of those delegate methods. That way you are being an honest > citizen, because it’s explicit what functionality the framework is designed > to control. It imposes the need for a few lines of glue code in the app > delegate, but if that code doesn’t do it, it’s not your fault. > Well, this is functionality that I am trying to add as part of the framework. The limitation to having these methods within the appDelegate makes this framework a much less modular solution. Currently, the hosting app just needs 1 line of code to start up and use a whole app that is within the framework. Not being able to get the APNS token within our framework makes it harder to pass it back to our servers without the involvement of someone else putting the required calls back to our framework in the appDelegate of their app. That and responding to remote notifications as well. The idea of the framework is to have our app as a self contained module to run in any other app. Not being able to handle push notifications from within our framework is a less than elegant solution. To be honest, our app is only ready for push notifications after a few round trips to get data from a server. And then when notifications come in, we don't want the hosting app to have to handle them, because well, they are for the framework. I trust that we're also going to have a few issues with custom URL schemes as well, which we also respond to. _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
