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.
Related
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
On the MVC paradigm, a view can only communicate with a controller, and via a blind communication (target-action or delegate/dataSource). I understand that, but is it a violation of MVC if a view communicates with another view, using a delegate?
Almost always. The delegate of the view should never be another view. It should be a controller. The controller is the appropriate place to drive changes in the other view.
A view should almost never say something that another view would care about. A view should say to its delegate things like "I was touched." Why would another view care? It's up to the controller to say "ah, a touch here means that I should move the active focus. I should tell the current active view to let go of focus" (as an example). I view is not responsible for determining what events mean in the broader application, only what events happened, and so are very unlikely to generate messages of interest to other views.
My opinion on this is to use the observer design pattern and simply use notifications (NSNotification)
I am a novice myself. But I would think that it's not. A jsp page when called could just redirect you to anothr jsp page. I have seen that happen sometime. So I guess it is in a way, a view calling another view.
When I switch tabs in my tab bar application, one of my views needs to update because the user may have changed a preference that affects it. It is a UIViewController's view, but when the views switch, the viewDidLoad/Appear methods aren't called. Can this be solved using an NSNotification or any other way? Please give example code, especially for NSNotifications, as I am new to them.
You might want to peek at UITabBarControllerDelegate and tabBarController:didSelectViewController:. There you can determine how to handle the view change and whether you need to update the view based on the possible preference change.
tabBarController:didSelectViewController: you can implement this method in the appdelegate.
you will get the sxact root view controller at which yopu clicked . then you can update that view .
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.
I would like to create an utility application that has a navigation based flipside, or "info", view. What would the most efficient way to accomplish this be? I think that i 'simply' need to make a root view controller for the flipside view...but i really only understand that conceptually...not so much how to go about it or, at least, i am not confident that i know how to go about it.
I apologize for the slightly "make my app" nature of this question i have books and books and books...but it shakes out so much differently when i want to make my own project.
You can use a view controller for the flipside view, or you could create / load a view in your app delegate. In the latter case, you can set up the delegate to respond to the info button press, and then set up a transition to the new view which will have a button (which the app delegate also responds to) that transitions back to the previous view.
There is a basic tutorial I found for this here:
http://www.iphonedevsdk.com/forum/iphone-sdk-development/12222-how-do-i-create-uiview-flip-animation.html#post104474
It should be able to at least get you started.