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.
Related
I want to send my Application to background simply clicking on Button inside my Application.
Is there any way to call applicationdidenterbackground manually or any other way ?
iOS Human Interface Guidelines says "Don't Quit Programmatically", whereby quitting must be understood as including "suspending":
Never quit an iOS application programmatically because people tend to interpret this as a crash. However, if external circumstances prevent your application from functioning as intended, you need to tell your users about the situation and explain what they can do about it. Depending on how severe the application malfunction is, you have two choices.
Display an attractive screen that describes the problem and suggests a correction. A screen provides feedback that reassures users that there’s nothing wrong with your application. It puts users in control, letting them decide whether they want to take corrective action and continue using your application or press the Home button and open a different application
If only some of your application's features are not working, display either a screen or an alert when people activate the feature. Display the alert only when people try to access the feature that isn’t functioning.
If you really want to exit your app programmatically, then you can call exit(0);, but I doubt that you app will pass the Apple review.
Unfortunately There is no any officialy way to force app to background state(Pause state).
I have a question about CLLocationManagerDelegate. The documentation says if the user changes the settings for your location services (in the iPhone's Settings.app) then your app is supposed to receive an didChangeAuthorizationStatus: message to the delegate. My question is, when would this happen?
If the user changed the setting, it means they are in the settings app, and your app is either backgrounded or not running at all, so in the former case, when would your app's CLLocationManager delegate get the didChangeAuthorizationStatus: call?
I just ran across this method an hour ago, so good timing on the question!
It looks like in my case this method gets called:
When the app becomes active.
On allowing Location Services for the app on the initial startup of the app.
I wrote a quick test app you can find here:
https://github.com/mharper/LocationServices
It simply logs the authorization status whenever the method gets called.
This delegate method will be called when:
The first time you init a CLLocationManager instance
1.1. If that's the first time your App launch on device, you'll receive state kCLAuthorizationStatusNotDetermined before user see the [Allow/Don't Allow] UIAlertView. (At this time, you can find that the UISwitch of your App in Settings - Privacy - Location Service is turn off or not shown.
1.2. When user re-launch your App. Because decision has been made in previous launch, so you can retrieve the state.
The first time after user made decision. This is obvious. After you call the startUpdatingLocation/startUpdatingHeading, then iOS show the UIAlertView.
In your answer's situation, user made changes in Settings, if your App is running in background, you'll receive the new state when your App become active. Otherwise, reference 1.2.
If your app is running in the background or not at all it will be called the moment the user returns to your application.
I encounter the same issue as well.
my solution is put the request gps authorization code in main loop.
I guess it can also works if you put in another run loop.
I ran into this problem of handling location permission changes correctly recently and did a lot of research and debugging.
If the app is not running at all and the user changes location permissions in Settings, then when you start your app, locationManager:didChangeAuthorizationStatus is called when the location manager is initialized as stated in mharper's answer. This behavior is not in Apple's docs.
If the app is in the background/suspended, I tested it in the simulator and it looks like the delegate function is also called.
I would like to close an iPad application as a result of clicking on a UIButton. However, I have not seen how to do this in the Apple documentation.
What call needs to be made to close an app?
Thanks.
You can call exit(0) to terminate the app. But Apple don't like this as this gives the user a feeling of sudden crash. If you still want to have an exit function (with a potential risk of rejection) then you should also send your app delegate the applicationWillTerminate message (if you have anything important there) before performing the exit.
It says:
Don’t Quit Programmatically
Never quit an iOS app programmatically because people tend to
interpret this as a crash. However, if external circumstances prevent
your app from functioning as intended, you need to tell your users
about the situation and explain what they can do about it. Depending
on how severe the app malfunction is, you have two choices.
Display an attractive screen that describes the problem and suggests a
correction. A screen provides feedback that reassures users that
there’s nothing wrong with your app. It puts users in control, letting
them decide whether they want to take corrective action and continue
using your app or press the Home button and open a different app
If only some of your app's features are unavailable, display either a
screen or an alert when people use the feature. Display the alert only
when people try to access the feature that isn’t functioning.
The only way for a user to exit an application is by pressing the Home button. You can't do it in your app, at least not in a way that Apple would accept.
You can try to use command:
exit(0);
I am fairly new to iphone app development. I am creating an app that has multiple views. Initially it starts with a view for authentication and then load views according to user interaction. When I build and run the app - the first time it shows the "Default.png" screen and then shows the first view where I do my authentication process (typing in userid,password and do a web service) and then after the credentials are verified it takes me to the next view. When I close the app at this state in the simulator and reopen it again, I am seeing the same state in which I closed my app. But here is what I want. When I relaunch the app I should be able to show the "DEfault.png" and screen and then show my initial authentication view. Can you please help me out on this ? Thanks
It sounds like the problem you are trying to solve is that your authenticated session may time out while the app is suspended and you need to log in again.
Although the proposed solution (setting UIApplicationExistsOnSuspend to true) would work I think you should consider a different approach.
Apple recommends that you do everything you can to make it look like the phone supports multitasking. That is why, by default, your app will suspend and resume instead of exit and relaunch. In your case, though, you may need to re-login to resume the session. I offer you a couple of alternate solutions:
Cache the credentials (ie username and password) and silently use them to resume the session when needed. If the back-end supports this.
Detect when the session has become stale and bring in a view to inform the user that the session has expired and ask them to log in again. This would also address the issue if the user keeps the app active past the timeout of the session.
Both of these approaches should improve perceived app performance and integrate better into the Apple usability guidelines.
That's because iOS 4 apps are supposed to support multitasking. You can change the app so it doesn't: In Info.plist, set UIApplicationExitsOnSuspend to true (i.e. <key> UIApplicationExitsOnSuspend</key><true/>) — make sure it's a boolean and not a string. Note that this will probably make startup slower, since the app has to be launched again.
The other way is to handle applicationDidEnterBackground: in your app delegate and do two things:
Reset your view hierarchy (you can do this on next launch, but doing it earlier might help to free more memory)
Show "Default.png" in a full-screen view — iOS takes a screenshot of your app after it's hidden which it uses to animate the app back in.
In the home page of my iphone app, there is a button added. When that button is clicked some other iphone app needs to be opened in a new viewcontroller (with out closing the parent app).There will be a back button on this view controller. When the back button is clicked, the new viewcontroller which is showing the another app needs to be closed and our parent app's home page needs to be shown.
Please give me some ideas on how to do this. I googled for this i didnt get any solutions.
Thanks,
Raja.
-- the following applies to iOS versions previous than 4.0 :)
Actually, there can be only one iPhone application running at once (with exceptions of Safari, Phone and some other system applications). The iPhone Human Interface Guidelines say so:
Only one iPhone application can run at a time, and third-party applications never run in the background. This means that when users switch to another application, answer the phone, or check their email, the application they were using quits.
However, if you only need to e.g. show a webpage, you can do it using UIWebView
Also, if you need to open another application, you should use URLs as pointed by Steve Harrison. This will, however, close your application. The recommended behavior in this case is to remember your application state and restore it when the application is run again, as Nithin writes.
According to apples documentation, they are not allowing any applications to be run in the background, except system generated ones. So you will be unable to do the thing you are going to implement. However, there is one thing that can make the same result.
You told that you are calling other application to run on a button click. Before initiating that application, save the current state of your application, may be using sqlite3 or core-data, and then open the other one. While returning back, load the pre-saved data from the database or wherever you have stored it. Every time you start the application, you check for the persisted data, if exists, load it or otherwise load your basic view
I don't think that you can run other iPhone apps within your own one. It doesn't make sense. You can open another iPhone app via a URL (see here and here), but this will close your app.
Like it has been stated: running two apps is not allowed by apple. You can however implement this apps features into you're app and have both get and save data to the same server...
Or like Nithin said: this functionality is available on JB iphones. Look into "backgrounder" for implementing one solution for normal users and one for thouse that has jailbroken.