[question]: 5.0.0-beta1, how do I get the current tags for a user? and how do I correctly determine eligibility for a user?

[TobiasEdqvist]

How can we help?

Hello, I'm trying to prepare for your 5.0.0 version and have gotten stuck on two issues when migrating our code...

Firstly, how can we get tags for the current user? Previously we used;

OneSignal.getTags { tags ->
}

I seem to be unable to find an equivalent API call in 5.0.0. Seems like it should be available on OneSIgnal.User no?

Secondly, previously we used the following code to determine if a user is able to add tags to OneSignal. If these conditions are not fulfilled we've seen that the tags will not be ready to be sent to OneSignal and therefore we hide the selection option from our users if isSubscribed is not True.

private fun updateNotificationStatus() {
  val device = OneSignal.getDeviceState()
  
  val enabled = device?.areNotificationsEnabled() ?: false
  val subscribed = device?.isSubscribed ?: false
  val pushToken = device?.pushToken ?: ""
  val pushDisabled = device?.isPushDisabled ?: true
 
  if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) {
    isSubscribed.value = (subscribed || pushDisabled || pushToken.isNotBlank())
  } else {
    // On older SDKs the pushToken might be filled before it is actually possible
    // to use, avoid that as a constraint for older android versions.
    isSubscribed.value = (subscribed || pushDisabled)
  }
 
  notificationsEnabled.value = (enabled && subscribed && !pushDisabled)
}

If I've understood correctly we in 5.0.0 only will have access to;

val pushSubscription = OneSignal.User.pushSubscription
val permission = OneSignal.notifications.permission
val pushToken = pushSubscription.token
val enabled = pushSubscription.optedIn

Is OneSignal.notifications.permission equivalent to the previous device?.areNotificationsEnabled() and pushSubscription.optedIn equivalent to device?.isPushDisabled? and device?.isSubscribed is always True / not needed anymore?

Code of Conduct

• I agree to follow this project's Code of Conduct

[jkasten2]

@TobiasEdqvist Thanks for feedback! Breaking down your questions below.

Get Tags

User tags are write-only currently on the SDK. We are open to changing, however we would like to understand how you use OneSignal.getTags currently. Could you share your use-cases?

When is it safe to write tags?

You should be able to set tags at anytime (even in 4.x.x) without any issues. If you see issues in 5.0.0 where this isn't working please let us know though.

Notification Enabled

If you need to know if your user wants notifications you can simply check if OneSignal.User.pushSubscription.optedIn is true. This means they have accepted the native Android notification permissions (and didn't disable them in the system settings) and OneSignal.User.pushSubscription.optOut() wasn't called.

Is OneSignal.notifications.permission equivalent to the previous device?.areNotificationsEnabled() ...

yes, this maps directly.

... and pushSubscription.optedIn equivalent to device?.isPushDisabled? and device?.isSubscribed is always True / not needed anymore?

pushSubscription.optedIn combines both the old device?.isPushDisabled and OneSignal.notifications.permission. There isn't a server side check for is subscribed any more, however let us know the your use-case if this is a must have your app.

[TobiasEdqvist]

Get Tags:
We use it to synchronize our own data storage and presentation that are linked to if a certain tag exist in OneSignal (i.e. the user receives a set of notifications related to the tag). We also use it to synchronize if tags for some reason failed to be sent to OneSignal, then we reset our own storage as well on next launch. Sometimes we also reset tags in the backend (before new seasons/tournaments) and we use OneSignal tag storage to let our users know which tag they've actually activated/have active after a reset.

OneSignal.getTags { tags ->
    val favoriteTeams: MutableSet<String> = mutableSetOf()
    tags?.keys()?.asSequence()?.let {
        var remoteTags = it.toSet()
        ... // Some cleaning and conversion code removed
        cleanedTags.forEach { tag ->
           favoriteTeams.add(tag)
        }
    }
    dataStoreManager.setFavoriteTeams(favoriteTeams)
}

Thanks for clarification regarding Notification Enabled state! We've previously determined that if not all those conditions were met the OneSignal API would still be initializing itself and not be ready to respond with a response in getTags. We want to wait until we have synchronized our local storage of tags with what is available on the OneSignal backend before showing tag status to the user in our app. But maybe not needed anymore in v5.0.0! We will test once we've either worked around getTags somehow or if we can access the tag storage in v5.0.0 as well :)

[jkasten2]

@TobiasEdqvist Thanks for the details on your tag use-case, this is very help!

If I understand correctly it sounds like you have been using OneSignal.sendTags and OneSignal.getTags to save and load notification preferences? In your case which teams your users want push notifications for? Lastly, you don't have these notification preferences stored on your server / backend so you have been using OneSignal.getTags correct?

Let us know if we understood your use-cases correctly!

[TobiasEdqvist]

@jkasten2
That is correct!

We could store these on our server as well, however, we would still like getTags to be available since that is currently our only way of verifying that the storage on OneSignal is in fact in sync with what we show our user is their notification preferences. Scenario; Our server is successfully updated with the preference storage but the tag fails to synchronize with OneSignal. The user believes it will receive notifications for a given team, but OneSignal does not have this tag actually stored due to some unknown error.

(This applies to our iOS app as well, but we started the testing of 5.0.0 on Android, so we've kept the feedback here for now!)

[Popda]

@jkasten2 Will you add getTags()?
Even if user tags would be stored on our server, managing them will be close to a attempt to predict future.
Why should we store "user supposed to have tags list" on our side when actual user tag list is stored by OneSignal?

Also, what if I'll need to clear tags for user or taglist on our side will be lost?
write-only tags is highly uncomfortable solution

[Popda]

Use-case for getTags in my case: we store only those tags on our server that user should have, so we check tags that user currently have with getTags to manage/update active tags

[billdacat]

Seconding (or thirding) this -- we're having to rewind our upgrade to the new SDK due to this. Same use case, we store settings preferences this way, and we can't set the sliders appropriately if we can't read the current values from OneSignal. This is a huge step backwards.

[dev-lcc]

Any updates regarding getTags() implementation?

[timeisgolden]

I want to get all tags, but there is no way to get the tags.
getTags() is implemented?

Thanks in advance

[TobiTobsn007]

I need getTags() as well. I am saving the time when the user wants to get notified (daily notification). And I want to display this settings on the UI.

[mayckondf]

I also use to get the user notification preferences

[oobi]

We have the same use case. User chooses what tags they want to receive notifications for. It doesn't makes sense to store that locally when the "source of truth" is on the server.

[billdacat]

Regarding that last linked thread here and the closure of it, is it safe to assume that reading tags is no longer on the roadmap/under consideration? If so, that is quite unfortunate for those of us who used it to store notification preferences.

[tiferet-blazepod]

Hi, I also need the getTags option. I use it to count the number of times something has happend - so when the trigger is happening I get the current tag value (which is an int) and then I increment it.
Is there another way to do so without the getTags option?

[jennantilla]

Hello everyone! Just wanted to post here in case you missed our 5.0.5 release, which added back the getTags method. We appreciate everyone's patience!