I'm scratching my head for days already trying to understand what I observe. I'm doing iOS development for many ears and I believe I have never seen such effect:
Basically for all ViewControllers I have in the app (defined in a Storyboard), when the view appears, the initial storyboard defined content/layout is displayed for a second and then the proper content appears.
I'm doing all UI element setup is viewDidLoad() so I expect when content appears it must be already properly configured.
No idea what it can be. Changes in Swift/Xcode? Some hidden project configuration?
sounds to me like you are displaying your vc too soon,
it might be that your initial setup is too costly, or that you are calling a service to get that initial data and until the response arrives your vc is still 'flickering' as you put it.
this is usually solved by presenting a loader and making the actual transition only once you are finished with the initialization / data getting phase.
some initializations are more costly than others.
Related
Greeting,
I am struggling with a project, because the segue between a UITableViewController (which lives in a navigation controller) and a custom UIViewController is not animating.
The checkbox in Storyboard clearly states "animates", the kind is "Show (e.g. Push)". Yet, when the segue is performed, there is no animation. After some testing, I have found that manually calling UINavigationController pushViewController(destination, animated: true) does not animate either.
The destination View Controller contains a couple views that do some custom drawing.
What could I be doing wrong ?
Cheers,
Alexandre.
#AlexandreCassange and I managed to find the problem in chat, but for anyone who is finding a similar problem here was the solution:
The problem was that while the viewController was being loaded (before viewDidAppear() is called) some code for laying out a CALayer was taking a too long and effectively blocked the animation.
The process to debug this problem is as such:
Check for any code that runs before viewDidAppear() that may take a long time and comment it out, then check if the animation is working. Do this one block of code at a time so you can find exactly where the offending code is. This is how Alexandre found it himself.
Alternatively, use Instruments (time profiler) to check for any long running code that occurs during the initialisation of the destination viewController.
Sometimes though this could happen because the viewControllers initialisation is complex, and while each individual code block runs relatively quickly, together the process is too slow. In this case use the time profiler to optimise your initialisation. I recommend watching the WWDC video Profiling In-Depth
I must be missing something really basic here, but I don't even know how to simply describe the problem. I designed my view controller layout in my storyboard, just a bunch of image views, labels, constraints, etc. All static - the only change the code makes is to add round edges to the buttons (UIViews), but I've also tried without that code with no difference made.
Once my segue is followed to the second view controller, it displays like this on the iPhone:
I've gotten it to display properly in 2 cases (most of the time):
Waiting. Anywhere between 30sec to 10min. Very unpredictable
Pressing the home button then resuming the app. Sometimes the text still won't show up when I do this.
Either way, this is what it's supposed to look like:
It doesn't lag or anything as the UI is completely usable even when it's not displaying properly. The images are not very large (biggest is around 300x600) so I doubt that is an issue. Image size also wouldn't account for why the text isn't displaying either. Do UIImageViews load their images asynchrounously?
I thought it might have been that the views needed refreshing because of the exit/resume behaviour. I tried [eachView setNeedsDisplay] with no success.
Any ideas?
-- UPDATE 1 --
Here is an image of my storyboard. As I said, everything is highly static. I have no idea why it's not displaying.
-- Update 2 --
I tried adding my image files to a bundle as suggested:
Then tried to reference them pragrammatically in the viewDidLoad method:
// Interface
#property (weak, nonatomic) IBOutlet UIImageView *backgroundImage;
// viewDidLoad
self.backgroundImage.image = [UIImage imageNamed:#"background.png"];
No difference unfortunately.
I have had this issue using an xcassets file. It tends to work just fine if I just add them to the bundle directly in a group. Check out this thread for some more details.
Impossible to load an image in xcassets on bundle
Here's what the problem was for those having the same issue. The previous view controller to the problem screen was a login screen. After receiving credentials, the controller would asynchronously hit the server to validate them. The response from the server was then handled in a callback function called by the networking thread. This meant that the segue was being invoked off of the main thread. Oddly enough, the segue still performed fine I guess it just took a while for the main thread to realize what was happening.
TLDR: Make sure to performSegue on the main thread.
I have a simple app that consists of a sidebar menu (I'm using SWRevealViewController) which contains a table view, each cell of which has a segue pointing to a UIWebViewController. So the user can pull open the sidebar and switch between various configured mobile sites (among other things).
I've got it working fine, but I've noticed that, as I switch back and forth between the sidebar tabs, the number of controllers that get pinged during a memory warning keeps growing. It appears that a new UIWebVewController is created each time I switch tabs, which is fine, except that the framework code appears to be keeping a list of each controller that is created and is never letting go, causing the memory to keep climbing. I'm sure there's a way that I can clean up that list, but I haven't found it yet…
So, my questions are
What is it that is holding on to references to each UIViewController that is created, and where can I find/access that?
How do I clean that up?
What framework code/class is in charge of calling didReceiveMemoryWarning:, and where does that guy get the list of controllers that need to receive the warning?
In searching around, I came across this StackOverflow question, which hints that popViewControllerAnimated: might be how I can cleanup unneeded controllers, but I'm not sure which object I should be calling that on, since I don't know the answer to #1 or #3 above...
It turns out, in my case, the thing holding a reference to my controllers (question #1) was a scheduled NSTimer that the controller was creating with itself as the target. To clean it up (question #2), I needed to invalidate the timer prior to leaving the controller (in my case, in the viewWillDisappear: method) via [myTimer invalidate].
I still haven't found the answer to question #3, and I'm still curious to know how Apple keeps track of which controllers are still alive and, therefore, need the memory warning, but question #3 isn't as important to me, anymore, now that my memory leak is gone. :)
Check if SWRevealViewController is holding on to the View Controller it is pushing on the stack. Usually you would create a dictionary of UINavigationControllers each one for your ViewController and then use the dictionary to retrieve the UINavigationControllers each time you need it.
Since I converted an old app to iOS 6 I've started getting the following message in my console.
WARNING: Slow defaults access for key ClientState took 0.023656 seconds, tolerance is 0.020000
Other than updating my code from iOS 5 to iOS 6, I also switched over to auto-layout. I've run Instruments/Time Profiler and the rootViewController in my appDelegate is the problem. Everytime I switch view controllers it sucks the vast major of the time, (regardless of whether I have to instantiate the view controller or re-using one which already exists).
window.rootViewController = myViewController;
I know what the method does superficially, but I'm not sure what happens under the covers... what would cause it to be slow now and what can I do to speed it up?
EDIT: I've tried taking my storyboard off auto-layout and the problem vanishes (of course my UI layout is in shambles). So the obvious conclusion is, it's something about auto-layout. I've probably just under 70 views all combined on the screen and the various constraints needed to lay them out. I have a hard time believing auto-layout is that much slower (from ~80ms with auto-layout turned off to ~1370ms with auto- layout turned on).
Having 70 views on-screen sounds like a lot! My proposal is to make it simpler in some way:
Do you REALLY need all 70 views at the same time?
Check if all views need autolayout, remove it where-ever possible
Can some views be replaced by graphics? I've used views e.g. for shadows, might have been images
Can you split storyBoard into several smaller ones e.g. one for login, details, edit mode etc. Part of the slowness might come from system having to deal with (too) big storyBoards.
Consider creating a new project with 2 view controllers and test the switching speed. Every iOS app has a window, a root view controller and a view controller. The problem isn't likely to be as narrow and clear-cut as you may be hoping. What does each view controller load? Did you inspect the underlying code? Does app delegate do anything on initialization or change of root view controller?
I have an Application, which is a SplitViewController that has a master view on the left and the detail view on the right. One of the views (Branch Finder) is a Map view that loads a series of Annotations to the Map.
If I let the annotations load before switching to any other view (loading the annotations take takes all of 1 second) then everything is fine. However, if the user quickly switches off the Branch Finder view, whilst the annotations are being loaded, then the App will crash with the following notice:
[BranchFinder_iPad respondsToSelector:]: message sent to deallocated instance 0x807d230
Now, my thoughts are that the deallocated instance would refer to the Array (declared in the header of the view) that contains all the annotations being released and set to nil when the user leaves the BranchFinder_iPad view. This is the array that is being passed to the addAnnotations method.
[self.mapView addAnnotations:branchSites];
Has anyone else encountered an issue where leaving a view, mid-way in the add allocations and a crash occurs if the user moves to another view.
Just to clarify:
If I wait for the annotations to load, switching to any other view causes no problem.
I did have a custom annotation view, but I stripped that out of my code (to eliminate it from the mix). Doing this has not changed anything.
I have looked elsewhere for help on this issue, but a lot of the view tutorials regarding map views are single view only, so this issue hasn't arisen.
I have found a vaguely similar issue # the following: mapkit addAnnotations crashes
And finally, I have just made the jump to x-code 4. I think some of my problems are just because I'm relearning some of the things I should know.
Regards,
Nathan A
PS: I wanted to attach an image to this, but am having trouble. I don't have the reputation points to do it natively, and my workplace doesn't allow me access to any image hosting portals. I will endeavour to add an image later today.
Hey anyone who reads this.
I basically performed a rookie mistake here - for the MKMapView in my application, I had to set the delegate to nil as part of the deallocation routine within my view. THe apple documentation makes mention of this in the below document:
http://developer.apple.com/library/ios/#documentation/MapKit/Reference/MKMapViewDelegate_Protocol/MKMapViewDelegate/MKMapViewDelegate.html
For the relevant section:
Before releasing an MKMapView object for which you have set a delegate, remember to set that object’s delegate property to nil. One place you can do this is in the dealloc method where you dispose of the map view.
Not having this was only causing an issue if I switched to another view AND if the MKMapView was still being referenced in executing code, such as the addAnnotations routine.