This repository has been archived by the owner on Sep 4, 2020. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
[ios] "the right way" to swizzle #427
Labels
Milestone
Comments
PR merged |
i imagine you mean this pr #426 (thanks for merging :-)) but the code still uses the pr i'm referring too in this issue does not yet exist :-) |
@athibaud my bad |
devgeeks
added a commit
that referenced
this issue
Mar 1, 2016
This still isn't the "right way" linked in #427, but seems to be safe and void of side effects due to the namespacing of all the methods. It has been tested to work side by side with another plugin that also swizzles AppDelegate's applicationDidBecomeActive. 1. wrapped swizzling in dispatch_once 2. first attempts class_addMethod / class_replaceMethod but if that fails falls back to method_exchangeImplementations. 3. swizzled_init => pushPluginSwizzledInit (if other plugins attempt to swizzle init and use the same name, there seems to be a collision) 4. added an observer for UIApplicationDidBecomeActiveNotification instead of overriding applicationDidBecomeActive 5. applicationDidBecomeActive => pushPluginOnApplicationDidBecomeActive (and it becomes a notification observer instead) See http://nshipster.com/method-swizzling/ and "Avoid collisions" under "Considerations". This will need testng by someone that understands the plugin better than I do, but it should not be changing the core functionality at all. The pushPluginOnApplicationDidBecomeActive method *is* called when the application becomes active, etc. Goes a long way toward fixing #427 without regressing #447, etc.
Closed
macdonst
pushed a commit
that referenced
this issue
Mar 9, 2016
This still isn't the "right way" linked in #427, but seems to be safe and void of side effects due to the namespacing of all the methods. It has been tested to work side by side with another plugin that also swizzles AppDelegate's applicationDidBecomeActive. 1. wrapped swizzling in dispatch_once 2. first attempts class_addMethod / class_replaceMethod but if that fails falls back to method_exchangeImplementations. 3. swizzled_init => pushPluginSwizzledInit (if other plugins attempt to swizzle init and use the same name, there seems to be a collision) 4. added an observer for UIApplicationDidBecomeActiveNotification instead of overriding applicationDidBecomeActive 5. applicationDidBecomeActive => pushPluginOnApplicationDidBecomeActive (and it becomes a notification observer instead) See http://nshipster.com/method-swizzling/ and "Avoid collisions" under "Considerations". This will need testng by someone that understands the plugin better than I do, but it should not be changing the core functionality at all. The pushPluginOnApplicationDidBecomeActive method *is* called when the application becomes active, etc. Goes a long way toward fixing #427 without regressing #447, etc.
This thread has been automatically locked. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
it seems using
method_exchangeImplementations()
can have some undesired implications and the right way to do method swizzling is to usemethod_setImplementation()
shouldn't run into the implications described in that article seeing the use of this plugin is more of a standalone application use rather than library use but still.
i could implement and pr this if needed.
cheers
The text was updated successfully, but these errors were encountered: