-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
FIRMessagingRemoteNotificationsProxy updated to use GULAppDelegateSwizzler #2683
Conversation
…DelegateSwizzler [WIP]" This reverts commit b2eabf2.
…public interface with no assumptions on the implementation details
…lementation details assumptions
Conflicts: Example/Messaging/Tests/FIRMessagingRemoteNotificationsProxyTest.m
…s applied to all targets. Move the hook to the top level to avoid confusion.
…etProxyOriginalDelegateOnceToken] at the beginning of each test.
…sts added. Cleanup
@@ -272,3 +261,14 @@ target 'InstanceID_Example_tvOS' do | |||
end | |||
end | |||
|
|||
# Set define to turn on GUL_UNSWIZZLING and GUL_APP_DELEGATE_TESTING for the unit tests | |||
post_install do |installer_representation| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now (Cocoapods 1.6.1) there is only post_install
hook supported for entire Podfile. It affects all targets anyways, so I moved it to the upper level to avoid confusion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool, thanks!
@@ -376,6 +459,18 @@ + (void)createSubclassWithObject:(id<UIApplicationDelegate>)anObject { | |||
} | |||
objc_setAssociatedObject(anObject, &kGULOpenURLOptionsSourceAnnotationsIMPKey, | |||
openURLSourceAppAnnotationIMPPointer, OBJC_ASSOCIATION_RETAIN_NONATOMIC); | |||
objc_setAssociatedObject(anObject, &kGULRealDidRegisterForRemoteNotificationsIMPKey, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, that's definitely an option! Feel free to refactor that in a separate PR :)
@chliangGoogle I tested basic use-cases like receiving messages sent from the console. Are there any cases I need to pay a specific attention to. |
Receiving messages are not enough for testing swizzling, if you look at the implementations, we swizzle because for a few reason. A. to be able to track analytics events, so would be great to check if Analytics is able to track notification_open or notification_foreground event; You can use the "debug mode" on Analytics console to see if a notification is opened or in foreground; B. when APNS token is updated, we need to notify FCM, so would be great if we can also make sure that logic is called. Basically we need to make sure all the "swizzled logic" is actually getting triggered. Does that make sense? |
Example/Messaging/Tests/FIRMessagingRemoteNotificationsProxyTest.m
Outdated
Show resolved
Hide resolved
|
||
@interface FIRMessagingRemoteNotificationsProxy () | ||
@interface FIRMessagingRemoteNotificationsProxy () <UIApplicationDelegate> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there an alternative than following this protocol? This makes macOS support very hard .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Refer comment below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chliangGoogle Does FCM support MacOS now? If not, I can take care of MacOS support for GULAppDelegateSwizzler
in a separate PR. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@maksymmalyhin FCM does not yet support MacOS. It recently added tvOS See https://github.com/firebase/firebase-ios-sdk/blob/master/FirebaseMessaging.podspec#L22
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@paulb777 It looks like tvOS has no difference in the App Delegate, so supporting tvOS by GULAppDelegateSwizzler
should be trivial. I'll update it in this PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will we make GULAppDelegateSwizzler macOS support in this PR? If not, we can add a todo and fix in another PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I created a ticket for this #2706
@@ -466,39 +389,36 @@ id getNamedPropertyFromObject(id object, NSString *propertyName, Class klass) { | |||
return property; | |||
} | |||
|
|||
#pragma mark - Swizzled Methods | |||
#pragma mark - UIApplicationDelegate |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tejasd Is this required that if I use GULAppDelegateSwizzler and I need to swizzle some methods under UIApplicationDelegate, my class must follow the protocol and implement the methods here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the current design, yes. If that's a blocker we can create our own protocol, say GULAppDelegate which can be platform agnostic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Needs approval from @chliangGoogle
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM on FCM part.
Also need approval from @tejasd
Example/Messaging/Tests/FIRMessagingRemoteNotificationsProxyTest.m
Outdated
Show resolved
Hide resolved
|
||
@interface FIRMessagingRemoteNotificationsProxy () | ||
@interface FIRMessagingRemoteNotificationsProxy () <UIApplicationDelegate> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will we make GULAppDelegateSwizzler macOS support in this PR? If not, we can add a todo and fix in another PR.
…Notification:` for tvOS just in case
@@ -107,6 +122,10 @@ - (void)userNotificationCenter:(UNUserNotificationCenter *)center | |||
@end | |||
#endif // __IPHONE_OS_VERSION_MAX_ALLOWED >= __IPHONE_10_0 | |||
|
|||
@interface GULAppDelegateSwizzler (FIRMessagingRemoteNotificationsProxyTest) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider importing the private header.
@@ -272,3 +261,14 @@ target 'InstanceID_Example_tvOS' do | |||
end | |||
end | |||
|
|||
# Set define to turn on GUL_UNSWIZZLING and GUL_APP_DELEGATE_TESTING for the unit tests | |||
post_install do |installer_representation| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool, thanks!
Conflicts: GoogleUtilities/AppDelegateSwizzler/GULAppDelegateSwizzler.m GoogleUtilities/Example/Tests/Swizzler/GULAppDelegateSwizzlerTest.m
@maksymmalyhin Please make sure to test it with Analytics to ensure the notification tracking still works. |
Changes required for #2591
NOTE:
FIRMessagingRemoteNotificationsProxy
still swizzlesUNUserNotificationDelegate
methods in its own way. I think, we should refactor it as a separate PR once we finish refactoring of app delegate swizzling in all libraries.