Releases: Azure/azure-notificationhubs-android
v1.1.4
- Fixing bug which prevented the Firebase Messaging ID from being discovered when this library was adopted and used for the first time with an update. See Azure/azure-notificationhubs-xamarin#21 for more detail.
- Upgrading Firebase Messaging library to version 21.
v1.1.3
- Introduces an FCM optimized SKU of the Azure Notification Hubs Android SDK. Available for download here, or by using
implementation 'com.microsoft.azure:notification-hubs-android-sdk-fcm:1.1.3'
in yourgradle
file. Note this is an alternate package, and can't be used with the general package. - Adds detail to the
NotificationHubException
message that was previously accessed only through getter methods.
v1.1.2
v1.1.1
- Updating
Installation.setUserId
to be publicly accessible to matchNotificationHub.setUserId
. - Fixing issue #123, which caused a Runtime exception if
NotificationHub.start
was called after onCreate had finished. - Fixing issue #121, where use of
NotificationHub.{get, set}UserID
would cause aNullReferenceException
.
v1.1.0
- Adds UserID methods, which makes identifying devices by the associated user a first-class scenario.
NotificationHub.setUserId("john.doe@example.com"); System.out.println(NotificationHub.getUserId());
- Remove explicit start of
FirebaseReceiver
, in favor of allowing Android to start the service for us implicitly.
v1.0.1
v1.0.0
In 1.0.0 we introduce a new model for using Azure Notification Hubs in your Android application. This approach is rooted in using Installations to more easily gather all of the relevant ways of contacting the device. This release also seeks to dramatically simplify the code you need to write to get up-and-running with Azure Notification Hubs. Just drop in your credentials, register a callback, and you're good to go.
Since the last preview, we've added our own NotificationHubsException types to help identify errors as they are returned from the server.
v1.0.0-preview3
A fairly incremental set of changes, as we settle in on the way we'd like this SDK to solidify our surface area.
DebounceInstallationAdapter
now will let at least one Installation through each day.- The
Installation
associated with this device is now automatically renewed every time an Installation is set the NotificationHub backend. ItsexpirationTime
will be set to 30 days from the current date. addTemplate
is nowsetTemplate
and has "upsert" characteristics.- Examples have been published to demonstrate how to populate tags to replicate App Center Push Device Properties.
v1.0.0-preview2
Incremental improvements from preview1, still preparing for a GA release in the future. We've added the following surface area:
- Built support for the
InstallationTemplate
type. - Added the interface
InstallationAdapter
which offers a contract for saving anInstallation
to a backend. - Offer an alternate
NotificationHub.initialize
method which accepts a custom InstallationAdapter, instead of Notification Hub credentials. - Provide callbacks for success and failure to save a Installation to the back-end.
- Remove dependency on Android Volley.
v1.0.0-preview1
This release previews the new namespace com.microsoft.windowsazure.messaging.notificationhubs
. This is a major overhaul of the SDK, and is an attempt to make registering your device with Notification Hubs, and listening for notifications much easier. Notably, it is also specifically designed to help developers who are moving to Notification Hubs from App Center Push, which is being retired. Some highlights of the new functionality when compared to previous releases include:
- Users no longer needs to implement their own
FirebaseMessagingService
. - On initialization, and after any changes to applicable tags, etc., your device is automatically registered with Azure Notification Hubs.
- Transitive dependencies are now automatically handled for you. No need to independently pull in Firebase.