I want to send a notification to my app users, if they not used the app before 12.00 they should get a message ("You should start the app... bla bla bla") - iOS
And if the users has start the app before 12.00 they should not get any message.
Do i have to use server push och can i use local push?
Sincerely
You could use either...but local notifications is going to be a bit hacky. Ideally, you'll want to use APNS via your own server, which will let you keep track of exactly when users have run your app and alert accordingly.
Of course, you're also going to need to build a system to handle this, and send data from the app back to you server to record and process. This is relatively straightforward, but if you've not done any back-end server work before you may find it difficult.
I suppose you could use local notifications by scheduling notifications for 12PM for the next X number of days, and cancelling notifications on a per-day basis if the user opens up the app before midday. But this isn't ideal either.
Personally, I'm not sure I'd enjoy using an app that constantly reminded me to use it, but that's just my opinion!
Related
I need opportunity, run some code at the moment when my app is killed. For example, a user doesn't open my app in the course of week or month.
Some information about working my app.
The User can save settings which contain push notification. These local push notification my app can get every day, but time every day can be different and I want to create local push when my app is closed and doesn't open during some days, weeks or months etc.
I have read about "silent push notification", but it is not fit me because in my app hasn't a server. Also, I have read about "significant location", also it is not fit me. Who knows an alternative way, how its implementation?
Since your goal is to run a local notification some number of days after the app is terminated, one solution is to schedule a local notification when the app enters the background. When the app enters the foreground or if it is restarted, check if enough time has passed or not. If not, delete the most recently scheduled local notification. This way it only triggers if the user doesn't actually use your app for those days (or whatever timeframe your choose).
There is no point to use repeating notifications if the scheduled time is variable. There is also definitely no way to run some code in the background if app is killed, so the only suitable solution would be to use remote push notifications. If you don't want to deal with the trouble of making a push server etc. Firebase might be a good choice: Firebase Cloud Messaging client app on iOS
Since push notifications may not be delivered sometimes (you can lose a few of them), you can not run code after the iPhone is turned on to check if there is new information available from the server, and you can not run code if your iOS App is closed... What can you do if you want to be as more accurate as possible in for example a Chat App in iOS?
I mean, inform the user as faster as possible that he has new info available. Comparisons: WhatsApp is updated without any delay.
You can do background fetch if your App is in background. But if the App is closed and you miss a push, it's not going to be up to date until the next push arrives or user opens the App. The same with silent notifications. If the app is terminated by the user, you are not going to receive it. Is there any way to solve it? It must be because other Apps do it... If there is any "private and secret" API that they are using (I read about this answer when no one know how to do that)... Is there any way to apply to use it?
UPDATE:
I'm using push notifications. The goal is to fix when a push doesn't arrive. Example: User A send chat message to user B. User B doesn't have the App open. The system lose the push. User B is not going to receive the message until he open the App.
Push notifications seems to be your only way even if you do loose a few of them, which I don't know how you would since they are pushed to apples secure server... but what do I know. As long as the user turns on the push notifications you should be fine. They may be delayed due to apples way of handling them. Honestly push seems to be the future, having your app constantly every minute or two check for new messages is a huge battery water in conjunction with normal texting apps. Your app should provide the best live data but since apple restricts to push notifications when the app is off or not running just stick to push notifications and only push major events to the user. I believe you can set up a job scheduler using quartz or schedulator to setup your server to push notifications to your app.
Suppose there are 2 people A and B, they are chatting using my instance messaging app, A or B may switch to other app or lock screen when the peer sends a message. As you know, the message comes from A will first send to server, then the server will send it to B. If the app of B is not in foreground, it will not get the message instantly, so I should use remote notification.
What I want to know is how my server side to achieve the Remote Notification functionality. I have two option.
I send message to APNS every time when the server gets a message.
I keep the app status(foreground or background) of A and B, when a message comes in, if the peer is in foreground, don't send the notification to APNS, otherwise send the notification.
The first one is a easy way but it may increase the pressure of APNS server.
The second one is complicated, it must keep the app status for every user and it may be not accurate. Suppose when the app of "A" comes to background and the network is very bad then, "A" fails to notify the server that it goes into background, the server consider that "A" is in foreground, so when "B" sends a message to "A", server won't send a remote notification to APNS.
Anyone who has experience on that please share your solution, thanks in advance.
I send message to APNS every time when the server gets a message.
Exactly! Just send a push notification for each message. If the app is in foreground, the notification won't be displayed anyways.
The first one is a easy way but it may increase the pressure of APNS
server.
APNS will be able to handle it, don't worry about that.
If you try to synchronize the app state with the server, you will sooner or later run into race conditions and other problems, so don't make things more complicated than necessary...
Although Push(remote) Notifications are delivered almost instantaneously (APNS is scaled to take load), I would suggest you to explore third part libraries. Here is a good tutorial on this. It would be worth exploring XMPPFramework. This may also be useful.
Hi i am developing an app that will fetch one qoute from my server everyday and will do a local notification in that app and more when you get inside the app.
I started by implementing Push Notification but then i figured that Local Notifications is what i need.
Official Documentation
For example, applications that depend on servers for messages or data
can poll their servers for incoming items while running in the
background; if a message is ready to view or an update is ready to
download, they can then present a local notification immediately to
inform their users.
The work flow of my app is that i need the app to make a post request to get today's quote and fire a local notification for that (that's the hard part) then when user opens the app i think things are easy.
Th issue here is that that request has to be made while my app is not running.
I'm looking for some help on how to acheive that..
Thanks in advance
Apple introduced in iOS 7 something called Background fetch.
The new Background Fetch capability allows your application to ask to fetch data on a regular basis, so when the user launches or re-opens your application, it can start up with the most current data possible.
You can learn how to implement it here
Another option to consider iOS Silent Push notifications. This will let you update the user database without interacting with him. I'd go with Background fetch, though.
I don't think you can run your app in background unless your app meets one of the background modes specified by apple . If you run your app in background without enabling one of the background modes it may result in app rejection by apple .
Now for your requirement you can simply save the qoute for a particular date from server within local DB once a day whenever user runs the app . By setting local Notification repeat itself at morning everyday you can display qoute of that particular date .
I am working on an application that must notify the user of a server-initiated event. These notifications are only useful for a short space of time (30-60 seconds). For this reason, I am looking for a method that can both deliver a notification quickly, and, importantly, can somehow invalidate (retract/cancel/timeout) the notification after it has already been delivered.
My understanding is that the APNS is not suitable for this. They 'send and forget', giving no ability to check/modify/delete a notification. This functionality is integral to my app though, so I am open to any suggestions for methods or services that might let me achieve this.
In my mind there are several options:
Server sends notification to user. Server then later sends 'cancel' message to user, which removes the notification.
Server sends notification to user, which has a built in timer. This timer is monitored locally, and once it elapses, the notification is removed.
App periodically polls server and schedules/cancels a local notification according to what the server says.
My preference is option 2, because it is self contained and efficient. One message initiates both the scheduling and cancellation. Option 3 has issues with iOS shutting down the app if it's in the background (not to mention the rate at which it would have to poll the server given the notification would only be useful for ~30 seconds).
Do any services such as Urban Airship offer some functionality that could achieve this? Any other suggestions/complete work around methods? All very appreciated.
Thanks for your time!
Matt
EDIT: In the interests of encouraging out of the box thinking, another idea might be that the server initiates an automated phone call with the app user. If the user answers the call, the required information is given to them. If not, the information is no longer available. Bit wacky, and my instinct is that it would be costly, but I'm open to anything!
Anything that happens asynchronously can be done with push notifications as it already provides a unidirectional, instant communication channel between you and your customers, so no need to do strange phone calls (which can interrupt your users' activities, bothering them).
You can go for a dual solution, in which you notify your users of how many unread notifications they have in their inbox. Then can you implement your own in-app message inbox, which connects to your servers and fetches the relevant data (in case it hasn't expired - if it has, just let the user know -).
This way users would be able to know how many notifications have been made available to them, but they could only check the ones that are still valid. UrbanAirship employs this approach for their Rich Push feature.
Apart from this, you need to bear in mind push notifications can be very intrusive for the user, so use them wisely or you'll see your users unsubscribing from them or even worse, uninstalling your app.
Well my guess you are out of luck, since your only option is APNS.
There is no support for canceling notifications.
Apps can't access the notifications for the app, only the one the user uses to open the app. Also you can't really run apps in the background is they are not used for location, media, VOIP or need to access some kind accessory.
See my point where you can't really run app in backgroud.
Third party services can not add extra functionality to the APNS server as provided by Apple.
As to your suggest that the server will the app, you can't intercept call, sms,... on iOS. I really you only solution is to build a VOIP app that will call the user when ever the notification needs to be displaid.
Apple has no solution that will suite you needs, guess it will have to be an android app then :S