I'm working on passing a couple simple things (like timestamps and settings) between apps installed on one iPhone, and I was wondering if there's any way to use inter-app URL handling in the background. The goal would be to pass a URL to another app without having it open, or even to simply have the receiving app detect when something else checks for the ability to open that URL.
Any chance that (or something similar) is possible in an app-store-friendly way?
I don't think thus is possible, but you could achieve this by setting up a webservice that "communicates" between the individual apps.
Related
I have an application that runs in the background, I need it to pseudo randomly take a picture using the forward facing camera and send that to a database.
A possible solution I thought of was to use URL schemes to open another application, which will take the picture and send it, then use another URL scheme to open the background application back up. Does anyone know if this is possible?
Or perhaps there is a better solution.
It is not possible for an iOS application in the background to initialize, utilize, or grab photos from the camera hardware, let alone store or upload them to a local database.
Not only is this a security risk, but it poses a potential privacy invasion, and is just plain creepy. Besides, background apps only stay alive for 10 minutes or so, so even if this activity were possible, sustaining it would be impossible.
However, it is possible to use the camera directly from an active app without having to delegate the task to another application (perhaps you are thinking a little too much like an Android developer :p). Take a look at UIImagePickerController.
There's a very limited set of actions background applications can do—GPS, audio, phone & VOIP calls, and a couple of others. Accessing the camera is not one of those allowed actions, so you can't take a picture in the background.
As an alternative, you could set up a notification system to alert the user that it's time to take a picture (for whatever reason), and if they choose to open the app it could do your required actions then.
I am making an app that has multiple usage cases. It has the main functionality (activated by pressing the app icon), then other subsets of the main functionality which are activated by a custom URL scheme.
To explain my problem, I should explain how I currently tell my app to behave differently.
I have been using:
-(BOOL)application:didFinishLaunchingWithOptions:
grabbing the url from the options:
[launchOptions objectForKey:[keyArray objectAtIndex:0]]
Now I parse that urlString and grab all of my launchType parameters, putting them in NSUserDefaults. Then I wait for my splash screen to come up, then it will tell my app how to behave.
This seemed okay at first, but then I realized that: if I deep-link into the app, and am presented with functionality B, then the app goes into the background, the next time the app take the foreground (no matter which way), it will display functionality B.
I was wondering if anyone had an idea about the standard practice, what methods do people usually use?
FYI,
I am going to be trying to fix this problem by telling my navigationcontroller to popToRootViewController, when
-(BOOL)application:application handleOpenURL:
is called, UNLESS didFinishLaunchingWithOptions is called before it, in which case, just do what I had previously implemented.
It sounds to me like there are a couple of things for you to consider about this approach.
First of all take a look at the UIApplicationDelegate documentation. -application:willFinishLaunchingWithOptions: warns:
If your app was launched to open a URL, you should examine the value
of the UIApplicationLaunchOptionsURLKey key and return a Boolean value
indicating whether your app can actually open the URL. You should not
try to open the URL in this method. Instead, implement the
application:openURL:sourceApplication:annotation: method in your app
delegate and use that method to open the URL.
Looking at -application:openURL:sourceApplication:annotation: we see:
If your app had to be launched to open the URL, the app calls the
application:willFinishLaunchingWithOptions: and
application:didFinishLaunchingWithOptions: methods first, followed by
this method. The return values of those methods can be used to prevent
this method from being called. (If the application is already running,
only this method is called.)
Secondly it sounds like you are using NSUserDefaults to persistently store what should be a temporary state (if the app was launched via a url or not). Do you ever reset the values you set there or does launching the app via a url once leave it stuck always following that path.
Finally users have a reasonable expectation that apps will resume where they left off. Users will leave your app to respond to phone calls, text messages, notifications, external distractions, needs for other apps, and any number of other reasons. Refusing to allow them to return to where they left off when they resume/relaunch the app (not via a url) may produce a poor user experience.
I have worked a bit with URL schemes and have managed to access a custom app that i created using another app. My requirement is to block my custom apps once the battery level goes less than a certain level.
Is there any way to do that? What data will I have to pass through the URL scheme?
By block i mean either disable or uninstall completely. Just seeking some control.
You cannot completely block your application from launching if it's being opened through URL scheme. I suggest checking whether your app is launched by opening a scheme and then just display an alert view with a notice that your app requires the phone to have more battery power (or be charging).
i think you should use push notification, it can handle your requirement
I want to make an app that runs in the background so that if a user is reading a web page or PDF file on an iPhone or iPad, he can mark some words, see the meaning of those words, and then have those words stored in the app's database. He can then afterwards look for the words which he has learnt and increase his vocabulary.
Does the iOS 4 API allow that? What are the limitations? Advantages? Disadvantages?
Thanks in advance
No is does not, you can only run voip. audio or navigation apps in the background.
Only one app can run at a time, and installing one app cannot effect any built in app. So no, there is no way to achieve what you are trying for here.
Your best bet is to instruct users to copy the word, open the app, and then you can snag whatever is on the clipboard then.
(Note there are multitasking APIs, but you still cant access anything outside of your app even if you convince the OS to let you run in the background for a little while)
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.