I have a UIView that gets created and added as a subview dynamically, not in interface builder. Problem is the subview disappears eventually and all that is left on the screen is the objects that are defined in the xib that is being loaded.
It seems to occur once the retainCount of the subview drops from 3 to 2. I'm fairly new to iPhone development and don't fully understand the memory management complexities so I may be missing something obvious. What could be my problem?
This is just a wild guess, but a low memory warning might be causing the view to get purged from memory, and when it's reloaded the view is no longer there because there's nothing in viewDidLoad to redisplay it if this happens. You may need to store the view in an ivar, then have viewDidLoad add it again if it exists.
You could test this theory by running in the simulator, then causing it to generate a low memory warning to see if that makes the view disappear. I don't think this should happen if the view is currently displayed though so make sure some other view is displayed at the time.
Related
EDIT**: Although someone has decided they would like to down vote without a reason I'm going to leave this up. I noticed that in viewDidLoad of my view controller container, the content view I setup was the same size as in IB. When I later tried to load other views with my view container controller, the content view had changed it's bounds. Hope this helps anyone else that has a similar issue. The excepted answer worked. Since this is a build for iOS 6 a simple check of OS version made this an easy fix.
I have a strange issue that seems to be iOS7 related. This is an iOS6 targeted app. I have followed apples own docs about creating custom container views here. The problem I'm seeing in iOS7 is the first view I load is within the proper bounds of the content view i have defined, the other two are filling the bounds of the entire screen so it hides under the navigation bar with my segmented control. I defined the view I'm loading in a separate view controller in storyboards. Is there some sort of constraint that is working against me?
I should add that I have noticed the content view I defined in my container controller is actually changing it's size after the initial view is loaded. I'm at a loss of how to stop iOS7 from changing that UIViews frame size when it really shouldn't be changing.
Here are some screenshots. Code is pretty much the same as in the apple docs, have tried a few other ideas, defining bounds etc. but I think it has something to do with IB since the content view is changing its bounds. It appears to only be doing so in iOS7.
There is actually a proper way to fix this,
Set edgesForExtendedLayout to UIRectEdgeNone for the view under the tab bar.
Of course, I might've just looked at the pictures and assumed this was your problem...sorry if its completely unrelated..
That's a known 'issue' in iOS 7. Since you can now have a blurred look through the UINavigationBars, UITabBars, ... This also causes issues in native apps (e.g. the Photos App) or APIs.
I have some view inside wich there are an UIWebView. For performance reasons, I do not allocate the Web view on the fly, but it is set into IB and linked with a class outlet. When I do not need it, I set its hidden property to YES.
But, after having profiled my application because of performance problems, I noticed that when resizing the views containing those UIWebViews, they take a huge amount of time in :
[WebFrame(WebInternal) _drawRect:contentsOnly:]
So to prevent this, I also set their scalesPageToFit to NO, but this doesn't change anything.
I've tested deleting them from the project, and yes, the resize of the view is really much faster.
So how can I prevent the UIWebViews that are hidden to eat my process time in useless drawing work ?
Instead of hiding the UIWebView try removing it from the container view using removeFromSuperview. When you want to make it visible again add it back as a subview. This should keep the instance of the UIWebView in memory and prevent it from redrawing when it is not visible.
As title says, I'm wondering if stacking subviews can slow down an iPhone application.
For example, I have a UIViewController, which has a view occupying the whole screen. When the user presses a button, I create a second view controller and add its view as a subview of the original VC, making the second view completely hide the first one.
Does the application have some kind of automatic optimization which would be something like "ok, I know what to draw for every pixel of the screen, I stop seeking for subviews" ?
If not, I don't think stacking 2 full-screen views can really slow down the app, but could 3, 4 or more views be problematic if they include many subviews themselves (labels, images)?
Read the View Controller Guide sections on Modal View Controllers and memory management. Prefer to use modal Views instead of subviews when you want to present a new screen temporarily and a UINavigationController for "drill-down" views.
You can always set UIView#hidden = YES on the views not seen. That should prevent redraws.
This is largely dependent of what the subviews contain and what is the total memory load of the app. Memory is very crucial for devices like iPhone and you should never keep the things which you don't require. When you are adding many subviews without releasing any, your memory requirement obviously will increase. This may slow down the app, even may crash the app. Stacking of two may not be a problem, but stacking many is not a very good design.
So the summary is you should always check the memory load of the app through instrument and always properly respond to memory warnings.
I'm looking for advice about a nib that's very slow to load. It's big and complex, with lots of subviews and doodads. When I fire my UINavController to push it, it's noticeably laggy (maybe almost a second) on my 3G. It sits there with the table cell selected and nothing else happening for long enough to make you wonder if it's broken.
I wonder about pre-loading it in another thread while the user is on the previous view. I could probably fire the selector in the background with a delay in the previous view's viewDidAppear, and then keep it in a property until push time comes.
Thoughts?
Can you split the subviews and doodads into their own, smaller nibs? Then you don't have to load everything at the same time, just what you need for when you need it.
I am working on a project, which is so full of the same, it would be unusable in NIB form. I choose to start creating my own sub-views in code, and then in performance concern areas, did my own drawing (like you would in a complex/custom UITableViewCell implementation).
It isn't really that hard to create some or all of your elements in code, or roll areas of them up to something that can be drawn by hand.
Just a thought.
I would be careful about assuming that it is the loading of the NIB file which is slowing you down. Run Instruments and / or Shark against your application, focusing on sampling what happens when you tap on the table to bring up your new view. You might be surprised at where the bottleneck is. In particular, it might not be loading the NIB itself, but something in the initialization methods of one or more of the subviews.
I have an animation in a EAGLView which is itself in a UITableViewCell. How can I pause the animation in the EAGLView when the view is not visible?
Normally, I would simply use the responsible UIViewController and listen to viewDidDisappear. But how do I do that if the EAGLView is in a table?
I don't think that this is a task to implement at all.
Once your cell is scrolled out of view, it will be deallocated instantly.
So if you have a Custom Cell, the animation will have to be stopped in -dealloc anyhow.
EDIT 1:
Actually, I was not really precise: I wrote "instantly", but of course, this depends on the OS and Apple and may be changed in future versions. Actually, the cell is deallocated whenever the OS garbage collector wants. Currently, Apple deallocates one cell whenever it needs a new one. Usually, scrolling a table implies that one row disappears and a new one appears, so that's why deallocation seems to happen instantly.
If the view, that is switched on, contains a table view, than you will see the same instant deallocation.