I am a learning developer that is always trying to learn new things. I am playing around with more advanced views and subviews, and am currently trying to use a view within a view. I know how to use modal views, but in this case I want both views to be present and running. So, picture the iPad running an unscaled iPhone app, that is basically the same idea of what I am trying to do. I can get the view to load up just fine, however, when I use buttons or anything inside the views that the user interacts with, the application crashes. It gives the following error message: EXC_BAD_ACCESS (Code=2, Address=0x17). What's weird is that there is no output from the debugger on this issue. I have tried to use a delegate (the way you do in a modal view) and it doesn't change anything. Any help is much appreciated :)
You can, of course, put many views inside a view.
EXC_BAD_ACCESS means you, or some object, is trying to access an object which has been deallocated.
I can mostly promise you that the issue is not because you are putting a view in a view, that statement and actually doing that is fine.
How you go about doing it, and how you handle everything is a different story.
You didn't provide any code or context as to where and how you are adding a view to a view, which is probably where the issue is arising. Enabling NSZombie as suggested by xlc0212 is a great idea to help diagnose the problem.
Hope this helps
Related
I found that a previously normally working iPad storyboard started working weirdly upon introducing auto-layout. In particular it seems not to properly show different ViewControllers when clicking different annotations but instead it always shows the first one whatever more annotations are clicked. When I disable auto-layout everything works fine again. Apple responded to my request hinting to a problem in the handling of segues:
#Apple: 'When running a segue from A -> B, it is not our intention that that segue over and over again will result in a chain like A -> B -> C -> D because the original transition is A -> B. However it would make sense if you had a self-referencing segue and you called performSegueWithIdentifier over and over again because you in that case are having the same instance just added to itself. I think you were just getting lucky before and that turning auto layout on was just enough to point that out.'
Yet all the hits I found on the web like in:
How to call a segue from a disclosure button on a map pin?
and
MKMapView show DetailView - How to make a segue
are quite the same as the the code I used and Apple says it is wrong; notwithstanding the iPhone version keeps on working and the problem just arises on the iPad.
Any hint before they crank up another funny suggestion?
Unfortunately the problem, the way it went the way it returned. Eschewing the possibility I ran mad, the same code including the one on the iTunes Store now, started presenting the problem again. I also tested it on another iPad and it presents the same problem leaving me totally in the dark. All the thing seems crazy.
After a number of tests I found that a normal working iPad storyboard starts working weirdly upon introducing auto-layout. In particular it seems not to properly pop-up dismissed views by always recycling the same view controller and to also badly handle the queue of instantiated view controllers. When I disable auto-layout everything works fine again. Does anyone know if this bug is known to Apple or there is a fix?
Not been able to complement the question with new information, I posted a new one at:
Triggering segues from annotations
I have a Main View which call a settings panel in another view with the page curl transition. All seems fine, but when I close the settings view it doesn't trigger the "viewWillAppear" method of my Main View causing me a lot of troubles because it doesn't get updated with the settings.
There is an answer which seems fine for me, but I don't know how to implement it. There is another easy way or someone who can explain to me how to apply that answer?
Thanks in advance.
Instead of reacting to views, you should probably react to settings changes. What I mean by that is that it would be a more solid design to use Key-Value Observing (KVO) so that your main view can be notified of changes to the objects that represent your settings.
Alternatively, if you can't or don't want to observe a specific object, you can use NSNotificationCenter and have your settings view fire a notification when the new settings are applied and your other view can register to listen to those notifications.
Here is a simple example of that.
I hope this helps solve your problem.
I am developing an app for the iPad, using split-view and storyboards. I did this once before quite a while ago but didn't write down how to do it. I've googled and SO'd all morning and found nothing specifically targeting my question.
I know there is a way to add multiple detail views by dragging objects to the storyboard canvas, and somehow (that's the question) setting the new object as either master or detail...
Anybody know how to do that?
I give up... decided to go to with a tab bar controller; much simpler. And the fact that it got voted down indicates to me nobody knows the answer.
Thanks anyway to all who looked at it.
In Apple's developer guide, they state: "A split view controller must always be the root of any interface you create" (see here). I was curious if anyone knew why they decided that. I have a tab navigator-based application and it makes sense for the content in one of the tabs to be presented in a split view. Why would Apple be opposed to that kind of design? Thanks in advance for your answers.
-Max
PS I'm not looking for ways to put a split view controller in a tab navigator controller (that much I can figure out, even if the code does look sloppy). I'm more curious if anyone has any idea why Apple frowns on it.
I don't think that this is necessarily a user experience decision as much as it is a technical restriction. UIKit makes a number of assumptions about how UIViewControllers will be used. Including the idea that only a single UIViewController instance has its view visible in given window at any given time. Now since Apple has access to the implementation they have been able to make exceptions for their own "container view controller" classes (UINavigationController, UITabBarController, and UISplitViewController). We can't tell exactly how much of a special case these controllers are or what they needed to do to support displaying nested sub view controllers correctly but one consequence seems to be that both UITabBarController and UISplitViewController are not intended to be used except as the root view controller of a window. Attempting to nest them within other container view controllers may cause unexpected or unreliable behavior.
I tried to cover these restrictions on the use of view controllers and some possible alternatives here: http://blog.carbonfive.com/2011/03/09/abusing-uiviewcontrollers/ Hopefully that's of some use to you but I'm afraid the only reliable way to get the UI you seem to be looking for it to implement your own split view style display within the view of a single UIViewController.
Please ignore my answer:
Because you can't resize UISplitViewController's subviews with touches?
Apple has always placed high value on consistent use of user interface elements. Having all applications work in the same way helps the user to immediately understand how an app works even if they've never seen it before. Establishing a conceptual hierarchy of view controller containers makes a lot of sense when you're trying to help the user predict behavior.