| 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
|
| |
|
|
|
|
|
|
| |
* 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
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
* 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.
|
|
|
|
| |
This is a slight tweak to the block comment describing `-retrieveFCMTokenForSenderID:completion:`, to more explicitly mention that this can be used to support the scenario of allow multiple senders to send notifications to the same client app.
|
|
|
| |
The header comments are directly reflected in Firebase documentation, so this improves that as well.
|
|
|