Performance issue of dismissViewController with Core Data - ios

I have two View Controllers, the main one and popup one. Each of them contains a UITableView and a fetchedResultController to provide data.
the popup is setup inside storyboard, and I add BarButtonItem to dismiss the popup. Dismiss code is very simple
[self.presentingViewController dismissViewControllerAnimated:YES completion:nil]
the issue is It took couple seconds for the popup to dismiss, the app freeze once I click the "dismiss" button.
If I commented the setup of fetchedResultController in the Popup view controller, the dismiss happens immediately. So I assume the problem is with core data. but no idea what it could be.
I have also tried run Instruments to see the problem, no other codes of mine is executed except the above dismiss codes. (although I'm not experienced with Instruments well)
Any help/hint would be appreciated.

OK, It turns out that the performance issue has nothing to do with core data and tableview. the guilty goes to a UISwith, which I apply a Scale to it to make it smaller than usual switch. After I remove the scale code, it behaves normal. so Now the problem is I need to figure out why the scale make it so slow, but it's another question.

Related

UINavigationController Interactive Pop Gesture only works first time

I have been working on an app for some time and just realized the swiping back in the detail view only returns me to the master view the first time. It also isn't smooth, even when it works on the first time. Instead of smoothly going to the master view, it jumps all at once, even when I swipe slowly. It used to work correctly, but I haven't been testing for this specifically, so I don't know when it stopped working and what I changed to cause this.
A little about how my app is setup...
I have a split view controller that is connected to my MasterTableViewController and DetailViewController.
Both of those are have TableViews and are embedded in Navigation Controllers.
I have set it up so that the app originally loads to the MasterTableViewController instead of going immediately to the DetailViewController, but even when I take this out, the interactive pop gesture doesn't work.
I don't believe I've messed with any of the back button controls. I have looked through my code and storyboard and can't find anywhere that I have. This is part of what is most confusing because these questions (1, 2, and 3) all seem to have problems stemming from changing the back button or can be fixed by entering the following line of code:
self.navigationController.interactivePopGestureRecognizer.delegate = nil
Adding that to my code seems to have no impact on how it behaves.
Here is a picture of how it is setup for reference:
I can usually figure out these things on my own, but this problem baffles me because it works the first time, but not any others. As far as I can tell, nothing changes between the first time and the others. I don't know if anybody else has had the same issue, but any help on why this might be happening would be greatly appreciated. I can provide code or answers to questions on how I am doing certain things if needed. I haven't put any in because there are so many different things controlling this piece that I don't know where to start.
When are you calling self.navigationController.interactivePopGestureRecognizer.delegate = nil?
Doing this will definitely disable interactive pop. It sounds like you may be calling this after a certain UIViewController appears.
What other modifications to UINavigationController are you making? Are you using appearance delegate?
Are you subclassing? If so, are you calling super in all of your method overrides?
Also check your overrides of viewWillAppear in child ViewControllers. This method gets called during an interactive pop. If you are doing a lot of computation (or synchronous calls) on the main thread within this method, it could cause frame drop, hence the choppy animation.
Hope this helps
From Alex Chase's answer : Also check your overrides of viewWillAppear in child ViewControllers. This method gets called during an interactive pop.
added it to viewWillAppear and it worked:
override func viewWillAppear(_ animated: Bool) {
super.viewWillAppear(animated)
navigationController?.interactivePopGestureRecognizer?.delegate = self
}

Why popover segue taking lot of time for the First time?

I've an application where one HomeViewController triggers the popover segue so that destinationView controller may appear as a popover View controller. Everything is fine and destinationView Controllers is opening as popover View controller.
But the problem is when I First touch the button, its taking lot of time to open destinationViewController. and later after that second touch onwards on its opening faster just on touch. why so ?
The answer mostly lies in your code itself.
My guess is you are making some network call or data processing on main thread making UI responsiveness hit. You are probably caching the massaged data and using it second tap onwards.
You can fix this by putting break point and understanding the implementation line by line.

Sliding my view controller back in iOS 7 is very slow for only one view controller

Has anyone encountered a similar issue? I have one view controller that it lags greatly on the sliding when I pull my finger across the screen to go back, but only on about the first half of the slide. The rest goes smoothly. If so, how does this get counteracted? I honestly can't seem to find anything that might cause it. Even removing all my gesture recognizers does nothing to help it. But other view controllers slide perfectly in my app.
It's hard to say without you being more specific, but it sounds like you might be performing some intensive tasks in the viewWillAppear: function of the view controller you're returning to. If the main thread is blocked here, even for a short amount of time, it could result in this behavior.

How to handle jumping back to previous screens in iOS

I am just looking for a sanity check here.
I have a screen that the user passes through on the way into the main application. That screen can be navigated back to from almost anywhere in the system.
As it stands I am just presenting ViewControllers without using a NavController to manage them (it does not seem applicable for most of my app, since screens are not necessarily sequential or related to one another).
My question is, if I have presented VC1, then navigate to other screens, and finally want to present VC1 again, I am doing something like:
[self presentViewController:[self.storyboard instantiateViewControllerWithIdentifier:#"VC1"] animated:YES completion:nil];
Is this bad form? Am I leaking memory by creating a bunch of VC1 instances or is there some magic that uses the previously created one?
If it is bad form, how do I get back to the original VC1 to reuse it?
Thanks for any input.
I think you pegged it: It's not a great idea to have multiple instances of the same view controller in memory at the same time. Every time you instantiate a new view controller and present it modally, you'll consume more memory.
The most elegant solution is the iOS 6 unwind segue. But most of us would be unwilling to give up on iOS 5 support quite yet.
If you need to support iOS 5, you could contemplate using navigation controller, but hide the navigation bar if you don't like it in your user interface. Then replace modal segues with push segues and now you can do popToRootViewController whenever you want to return to the main view controller.

How to update behind presentModalViewController when using UIModalTransitionStylePartialCurl?

How do I make a curled-up view update live as the user interacts with view being presented with presentModalViewController: under it?
The behaviour I want:
User taps a view settings button.
User taps controls in the view settings screen. Rather than dismissing view settings, the view automatically updates in the background.
User taps something to dismiss view settings.
Imagine if in Maps tapping Map, Satellite, Hybrid didn't uncurl automatically but just updated the display.
I'm able to get notification that something's changed from the settings controller back to the main view controller. The main view controller can update and signal that it should redraw parts of itself, but actually updating the screen is intermittent. It will work 5 times in a row, then not work a couple times, then work another 5 times in a row. Dismissing the modal view always catches up the view underneath, however, so I assume the rendered image of my view is sometimes being cached or not being redrawn despite my request. But I can't think of a way to verify this.
This happens on both the device and the simulator.
While there might be multiple root causes of this behavior, here's a common issue I've seen that causes 'delayed' or 'intermittent' updates to UIKit views.
If the statements that update your presenting view (or the presented view) are running in a dispatch queue other than the main queue, UIKit may produce inconsistent results and timing in the actual UI update. You can usually tell by putting a breakpoint on the statements that update the UI and examining the name of the 'queue' displayed in Xcode's left-side debugger view. It should be 'com.apple.main-thread'. If it's not, that could be your issue. This can happen in quite a few delegate methods such as the network APIs.
Try wrapping your UI updates in:
dispatch_async(dispatch_get_main_queue(), ^() { ... }); and see if that helps! You should only do this when needed and take care to use block-safe techniques as always.
I tested this in a brand new Universal app for iOS 7.0.3 using the iPad simulator with a view controller presented using the partial curl transition. I was able to replicate the original issue, including the intermittent update and the 'snap' update when dismissing the presented view by using a background queue in the code I provided above. Once I switched to the main queue, everything worked A-OK.
Let me know if this helps or if there was some other issue :)

Resources