push_enabled is not updated after permission is granted

[tfcporciuncula]

SDK version: 3.6.4

Environment: Development and Production

Are logs available? I don’t think it’s relevant

Describe the bug

When users grant push notifications permission, CIO doesn’t update and still has push_enabled as false for that particular device. It only gets updated after the app is killed and opened again. This issue is also present on iOS.

Looking at here I kinda see why this is the case since we simply make that call once and that’s it, and it seems it’s similar on iOS as well.

To Reproduce

• Create a new user and observe push_enabled is false
• Grant notification permissions and notice push_enabled is still false
• Kill and open the app, observe now push_enabled is updated to true

Expected behavior

Either the SDK should automatically notice the permission was granted so it can update itself right away (I don’t think there’s a good way to achieve that, though, since what Accompanist currently does for that is to simply check the permission in the resume lifecycle event, for instance), or it should provide an API that we can call to update this as soon as the permission is granted. Is there currently an API for this that I’m missing? Do I simply need to call identify again or should I simply restart CIO if the permission is granted?

I also think the documentation should highlight this case as it’s quite critical for us that this is updated as soon as our users grant permission. Maybe here you could say that if an identified user grants permission, there’s still something we need to do to make sure this is immediately reflected on the customerio side?

[mrehan27]

Thanks a lot for the detailed feedback. We really appreciate you taking the time to explain the issue.

As a quick workaround, you can use the CustomerIO.instance().deviceAttributes method to update push_enabled. Any changes you make to device attributes should update the value for you without needing to relaunch the app. Do let me know if this doesn't work for you.

Regarding the behavior you experienced, this is expected, and I've shared your findings with the team so we can discuss this internally. We will keep you updated on the progress. Also, thank you for the feedback on areas where our documentation can be clearer; we'll review it and make updates accordingly where needed.

Thanks again for your help in making our SDK better. If you have any more feedback or questions, please feel free to reach out.

[tfcporciuncula]

Thanks for the quick response!

How exactly should I use deviceAttributes? It’s not mutable, so it’s not very clear how I can update push_enabled. Do I need something weird like this or am I missing something?

val deviceAttributes = CustomerIO.instance().deviceAttributes.toMutableMap()
deviceAttributes["push_enabled"] = true
CustomerIO.instance().deviceAttributes = deviceAttributes.toMap()

Edit: now I see this is a map of custom device attributes, right? So if I set a custom attribute that has the same name of a non-custom attribute, it overrides it? Which means I can simply go with something like this?

CustomerIO.instance().deviceAttributes = mapOf("push_enabled" to true)

[mrehan27]

Yes, that's correct! If you set the same name using the deviceAttributes, the value you pass will take priority and override any value previously set by the SDK. Additionally, if you pass any other value to deviceAttributes, the SDK will rebuild the device attributes, automatically updating the value for push_enabled.

If you have any more questions or need further assistance, please feel free to reach out!

[tfcporciuncula]

Thanks! I actually do have another question: do you think it makes sense for us to use push_enabled to determine who to send pushes to? Or that’s not really the purpose of this attribute? I’m asking this question because this is actually the reason why this is critical to us: we noticed we were potentially missing users as we currently rely on this attribute for deciding whether we should send a push or not.

[mrehan27]

The push_enabled flag is primarily intended to determine whether a user has allowed notifications on their device or not. While it's useful for understanding their notification settings, it may not be necessary to decide whom to send push notifications to, as notifications sent to them will automatically be blocked by the OS and will not be displayed on their device. However, the metrics will show the notification as delivered because it reached the user's device.

On the other hand, you can use the push_enabled flag to create segments and run campaigns to target users with relevant in-app messages, emails, or other forms of communication, even if they have notifications disabled. This way, you can ensure that important information reaches your users through alternative channels.

Since the solution resolves the issue for you, I will proceed to close this ticket. If you encounter any other problems or require further assistance, please don't hesitate to reopen this or open a new issue, or reach out to us. We appreciate your cooperation.

Even though this issue is closed, please remember that you can still ask more questions or seek further assistance if needed. Thank you!