While working on iphone security architecture, i came to know that i can run applications from other applications in iphone. referring to the following url http://iosdevelopertips.com/cocoa/launching-other-apps-within-an-iphone-application.html
for example, i can put a link in a website with following hyperlink
skype://
will result skype to run and call at particular number. Now i have few concerns here.
is there a shell running in background in iphone, so that it allows other application to run basic app commands.
if the above statement is true then how can i enable or run commands directly into iphone shell?
if above statements are false, then could you please explain how these commands are being executed?
is this part of iPhone SDK? or this funcationality is iPhone OS
This is functionality of the iPhone OS. Applications register themselves as URL Handlers for particular protocols. In this case the Skype app is registered to handle skype:// URL protocols.
An Application registers itself as a protocol handler via the CFBundleURLTypes key in it's Info.plist. See here.
The OS reads this key when your application is installed.
Whenever a URL for that protocol is encountered and tapped on, the OS will launch your App and your Application Delegate will be sent the application:handleOpenURL: message.
It is then up to your Application to correctly decode the URL and perform the correct action.
PS. There is virtually identical functionality available in Mac OS X, with the additional possiblity for URLs to be sent to already running applications.
A shell can be spawned with system or popen etc. Of course, because the apps are sandboxed, fork() is denied so the shell won't be accessible from any AppStore apps.
However, there are lots of stuff running in background on the iPhoneOS. One of them is SpringBoard.app, which is the "home screen" you see on start up. Actually SpringBoard.app is responsible for much more stuff than just displaying the home screen, one of them is to receive and deliver URL requests.
The registration process has been described by #Alan. But under hood, when a URL request is issued by an app, the following will happen:
The app, knowing itself cannot handle a particular URL, calls -[UIKit openURL:] to delegate the open request to others.
UIKit will package the URL request into a GSEvent (an IPC mechanism), and then dispatch it to SpringBoard.
SpringBoard, receiving this GSEvent, calls -[SpringBoard applicationOpenURL:].
This method will check if the URL is well-form and safe (stuff like tel://*5005*78283# will be rejected, for example). If it is valid, the action will be performed (dial a number, subscribe to a calendar, open an app, etc.)
what alee is asking about, I guess, is the "mailto://". when you put this in the browser address bar it does not do anything, but if you put it as a link and click on it, it lunches the mail app. why does the mail app have this behavior?
Related
Here is the use case:
the user launches the app and grants permission, the app connects to the server
at some point in the future, the server sends a request to the app
the app
regardless of whether it is running or not in the foreground or background, wakes up to run this code
Here are some options I have explored which I am unsure about:
server sent events
websockets
push notifications
Is there a reliable and safe way to do this on android, whether it's Kotlin or Flutter? Can you provide examples or documentation?
Thanks!
Turns out that the best way to do it is with push notifications!
Websockets and server sent events are better suited for other use cases. Persistent connections to a server are resource consuming, and both Android and iOS have mechanisms in place to terminate apps running in the background to save memory etc. So we would probably lose the connection and not be able to receive anything from the server if we minimized the app or locked our phone screen.
Push notifications are basically built for this exact use case because, even though they work differently on Android and iOS, they are built to receive messages from a server regardless of whether the app is in the foreground, background, or not even currently running.
I used Firebase Cloud Messaging to build my app since it's primarily an Android app. It worked like a charm.
I know this question may be a little bit common and over asked but I cannot find any precise information... so :
Is it possible to have some kind of thread running when the app is in background so I can perform basic sync with my webservice ?
App is in background : I mean the user clicked the Home button, or switched to another app
basic sync : photo upload and download with AFNetworking. I know it has method to continue an HTTPRequest while app is in background, but this is not my point.
My goal would be to make some kind of sync manager, reading a list of photos to update created while the user was on the app, and perform those changes.
I know that the manager could be killed by the OS, but since my server uses atomic transfers it is not a problem. I just need a way to relaunch it... Push ?
I think apps like Google Latitude or Mail and those kind of apps uses what I am looking for but I cannot find any relevant details on it. And using iOS5 is not a problem but waiting for iOS6 would not be a solution.
Thank you for your replies !
PS : well I almost forgot. the app is designed for an enterprise program, so maybe rules are different ? I don't think there is any check for in-house deployment so it might lead to new possibilities...
Apple's Mail client has a background daemon which keeps it running but you can't have that with your own applications. Once an app enters a background state, it must halt it's operations. You can request for a little more time when backgrounded to finish off any transfers or writes to disk (see the Executing a Finite-Length Task in the Background section on Apple's Multitasking Guide)
Google Latitude has events generated based on location. This is a special type of backgrounding introduced by Apple for certain types of applications (see Implementing Long-Running Background Tasks section on Apple's Multitasking Guide) but this can't be used for HTTP syncing. It can only be used for audio, location, voip, newstand content, bluetooth and external hardware attachments.
Push doesn't seem like a solution because it only generates an alert. It doesn't trigger any action until the user triggers the opening of the notification.
You'll want to read Tech Note 2277 Networking and Multitasking.
Basically you have a couple of options:
If you can convince Apple that your app is a VoIP app then you can register a VoIP socket and the OS will resume your background app whenever there is activity on that socket.
Your main option though is to register a background task for any outstanding activity that you have to do when your app is put in the background. You typically get 10 minutes to finish up that work.
Mail is a special app with privileges you don't get.
Apps like Latitude typically register themselves for location updates, specifically to be woken up when there are major geo-position changes. Apps that record GPS tracks do similar things.
Found it !
Using Suhail Patel 's link on Apple's Multitasking Guide I added the voip tag to UIBackgroundModes in Info.plist and use setKeepAliveTimeout:handler: method of UIApplication to relaunch it if needed once the app is going to sleep.
I hope this will help a lot of you !
Of course this app won't be allowed to be on the App Store but for in house development this is in my opinion the best way to do so.
Thanks everyone for showing me the right direction !
Under iOS there are several built in hooks for launching service-specific apps based on a passed URL for example handling http:// (to Safari), handling addresses (to google maps) and phone numbers (to the built in phone app). Several apps make it a standard practice of implementing the rarely used ability (for most apps) to register your own service prefix. Two handy apps that come to mind that implement this are facebook:// and skype:// and it is a handy way to add quasi-integration with their app into yours. Skype even does this on most desktop os's so you can literally run the command line skype://555-1234. You can also check for these registered service prefixes and expose useful menu choices in your apps but I digress.
As with all of these service handlers built in or not, the problem under iOS is that you lose the user and the flow of their experience ends with the phone app (for example). Yes you can embed web views to handle some cases but things like the phone app still win out.
I propose that it would be great that if iOS apps were handed a trailing URL as part of their arguments (even if they accept and might handle say two args already) that by convention when our app is exited we launch the trailing URL we may have been optionally handed. If fully supported in some manner this would allow for multi-app integration and an extended user experience flow-wise. I'm imagining being able for example to launch a phone call and have the user return to my app when it is finished by launching my app again using the URL I passed it such as "myapp://return-context-values". Obviously this could be taken further.
Does such a mechanism already exist in some way? If not I'd like to hear your thoughts on the idea.
Check out x-callback-url.com, it proposes precisely what you're suggesting.
And yes, I think it would be great. You're much more likely to pass a request to me if you know you'll get the focus back, and vice versa.
Is there any good advice on uploading files to the device? I've seen many apps create a http server on 80 or 8080 to upload files. Does that mean I have to implement a server too?
Are there any 3rd-party libraries? (Preferably open-source and non-GPL)
EDIT: I am going to upgrade files in the app for specific devices in a corporate environment, so the ipad pulling files from a central server is also an alternative. But I would have to send messages to these ipads to tell them to fetch those files.
But I would have to send messages to
these ipads to tell them to fetch
those files.
Push Notification Programming Guide
Or mail with custom URL scheme for launching your application.
iOS Application Programming Guide - Implementing Custom URL Schemes
I assume what you want is a kind of automatic update. An app do something by order from server without user's manual operation.
I don't know enterprise-license specific feature of iOS. But I believe there's no such enterprise-specific APIs. And as I know, automatic update is almost impossible. Because,
There is no system-level support for automatic update. (yet?)
So messaging and fetching feature should be implemented in app.
But no app is guaranteed to run in background for long time.
And also user can turn off any app at any time.
There is no way to send message to an app which is not running.
Even you can send, there is no way to address each client form the server.
If your app is running, sending message or commanding them to fetch or do anything is just a simple work. The problem is there is no regular way to force them always keep alive. Even under situations like OS reboot or abnormal termination.
However there is an alternative. Just registering app as VOIP app like Skype. OS does not keep the app running too, but will monitor specific socket port, and will wake your app when the socket receives some message. For more details, see here: http://developer.apple.com/library/ios/documentation/iphone/conceptual/iphoneosprogrammingguide/BackgroundExecution/BackgroundExecution.html#//apple_ref/doc/uid/TP40007072-CH5-SW15
In AppStore, an app using VOIP for other purpose like automatic update will not be passed, but you have no need to concern about it.
And other way to send message to device without running app is push notification. This is a feature supported in system-level. But this is not designed to commanding app. This is designed to send textual message. So If your app is not running, the message will be displayed to user. However, you can guide the user to start the app by sending push notification.
As a final option, you can request some feature to Apple for enterprise environment. If your company is big enough to get an enterprise license, Apple will consider your feature request seriously.
If you decided to use VOIP method, I'm sorry I can't help you any more. I have no experience of implementing this kind of app. But it should not so hard.
However hard part is server. It definitely require custom server program which keeps TCP/IP connection. Regular HTTP server cannot be used. Because HTTP itself is designed as not to keep TCP/IP connection. You have to build this kind of server yourself from scratch. You'll have to handle lower level TCP/IP transmissions.
There are a few solutions(both of free/commercial) for this kind of server, but none of are popular because this kind of server regularly needs full customization. So there's nothing to re-use or share.
However I believe this is most suitable implementation for your app.
If you can satisfy automatic update only when the app is running, you can archive it by polling server status from the client periodically.
This is easy to implement because you can use regular HTTP servers for this. Client connect and download recent updates from central server periodically. If there is a new update, just fetch and do what you want. And the app is launched, just check the update at first. Prevent all operation until update applied.
This is regular way. Most of applications are built with this method. In this case, you have no need to implement server or hard thing.
However applying speed of update is depend on polling period.
(Edit)
I couldn't care about private APIs. Because your app is not for AppStore, so you can use private API's freely. (This is different thing with jail-breaking. There are so many hidden features by excluded from documentation) I don't know about private APIs, but it's possible there is some API which enable the support for keep-alive of the app.
However, this reverse engineering work is so painful unless you're born to hack.
You may try to use the following open-source in your project:
http://code.google.com/p/cocoahttpserver/
https://github.com/robin/cocoa-web-resource/wiki
Apple has some sample code on their website that details exactly what you're looking for:
http://developer.apple.com/library/mac/samplecode/CocoaHTTPServer/CocoaHTTPServer.zip
So you have a couple options:
You could distribute your app wirelessly within your organization and push new content out as app updates. Apple provides this option to their Enterprise Developers.
Wireless App Distribution
iPhone enables enterprises to securely host and wirelessly distribute in-house apps to employees over Wi-Fi and 3G. Apps can be updated without requiring users to connect to their computers. In-house apps can be hosted on any web server accessible to users. Users simply tap on a URL to install apps wirelessly without needing to connect to their computers.
The alternative is you configure the app to fetch the updated data. You describe adding an HTTP server to the iOS device, but there's no way the server can receive data when the app isn't running. Given your needs, it would probably work better to embed a web client in your app instead.
If I was in your shoes (and option #1 didn't work), I'd use ASIHTTPRequest to check with a server at launch/daily. If there are new updates, the app could then either prompt the user that there are new data files to download, or it could just silently download them in a background thread.
UPDATED: Perhaps I should have been more explicit about how to do #2. You can configure the download so it isn't interrupted when the user quits the app (you don't need to do a Voip hack). Check out the Completing a Finite Length Task in the Background section in the iOS Programming Guide.
There are http server sample codes from Apple and open source community such as cocoahttpserver TouchHTTPD.
You can upload file to the http server on iphone.
Here's a blog and screen-shots about running cocoahttpserver and upload file to iphone.
The Python CGIHTTPServer allows you to create a server in 0 lines of code:
jcomeau#intrepid:~/rentacoder/bin2txt$ python -m CGIHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...
Actually implementing a script to parse the input and save the file would take a little more effort.
[later]
OK, so forget about that, Apple doesn't allow it. See Local server on iPad for the iPad at least.
We want to build an application that the user can interact with while taking a phone call. The idea is that the user can do voice communication using the phone application of the iPhone and at the same time use our application to type and send additional data that is relevant to the call such as an e-mail address. This is the scenario:
User get's a call on the iPhone
The user clicks a button on our app to answer the call and let the phone application on the iPhone handle the phone call in the background.
Our application continues to run in the foreground so that the user can interact with our application to type and send data such as an e-mail address that is relevant to the call.
Is there a way for our application to answer an incoming phone call and let the phone application of the iPhone handle the call in the background while our application continues to run in the foreground?
Thanks,
Prasanna
Currently, the iOS SDK does not support redirecting incoming calls from the system to a custom application. There is only support for initiating a call.
This is not possible with the iPhone SDK.
You could possibly do this if you created your own calling (for example, like Skype does) but I'd say you're barking up the wrong iTree here. It is however possible on jail-broken devices using the custom toolchain but I wouldn't want to recommend that path for development!
You have no control over the phone call process on an iPhone (this is assuming that you’re not talking about a jailbroken iPhone). When the user receives a call, the iPhone presents a window with the number and the “Answer” and “Ignore” buttons (or, if the phone is locked or asleep, the “Slide to Answer” bar). To return to your or any other application, the user must press the home button, sending the call to the background (and activating the red in-call status bar).
The closest you’ll get to this scenario is the user manually running the application while on the phone. But then, if all they’re doing is writing notes, they could just use the Notes app.