Consider an app that was in the multitask bar, and was closed, clicking on the minus sign.
What is supposed to be the behavior of this app at restart?
Does the app restart from scratch with the splash screen and without old data?
Or does the app load saved data and restart without splash screen and with previous data reloaded?
Thank you.
The application should restore its previous state in as many cases as possible. Prior to multitasking, all the applications tried to do this, to give the users the impression of multitasking. With multitasking in iOS 4, this doesn't change. You still need to do this to:
Support older devices.
Keep the user experience the same even if the user opens tons of apps and the device frees memory automatically.
If its closed then it will start from "scratch" unless you use the app delegate methods which are fired to store data and create the functionality to reload somewhere specific in your app yourself.
The splash screen will show if there is loading time needed, just like when you start an app the first time.
I think a user who clicks the minus is probably doing it, either just to clean up, or because he/she would like the app to return to it's beginning setup, just as if the device was reset.
I handle the minus, just like that, and start fresh with the splash screen. (not sure what the apple guide recommends)
This operation (tapping on minus icon) is intended for freeing memory.
When Apple has introduced multitasking in iOS, usage of memory has increased a lot!
So, why you have to tap on minus to kill application? When do you have to do this?
When your device responsiveness is too bad.
After killing (closing) application, when you restart the app, it start from scratch or resume last operation depending on how the application has developed!
For example, look at FacebookApp. If you are logged-in and quit app, at next restart it's reopen your account and last page seen!
For something like a game, I would suggest you restore the user's state ONLY IF they were in the middle of a game, else just start from scratch. However, for anything else, always start from scratch.
If you do nothing, your app will probably start from scratch at the moment.
Related
I have a screen on my app that tracks the location (geolocator) and time with (timer_builder) when the user hits start button. When the screen locks/sleeps, it stops (or pause) tracking the location, but it should pause just when the user hits the stop button.
Could anyone help me on this?
I believe there is difference between running the app on background vs on lock screen, because I just found topics about running the app on background with android_alarm_manager/background_fetch (on this case awaken app in the background about every 15 minutes would not work too).
One solution would be prevent screen from going into sleep/lock mode, but then battery is problem. Any other solutions?
Thanks in advance!
I think background geolocation is a hard problem. However there is a project, flutter_background_geolocation. It works with debug mode. Unfortunately, in release mode, you need to purchase a license.
You can create background tasks with Flutter, see this article. Never tried it though.
I'm developing an iPhone/iPad application through Phonegap, is there a way to implement a sort of "click here to quit app"? I mean quit for real, not "put it in the background and go to home screen".
Thanks in advance.
you can use following code to quite your app on click,
device.exitApp()
OR
navigator.app.exitApp()
Hope this may help you.
is there a way to implement a sort of "click here to quit app"?'
Yes, there is a way for really exiting the app and killing its process.
But never do that. Not only because Apple rejects your app if you do this. The problem with this is bad user experience. iOS is not a desktop operating system. You have a Home button for leaving apps (and again, there's a reason apps don't exit completely).
The window size is, conceptually, not spacious enough for maintaining an extraneous 44x44 pixel frame (44 pixel is the minimal size that can comfortably be touched, according to Apple's Human Interface Guidelines) dedicated only for exiting.
However, if you still want to exit after this lecture, there are several ways:
exit(0);
pthread_kill(pthread_self()); // on the main thread
[[UIApplication sharedApplication] terminateWithSuccess];
etc. Some of them may have a binding in PhoneGap (if not, it's easy enough to write one yourself).
You should not do that as this may considered as violation of iOS Human Interface Guidelines, lead rejection of your app.
Always Be Prepared to Stop
**Save the current state when stopping at the finest level of detail possible so that people don’t
lose their context when they start the app again.** For example, if your app displays scrolling data,
save the current scroll position. To learn more about efficient ways to preserve and restore your
app’s state, see “State Preservation and Restoration”.
Apple guidlines link :
http://developer.apple.com/library/ios/#documentation/userexperience/conceptual/mobilehig/UEBestPractices/UEBestPractices.html
in the application's plist put
UIApplicationExitsOnSuspend = TRUE
and when the user hits the home button, the application will quit. No need for a button, no need for exit().
http://developer.apple.com/library/ios/#documentation/general/Reference/InfoPlistKeyReference/Articles/iPhoneOSKeys.html#//apple_ref/doc/uid/TP40009252-SW23
In one of my apps when returning from background I get a non consistent behavior:
Sometimes I get the default.png and sometimes I get a snapshot of the last screen which the app was in.
In both cases it takes the UI a good second or two to respond again.
Therefore I would rather show the default.png rather then "unresponsive UI"
Is there a way to make the app display the default.png always until the app becomes active again?
Currently the "stupid" way to do it I thought about is by displaying some Modal view with the default.png and removing it on return to foreground.
Few Clarification:
I am doing this to avoid unresponsive UI.
I am using the default.png as it looks like loading and gives a better experience then unresponsive UI
The app has to run in background.
(And to whoever asked - no it is not closed when I sometimes return and see the default.png and not the last UI state - App loading from the start has a very different path and I'm sure of that)
Thanks in advance.
This is not a correct behavior and you may experiencing a bug. Basically as long as your app is in the background, when you launch it, you should not see the default.png, unless you remove it from background (double click on home button and delete that app).
For future people interested in this you can use the fact the last view in the app is used to be displayed when the app loads back.
You can display a VC as your moving to background which will represent some loading - hence achieving the desired behavior.
I've already seen a few other apps using the same behavior in cases operations are ran when coming back into the app.
Most probably, you are taking too long (performing too many calculations) in methods such as applicationWillEnterForeground:, applicationDidBecomeActive:, etc. As a simple test, try commenting out the code in these methods and see if the problem occurs again.
Simply set in your Info.plist the property "Application doesn't run in background" to YES. The app will never go in background and when the home button is pressed it will be simply terminated. So you're back to the pre-iOS4 behavior.
Note that when you see now the default image at start-up it is simply because your app has been terminated while it was in background. This is normal especially for apps that take a lot of memory and then don't free it enough before going in the background (I think the threshold for the OS is about 18MB but I'm not sure)
First some background; for the tl;dr version skip to "the problem" below.
Background
This is really more of a user interface question than a technical one, but I think it fits better here than on the UI site anyway.
Since iOS (iPhone OS) 4.0 apps can run in the background, and actually always does so instead of quitting. Quitting an application requires pressing the home button, pressing it again, holding your finger on the application icon until it starts shaking, touching the "close" indicator, pressing the home button again. Not really intuitive.
The reason for this is of course that usually the user shouldn't care if the app is quit or just suspended, because it doesn't matter. But for some apps it does.
The problem
I have an app that logs location changes; think "RunKeeper" if that's familiar. The user starts the app, chooses to start recording (to a file), or just uses it to view distance, speed, etc. When the user is done (or wants to do something else), they hit the home button. The app disappears. Now one of several things happen:
The app quits, closing any ongoing recording (iPhoneOS 3.1.3 and below).
The app continues running in the background, using the GPS and draining the battery (iOS 4). This is appropriate if the user for example wanted to switch to the iPod app to change their soundtrack.
The app continues running in the background, using the GPS and draining the battery (iOS 4). This is completely inappropriate if the user was done and wanted to quit the app.
There is of course no way for the app to see the difference between cases three and four. A quick look around RunKeeper forums indicates that many users have no clue what is happening and get seriously confused by this.
Ideas
So what's the best way to solve this from a user interface point of view?
When the home button is pressed, go into background as is the default action. It's the user's problem to actually kill the app if they are done. It's the platforms fault that this is non-obvious and slightly tedious.
When the home button is pressed and a recording is in progress, continue in background. If we are not recording, quit the application.
Present a toggle widget somewhere in the application that allows the user to choose what happens when the home button is pressed. (This might run afoul of the HIG; I'm not sure)
...?
What do you think?
I though to the third option without reading at it ^^ (I don't think it would be against HIG)
So a "big" button when recording to change the "mode" ? Or a switch ;-) (Like "Continue Recording when in "background" ?")
And maybe asking the user about it when he start registering ? (with a default value available in prefs page ?)
And as you can change songs without quitting the app, maybe setting the default value as stopping record when the app is going to background.
But I haven't any other solution for you :-/
Can we use sleep function at applicationDidFinishLaunching to take more time to show Splash screen?.Is this Valid in HIG
You can use the sleep function in applicationDidFinishLaunching, but doing what you want to do is frowned on in the HIG
Avoid displaying an About window, a splash screen, or providing any other type of startup experience that prevents people from using your application immediately.
Yes. But it's really stupid. Also if you don't exit applicationDidFinishLaunching in a certain amount of time (say, 2-10 seconds) your app will be killed by the system.
I never really understand the view against a splash screen as most apps I run on iPhone and iPad have them. I see not issue with a company logo on display for 2 - 3 seconds rather than a Default.png that flashes on screen for a nano second leaving the user to wonder "er what was that?"
Nearly all applications have a splash screen either on mobile devices or desktop. I agree with not delaying the user experience but I also agree with a company logo.
If a user is put off by a 2-3 second delay then they really should go on a "learn to chill" course!