| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
isDirectChannelEstablished as it represents whether user "should" connect instead of whether user "is" connected (#1190)
shouldEstablishDirectChannel cannot be replaced by isDirectChannelEstablished as it represents whether user "should" connect instead of whether user "is" connected
|
| |
|
|
|
| |
This fixes a bug that when we delete IID, IID refreshes new checkin info and FCM stops querying the checkin if checkin exists. And this causes FCM using staled checkin info and not able to receive data message.
|
| |
|
| |
|
|
|
|
|
|
| |
(#1094)
* remove a call that is triggered by IID, but no longer possible once we remove the deprecated method in IID
|
|
|
|
| |
Getting warning message from xcode so we need to define it to remove warning.
|
| |
|
|
|
|
|
|
| |
* remove deprecated data message callback
* Fix the issue that swizzling is not setup in recommended data message callback for message tracking.
|
|\
| |
| | |
Release 4.12.0
|
| |
| |
| |
| | |
* Remove deprecated remoteMessageDelegate and simplify the shouldEstablishDirectChannel property
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* updates the changelog for pending release (#1025)
* updates the changelog for pending release
* addresses comment
* Fix the comments for subscribe to topic (#1026)
|
|/ |
|
| |
|
| |
|
|
|
|
|
|
| |
(#1001)
* add new topic subscription/unsubscription method with handler
|
| |
|
|
|
|
|
| |
* fix the issue that handler not get triggered
|
|
|
|
|
|
| |
* improve the documentations on auto init property
* adjust the comments
|
| |
|
| |
|
|
|
|
|
|
| |
* add CHANGELOG for FCM
* fix the typo
|
| |
|
|
|
|
|
|
|
| |
Added functionality not exposed in public header yet. I would leave to next FCM SDK owner to expose this functionality (and follow any required review process).
Bugs:
72701086
|
|\ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/
|
|
| |
Qualify all cross-pod imports of FirebaseCore headers
|
|
|
|
| |
part adding prefix.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
* Replacing FIR_SWIFT_NAME macro with NS_SWIFT_NAME.
This pushes the minimum Xcode version to 7.3, as NS_SWIFT_NAME was
limited before that version (which is why the macro was introduced in
the first place).
* Fixed FIRMessaging header
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
| |
The previous message was worded in a way as to imply that the FIRAppDelegateProxyEnabled key **should** be set to NO, disabling swizzling. This clarifies that message, indicating that this is for developers who would prefer to manually integrate the SDK.
|
|
|
|
|
| |
This fixes a bug in the automatic direct channel logic, where a failure to get checkin info from the Instance ID SDK was resulting in a non-retrying failure, causing the automatic connection logic to not retry connecting. A listener is added for a new notification that will be fired from Instance ID. When that notification is fired, `FIRMessagingClient` will re-attempt to connect.
NOTE: The actual fix will not work until the Firebase InstanceID SDK is also updated.
|
|
|
|
|
|
| |
This removes the `FIRMessaging_FAIL` macro which was using `__builtin_trap()`, and replaced with `NSAssert` calls. These `NSAssert` calls may not get called in release builds, and so we also log them with FIRLogger error messages.
The RMQ database open error result code is now parsed and included in the error message to help us identify causes for #199 .
|
|
|
|
| |
This should address the issue filed at: https://github.com/firebase/quickstart-ios/issues/242, where a topic name containing a `%` character was failing. It turns out that the topic name was never being url-encoded.
|
|
|
|
|
| |
This seems to be a holdover from some old code, and it's not being used anywhere in the component. Plus it's better not to be saving anything in `[NSUserDefaults standardUserDefaults]` as that is the developer/app's domain.
Also renamed the messaging code while I was in there to be something meaningful ("000" → "PrintLibraryVersion").
|
|
|
| |
This addresses #125, where a developer is setting `.shouldEstablishDirectChannel` in a background thread, and getting a main thread sanitization issue in Xcode 9.
|