I am experiencing an issue with activity indicator freezing when I move application to background and then bring it back to foreground. The application can be loading some data over the network when it is moved to background. Hence I display an activity indicator to the user. I have added the code to make sure that the task finishes in the background.
When the application is brought to foreground immediately and the data is not completely loaded, the spinner stays on the screen but it stops spinning. When the data is completely loaded, the spinner disappears.
Any idea why the activity indicator freezes and what could be a possible solution to it.
Thanks.
There's almost no reason for an app in the background to be updating its UI.
For one, who is there to see it? Another reason that the indicator freezes is that going to the background stops UI updates and animations that needlessly drain the device's battery and slow down the foreground app.
From Apple's excellent iPhone Application Programming Guide, the app delegate method -applicationWillEnterForeground: is called whenever the application comes into foreground.
You can override this method and add logic to wake up widgets here. Or you subscribe your class (view controller, etc.) to listen for the UIApplicationWillEnterForegroundNotification notification. If you listen for this notification, you could call a selector that updates the state of the UI, given whatever the application is doing at the time.
Related
In Xcode there is a place to set actions when the interface controller is dismissed in:
override func didDeactivate() {
// This method is called when watch view controller is no longer visible
super.didDeactivate()
}
However, my watchOS app needs to perform an action when the app quits completely i.e. the home screen is visible. Not when the watch is simply lowered and the screen is dimmed because the app is still running as a workout app and is performing actions.
Is there a way to do this?
In ExtensionDelegate, you'll find the method applicationWillResignActive.
Sent when the application is about to move from active to inactive
state. This can occur for certain types of temporary interruptions
(such as an incoming phone call or SMS message) or when the user quits
the application and it begins the transition to the background state.
Use this method to pause ongoing tasks, disable timers, etc.
You can use this method to do what you need.
I am created an app, after login have to download new database from web and when you logged
in a custom UIAlertView appears if user press yes the download phase will be started. When
the UIAlertView disappear and the UIAlertView's delegate called i start on the background
thread a download. Now i am trying to modify a label which display the current percent and
adding to the view a custom activity indicator. After that when the activity indicator
changing the pictures or the label.text get a new string the screen start flickering, but
only at the very first start (after install), if i force close the app and starting it
again the flicker thing is not appearing, on previous version of iOS the app not flicker. I
am calling from main thread when i modify the label. I tried remove label and activity
indicator and after the alert view disappearing the app not flicker. I tried to remove
alert view and start instantly the download and after that only the status bar started to
flicker.
So my question: what should i do to solve the flicker bug?
I believe that the reason is because you are updating the UI on a background thread. You must not do this, you must use the main thread for this:
To run code on the main thread from the background thread, you can use GCD:
dispatch_async(dispatch_get_main_queue(), ^{
//your UI code here
});
If this doesn't fix the error, it's probably a bug with your device.
After an iPhone app is put into background, then the user clicks on it again and it comes back to foreground, THEN
Question - How to tell what is the current UIView/UIController after an iPhone app in brought back to foreground?
I know that the application delegate's applicationDidBecomeActive method can be used to trap the return to foreground. I also know that each controller could subscribe via notification centre to UIApplicationDidBecomeActiveNotification.
But if what I want to do is reload the UI data in the UIView/UIController that is displayed, and not carry out this same operation through all other view/controllers, how can I tell which is the one to do the reloadData on?
If your using a nav controller, you can use this:
self.navigationController.visibleViewController
I would like to know how i can detect when an application is about to be terminated. I mean really terminated, not just going into background mode. I have used this event, and it doesn't fire :
applicationWillTerminate
What i would really like to achieve is get some kind of event or notification when the user taps Home twice and presses the red baloon on the app. I don't care about the application going into background mode, there are a couple of events that handle this properly and they all work fine.
I need this so that i can "inform" my server to stop sending push notifications to APNS for apps that are terminated and aren't running in the background.
If you know of an easier way to achieve this, i'd be glad to hear :)
Thank you
Register your object (view controller, etc.) to listen for the UIApplicationWillTerminateNotification notification, and/or override the application delegate's -applicationWillTerminate: method and put your code there.
Angel, what you're asking for cannot be done. The app will be terminated with SIGKILL. Unstoppable, not catchable, no notifications. There is no difference between a system-initiated termination or one requested by the user.
You'll get applicationWillTerminate only if your app doesn't support background processing.
From UIApplicationDelegate docs on the matter:
For applications that support
background execution, this method is
generally not called when the user
quits the application because the
application simply moves to the
background in that case. However, this
method may be called in situations
where the application is running in
the background (not suspended) and the
system needs to terminate it for some
reason.
Seems to me that unless your background process is actively doing something in the background (not being suspended) it the applicationWillTerminate method will never get called.
I guess it depends what you definition of "being in the background" is.
IIRC it goes like this:
On start:
didFinishLaunchingWithOptions
applicationDidBecomeActive
Pressing home:
applicationWillResignActive
applicationDidEnterBackground
Coming back from home screen:
applicationWillEnterForeground
applicationDidBecomeActive
applicationWillTerminate is called when your application exits due to a call or the OS kills it for some reason.
I've made a custom activity indicator (actually just an imageView)
When user clicks something and I expect it will take a bit long to process(alloc a UIViewController and push on to navigation stack),
I alloc the indicator and add it as subview of current view just before the lengthy process starts.
Strange thing is, indicator doesn't show up until the push (left-right) animation starts.
Is it because the lengthy job takes the system, and ui drawing for activity indicator is delayed?
Am I doing something wrong here?
Thank you
Edit
Looks like I can do the "push" in background.. i'm trying it now
IPhone SDK - Leaking Memory with performSelectorInBackground
Is your job synchrone or asynchrone ?
If it's the first case, then it can be the problem.
Check all the method like :
[ self performSelector:<#(SEL)aSelector#> ];
You can thread this to avoid your [potential] problem.
Good luck.
You should process your lengthy tasks in the background. The UI won't update if you block the main thread.
So you have to refactor your app, the alloc and push of the viewController should happen within the blink of an eye, because you can't do this in the background.
But you can do the processing (downloading data I guess) in the background.
There is plenty information available about background processing. The way to go varies heavily on what you want to do exactly.