I plan to extend my Xamarin.Android app (runs only on Android 9 devices) to periodically check a web service for new info and if there's new info, show a notification to the user.
How can I implement this if the polling and the notification shall also happen when the app is not running, e.g. when the device has just started?
Are IntentService and AlarmManager the right places to dig into?
Rather than writing a service in the background which may be killed by the android or having issue with the network reliability and complicated retry logic. It is far better to use the FCM push notification from the server to the devices and show them the information what you want to show.
For more you can check this https://learn.microsoft.com/en-us/xamarin/android/app-fundamentals/notifications/
best way is using push notification services like firebase:
https://firebase.google.com
also for realtime notifications and detect trigger on sql tables in c# you can use SqlTableDependency :
https://www.nuget.org/packages/SqlTableDependency
Related
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.
I'm working on an iOS application, and want to achieve behavior like push notifications using firebase real time DB.
In case my app is listening to some firebase node and i'll send local push notification to the user in case that node is updated.
The issue is, if the app is not running i.e. user has killed it, will my app continue listening to that particular node?
I guess, in Android we've support like this, as explained in this link (Link).
Can we achieve the same behavior in iOS. If no, what can be the alternative?
Thanks
Update:
1- There's nothing like triggering push notifications locally in iOS app. I wanted to achieve remote notification's behavior and that can't be done.
2- As far as listening to some event is concerned, it can't be done when app is not in foreground or background.
You can’t do anything if an iOS app is killed/not present in memory.
However, you can do some tasks if app is in background, and is present in memory.
You can use background fetch request in this case.
In Android, there are Services which run even when the app is killed. But on iOS, there is no such thing like this.
You can add Firebase observers in your root view controller, and implement background fetch request to continue observing data when app is in background.
When you app is killed, the listeners are disconnected.
The typical way to send messages to your app in this state is by using a push notification, which in Firebase maps to Firebase Cloud Messaging.
This is why you'll often see the Firebase Database and Firebase Cloud Messaging (FCM) used hand-in-hand: the database is used for messaging while the user has the app open, and FCM is used to send messages when the app is not active.
When something happens on the backend, I want to let my users' iPhone app know of this change. (The app is currently open, not in the background...if that makes it any easier).
Should I install Firebase just to achieve this? What are other ways?
Push notifications is just the UI for the user...am I right?
You could use Apple Push Notification Service. If a Push Notification arrives while your app is in the foreground, it gets passed to you directly, rather than triggering a UI event. Last I knew, you can only have 1 notification outstanding at a time, so you should not depend on it for passing content, but just use it as as signal to query your server. With iOS 8 you can use background notifications, that do not require any user permissions.
Best way is to use Push Notification. Because it will save battery power on the device.
You can use the Apple Push Notification Service (APNS) to send push notifications to the user.
You could ask your server frequently about changes or use a blocking function in seperate Thread to handle events.
What kind of events are we talking about?
As Black Frog said, PNS is the easiest and most battery saving idea.
I am considering using EventSource (server-sent events) to send notifications to my iOS App users, instead of APNS. This is great when app is active, but is it possible to ensure these users receive my messages when my app is not currently running on their device? Or is the only way to do this APNS?
If you need your events to arrive in real-time (like a messaging system), then APNS is probably your best bet. APNS is the only way to send realtime messages from a server to your app. However, it is wise to know that there are downsides to push notifications.
If you don't care about real-time events (not a messaging system), or if it's okay if you get the events a bit delayed, you can use background fetching to periodically poll your server for new events.
Objc.io has a great article discussing some of these: http://www.objc.io/issue-5/multitasking.html
is it possible to have the App Connection to a server Open even if the App has been Terminated from the Background ?
Here is what I'm trying to accomplish
Twitter Client should keep watching user events . and when that events occur it send a Local notification to the user . the whole idea is to stay a way from Push notification and all servers Problems and costs
so in order to to get Local notification works just like Push notification the connection between my IOS 7 App and Twitter API must be Open all the time
any idea if that even possible ?
No, this is not possible. What you're basically asking for is a daemon functionality which is not available on iOS. The whole point about iOS multitasking is that the OS can (and will) terminate your app if it is in the background and other tasks need the resources. That's the problem Push Notifications solve (to some degree).
You could possibly try background fetch feature on iOS 7 to periodically download content updates for user in background.