I am relatively new to iOS development.
I have a requirement wherein it is important for us to notify our server about a client's current IP address. The reason behind this is because our solution needs to know the current IP address of the registered device.
Now ideally we would want to create a service that can run in background (indefinitely), poll the ip Address of the device every 10 seconds, and if it sees that the ip has changed, then call a web service notifying the server about the same. I have the folowing questions based on my limited knowledge:
Apple gives us limited choices for apps that are allowed for running
background threads (VoIP, background download, music playing,
location updates etc.). Unfortunately my use case is not an exact
fit for any of these. Can I still go ahead and somehow accomplish
this?
I have read that iOScan close any background thread if it needs
resources. Although my process is not resource intensive, should I
be worried?
The background mode will only start once my app has been MANUALLY
started. What I mean to say is that suppose I am able to run this in
background, but for this to happen the user has to once start the
app manually after restarting the device. Is there a way to start a
service/thread on restart? Is there a workaround?
You cannot trust IOS to handle this in the BG for you the way you describe it, because there is no good way to have a task run in the BG indefinitely, you might get away with using location services and trigger your IP uploads when a device moves but that will not resolve the situation when the device is stationary and changes IP although that might be a corner case but will surely happen as the device moves from tower to tower on 3/4G networks or between different WIFI networks.
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.
I am not sure how to best implement keeping our server informed that our iPhone application is currently running (even when in the background). There are a few different options but there is some concern as to what is allowed by the Apple approval process as well as what is the most reliable. The application does have the ability to play music in the background, if that factors into what is approved by Apple.
The first option, is to continually send some sort of heartbeat to the server at a set interval through a simple GET/POST; however, the concern is whether or not this is allowed as a background task. In a very roundabout way it can be argued that it is necessary for the playback but I'm not so sure whether or not that is acceptable. If the server does not hear from them in a set amount of time it will assume the app is no longer running.
The second option involves using a presence channel socket connection and have the server just handle when users enter and leave that channel. With this option the main concern is how reliable is a socket connection like this while an app is in the background. Similarly, whether or not this is allowed by Apple. In this case when the app dies, connection closes and server knows app is not running.
Third option can be used in tandem with either of the other options but to use some sort of APNS push to query the phone as to whether or not it has died and have it respond with some data to let us know; however, this seems somewhat counterintuitive as the push itself wakes the app up.
Any other suggestions or input are also welcome.
Not sure if this should be a comment or answer, but let me put my 2 cents here.
Firstly, Can you please elaborate your needs further, because in case you are playing an Audio in background with AVPlayer/AVPlayerItem you would hand over your content URL to iOS and it will make the calls as and when necessary to keep the playback running, you dont need to know about apps' state.
Let me assume, for whatever reasons you want to achieve what the question asks:
There are 3 states your app can be in when it is "Not Running"
i. Suspended State: your app is not killed but its not receiving any CPU time to execute your code.
ii. Killed by OS: Your app can be terminated by iOS to free up the memory or any other resources.
iii. Force Killed by User: If user swipes up your app from app switcher it gets force killed.
Now when your app is Not Running, you CAN NOT query it, but you can move it to Running State. You can achieve this transition by using following methods (Not exhaustive list, but mentions common ways)
i. Background Fetch : You can configure your app to be invoked periodically, so that it can synchronise with the server and updates its state.
ii. Push Notifications (APNS) : You can ping the app from server so that iOS invokes it for some short period of time (few seconds) to update its state.
iii. VOIP Pushes: If your App is VOIP app you can use PushKit to send Silent Pushes which will launch even the Force-Killed Apps, the above two methods does not transition the app to Running state if it was force killed by user
The above point can be helpful in devising overall strategy but does not answer the question, "How to keep syncing the RUNNING state"
i. When your app is Running(Forground/Background), you can do almost anything that is publicly documented, you can keep calling a URL every minute or every 5 seconds, you need to worry about UX on the device rather than approval process, (People will delete app if they see your app in top battery drainers in the settings section)
ii. For making an HTTP call while your app is in background, you can look at Background URL Session, which off loads the HTTP calls to another process so that the call completes even if app gets killed.
iii. For the socket based approach please refer this technical note. The main issue is that you do not/can not know when your app moves from Running to Not Running State.
iv. As you mentioned that your app uses background audio, it will be always be in Running state if the user plays an audio and puts app in background, in such case you can use Periodic Observer to do some Heartbeat call periodically when the content is being played out.
I am trying to create a GPS location app that will monitor and send the location to a server. I want the location service to be able to continue to run even after the app is terminated/killed(not just in the background).
Does anyone have any idea on how to do this?
You can do this, but your options are very limited
Your app won't be able to be in the store:
2.8 Apps that install or launch other executable code will be rejected
https://developer.apple.com/appstore/resources/approval/guidelines.html
It might get kill on background
Save user data and app state information. All unsaved changes should be written to disk when entering the background. This step is necessary because your app might be quietly killed while in the background for any number of reasons. You can perform this operation from a background thread as needed.
http://developer.apple.com/library/ios/#documentation/iphone/conceptual/iphoneosprogrammingguide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html
But if you still want to do this, check this out:
I guess the answer is 'sort of'. If you don't want to jailbreak phones, your options are rather limited. As long as you're only intending to distribute internally, you can look into the VOIP background services.
It's part of iOS 4's background services, and is intended to allow VOIP apps to run constantly in the background to pick up events such as incoming calls, etc. It is possible to use it to achieve other things, such as a regularly scheduled service (I think there was a recent question where somebody wanted to use it to act as a 'data counter', again for the enterprise program).
From Here: iphone daemon process
I'm currently developing an app where the device's location should be send to a server. I've worked through the MSDN articles on the background agents and accessing the location. This works so far. My location is transmitted to the server when I've triggered a location change which is farther away than the set MovementThreshold.
However, I've read that testing of background agents can be complicated. If you use the Emulator, you can easily change your device's location very often. But on a real phone, location background services are limited in their idle runtime to 30 minutes and execution of commands should only take up to 25 seconds. Background agents can also be disabled by the user from the phone's settings screen. They are also deactivated, when the agent crashes more than two times in a row. Another limitation is that inactive background agents are stopped after 4 hours, if they don't update an apps live tile.
My app updates a live tiles counter, so I think my background agent should be running up to 14 days without restart from my app. I've tested the app from yesterday to today and saw the background agent running (when looked up from the settings). There was also the small dot in the upper bar visible, indicating that a programm is accessing the phones geo location. However, sometimes the dot vanishes and my background agent is killed for no obvious reasons.
Therefore my question are:
How can I reliable test geo location on a real device without the need to travel with phone and attached debugging laptop?
How can I test in a timely manner for the timeout scenarios I've mentioned (30 min, 4hrs, 14 days)?
How can I check for these two crashs of the background agent?
I think I've made some missinterpretations of how WP8 defines Background Agents. The new WP8 background agent for location is only active, when the app is running. This means that the app must not be closed with the back button. However, it can be switched to the home screen with the windows button or with a long hold back button to access other apps from multitasking.
Regarding my questions:
How can I reliable test geo location on a real device without the need to travel with phone and attached debugging laptop?
How can I test in a timely manner for the timeout scenarios I've mentioned (30 min, 4hrs, 14 days)?
I still have no suitable solution. You are somewhat limited to testing with real devices and the necessary time required to test your constraints.
How can I check for these two crashs of the background agent?
I don't know how to check for this programmatically. It may be, that a user can see this crashing app as a blocked app in the list of background tasks of the phone's setting. There should be a way to detect a blocked app from this list with the help from the links I've supplied above.
For my project, I needed a location background agent, which runs even with locked screen or with no open app. Therefore I've used a PeriodicAgent to require the location once every 30 minutes so that I can send it to the server. But be aware that this background agents cannot access your application settings or classes (see Communication between foreground app and background agent).
We are working in a groupon-like app where alerts are displayed to the user when he/she enters in the range of an offer.
The client insists on having alerts even when the app is in the background.
Due to the architecture of the system, the app gets the location of the client at intervals and checks with the server if there is any new alert. If so, the app does some processing in the local database and displays a notification.
APN cannot be used since changes in the server are out of reach for this project.
My question is whether Apple would accept it in AppleStore as I have read different opinions about it and Apple discourages its use as in this extract from iOS Developer Library
http://developer.apple.com/library/ios/#documentation/userexperience/conceptual/LocationAwarenessPG/CoreLocation/CoreLocation.html
At wake-up time, your app is put into the background and given a small amount of time to process the location data. Because your app is in the background, it should do minimal work and avoid any tasks (such as querying the network) that might prevent it from returning before the allocated time expires. If it does not, your app may be terminated
Thanks
How often does your app get location from the user? According to Apple's Background Execution and Multitasking, if you are getting the location updates on a regular schedule (I think it's less than 10 minutes), your app can still process in the background if you add location to UIBackgroundModes in your info.plist. With those CLLocation coordinates, you can then process your web service requests.
I personally have not done something like this, so I can't tell you for sure if Apple will reject your app or not. However, if everything is within the guideline and requirements set by Apple, I don't see why they would reject your app.
EDIT:
From the Apple doc:
An app that provides continuous location updates to the user (even
when in the background) can enable background location services by
including the UIBackgroundModes key (with the location value) in its
Info.plist file. The inclusion of this value in the UIBackgroundModes
key does not preclude the system from suspending the app, but it does
tell the system that it should wake up the app whenever there is new
location data to deliver. Thus, this key effectively lets the app run
in the background to process location updates whenever they occur.
I guess even if the app is suspended, it will wake up whenever there is a new location data to deliver.
I think you should reconsider your approach for this application. It sounds like you have decided to build a set of features which are not necessarily well informed by, or a good fit for, the characteristics of the devices the app will run on.
You write that "the app gets the location every n minutes" but that's not how iOS location services work. Querying location services for the current location occasionally is a good approach when your app is running in the foreground but that's not an option once it is suspended or terminated. Instead you need to subscribe to location events, at some level of accuracy, and your app will be notified when the device's location changes. There are no guarantees about the schedule on which you receive these events and it varies depending on the accuracy you request and the speed at which the device is moving.
Additionally, obtaining a location is an expensive operation and can quickly drain the device's battery. Burning through a user's available battery power in an hour or two is a very good way to get your app uninstalled quickly. Where possible you should be using the significant location change service to get low accuracy location updates with minimal power consumption. If you need more precision then consider using boundary crossing events for a defined region or at least reduce the accuracy your have requested as much as possible.
With all that out of the way you still need to work within the limited time your app has to run once started by a location update. That's probably not long enough to make a round trip to the server. If a network connection is already active and the device happens to have low latency you will probably get a response some of the time but I would expect to see the app terminated by the OS frequently. When that happens I don't know that you will continue to receive location updates which might otherwise re-launch the app.
Instead of downloading a list of alerts and displaying them locally a better solution might be to attempt to send your current location to the server via UDP when you see a significant location change. That way you can fire off a network request without waiting for a response. Only some of those requests will still succeed but at least your app won't be terminated. You can then process the locations you receive on the server and send push notifications when appropriate.
I realize that you don't seem to be able to make server side changes. In that case the best you might be able to do is pre-fetch alerts for the nearby region when the app runs (and if you ever manage to complete a round-trip while in the background). That way you could compare location updates to that list and not need to fire off a network request on every location update. Unfortunately it sounds like you might be backed into a corner here with no reliable solution available under your current constraints.