I know that iOS only allows a few background-modes, so is it possible to ping a website when the app is in the background, then use a local notification to alert the user that the server is now unavailable?
I'm able to ping the site, but I'm unsure about the background notifications.
I am using BackgroundFetch in with a remote server where I update some information for the application or push a local notification if the server is unavailable. It is good to use the available types of refresh rates for BGfetch and not set exact time interval, the app will adapt to the users needs and check the server at appropriate intervals that preserves the battery.
Some good resources:
http://code.tutsplus.com/tutorials/ios-7-sdk-background-transfer-service--mobile-20595
https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIApplicationDelegate_Protocol/Reference/Reference.html#//apple_ref/occ/intfm/UIApplicationDelegate/application:performFetchWithCompletionHandler:
While technically possible it isn't really a good idea. This is a mobile device, so there are many reasons why it wouldn't be able to connect to the server, and it also has limited battery life and potentially limits to the amount of network traffic it can use.
What you describe is much better handled by a server with a fast and reliable connection to the net and which uses push notifications to alert users to the outage.
Related
I have an idea for an app that utilises Live Activities, inspired by the Flightly app (it starts a Live Activity for a plane ride): Basically I wanna use open data from an HTTP endpoint that is reachable via the onboard WiFi on a bus. E.g. you board the bus, connect to the onboard WiFi, open the app, it fetches details about the stops and then you start a Live Activity guiding you to a selected stop. So far so good. But sometimes the bus faces delays, etc. In that case, I need to update the Live Activity. That is easy when my app is running. It is not so easy, when my app is not running (or running in the background).
What is my best approach to regularly fetching data from the endpoint and updating my Live Activity? The problem is, that the endpoint is only reachable on the buses WiFi. So it looks like I cannot use APNS to push updates to the Live Activity (since my service running outside the bus cannot access the endpoint that provides the details and thus cannot push any meaningful updates). Background Tasks (e.g. background app refresh) run infrequently.
What options are left? I thought about receiving location updates in the background and acting on them to update my app state (and possible the Live Activity, if needed), although I haven't investigated that path in detail, yet.
Has anybody faced a similar issue and found a solution or can provide some guidance on how to approach this problem?
I think the easiest option is core location. So keep your application running by monitoring the position and then you can update the Live Activity by fetching the information from your access point. It should be fine for app review since you could use the the location to show a position on a map and only while the person is on the bus.
If your application isn't running you have to send the ActivityAttributes via APNS. Since the data cannot be accessed from a remote server that would communicate with APNS there is no direct way to use ActivityKit push notifications. An indirect approach (which I would not recommend) would be to send silent push notifications triggers every 5min or so and fetch the newest information when the application is woken up. But this won't work when the app is force-quit and using silent pushes to trigger polling will give you a bad score by the system and eventually the frequency will be throttled from APNS.
App that I am working on is offering a VPN connection, that can run even when the app is not running at all. This service is paid, but also I would like to offer a free trial limited by session length and maximum data transfered.
The problem I've encoutered, is with monitoring the data trasnfered when the app is in background or not runing at all. So far the best solution I've came up with, would be to periodically run small task that checks if the user is still within the data limit and if not, the VPN will be disconnected and notification shown to the user.
Will silent notification get priority every time it will be required? According to this quote from developer.apple.com, they are low-priority which isn't what I need, but I was unable to find anything else.
Silent notifications are not meant as a way to keep your app awake in the background, nor are they meant for high priority updates. APNs treats silent notifications as low priority and may throttle their delivery altogether if the total number becomes excessive. The actual limits are dynamic and can change based on conditions, but try not to send more than a few notifications per hour.
How can this be done reliably? Is there any other way?
If this is a personal VPN connection (i.e. you're just providing a config to the standard system) and you're not in the flow, then this isn't possible. There is intentionally no "I want my program to run all the time" solution. Even if you come up with one, Apple will probably shut you down.
If you're writing an MDM/supervised VPN connection (i.e. you're providing a ...Flow object of your own), then you're already running all the time and you can just control it as you want. I'm assuming you have the former or you wouldn't be asking.
I believe you're doing this backwards. Monitor the session length on the server, and disconnect there. When you disconnect, send a push notification, which can display a message directly without having to open the app. That is both robust and the intended solution.
Periodically posting a silent notification to wake yourself up will definitely not work because Apple specifically does not want you to do that and they explicitly break it (as they note "silent notifications are not meant as a way to keep your app awake in the background"). It's bad for battery life. This is intended to be solved on your sever, on on the user's device.
For a project I need many clients to subscribe to different hardware devices. In this setup the clients are iOS - Devices. The hardware is something like a raspberry pi but i don't think this matters. This hardware devices send a signal if it measures some kind of information. This is a rare event and possibly could never happen.
Purpose of the app is to warn the user when some kind of event appears in a location he is interested to.
I planed to implement this using the MQTT protocol.
That is where my problem is. To work with MQTT the app needs to send PINGREQ every few minutes even when the app is in background. Also the app needs to receive its subscriptions and handle them immediately.
This is what I planned to do:
Set the "UIBackgroundModes" key in Info.plist to "voip".
Mark the socket as voip socket to wake the app when it receives something
Set the keepAliveTimer:callback: and send the PINGREQ
.. as described here
My questions are: Will Apple allow this? My app is not an VoIP app. If no, are there any alternatives to this approach?
If Apple policies doesn't allow your to put your MQTT client App running in the background, then the solution should be to implement an additional push service.
A push service subscribes to your MQTT broker and sends push notifications to your mobile devices, so that either they have the MQTT client App running or not they will get the events.
Yes!
There is a chance that apple can reject your application when you are using VOIP(even though your app is not a VOIP Kind of application) to keep application alive!
I'm using Location services which is a proper solution to keep application alive in background mode.
Ask permissions to use location services even when the app in background mode & after getting the allow call back,set your location manager's desired accuracy to worst,distance filter to 99999(means your app will be notified if the user travels more than 99999 Meters from last location update call back)
By altering the desired Accuracy and distance filters you can save the user's battery consumption,otherwise your app will consumes lot of energy
That was one proper way which makes your application to run in background for more than 2 days continuously (Already using in our projects).
HTH! Have fun in coding :)
I understand the basic concept of having a provider talk to Apple's Push Notification Server which then pushes the notification to the phone. Usually, the provider is an app server running on some machine somewhere completely separate from the app.
However, we don't currently have a separate server, and don't yet need one as everything is currently handled in-app. So, is there any way we can use the app itself as the provider to send a notification to Apple's server and thus to another phone?
Basic concept: we have a game and when a user completes 70% of the level, we'd like to notify his competitors that he's close to finishing the game (or that he has finished at 100%).
If it's possible, are there any security concerns with this approach?
P.S. The app already knows who the competitors are because it displays them in a UITableView.
Technically it's possible. If you include the push certificate with your app, and you have a way to send the device token of each device to all other devices that may need to push to that device, you can push a notification directly from one device to another.
However, in practice, that would require opening and closing many connections to the APNS servers frequently (you'll need a connection for each device, and every time a device loses network connection - which may happen often - you'll have to re-open that connection), which will probably cause Apple to block your app from connecting to their APNS server (since they would interpret it a DDoS attack).
Therefore you should use a server.
For future visitors to this question: we wound up ditching Amazon SNS since we spent nearly 8 hours and couldn't get it working the way we wanted. Instead, we setup Parse Push in rough 15 minutes with exactly what we wanted to do, so I would definitely recommend giving it a look.
I have a chat application developed by JS. I want to send PING to server once in a while. Its not a problem if app runs on fore ground. The problem is when user minimizes it or open another app. My app looses its focus and gets into suspended state.
I have following two use-cases.
To keep the chat session open I need to send PING to server (Its an IRC server) every X minutes even the app runs in background.
We also need to check for new messages (by ajax on a local http server) and add a local notification to the notification queue so when user clicks on it app can resume
I have found apple does not allow running apps in the background. if they allow they require special permission. I found some apps does it by requesting finite length execution time.
What is the best way to get highest possible background execution time? As a chat app can I request permission for voip, location or any other way ?
Note: the app will be running in an environment where there is no Internet. Hence push notification will not work here.
Update: After doing a lot searching I found background fetch. It seem background fetch will suite it. But still the problem remains, its not called in a timely manner.
This sounds like an interesting problem. From reading the various comments, it sounds like you want this to work when you're on a local network - so you have wifi, but the wifi router/base station isn't connected to the actual internet?
Because background refresh isn't going to be predictable - you'll never know when it is going to update - you might want to get creative.
You could look into exploiting iOS VOIP support, only without the Voice! Apple has some tips on VOIP here. VOIP basically uses something called SIP (Session Initiation Protocol), which is signalling layer of the call, and a lot like HTTP. It's this SIP layer that you want to take advantage of.
This isn't going to be terribly easy, but it should be achievable. Setup your app to use VOIP, and then look into something like PJSip as your SIP library. Then, on your local network have a SIP Server (I'm sure there are plenty open source implementations) that you can register your iPhone against (so your server knows where your phone is, pretending to be a VOIP phone). This should work, because it doesn't need to go through Apple as far as I am aware... And will run happily on your local network.
Then, the server can send a message via SIP to the handset, as if it were instigating a VOIP session. You app is awoken, gets the messages - ideally from the SIP message if possible - and then just doesn't start the session. SIP was designed just for creating sessions, not just VOIP. When I worked in Telecoms R&D (a long time ago) we were using it to swap between Text/Voice/Video, all using local servers.
You'll have to jump a lot of hoops to make this work, but it would be pretty awesome. I have never tried this actual use case - especially with iOS, but I'm fairly sure it will work. It is a bit of a fudge, but should get you where you need to go.
Good luck!
You can use something like PubNub to build this chat app with iOS using native Objective-C code, or with the Phonegap (Cordova) libs.
The beauty with using a real-time messaging network like PubNub is that when the app goes to the background, you can easily have the chat messages come in on APNS.
When the app is in the foreground, it can just receive them as the native (PubNub) message. And if it needs to "catch-up" with the messages it missed while in the background (but received via APNS), its trivial to implement.
Also, PubNub is platform agnostic -- so you can easily also use it on Web, Android, BB, Windows Phone, etc.
http://www.pubnub.com/blog/build-real-time-chat-10-lines-code/
http://www.pubnub.com/blog/html5-websockets-beautiful-real-time-chat-on-mobile-using-pubnubs-channel-presence/
https://github.com/pubnub/objective-c/tree/master/iOS
https://github.com/pubnub/javascript/tree/master/phonegap
geremy