Is there any way to detect what user choose when promoted with the "allow push notification" dialog?
I want to catch what user choose at the moment he tap one of the dialog buttons ("Allow" or "Don't Allow")
any why I can do this?
I'm afraid not. While you can determine whether notifications are enabled (using UIApplication's isRegisteredForRemoteNotifications method), this does not tell you why notifications are not registered when they aren't.
It could be for any of the following reasons:
• The user has never been prompted for them.
• The user has specifically declined them.*
• The user approved them at some point, but has since turned them off.*
It's unfortunate that Apple does not provide a means to detect a user declining push notification registration when prompted. I suspect this is a conscious design decision intended to make it less likely for developers to harangue users.
I hope this helps.
(* ...you could infer which of the second and third options applies by storing a persistent flag upon the first registration, but this doesn't seem to be what you're asking for...)
There is no direct way of doing this, but I've implemented a workaround: APNPermisionRequest.
The interesting part here is to add an observer for UIApplicationDidBecomeActiveNotification and then show the request. After the notification is fired (ie. the request was answered), you can check for the status using [[UIApplication sharedApplication] isRegisteredForRemoteNotifications].
Related
If I enable FCM swizzling in iOS, I found that the FCM token is still there even when user turns off the device notification setting for my app(probably saved in app data).
It seems not logical to manage this setting anymore inside the app since FCM takes care of that part for me.
I have 2 questions:
Do I need to create a Notification setting switch inside my app so that user can turn on or turn off the notification?
If I need to do #1, how do I call the FCM registration manually?
I know that this api [FIRApp configure] will do everything automatically.
I think following pointers should help you answer the question.
Generically (Regardless of which SDK you use), generating and maintaining deviceToken is completely decoupled from the permissions prompt and the response given to that prompt. There are use cases like silent pushes which can be used to send pushes to the device without even asking the user for permissions (well, these pushes invoke your app for data refresh, but can not show anything on UI)
Even when we prompt the user for permissions, denying the permission does not invalidate the token that has been generated already. The UI based pushes(Alert, Badge, Sound) sent in this case, will still land on the device but iOS will not render those notifications after checking the user's permissions.
So based on above data points, to answer your question,
Do I need to create a Notification setting switch inside my app so that user can turn on or turn off the notification?
Yes, its certainly a good idea to have it so, but note that after the initial permissions prompt the same dialog wont be shown again, hence its better to redirect the user to settings of your app where he can re-enable the notification permissions, refer to this thread on implementing the same.
If I need to do #1, how do I call the FCM registration manually? I know that this api [FIRApp configure] will do everything automatically.
I don't have experience in using Firebase directly, but, mostly you don't need to tell anything to Firebase, because it already has a token and it can sent pushes to this device anytime, the next push that comes after user modifies the setting will automatically show up according to latest preferences of the user.
In my settings tabbar:
I have a feature specific switch which can be turned OFF or ON based on API response.
From website only admin is authorized to turn ON/OFF.
I can make /user API call everytime on settings tap to check the current settings for the user but there are couple of disadvantage like if user is already on setting then it will not update the UI and calling api everytime on settings tap doesn't sounds a perfect solution.
I think better solution is to send a silent push notification which i can use to make the API call to update the settings UI whenever needed.
But if user has disabled the push notification will I still receive silent push ? What is the recommended approach to handle such situations ?
Short answer, yes
The exciting new opportunity for app developers in iOS 8 is that Apple will now deliver “silent” pushes even if the user has opted out of notifications. Also, “silent push” is no longer just for Newsstand apps. Every app can take advantage of this ability to refresh content in the background, creating the most up-to-date, responsive experience possible, the moment the user opens the app.
Although...
Users still have the ability to switch off your app’s ability to process a “silent push” by means of the “Background App Refresh” control. Even though Apple Push Notification service (APNs) will deliver a push marked “content-available” to your phone, the OS will not wake up your app to receive it, effectively dropping it on the floor. However, opting out of “Background App Refresh” is a lesser-known capability not directly associated with Notifications. You don’t access this preference in your Notifications Settings--it’s located under General > Background App Refresh screen.
Keep this in mind when building your application.
Source:
https://www.urbanairship.com/blog/watch-list-ios-8-opt-in-changes
This matrix might help. At left hand side, it shows if "didReceiveRemoteNotification: " method will get called or not. Other two columns is related to setting app. Settings -> YourApp. If yourApp supports Notifications and background app refresh. Look into matrix to check when you app will receive silent push.
Other answers are good. But they are not official answers.
The official answer is in What's New in Notifications WWDC 2015 video:
Silent notifications are enabled by default. The user does not need to
approve your -- does not give permission to your app to use them, and
you can just start using them without asking the user for permission.
But silent notifications are the mechanism behind background app
refresh. At any point you know that the user can go in settings and
disable them. So you can't depend on them always being available. You
don't know if the user the turn them off, and you are not getting a
notification anymore. This also means that silent notifications are
delivered with the best effort. That means that when the notification
arrives on the user's device, the system is going to make some
choices.
For more see this image and this answer
When I registerForRemoteNotificationTypes On the app is there any way that
i can give the user more information about the types of notification they will receive
IE `#"Accept to receive notifications of in-show special offers, discounts & special events"
I think you might be asking two different things:
Can I ask the user before calling registerForRemoteNotificationTypes which types they would like to receive?
or
Can I give the user some context about why I'm going to ask for APNS permissions (i.e. what I'm going to use them for) before the APNS pop up is shown?
Both are possible.
To do 1 you could ask the user using your own UI which types of alert they want (sound / badge / alert) and then call the registerForRemoteNotificationTypes:(UIRemoteNotificationType)types with types set per the user request
To do 2 you can certainly present some pages - like welcome screens - that explain that you are about to ask for permission and why the user should accept the request. And then after this explanation call registerForRemoteNotificationTypes
From my perspective, I think 2 is best practice, and substantially increases the chance that the user will accept the APNS request (the same goes for Location services).
You can not Change the Text For Default Notification Alert,
You can use Trick like first with custom UIAlertView with additional information, After it You can ask for default Notification permission alert. But this will show two alert so may user will not like it.
No. You can not change notification type as per your requirement.
The default notifications can not be changed. If you need to customize notification then change json data and show alert as per your requirement when the receiveRemoteNotification is called.
Is it possible to postpone the first time app startup request, about allowing apple push notifications: "X would like to send you push notifications" ("Don't Allow / OK")
I seems to remember having see apps before, where the request first popped-up after a pre conditional action. Is it possible to postpone the request from startup to a time where the user has done a pre conditional action, and the user then knows why they should/shouldn't allow push notifications for this app?
It is also regarding the thought that most people would reject it, if it is the first thing that pops up after they opened an app for the first time, and they have no idea why the should allow it.
Just call
[[UIApplication sharedApplication] registerForRemoteNotificationTypes:notifTypes];
when you want the user to enable push for your app.
That's when the popup will show.
I would like to know if it's possible to force the "XXXXX would like to send you push notifications" popup from within an app, after an initial decline. The use case is as follows:
The user installs the app, gets the alert about push notifications,
and declines because they don't know/trust the app yet.
They use the app and proactively request within the app to be alerted
when something happens (say for example something they want to buy is
sold out so they want to be alerted when it is back in stock).
So now the user has asked the app to notify them about something
specific but has push notifications disabled at the operating system
level.
So if the user requests an alert, but I detect that they declined
alerts on first run, I need to notify them of this and have them turn
push notifications on for the alert to work.
Ideally, I would like to force the "XXXX would like to send you push
notifications alert" at this point (a second time since they
installed the app).
I guess plan b would be to show them my own message telling them they
have to go into their system settings and turn it back on manually in
order to receive the alert they want. This is far from ideal.
Any help would be appreciated. Thanks.
You can't make iOS show the alert again. Here's a better approach:
Keep a flag in your NSUserDefaults indicating whether you should register for push notifications at launch. By default the flag is false.
When you launch, check the flag. If it's true, register immediately. Otherwise, don't register.
The first time the user does something that would cause a push notification, register for push notifications and set the flag in NSUserDefaults.
This way, when the user gets the push notifications alert, he has some idea why he's getting it, and might actually say yes.
I am also facing a similar kind of issue. After searching so much, I decided to do what you call Plan B. That is, show the user my own alert saying that push needs to be enabled for better experience, or something like that.
To check that required push types are enabled, use this method:
- (UIRemoteNotificationType)enabledRemoteNotificationTypes
UIApplication reference
I think that this is the clean solution. Consider a case where after accepting the request at first, the user turns off push, this thing will work even in that scenario.
The best way to do it would be to (if you're making a game) ask them a preemptive question (e.g. Do you want us to notify you when your crops are ready to be harvested? -Yes -No), and when they answer "yes", then fire the native iOS push popup. then you can layer in multiple questions along the user funnel, and you'll eventually catch them all.