I created a web app and added to my iPhone Home Screen. When I switch to another app and back, iPhone automatically reload my web app. This breaks my app flow.
How do I prevent iPhone from reloading the app?
I have apple-mobile-web-app-capable meta tag enabled to hide Safari toolbar and I don't want to turn it off.
I just found this related question on SO: Stop native web app from reloading itself upon opening on iOS
As it seems it's a limitation of Safari, a proposed solution is to persist your web apps state using Javascript and HTML5 localStorage. When your web app is launched, check for the persisted state and load it if available.
You can read about using localStorage in Safari here: http://developer.apple.com/library/safari/#documentation/iPhone/Conceptual/SafariJSDatabaseGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40007256-CH1-SW1
Hope that helps you. At least it did for me, as I had the same problem as you. :-)
The short answer is that you can't control this. Sometimes iOS will keep a web app active in the background, at other times it will kill it. It's entirely related to how much memory is available on the device.
So, your best approach is to minimise the problems presented by this reload. Make sure your webapp updates the URL when you move from view to view, either by changing location.hash or using history.pushState(). This will allow you to reload whatever view the user was on before they switched apps. There are pagehide and pageshow events that allow you to execute code when the user moves away from your app - take that opportunity to store local state in localStorage and/or IndexedDB, then fetch that data again when the webapp is reopened.
I found a hack, tested on iOS 11.4.1/12.0
Open file uploading window and then switch back to the home screen.
The app still continues to work, in my case audio is playing and localStorage is updating
Proofs:
https://youtu.be/heehLUhGKYY
PS. note how song progress changes when we seek, it proves that app works in the background
Update: as this answer is receiving downvotes, I added this explanation.
Your problem might not be the actual reload, but the fact that Mobile Safari treats your user's cache and cookies differently when your web app is opened through the browser, than when it's 'installed' as a web app to the home screen. Although the solutions proposed here that use localStorage will work, they're a lot of work for client-side logic that can be avoided if your server is already responsible for persisting the session state of your user. The 30-second solution is to simply explicitly set the session cookie to have a longer lifetime.
This allows you to keep the state intact even between device reboots, so even though it doesn't technically stop the web app from being reloaded when launched from the home screen, it is an easy way to restore the state for the user without him/her noticing the reload - which in many cases I suspect is the real problem.
For a more elaborate discussion of this strategy and code examples, take a look at these questions and my answers there:
Maintain PHP Session in web app on iPhone
iPhone "Bookmark to Homescreen" removes cookies and session?
Related
In Android, When I minimize and maximize, the app maintain the same screen what I saw previously.
In iPhone, When I minimize and maximize, The app not maintaining the same screen. reload from home screen.
Full screen implementation web app for IOS is quite different when compared to that of android. If you are running your web app in full screen mode in IOS, minimize the app and maximize again, IOS considers it as fresh start so all the session cookies(cookies having session as timeout) will be cleared on minimize. so if you have cookies related to session, they all will be cleared. However you can try implementing html caching(using cache.manifest) to cache the pages. I've not personally implemented this but it might help. All the best
When displaying web content within an iPhone App, we can generally choose between displaying that content within a UIWebView, or popping open an instance of Safari.
I've generally found that for related content, the experience of displaying the content "in-app" by using a UIWebView is cleaner (maybe in a modal view or navigationcontroller), though it's a bit more work to do so.
For possibly unrelated content, I'll generally go for Safari.
Is there any established line of reasoning for picking one method over the other?
EDIT: Along with the technical, what's your reasoning with respect to user experience?
Last I read, Safari will execute JS much faster than an embedded UIWebView. The UIWebView, as it is used in user-generated apps, will not precompile the JS for improved speed.
It looks like this deficiency may go away iOS 5.
With respect to the UX, I think it depends on when the web content is displayed to the user in the user's workflow. Also, how frequently it is done & how distracting it can be? These things matter because you want to keep the user inside your app for the maximum amount of time (there is a good chance that the user won't come back). It is frustrating for the user if she has to leave your app to go to Safari multiple times & return back to your application within a short span of time. Moreover, if by any chance you have specified that your app be terminated if it is sent to the background, then you should not be launching Safari.
For example, the same factors hold when you create you Settings page. To quote from the HIG,
Applications then have two options for presenting preferences:
Display preferences inside the application. OR
Use a Settings bundle to
manage preferences from the Settings application.
Which option you choose depends on how you expect users to interact
with them. The Settings bundle is generally the preferred mechanism
for displaying preferences. However, games and other applications that
contain configuration options or other frequently accessed preferences
might want to present them inside the application instead.
HTH,
Akshay
How can I quit iPhone4 app? When I use exit(0) the app goes in the background. I want to quit the app instead of sending it to the background.
iPhone apps shouldn't have a quit button. The user quits by pressing the main button.
From Apple's docs: (http://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/MobileHIG.pdf)
People quit an iPhone application by opening a different application. In particular, note that people don’t tap an application close button or choose Quit from a menu. In iOS 4.0 and later, and on certain devices, the quitting application moves to a suspended state in the background. All iPhone applications should:
Be prepared to quit at any time. Therefore, save user data as soon as possible and as often as reasonable.
Save the current state when stopping, at the finest level of detail possible. For example, if your application
displays scrolling data, save the current scroll position.
iPhone applications should never quit programmatically because doing so looks like a crash to the user. There may be times, however, when external circumstances prevent your application from functioning as intended. The best way to handle this is to display an attractive screen that describes the problem and suggests how users can correct it. This helps users in two ways:
It 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
Set UIApplicationExitsOnSuspend in your application's plist. This will cause the app not to go into the background under iOS4 when the user switches to another app.
Then have your app send an openURL: message to Safari when your app wants to exit. When Safari launches, your app will be terminated (by honoring the UIApplicationExitsOnSuspend plist key).
If you point the Safari URL at a web page explaining why your app just stopped running, the user might be less likely to give it a 1-star rating.
Note that this procedure may or may not follow Apple's recommendations, but it does stay within legal public API use (e.g. even some of Apple's example apps launch Safari).
after that I put everything I had said I put this and it worked
- (Void) applicationDidEnterBackground: (UIApplication *) application
{
exit (0);
}
comes completely out of the application
in app delegate there is method call applicationDidEnterBackground
call the 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.