I am trying to disable the notifications on client's side so they don't get notifications at night (10PM to 7AM).
Server's is not aware of the timezone and the app is used worldwide so my only option is to disable notifications on the client.
I haven't seen anything that could help me to achieve that around.
Do you have any idea how to do that?
The server has to do it. Make/ask for an endpoint that accepts two times, both in GMT. The client should know how to convert it's local time to GMT and the server should be able to respect the GMT time range.
Related
I'm trying to decide which way to implement a "quiet hours" feature in my app to allow users to specify times in which push notifications should be silent. I see two options:
1) Server-side. Their settings are sent to the server which sends notifications with different properties (or perhaps not at all) during quiet hours.
2) Client-side. The app receives all notifications via silent push, the app then processes each notification and only notifies the user as appropriate.
I see problems / limitations with each method.
For #1, the implementation becomes more complex (especially if I want to add additional notification filters based on alert type, etc), and the issue of which timezone the client is in would be very hard to resolve (especially as the client moves from one timezone to another). I certainly don't want to be tracking their position and updating their current timezone on the server.
For #2 I have read a number of comments in various places that the silent push that goes only to the app is not as reliable as normal push notifications that directly notify the user and are not processed through the app. I would prefer to implement quiet hours in this way, but I am very concerned about a reduction in the reliability of the notifications coming through. I have also read that the app will NOT be started in the background if the user has force-quit it. Is that still the case?
I have two questions. First, how have others handled this concept of quiet hours? Second, is the silent push as unreliable as I have heard in the real-world, or has this gotten better (or worse) with the latest versions of iOS? I know there are factors, such as how much power the app consumes while processing these notifications. On average my app would only receive a few silent notifications a day, and processing would be very fast.
Not sure this is really an answer, but too much for a comment!
Is your app likely to be used in different time zones?
Or are your users all based in one country?
This could mean handling client side is going to be a lot simpler.
Also remember that there is no guaranteed delivery time of a push, its normally pretty instant, but not always, so although you might of sent it with 5 minutes to spare before a quiet hour, it might arrive after the quiet hour has actually started.
I am looking for solution to get data in background mode even app is terminated.
There are lots of tutorials and answers available for this questions, but my questions is different than other. I haven't find any proper solution on stackoverflow, so posted this question.
I have scenario which I can explain. I'm using realm database which store event date, name, time, address etc. Now the thing is that, I want to write a code which are execute in background, In this code I want to get all event data and compare their date with today's date. And based on days remaining between these days fire local notification to remind user about how many days are remaining for specific event.
I want to call this background fetch method exactly 8 AM in local time everyday.
I haven't write any code due to confused with Background fetch and implementation. Can anyone know how to implement this ?
Help will be appreciated.
I have got solution to fix issue. As per I have talked,
I want to write a code which are execute in background, In this code I
want to get all event data and compare their date with today's date.
And based on days remaining between these days fire local notification
to remind user about how many days are remaining for specific event.
So, when I getting response from API, I'm creating local notification for all events with unique id, which are fire and repeat daily at specific time, where I have display event time and remaining days of event.
Apple documentation states that there is no guarantee when background fetch is performed. It's up to the system to decide.
The system waits until network and power conditions are good, so you should be able to retrieve adequate amounts of data quickly.
The guaranteed way to wake your app is to send at 8 am VoIP push notification from the server. It is guaranteed that the app will be wakened upon receiving a push, and you'll be able to execute the jobs you need. For more details, https://medium.com/ios-expert-series-or-interview-series/voip-push-notifications-using-ios-pushkit-5bc4a8f4d587
It is not possible to wake up the app from suspended mode in iOS except with push notification (for this server has to send push notification).
This is something which is not documented anywhere. IMHO and experience with iOS, Apple must be recording user activities since the start of the iOS era. ScreenTime is a product of those recordings only that apple was able to create and visualize the data to present a user facing app that very beautifully restricts, manages and displays your activities. In WWDC 2018, it was even quoted that apple will even detect, if the user opens your app at let's say 9 PM daily before going to bed, iOS will allow every possible resource (battery, internet, processing time etc) to that app at 9 PM. But you need to understand your user activities before you do this. Let's take an example of:
News App:
A majority of users would check the news in the morning (If they are not instagram addicts). At this time even apple should be biased to open your app with background fetch. Unless of-course there is too much of a resource crunch
A Game: Many games allow provide a restriction time by calling it "recharge" or "re-fill" the energy of a character before user can play another round. This is done so that the addicted person would buy gems to remove that restriction and hence monetize the idea. But if you know that the refill process is completed before 8:00 AM in the morning or user plays your game daily at 8:00 AM configure background fetch accordingly.
Background fetch works with interval rather than specific time.
// Fetch data once an hour.
UIApplication.shared.setMinimumBackgroundFetchInterval(3600)
Lastly why don't you try silent push notifications? Based on your question, I think silent notification is enough to wake your app after a push notification from the server, download some data and do your calculation and provide a local notification.
May be I am asking a stupid question here.
I recently noticed an UIApplication delegate method
- (void)applicationSignificantTimeChange:(UIApplication *)application {
}
I was wondering what will be its actual use? Do we need to handle this. Can anyone explain a scenario that can happen in an iOS application and we need to do some coding here.
My App is really sensitive to system time, that is the reason I am asking this question. After seeing this API , I have a feeling that I am missing something here to handle.
I am just curious to know... :)
Thanks,
Ramesh Chandran A
Per the documentation on iOS, this method is called:
Examples of significant time changes include the arrival of midnight,
an update of the time by a carrier, and the change to daylight savings
time. The delegate can implement this method to adjust any object of
the app that displays time or is sensitive to time changes. Prior to
calling this method, the app also posts a
UIApplicationSignificantTimeChange notification to give interested
objects a chance to respond to the change. If your app is currently
suspended, this message is queued until your app returns to the
foreground, at which point it is delivered. If multiple time changes
occur, only the most recent one is delivered.
Examples of when this should be used include:
If your app has repeating scheduled events, such as a local notification that now is past, and your app should reschedule the next notification (like daily reminders).
If your app displays data in time ago that needs to be correct, even if the user sets a bad time (for example a medical app that shows your current glucose reading or similar). If a glucose monitor showed an old glucose value as the users current glucose value for instance, the user could make the wrong decision and get hurt.
How you respond to this event depends on your application. You could for instance, read UTC from a server to see if the phone's UTC is correct within some margin, and take appropriate action, such as warning the user, or updating an internal offset between actual UTC and phone UTC.
Hope that helps.
-applicationSignificantTimeChange: is roughly equivalent to the UIApplicationSignificantTimeChangeNotification notification.
I have a custom date picker control that highlights the today date. Subscribing to this notification allows it to change its highlight at midnight, or if the user messes with the time setting manually.
I am quite new into programming and I cant find efficient solution for my problem. Could someone point me in the right direction please?
I have an app which is heavily relying on server data. Data on server is unique for each user and may change every minute as well as only every few hours. Currently I am updating local data when app becomes active but I also need a way of notifying app to trigger updates when app stays in active state and data has changed on server. I thought about few solutions:
1) NSTimer set to one minute and triggering url request to check if there is new data on server. Server after comparing lastModified value would return new data if available.
I don't really like that solution as I don't want to overload my server with number of requests, especially that data in the database may change only every few hours or even longer.
2) APNS - sending notifications from server every time data will change and than update local data with server database when notification received.
It seems like a good solution but only if it would be possible to restrict remote notifications to be received when app is in active state. As far I know it is not possible and as I mentioned before data may change even every minute so I don't want to spam users with number of notifications when app is not running.
3) TCP Sockets using NSStream/CFStream?
This is something I never did before, so I am not even sure if I am going in the right direction researching about this one.
This is a hard topic in general, but more technologies are coming out to help with it. Couple thoughts on each of your solutions:
The NSTimer solution is effectively polling, which is the worst option I feel. You'd be hitting your server pretty hard for each user.
This would be a better solution. APNS now supports silent notifications, so you can send push notifications to a user without worrying about notifying them. You can send a silent notification by including the content-available key in the payload and not including the alert key. More info here: http://hayageek.com/ios-silent-push-notifications/. It is rate limited, though. You may go minutes to hours without getting a delivery, so if that's important you'd be best to go to option 3.
This is your best solution. It would require a persistent connection with your server. AFNetworking 2.0 supports this kind of connection based on Rocket. Here's Rocket's documentation: http://rocket.github.io. Take a look at server-sent events.
Hope that helps!
My server needs to send an Apple Push Notification with an alert that goes something like, "Your driver will arrive at 2:45pm." It would be nice not to have to pull the user's time zone and time formatting preferences up to the server, and instead just pass some kind of universal point-in-time indicator (e.g. epoch seconds or UTC timestamp) and have the iOS device turn that into a timestamp in the user's preferred format.
Is this possible?
Short answer - generally 'no.' Here is the Apple documentation:
If the target application isn’t running when the notification arrives, the alert message, sound, or badge value is played or shown. If the application is running, iOS delivers it to the application delegate as an NSDictionary object.
Since your application would generally not be running, you don't get a chance to interpret the contents of the APN package. If however, you do expect to only get APNs when running, then you do have a chance to do application specific actions.
Noting - you also have the issue of the user's language. You've currently selected English for "Your driver ..."
The typical approach is to record the user's timezone and language (and other locale information) on your server, usually at the time of registration. Then, when your server generates the APN it customizes it for the user's locale.
No, there's no way to turn that message.
I think you should get the timezone permanently at your server.