I've read a lot about notifications in iOS now and I'm quite confused about how to reliably schedule notifications, actually. Let me explain my scenario:
I created an Android app that holds a fixed list of dates. The user can not add or remove dates, he can only view that list (garbage removal dates for my area). You can, however, configure that you want to be notified the day before. I've made that app so that when the device starts, a notification timer is started that fires at a certain time, checks whether there are pending items for the next day and if so, shows a notification. Then it re-schedules itself for the next day. So normally, the user doesn't need to open the app at all to receive notifications. He only opens the app once to configure his street, which triggers the first scheduled event, or to actually see the list of upcoming dates.
I'm now trying to port this app to iOS and I understand from what I've read that there's no way to replicate the way I'm doing stuff on Android. I understand that I can create up to 64 notifications for certain points of time in advance, but without the user opening the app at all I can not be sure to reliably schedule all the notifications I may need.
Is there a reliable way to simulate the described Android behavior? Or is there a way to force the user to open up the app once every 30 days or so?
In a nutshell no.
If applicable you can make notifications repeating, but if the dates are random and you can't repeat the notification then you can't schedule more than the limit.
You can't schedule your app to run and you can't force the user to do anything. All you can do is post some sort of notification for 30 days or whenever with some message that you hope will compel them to open your app.
If you have a valid use case for it in your app, you can enable a background mode such as a location change on a cell tower transition for example, then when your app runs in the background re-schedule the notifications. Or remote push, or background fetch etc. But even with background modes you cannot guarantee your app will actually run in the background, you can just help to increase the chances that it might and the different background modes have different degrees of usefulness in this sort of area.
Related
I am developing an application that monitors buses' icons on the google map and triggers a notification once they get close to the bus station. Everything works perfectly fine as long as the app is visible to the user. Right when the phone's screen is turned off, the app is no longer responsive to the runnable running in the background. I am aware of the doze mode and researched a lot on the web. Currently, I was able to overcome this by using a service in the foreground that binds to the application. However, this creates a notification in the status bar and might not be pleasant to the user. I have another option, ask the user to grant the permission to my app to be on the whitelist apps for battery optimization exempt. I want to know which one is better and are there other approaches that are working better in my situation? Please note that my app needs to get data from a server every 5 seconds, and this synchronization will not last long, maybe 30 minutes maximum, so I am not worried about battery drain.
I'm implementing an app with an internal calendar, fetched from a remote web service. I want to send a local notification to the user when an event of interest is scheduled in the calendar, at a specific time chosen by him. Just like the iOS calendar app, when you can create an event and ask to be notified X hours/days before it happens. The main difference is that you can't create events: they are downloaded from a pre-populated remote calendar.
In Android I've solved the problem by using AlarmManager, while in iOS with Swift 3 the closest I've got to porting the same solution was via opportunistic background data fetch. The main difference between the two solutions is that background data fetch doesn't work when the app has been killed.
It would be really important for me that local notifications worked even when the app is killed. I think users expect apps notifications to work even when the app is closed, like it happens with WhatsApp or Facebook. I know that those notifications are triggered by someone writing something and therefore they are Push Notifications, but the average user just expects notifications to keep working even when the app is closed.
What would be the most elegant solution to "emulate" the behaviour of Android's AlarmManager in iOS?
Scheduling a bunch of notifications in advance hoping that the user will eventually open the app before all of them are dequeued looks a badly designed solution.
Also, delegating all the work to the server and push the notifications to the subscribed devices looks quite bad too as it requires much more work on the server side. Plus it requires a server which is able to awake itself to send push notifications, which is something that I don't have. I only have a simple webserver which answers to HTTP requests.
EDIT : The ideal solution I'm looking for isn't any of the previous 2 options, since I find them more like workarounds than actual elegant solutions to what I perceive being a fairly common problem. There has to be a third option...
In iOS there is no way to achieve this. Looking at the documentation of application(_:didReceiveRemoteNotification:fetchCompletionHandler:), it states that
the system does not automatically launch your app if the user has force-quit it. In that situation, the user must relaunch your app or restart the device before the system attempts to launch your app automatically again.
You can receive push notifications, but no code will be executed until the user launches your app. So unless you are sending remote push notifications from a server, you cannot set up new local notifications until the user opens your app.
How does an Android alarm app or any other time based notifications app like Calendar, Clock, etc work? More specifically, how does it show up the notifications at exactly the time specified by the user? Does it constantly run in the background and as soon as the required time comes up, does it show the notification? Or does it schedule the notification in Android's kernel before exiting? I am working on an app that needs to give the user notifications at times specifies by him. I am not able to figure out how to do that.
Maybe what you mean is to create an alarm, you can see this example.
I want my app to notify users of specific events that can occur at a certain time.
I know how to send a notification knowing the exact time of it, but things get a little complicated for me when I want to trigger notifications at times that are unknown at app install (notifications whose time can change or which depend on a specific event).
Here are two cases in which I don't know how to trigger a notification :
Send a notification every day at a time that can change from day to day. Say I want to notify users that it's sunrise time, do I need a Service to run permanetly an calculate for each day the time of sunset and trigger a notification when the time comes ?
Send a notification everytime something new in the community occurs. I don't want to notify users of an update, but just of a particular event at a certain time. How do I send notifications to them?
How can I achieve this ?
Thanks !
For your first option i would use a AlarmManager. It will execute a function on a specific time, that can be set on app startup. Everytime the AlarmManager executes and sends a notification to the user, it should re-calculate the next message time and reset the AlarmManager. ( see how to reset here )
For your second scenario you could use a library like OneSignal. It's a verry usefull library for registering users for pushnotifications and sending messages from a website to your users. You can choose groups of users or specific users for sending messages and you can customize the look of your pushmessages ( add buttons, images, .. etc).
I have an app which is on Android and iOS. I have added a local notification to fire every 24 hours at a time specified by the user of the app. In Android, the local notification functionality is exactly what I need, but in iOS it seems to lack the functionality I need, unless maybe I am missing something...
Lets say the user sets the time the notification is to fire to 11:00am. In Android, at 11AM, it will wake up the app, go to the broadcase receiver and I am able to run code in a method that calls out to an API to fetch the latest data. Once it gets the data, it posts the notification to the user.
In iOS, it seems the data being posted to the user has to be pre-scheduled. So I have to create the notification message during scheduling of the notification. What I need is to be able to do something more like the above example.
So the problem is that at the time of when the notification is scheduled to fire, I need to check for fresh data, not the day before...
Any suggestions?
The same functionality doesn't exactly exist on iOS.
You can setup a local notifications using the functionality of a UILocalNotification object. With this you can set fireDate, etc. which is sort of like a push notification without a server. You can send a message, add a badge on the app icon, play a sound, etc.
Now the issue is that the app doesn't get launched by the OS. The app simply registers a notification in the OS, which is then handled at the fireDate time. This means you won't be able to have a chance to check for data and verify whether to continue with the notification, etc.
UILocalNotification Class Reference