This is official image notification support for FCM. Now an image can be rendered in notification when user enable service extension and calling the extensionHelper API.
* FirebaseMessaging: `NSUserDefaults` replaced by `GULUserDefaults`
* FirebaseMessaging: `GoogleUtilities/UserDefaults` added to dependencies. `GoogleUtilities` dependencies version updated to `~> 5.3`
* FIRMessagingPubSub: imports order
The singleton is cached and vended from the Core component system, we
shouldn't wrap it in a dispatch_async or cache it with a global variable.
This matches a change internally that has been made and shipped.
* Prevent Messaging and IID singleton usage during tests.
* Remove other uses of static Messaging instance.
* Removed usages of messagingForTests.
* Remove unused imports, unify testing code.
* Use local import path instead of framework import.
* Addition of global data collection switch.
* Added Messaging conformance to data switch.
Also formatted code.
* Move data collection flag internal until all SDKs conform to it.
* Formatting in response to code review.
* Migrate Firebase off @import statements
* - Migrate tests and test utils from @import to #import.
- Update Xcode projects for tests to explicitly link in framework deps.
- Update check_no_module_imports.sh to look for @imports in tests/test utils/
integration tests.
* Ensure check_no_module_imports.sh explicitly exits with code 0 on success.
This new delegate method will be called generally once per app start, to always provide a current token. This token may change over time. This simpler method makes integration much simpler, as:
* Developers no longer have to check for a current token using the `.fcmToken` property, and also check for token changes using the `-messaging:didRefreshRegistrationToken:` delegate method.
* There is a single code path for when a token is available, making operations that depend on a token being available easier to implement. For example, this is the right method to always upload your FCM token to your application server, or to subscribe to topics, etc.
FCM's swizzling of the user notification center currently swizzles only one of the two optional delegate methods (userNotificationCenter:willPresentNotification:withCompletionHandler:), but not the other (userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:).
The didReceiveNotificationResponse, if implemented by the delegate, is the sole receiver of all user action on a notification, including simply tapping on the notification itself. Prior to this change, if the developer had implemented didReceiveNotificationResponse, then FCM would not be able to collect this event for analytics.
Additionally, I changed the logic in FIRMessagingRemoteNotificationsProxy to check whether these methods are actually implemented before swizzling them. It was always swizzling, which meant it was adding an implementation if the method didn't exist. This would confuse iOS into thinking the developer did implement these methods and NOT fall back to delivering the notifications to the application delegate.
With this change, if the developer did not implement these methods, then FCM will not swizzle those methods. That keeps the behavior true to what the developer intended.
Chen Liang