When a view controller (VC) has hordes of views and subviews it becomes very difficult to modify a subview because I can't even see it completely (it is hidden behind some other subview). For example please have a look at current state of one of my VC:
I can't see highlighted "Congratulations - UILabel" or its UIView.
Is there a way I can see a specific view clearly (may be at the top of all the other views)?
Generally I drag drop a UIView on a different dummy blank VC, design view completely on that VC with all constraints and finally drag drop it back to my actual VC. This works most of the times but it seems like an inefficient approach to me.
I've observed that seeing overlapping views used to be easier in iOS6 but it is Very difficult in iOS7. Is there any feature in iOS7 Interface Builder that I am missing? Thanks for your precious time.
Update: Would Spark Inspector help me here? I am newbie to development so don't want to waste my time trying and understanding new plugin if it doesn't help me achieve what I want. Thanks.
This is widely considered one of the weak points of Xcode's new Storyboards feature. They're great for apps that require a large number of simple controllers, but they become difficult to work with when your interfaces get complicated. Most experienced developers use Storyboards in some places and individual controller XIBs in others, depending on what they're building.
Here's how to solve your problem:
Step 1. Break the View Controller out of your Storyboard into it's own XIB
From the File menu, choose New File and choose an Empty XIB file (from the User Interface section). Name it "YourExactVCClassName.xib".
Go to your Storyboard. Copy the entire View of your View Controller and then delete it.
Paste the View Controller into your new XIB. Change the class of "File's Owner" to be your View Controller, and set it's "view" property by drawing an outlet from the view to File's Owner.
When your app runs, it will try to instantiate the view controller
from your storyboard. When it realizes there's no view in the
storyboard for that controller, it will automatically find the file
MyViewController.xib and load it from there.
Step 2. Organize the contents of your main view into detached views that make sense.
In your example above, it looks like you have different views for different states of the game (game over, high score, etc.) Take each of those and remove them from the main view. With your controller in it's own XIB file, you can just drag the view out in to the whitespace around your controller. Each view you drag out becomes a top level object in the XIB file that you can design and see easily.
You're no longer stuck with an iPhone-5-sized workspace.
Create IBOutlets for each of your detached, top level views so you can reference them in your controller.
In viewDidLoad, programmatically add each of the separate views to your main view. Note that you may want to set their frames, make some of them invisible, etc. You have to write more code, but it's generally worth it for an easily maintainable XIB.
Related
I've a view which I want to reuse on other scenes in IB. This view contains user details such as name, avatar, description, few buttons etc. These views are exactly same and have same elements inside them. Right now it's pain to copy them across scenes, fix the constraints and then code the same elements over and over again. It's not quite productive and it's time consuming. Ideally I want to see these views on IB so I don't want to code do everything programmatically without any visual. Is there a way we can make it in better way so that I can just reuse it?
Not only is it pain, it is poor design to rebuild the same component. I would create a xib file, create the backing swift or obj-c files. Wire up all the outlets as you would normally.
In each view controller or view that you need it, initialize it and add it as a subview.
In swift, I would do something like:
if let subview = Bundle.main.loadNibNamded("SpecialView", owner: self, options: nil)?.first as SpecialView {
// set constraints
containerView.addSubView(subview)
}
Yes you can. I've done this recently. I started in a VC that was a child of a NavigationController and pushed a view onto the view stack that was outside of the NavigationController's scope so the new view did not have the NavigationBar up top.
Assuming you are using a storyboard, you'll create the view with all of it's actions and outlets and link them up to its own class file. Also give the storyboarded view an ID. Then you need to define the controller as a constant and push it to your view stack when you want it used.
// define the controller
let controller = self.storyboard!.instantiateViewController(withIdentifier: "YourCustomControllerID") as! YourCustomController
// if you want to pass data to the new controller
// first you must define some class variables in that class then you do this:
controller.image = whateverImage
// then you push it to the stack like this
self.navigationController!.pushViewController(controller, animated: true)
To dismiss that view, you call dismiss(animated: true, completion: nil) in YourCustomController
Yes, there are a few.
Custom views are loaded as cnbecom said, using LoadNibNamed. Owner is a proxy class, meaning it just represents "anything". Owner is like a connection that is fitted but not made until you create the class, if that makes sense.
Another method is to create the custom view in code, but instead of having a separate nib, you just re-create the view and change the type in the main Xib/Container Xib. You will have to copy/paste the nib, and that's made easier by embedding it into a view before copying. Even with constraints, this method is easier. Hook up the outlets in the containing Xib.
Third is pure code. This is one primary reason constraints are just extra work, no benefits.
Fourth, is to load the Nib but inside a container. Basically it loads itself into its own type via the AwakeFromNib method. You then have to hook up the outlets to the inner Xib realizing that Owner changed. This method is useful if you can visualize what is inside the white square.
Also I never use constraints. The few times it would be helpful, it's still faster to write a basic single-line of frame x,y code in layoutSubviews or similar. Custom views and manually using layoutSubviews will save you lots of time. Springs and struts are extremely powerful, and iOS lacks the CSS media queries for full layout-changes, just has ways to move constraints around (which modifies existing layout, not helpful if changing menu entirely for two different device types).
Create different xibs for tablet, then write a loading func that tests if on tablet and appends a prefix, will give you an amazing system once you get custom loading down.
Anyway, enjoy! I believe this question is a slight duplicate, as your marker was the frustration with auto-layout, but your real question is "How do I load custom views in Swift", which has been answered many.
There are two ways to that:
Programatically (or writing code might be involved)
create a custom view and include all the interface setup you need including the data and add it to each controller you want it to be shown
Take the advantage of Container view for loading the other content in another controller as in this Github repo
Here is what I did in the second example:
Create a base controller that holds the view that I want to always be shown
Add a view and customize it as required
Add a Container View in the same controller
Add a NavigationController and embed it in the Container View
I am worried I am missing some high level understanding of Objective-C. Could someone clear this point up for me please?
When using storyboard I put ViewController on the design area. For example 'MyDetailViewController'. I then put labels, text boxes and such in this view controller.
Is this my view?
Am I being stupid and putting my controls within my controller instead of creating a separate view and connecting this to the controller or is the area I am working in within the storyboard essentially become my view and assigning a UiViewController class to the controller is correct?
Thank you for helping me out.
It is both your view controller and its view. If you look closely you will see that they are two different things, and that they are connected by an outlet (the view controller's view outlet). This is the usual arrangement in a storyboard (a view physically inside its view controller in the canvas), though it is not absolutely required — if you wanted to, you could have this view controller get its view in some other way, e.g. from a .xib file.
Is it a good practise to creates views in xcode and hide them and when required show them?
I am asking that because I prefer to create views visually and not in code.
If the view is to complex(a lot of subviews) should I create a new view controller to it?
I know there isn't a specify question here but I really need a clarification on this matter.
Regards
One of my first iOS applications had a tab bar and views that the user could switch between. Originally it was done by hiding and showing the right views depending on what the user pressed on the tab bar. This ended up being a complex disaster.
I then rewrote the app so that each tab bar view had its own UIViewController with its own set of views. That turned out to be so much easier to manage. (I also changed from using Interface Builder to straight code for creating the views, but that's beside the point and you can continue to use IB if you want.)
As for me, I prefer folowing practice:
Usually, a use storyboards,where views are placed, but if a view is complex, I create a separate XIB file, arrange all subviews there, and then in storyboard drag an UIView subclass and connect my XIB view with it.It helps to avoid mess in storyboard.
As for hiding views, I also don't recommend such practice as it can become very complex to understand your code and all those views are allocated when XIB is loaded, so the mobile developing rule "do as lazy as u can" is not met. We should try to spend as less memory as it's possible.
UIView is the best way to create iOS app, esp. if you want to reuse the code.
For example if you have same view to present in iPad n iPhone then using UIView can result in lots of similar code in View-controller
In another case if your view might need to have multiple table view it can be quite complex to handle each with delegates in ViewController. But separate view will solve this problem.
I have made my 1st open source code after learning how to use View
https://github.com/bishalg/BGRadioList
which I had learned from
http://www.raywenderlich.com/1768/uiview-tutorial-for-ios-how-to-make-a-custom-uiview-in-ios-5-a-5-star-rating-view
About the hiding view - I have used lots of hide and show view codes in my apps but believe me at one point it will become complex and unmanageable if you have lots of views.
Situation: two UITabBarController's, each with their own tabs, but last tab in both is identical so want one UIViewController to show content.
Issue at runtime: Shared item only appears in one of the tab sets when shown.
Question: anyone know a way to make this work?
Link to external graphic of storyboard setup: (sorry, don't have enough reputation to post images here!)
Storyboard graphic
An Xcode project with that storyboard:
XCode Project
Each tab content item has it's own UIViewController class. They contain no code except the line to make the back buttons work.
(Yes, I know this is odd. Real situation is an iPad app where tab controllers are shown in popovers; popovers are "property editors" where different objects have different properties, but all share a common set of properties... thus one tab for "unique" props, one shared tab content for the "common" props all objects have.)
I've found a couple ways around this to get the effect I want, but if this storyboard worked it would be a much easier solution.
-- Other info, somewhat unrelated to question --
Alternate solution I'm using: TabBarControllers only link to one VC as tab content. When that tab VC loads, I use code to (a) instantiate shared VC from storyboard by identifier, (b) add that new VC object to the TabBarController via [tabController setViewControllers:list animated:NO].
(Another possible solution I like even less: not using a TabBarController, and presenting content VC's with my own "tab" graphic drawn into them, each showing "myself" as selected. Yuk.)
So I have a working solution, I'm just curious as to why this doesn't work (just a known thing in iOS API, or some magical property setting that might render it functional?)
You can't put the same view controller instance into two tab controllers. The problem is that a view (UIView) instance can only have one parent view (superview). When you try to add the view controller to the 2nd tab, the view controller's view gets removed from its first parent (the first tab) and then added to the 2nd tab.
I stumbled upon your thread while running into the same issue today...
The solution is to just make a duplicate of the view controller in story board and attach the duplicate to the other tab bar controller.
I just did it and it works...
I think the 'rdelmar' is right about this... copy it and set it ..!!
I ran across this same issue today. I managed to come up with a workaround that seems to do the trick. The key is to add a layer of separation between the tabbar and the controller you want to reuse. From each tabbar, I created a relationship to a distinct UIViewController with a container view. Then you can do an 'embed' segue from the container to the controller you actually want to reuse as the tab view. It is not quite as clean as a direct connection (not sure why that is not supported) since you do have to create a controller class for each reuse case. It is still a better solution than the nightmare of having to duplicate the actual tab view ( as well as any additional views that connect to it) for every use.
Hope this helps. Let me know if anyone needs more details.
Background
I'm using interface builder to create the UI for an app I'm working on. The app has a single screen that displays a series of buttons. Clicking on a button displays an associated view which overlays the buttons. Clicking another button hides the previous overlay view and displays another one.
Too make managing the UI easier in IB I've decided to create multiple nib files for each sub view that is to appear when clicking the relevant button. I'm then loading the sub view's nib file in the view controller's viewDidLoad method using the UINib class.
The idea behind this was to avoid having multiple views stacked on top of each other in a single nib file as this would be hard to manipulate in IB. I could have created all the views in code but this would require a lot of tedious coding as the layouts of each sub view are quite complex (with multiple child views).
Example code loading a sub view from a nib file.
- (void)viewDidLoad
{
UINib *aSubViewNib = [UINib nibWithNibName:#"aSubView" bundle:nil];
NSArray *bundleObjects = [aSubViewNib instantiateWithOwner:self options:nil];
// get root view from bundle array
UIView *aSubView = [bundleObjects objectAtIndex:0];
[self.view addSubview:aSubView];
...
The code above is repeated for the other views.
To summarise I have a single screen iPhone app that has layered views that are shown/hidden by clicking buttons. This is achieved with a single view controller with an associated nib file and a series of additional nib files for the sub views which are loaded in the view controller's viewDidLoad method.
Questions!
Sorry for the long introduction but I wanted to be very clear what it is I am doing.
Is my approach bad or unusual?
Are there any potential issues to doing it this way?
What have other people done when they need a dynamic interface and
still want to keep everything in Interface Builder?
Notes
Before anyone asks why don't I just display the sub views on a new screen and use the navigation bar, let me say that I have very good reasons and I do understand iOS UI guidelines. The above use case is not exactly my use case but it's one that clearly describes the problem without getting bogged down in my development app.
Also I know I could have written all the sub views as code but each sub view has a complex layout of child views and it would be a lot of code and messing around to try and get them looking right.
Thanks in advance.
There isn't necessarily a 1-to-1 relationship between view controllers and views. Most views contain many subviews, which are views themselves, so this literally doesn't make sense.
However, depending on the complexity of the views (including their content), you may want separate view controllers... or not.
For example, if you have two sbuviews that are each tableViews, you may want to have one view controller for each tableView. This is because each tableView is looking at the same delegate methods, and if they are in the same viewController, then the delegate methods have to differentiate between the tableViews. The delegate methods have signatures that allow this, but, in my experience, it can really make for a messy code design that is hard to follow and hard to manage.
On the other hand, you may have two tables that are managed by the same viewController, where one table is filled with meaningful data and the other is simply a place holder (as when the data source is empty). One might be visible while the other is not. Why make you life complicated by creating two view controllers when both are driven by the same data source (the model)?
In my mind, it comes down to how difficult it is to follow and manage the code. If the complexity of using a single view controller becomes burdensome, consider using more view controllers.
UPDATE
By the way, I have an example that I am currently working with that may illustrate a similar situation. In the InAppSettingsKit, that a lot of developers use, there are several xib files for pieces of the main view. You can look at the structure here on github. There is one main view controllers and several xib files. (There is also what I would call a "helper" view controller and an email composer view controller.) In this example, the xib files may be used multiple times to specify the layout of table view cells. There is no view controller for each xib file, though. (The documentation for InAppSettingsKit is sparse, so these things may not be obvious just by taking a quick look at it.)
Every View should have a corresponding UIViewController. Using one ViewController to "Control" more than one view breaks the MVC paradigm. "Controlling" multiple "views" from one controller will make it much harder to change one thing without breaking something else. The choices you make on how to present the content to the end user will be different for every individual. So if you say a NavigationController won't work in your case, maybe a Modal view is the answer or, you might just instantiate your custom UIViewControllers and add them to your view ([addSubview:]), if thats the road you want, but like I said, it would be beneficial for you to make a "controller" for each view object along with the corresponding xib. If you need information sent back, use a delegate or use Notifications to send the message back to the parent view. I learned the hard way that not following MVC paradigm, will make you life miserable. Try and keep your code as decoupled as possible. And read up on the MVC design pattern, you won't regret it.
actually its possible to do this.
Open your .xib file,select File’s Owner(in placeholder) -> "identity inspector" (utilities) -> change class name to your controller classname -> press control and drag file's owner placeholder to View object, select "view" in dialog.
Now you can customize your view.
p.s. you can use the same outlets as first xib, you need only to drag them to the new xib(+control sure).
here is an explained tutorial:
http://irawd.wordpress.com/2013/09/05/how-to-link-a-xib-file-to-a-class-and-use-2-xib-files-for-iphone4-and-iphone5/