I want to make an iOS application (for iPad specifically), which behave like a web server.
I saw the examples coming with COCOAHTTPSERVER, but i didn't understand something.
Is it possible for my application, while being in background, to receive a request from another application running in the same device?
If it is possible how can i do this?
Otherwise, if it is impossible, what is the meaning of a web server application, that can't work in background?
My exact problem is as follows: I need an iOS application that can receive a request from a javascript application, running on safari, in the same device. Can i create an application behaving like a web server in background (because safari must be in foreground), or there is another way to implement this?
You can run a web server in the background on iOS but unfortunately only for a limited time (up to 10 minutes max) and the OS can stop it at any time. See this tech note [1] for more info.
If that limitation is acceptable to you, you should use an already existing web server like GCDWebServer which handles background mode for you [2].
[1] https://developer.apple.com/library/ios/technotes/tn2277/_index.html
[2] https://github.com/swisspol/GCDWebServer#gcdwebserver--background-mode-for-ios-apps
This library may make your task much easier.
https://github.com/swisspol/GCDWebServer
No, iOS does not support web servers running in the background.
The reason Apple does this is that a web server has to listen for inbound network requests. Listening for inbound network requests requires that the radios be active all the time. Active radios drain the battery.
Related
I've created an iOS app, that connects to an embedded device using swift-nio-ssh. This app has no UI to control the device, as that is supposed to be done with a Watch app, using WatchConnectivity.
As it stands, I have to keep the iOS app in the foreground or the SSH client will die after a few seconds. Instead I'd like to be able to keep the proxy app running in background, screen locked or whatever else the user wants to do with their iPhone.
I've done research on background modes, but none of the available APIs seem to fit my use case.
Have I overlooked something?
If not, would I be able to abuse another API instead (Audio, VoIP or NetworkExtension from what I've gathered)?
If so, would the app still be able to pass the review process somehow?
Thanks!
You haven't overlooked something and this applies to everything, not just SwiftNIO-using apps. On iOS, if an app goes into the background then it will be stopped and network connections will die at some point.
The only way around that are the mainly VoIP exceptions you mention in (2) which you have to specifically request from Apple.
I am currently in the process of writing an iOS app and it's now been decided that there will no longer be an in-built real time messaging service. This was the main reason around using Socket.io on the server. So basically when the app is loaded it logged in in the background by sending the login credentials with the connection request. Now that I don't need the messaging service, most of the app is just information requests and the server responds with the relevant information. I could still utilize the real time aspect by sending updated information to the device if it gets updated on the server and some in-app notifications could utilize this too. However I'm pretty sure it can be all done using http requests and I'm not sure how likely I would need real time functionality in a future update.
Ignoring time and money, should I fundamentally re-write the way the server and the app communicate or would it be okay to continue using Socket.io and websockets?
Certain kinds of iOS apps are allowed to periodically run in the background. For a background-audio, bluetooth-central, or location-fencing app (as listed in the app's capabilities plist), can the iOS app open a BSD network socket (assuming the device has appropriate network connectivity) when given time in the background?
If so, what kind of problems might one encounter when doing this (errors, timeouts, etc.) other than those that an app would see when networking in the foreground?
I believe other than the services you mentioned the only other background task you are allowed is via the NSURLSession class. Using the NSUrlSession class you are allowed to make HTTP requests to a web server while the application is in the background.
For example, you're app could monitor for significant location changes in the background, and during the location change event you could send the GPS coordinates to the web sever via an NSURLSession.
However, from what I understand this is the ONLY networking you're allowed todo while the application is in the background without hacks. Therefore, I do not believe it is possible to open a BSD socket connection while you're app is in the background.
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
Is it possible to interface with a webservice (or, for what matter, do any scheduled local or remote activity) while the app is in background?
I know that you can receive remote pushes or schedule local alerts, but I wonder if I can periodically send my GPS position to a webservice even if the app is not in foreground.
I have been thinking about this myself in an attempt to impress my boss with an iPhone/iPad App that accesses our Web Service.
If the Web Service takes a non-trivial amount of time to process a request then there is absolutely no guarantee that the App won't be interrupted and stopped, therefore making it useless for any business-level tool. The only Apps that are allowed to run for extended periods in the background are a select set that use certain frameworks (music players, etc.).
I concluded that the only way of doing it is to introduce a middle tier that performs and waits for the response from the actual Web Service and provides an interface that the iOS App can poll or be pushed to in order to allow it to sleep/die whenever iOS thinks it should.
You can make sporadic network calls while you are running in the background if you are a location-based app with proper permissions. You need to make sure you are running a background task properly. FYI, there are a number of applications in the app store that do this.