target:
Now, I have a mission that is use the queue to manage the mutiple of notifications. So no matter how many notifications app received in a short time when app is active, app can play the notification UI(firstly show the notification UI, then dismiss it) at a fixed frequency. For example, play the notification UI every 2 seconds. But I have no idea about how to control the frequency of the task in the queue,Thank you!
What you describe is a rather complex task, and would involve learning about several technologies.
I'm not sure if queues are appropriate. A simple array and a timer might be better.
Set up an array in your app delegate to hold notifications that need to be displayed. When you receive a notification, add it to your array.
Then set up a timer that runs when the app is active. When the timer fires, pull a notification off the front of the array and display it.
Explaining how to do each of those things is beyond the scope of a SO post. You need to do some research on your own, write some code, and post specific questions if you get stuck.
Related
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.
I need to notify user when a certain condition is met but that condition might or might not meet in months. I need to run condition check in background (even when app terminates) so that I could detect condition is met (even if it happens after 3 months). If condition is met then I need to send notification only to a single user (not all users).
I am not sure what is the best way of doing it. Local Notification or Push Notification? I can not schedule a local notification in advance because I don’t know when it will meet the condition. I think Push notification is not needed because I am sending only one notification to only one user in several days/months.
I also need to constantly run this check in background. I know it can be run infinitely in background by using location update (significant monitoring or background navigation). But my condition checking code doesn’t actually require location updates. As far as I understand, Apple allows only location update or network related task in background (for few minutes). That's why I am thinking of putting my code in background location update code.
In my opinion , I should use local notification and put my code in background location update code so that I could check constantly if certain condition is met. This background check will schedule local notification and show it to the user who is using that device. I don’t think it is possible to schedule a push notification by code running in background.
In summary, I have following 3 questions
Should I put my code in background location update? If not, what is the right approach of running my code infinitely in background without location update?
Will Apple reject application if I put my code in background location update while location update code doesn’t actually send/receive current location?
What kind of notification should I use in this kind of situation where I send notification to a single user after months? Would you use Local Notification? or Push Notification.
Please reply. Any help is truly appreciated.
Thanks in advance.
This is a bit of a tricky problem unfortunately.
Apple won't allow you to create long-running operations in the background. As you mentioned, you can add code in the background with location updates or audio, but neither of those are very good solutions since (1) Apple will likely reject you from the app store and (2) the user will probably close the app if they notice a big locations banner at the top of their phone (or a weird background audio signal), and closing the app will kill your operation. For any truly long-running tasks it's probably best to set up a server and run a cron job or equivalent long-running operation. It's the only way you can know that the task will continue running.
Sorry, I was just answering one at a time, but as I mentioned above, yes, they'll probably reject your code for that. As a rule of thumb: if you think the Apple-created code you're using wasn't meant for what you're using it for, Apple will probably reject your app.
It sounds like you should use a remote notification. If you do use a remote notification, you'll probably want some sort of backend anyway. You could use a local notification to notify a user after a few months, but you would need to know the exact time to send it up front, which it doesn't sound like you would.
In summary: Try to build a simple BE. Maybe use Firebase Functions or something, and also build an APNS system to send pushes. In the app, tell the server to start processing the information and send the push back when it's done. The situation sounds like a perfect use case for server-side logic.
Hope that helps!
I am working on an app where I would have to implemented at least two background tasks. The scenario becomes like this, I have a web service which tells me when to start the location updates for a user. So, I would need to periodically call this service to check if it's time to start, and/or stop, user's location tracking.
So there are two background tasks, fetch and location tracking. Fetch should run periodically which defies Apple's procedure that it will monitor your app's usage and decide on it's own when to update the content. This has become my first problem, is there any way that I can avoid this? The second problem comes with the multiple tasks, how can I switch between either of them?
What is the best practice here? Dos and Don'ts?
You should use Push notifications through Apple's push servers, or you may find a service like Parse.com easier to work with. You can use the push notification to trigger or create anything in your app delegate (where you handle receiving push notifications). As #Paulw11 's comment states, you can even attach a payload(data) to a push notification and deal with it. So the first part is fire a notification to the user's device when they should start tracking and end tracking.
Most location tracking stuff using an instance of a CLLocationManager can be done via it's delegate methods. However if you want you can use it in a subclass of an NSOperation and manage it in an NSOperationQueue, see here for a tutorial:
http://www.raywenderlich.com/76341/use-nsoperation-nsoperationqueue-swift
And I suggest researching the class documentation.
I'm trying to code an app that reminds me to hit a certain diet goal (drink 8 glasses of water, eat two fruits, take vitamins etc)
The problem is if I code these as reminders using local notifications, I don't get to execute code. So I can't adjust the reminders every hour relative to my goal. For example don't show the reminder if I already hit the goal. Or say stop the reminder past dinner time and start again in the morning.
If I code these as NSTimer the problem is they don't run in the background.
I suppose I can move all the logic to a server and use push notification instead. But this is huge amount of work for what I would consider a very simple self reminder app.
What is the right approach?
if I code these as reminders using local notifications, I don't get to execute code
I use a pill-taking app, and it does use local notifications. The local notification does let the app execute code, if the user taps / swipes (whatever) the notification. The app then puts up a dialog where I enter what actually happened (I took the pill, I skipped it, etc.).
The app simply assumes that if the user doesn't respond and tell it what happened, then nothing happened (i.e. the user missed the pill). How does it know that? Well, as with any local notification-based timer app, the app must maintain an internal list of pending events. It strikes a pending event from the list when it knows the outcome. That way, if the app is not running and then it is running, it can look back over its list and note that there are past pending events, thus proving that the user failed to respond to a reminder.
I have a background app with a UIBackgroundMode of location.
I would like my app to additionally contact a server every few or several hours to see if there is some new data for it (because using apple notification push would notify the user and that is not desirable).
Polling is something I would never use on any other OS, but with iOS they don't leave you much choice if there is certain functionality you would like to try to achieve.
If the polling interval is quite lengthy such as a few or several hours between polls, and the polling activity itself only lasts several seconds then the usual knee-jerk reaction about it draining battery life is greatly diminished.
Would a repeating NSTimer fire when an app is in background mode? If not is there another type of timer or mechanism available?
If it's just to check for new content, and not really time sensitive, you COULD use the significantChanges background location method...but if the user stayed fairly immobile it'd rarely/never fire. I would probably also add the update check in applicationWillEnterForeground to be more sure
No, that's not allowed. You should have a look at Push Notifications and find a server side solution.