FIRMessagingRemoteNotificationsProxy updated to use GULAppDelegateSwizzler #2683
Changes required for #2591
The text was updated successfully, but these errors were encountered:
…DelegateSwizzler [WIP]" This reverts commit b2eabf2.
…public interface with no assumptions on the implementation details
…lementation details assumptions
…s applied to all targets. Move the hook to the top level to avoid confusion.
…etProxyOriginalDelegateOnceToken] at the beginning of each test.
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?