I have multiple view controllers for my app and I've been working on one view at a time in Interface Builder to make sure they work on all screen variations. I used "View As" option quite frequently to see how UI looks in different screen sizes. I just finished working on one view controller and want to move onto another view to do the same. However, the "View As" option does not change the screen size of the new view which I have currently selected. Instead, it changes the screen size of the view controller that I worked previously. This option seems stuck with the first view controller. Is that a bug or I'm doing wrong?
Just in case if anybody runs into the same problem, here what I was doing wrong. I need to set Simulation Size value of the viewcontroller that I want to work on to "Fixed" instead of "Freeform". Otherwise, it won't work.
Related
seems like Apple change how Interface Builder behaves in Xcode 8? Because when I check hidden in Attributes Inspector on a view in Interface Builder, that view is still visible.
This makes it very tedious to work with views where some views needs to be the view with the highest "z value", the front most view that is.
Is there some other way to show the green view in this example, than to change the order of them to the right (i.e. change their "z value")
In the image below hidden is checked, but I still don't see the green view below. You can download this trivial project at github
When the project is run, the green view is indeed shown, but the issues is that it is annoying when working in Interface Builder.
Am I missing something?
I have the same opinion on it and I also believe that it's annoying. I with they gave you the choice to update the actual storyboard before runtime or not but they didn't so for now we have to deal with it.
There is a quick alternative option though. Hidden will not update in the storyboard but alpha will. If you change the alpha it will update in the storyboard so if you want to see the view behind it just change alpha to 0. You can always change it back easily or if your doing it in code, instead of unhiding your view just change the code so the alpha is set to 1.
How about unchecking the installed checkbox of the red view?
This has also the flaw that you have to remember to reinstall it, but you don't have to change the z-order of your views.
This is deliberate. We wouldn't want a view to be hidden from you, the editor, just because it will be hidden when the app runs. You can easily select a covered view, such as the green view, using Shift-Control-Click on the red view (or use the document outline at the left of your screen shot).
I'm trying to get the split view controller working properly but apparently there's a bug in there or I'm missing something.
First of all, I've started a blank OSX Obj-C application, and in the Storyboard I've dragged the split view controller. Next, I've linked the segues from the main window controller to the split view and added two labels.
http://i.imgur.com/dlFObaF.png
When I build the project, it shows only the second page. Not to mention strange window size in the final build.
http://i.stack.imgur.com/IqRqr.png
I've tried everything.
This occurs in both vertical and horizontal split view.
Any suggestions?
I had the same issue myself today, but it's just the split line wasn't initiated properly.
To see, this, once you run your app, move your mouse toward the edge of the window and drag it, you will now see another view emerging.
To my best knowledge, I do not know how to fix this in IB or in code. Apparently NSSplitViewController does not have a property like UISplitViewControllerAutomaticDimension. Would appreciate if someone can contribute to this.
Edited: Found an answer via another thread. Basically, try to add some constraints to the subviews inside each view and that should prevent the size of a view to be zero. In my toy example, adding margin constraints to my buttons worked out well.
I have seven views that I need to navigate between from any of the other views. I don't want to keep doing segues from each one as new instances would keep being created...among other issues. What I was originally trying to do was have all the segues start from a home view and then go to the designated target view. When the user left that target view a public variable would be set if they wanted to go to any other view other than the home view. When the home view reappeared, it would check that public variable to see if another jump was needed. In the Home view I put the segue jump check in the -(void)viewDidAppear:(BOOL)animated function. The problem with this being you see the home screen for a second before it goes off to the new target view. The -(void)viewWillAppear:(BOOL)animated does not work for segues. I guess this is because it hasn't fully released the old segue yet?
Is there a better way to handle a freeform many view navigation issue like this? If anyone needs it, I can post some sample code for what I was trying to do. Thanks in advance for any help.
It sounds like you need a UITabBarController.
It allows you to have multiple view controllers, and switch between them by tapping the tab on the bottom of the screen.
It allows you to have only one instance of each controller, so that as you switch between them, data persists and you aren't creating new instances each time.
Here is an example of what one looks like (notice the tabs at the bottom of the screen):
(source: xamarin.com)
I’ve been reading through several books on Mac development, but cannot find the information I’m looking for.
The books all describe how to make floating windows or panes, but never mention how to make them all in one window. A simplified example of what I’m looking to create is shown below:
Basically, there will be three windows; A selector window with radio buttons to choose which NSDocument is currently being used, a window underneath that with buttons that show different windows to the right that allow viewing and manipulation of certain data.
For a example, each NSDocument may have a color value that can be set in the window shown by clicking view A, and some text strings that can be set in the window shown by clicking view B.
So the questions are:
Is it appropriate to use a single NSDocument sub-class for each Doc #1 and Doc #2?
Which classes should I use to set up the application as shown? NSWindowController? NSWindow? NSPanel?
I’m only looking for guidance on what to read up on, so any pointers are appreciated.
EDIT:
To clarify this further, I want to have a table view where the buttons are (View A & B), and by clicking them they will cause the other window/view to change it's contents.
It's like the split view in the iPad settings application, there is a table view on the left, and when it's pressed the right side changes.
The radio buttons are there only to illustrate that I want more than one Document. I'm guessing I need more than one to handle this? Or perhaps I should place them all in a single NSDocument? Somehow that doesn't seem right.
To achieve what you want you need one window (NSWindow), one window controller and various views each with their own view controller. There are several ways you could set this up, all depending on your requirements:
You'd have at least 3 views (instances of NSView): one for the selection of the document class, one for the view selection and one for the content. Each view is controlled by a view controller (instance of NSViewController). Additionally you can opt to wrap the views in split views (NSSplitView) so your user can resize the real estate available to each view.
You have one window with a window controller. If you choose a Document based app template in Xcode, Xcode will generate a subclass of NSDocument which you can use as your window controller (or choose to use Core Data and Xcode will generate a subclass of NSPersistentDocument with all bells and whistles you need to access Core Data for document persistency).
So to come back to your questions:
1: Yes, but depending on your requirements. If Doc #1 is a completely different thing than Doc #2 than you might need to re-evaluate. For example Doc #1 might have completely different persistent requirements than #2.
2: There's no single scenario here, but one that worked for me: Take the project template for a document based app (with or without Core Data). Use the generated subclass of NSDocument (or NSPersistentDocument) as your window controller. Use NSView to implement the views in your window where each view is managed by its own controller, which is an instance of NSViewController.
I know this is an old question, but a way to do it how you want would be to use: ContainerViews and set their embed segue to be the view controllers you want.
Summery:
I have a custom UITabBarAutoRotateController which returns YES from shouldAutorotateToInterfaceOrientation. This has no effect.
If I minimize and show the app again, the rotation issue goes away.
How do I refresh the screen so the user does not have to do this (so rotation works again)?
Details (setup graphically, so no code):
I have two UITabBarController in MainWindow.xib. I only want one to show at a time. So I am linking graphically rootViewController = tabBarController_name1. There is also tabBarController_name2.
I will also have an alert MessageBox for a user to choose what type of application they need, and it will choose a tab bar controller based on their request (per customer definition). This is commented out for now.
There is a bug with Rotation when two UITabBarControllers exist on the same xib. When I try to rotate the screen, it stays upward with wherever the main screen button (power button looking button) faces. HandleOrientationChange does not get called on the active custom ViewController being shown.
The reason I believe it's a bug is because if I hit the main screen button (minimizing the application), and click back on the application (brings it back to the foreground), rotation works perfectly!
Sorry for making you read all that mumbo :). My true question is, "Is there anyway I could refresh the main window or likewise UITabBarController's to get rotation working (without requiring the program be minimized and shown)"? A work-around, if you will?
p.s. I cannot use Storyboard for backwards compatibility reasons. The customer will be receiving this code/project. So I would like to keep this in one graphical page, rather than hiding/showing UITabBarItem's.
EDIT: two-uitabbarcontrollers-and-autorotation and uitabbarcontrollers-and-uinavigationcontrollers were both helpful, but did not address "why" this issue happens. "noob" here when it comes to xcode :)
Tab bar controller inside a navigation controller, or sharing a navigation root view is the answer. Do not use a TabBarViewController. Which, as a noob, I'm not quite sure why TabBarViewController exists (or at least isn't depreciated).
Dragging two TabBarViewControllers into the same page should result in a warning saying that you probably want to implement TabBarViewController by making a custom UIViewController and attaching a plain UITabBar to it.
Frustrating...but finally making progress :)