-
Notifications
You must be signed in to change notification settings - Fork 263
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Fix] swizzling not forwarding with apps that use UIApplicationDelegateAdaptor #1091
Commits on May 19, 2022
-
add AppDelegate swizzling test to add selectors
Add testAddsMissingSelectors to ensure we add all selectors we need to get events from iOS. The change made to setOneSignalDelegate was required to make it testable. This equality check is already done in setOneSignalUNDelegate so this is also helping match our logic between these.
Configuration menu - View commit details
-
Copy full SHA for 6e0a685 - Browse repository at this point
Copy the full SHA 6e0a685View commit details -
add SwizzlingForwarder and test using it
Added one failing test for the case where forwardingTargetForSelector is not accounted for in swizzling. The most common case for this is a SwiftUI app with @UIApplicationDelegateAdaptor. Just added one test and fixed one case to keep this PR small and readable, will add the rest in a follow up commit.
Configuration menu - View commit details
-
Copy full SHA for a22f6d3 - Browse repository at this point
Copy the full SHA a22f6d3View commit details
Commits on May 20, 2022
-
Add remaining forwarding logic to AppDelegate
iOS 9 selectors we only swizzle on iOS 9 since UIApplicationDelegateAdaptor requires a newer version of iOS.
Configuration menu - View commit details
-
Copy full SHA for 91c2c69 - Browse repository at this point
Copy the full SHA 91c2c69View commit details -
This fixes a bug where an infinite loop happens when we call the origin implementation if delegates we swizzle if something attempts to set the delegate back to the original class. This would only happen if the class didn't have the target selector to begin with when we run this swizzle logic, but then it is called a 2nd time with same target class. We have a check in the setOneSignalDelegate and setOneSignalUNDelegate but if the app developer or another library changes the delegate then puts it back this scenario can happen. Added a test for this scenario, ensuring it fails and then passing after. This also fixes an issue in the last commit where this bug was causing tests after UIApplicationDelegateSwizzingTest to infinitely loop.
Configuration menu - View commit details
-
Copy full SHA for ce1c876 - Browse repository at this point
Copy the full SHA ce1c876View commit details -
Configuration menu - View commit details
-
Copy full SHA for bba27a8 - Browse repository at this point
Copy the full SHA bba27a8View commit details -
Fix testUNUserNotificationCenterDelegateAssignedBeforeOneSignal
This test broke in the last commit since the test was relying on a 2nd call to injectSelector to unswizzle. This was intentionally done as we don't want app or other SDKs swapping delegates back and forth to cause OneSignal to no longer receive events. This forced me to rewrite the OneSignalUNUserNotificationCenterHelper used for tests to not reply on this behavior and in the process made much simpler. It is declarative of the methods to swap back and therefore much easier to understand.
Configuration menu - View commit details
-
Copy full SHA for e646a9f - Browse repository at this point
Copy the full SHA e646a9fView commit details -
OneSignalUNUserNotificationCenterHelper warnings
Fix missing selector warns in this file from the last commit since.
Configuration menu - View commit details
-
Copy full SHA for 1a2b961 - Browse repository at this point
Copy the full SHA 1a2b961View commit details -
Add testSwizzleExistingSelectors
Add test to ensure our swizzling still calls the original methods.
Configuration menu - View commit details
-
Copy full SHA for 9a6c8c4 - Browse repository at this point
Copy the full SHA 9a6c8c4View commit details