views:

109

answers:

2

Hi guys,

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

A: 

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.
tc.
@tc: thank you so much... That helped a lot... I edited info.plist and it works fine. I will use your method 2 in case my loading time becomes longer in the future when I add more functionality into the app.
+1  A: 

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:

  1. Cache the credentials (ie username and password) and silently use them to resume the session when needed. If the back-end supports this.
  2. 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.

Jeremy
@Jeremy: Assume that I cache my details before the app goes into background. Say that I was in a navigation controller's (x+5)th view. Now when I reopen the app I want to display "Default.png" and then the navigation controller's (x+1)th view no matter where I was when the app went into background. Basically I am asking how to reorder views and also delete some views if required before going to background. I know this might be a silly question..but am new and sorry about that. your help will be greatly appreciated .... Thanks
My interpretation is that Jeremy is asking *why* you want the UI to behave the way you do. It's a terrible user experience if you have to start from the beginning if you receive a phone call while using your app. While there may be valid marketing reasons (e.g. you want to show the splash screen), that doesn't make it good UI.
tc.
basically for the authentication timeout. Is this method good ? -- > when app enters background: run a timer for 15 mins and if it expires then kill the app. Is there a better way to do this ?
You can definitely take action when your app is about to be suspended and when it returns from suspend. Implement the following functions in your app delegate:applicationDidEnterBackground - clean up your views hereapplicationDidBecomeActive - restore to your chosen state hereHowever, my point, as @tc mentioned was that you need to think about your app being suspended for non-user triggered events like an SMS or a phone call. In this case not going back to what the user was doing would be extremely annoying.
Jeremy
As to knowing when the session has timed out don't run a timer as this will be suspended when your app is and is a waste of CPU. Instead record the absolute time your user authenticated and then, before using the session, check the difference between the current time and the timer and trigger a re-authentication if you need to.Clearly, the logical approach here is to put this login-time variable inside your session object.
Jeremy