there are different conditions for same design file. i can't use if-else in same class file to differentiate them. because manage all conditions are difficult. is there any way to change class at dynamic time.
Yes, we can set class using Xib. But from my research i didn't find any way to change storyboard class dynamically. I found other way to reuse the view like using container view. following link shows how can we reuse storyboard view.
Diego Lavalle describe it on medium.
and you can read about container view at here.
I think you can use a master view controller and can load different view controllers as child based on some condition.
For example in Master View controller you can use UIsegmentedControl and based on the option the user chooses, you can show different view controllers.
Refer the following for implementing the same.
https://medium.com/#Dougly/creating-a-custom-view-controller-navigation-interface-programmatically-swift-3-1-8c9e582cdb30
Related
I need some help on creating a "Header" for multiple View Controllers without copy/pasting every time the line of code into the new view controller I create.
Something like creating a header in PHP and including it into the pages you want.
In the header I want to add custom text/data.
I tried creating a View on a single View Controller and then implementing that view on multiple storyboards, but it doesn't work and doubt that's the way of doing it.
I tried looking for something similar to what I needed but couldn't find it.
I am new to swift/xcode.
Thank you
Create subclass of UIView with nib.
When adding instance of this view to view controller, also create
constraints(or create them with interface builder).
Add setup
method that takes String argument and sets the label outlet.
If you meant header that will push all the view controller content down, that's hard to implement and I don't advice it.
I need some help on creating a "Header" for multiple View Controllers without copy/pasting every time the line of code into the new view controller I create.
There are at least three ways to do this:
Common view: Create a common view that you just add to each scene where you want the header displayed. RealNmae gives pretty good instructions for that, as does the possible duplicate that matt linked in a comment, so I won't try to describe that approach again.
Inheritance: Put the code to create the header in a view controller class that's otherwise empty. You might call it HeaderViewController or something like that. Then make all the view controller classes that need to display the header subclasses of that HeaderViewController class.
Containment: Create a container view controller that displays the header. Container view controllers can draw part of your UI, and then let a contained "child" view controller handle the rest. UINavigationController and UITabBarController are examples of container view controllers -- they draw a bar at the top or bottom of the screen that provides some functionality, and everything else gets drawn by the contained view controller(s).
I would like to use a single WizardViewController with different inputView subviews. The WizardViewController would share a searchCriteria and pass it along to each new step, with each step adding to the criteria depending on the input for that particular inputView.
The problem I am facing is how to structure my objects/views so that I can reuse WizardViewController accepting different types of input/controls. For example, I've thought of using a WizardViewModel that had members like enum wizardViewModelType (for each type of view), UIView *inputView that corresponds to each type of WizardViewModelType, and creating custom UIView subclasses that correspond to the different possible inputViews that would be needed, connecting outlets as necessary in Interface Builder. The problem is that I believe that going down this road will lead to a lot of inter-class dependencies and basically defeat the purpose of separating the inputView logic from the WizardViewController. Furthermore some of the inputView will require me to grab possible values from a web service, which is something that the ViewModel will have to handle, further breaking the logic. Perhaps I need separate ViewController for each type of input view? Or am I thinking about this in entirely the wrong way?
Normally, the right way to do it is by having a ViewController for each UIView. The logic of your application should not be on the view, but on the viewController, and you can share data by using segues (if on ios 5), and I'm sure that there are other methods for ios 4 or below.
If I wanted to share codes between the UIViewControllers, the way I would do to make a wizard is to embedded it in a navigation controller and push the next viewController on the navigation controller stack.
If you want to share code between view controllers, I don't think you should do it on the view controller class. Basically, I would think of two options to do that:
1) write a base class: the base class should extend the UIViewController and your UIViewControllers could extend this base class.
2) extract the common code into another class (better, if applicable): You create another class that share the common code, and inject it into your view controllers.
Being new to Xcode and Objective-C I find it hard to get my head around the Interface builder and Objective-C when doing things that are following the basic pattern. I have created a subclass of UIViewController that I want to instantiate several times to make a grid with each row being controlled by an instance of this class. So there will be one root view controller (with navigation etc) that should include/genereate all the instances of the custom sub-viewcontroller.
Now what would be the best way to do this? All examples I can find are about navigation, where one view should replace another, but I want to have all the viewcontrollers visible on the same "page". Do I need to create a nib file for the custom controller at all? I have also been thinking about using the UITableView somehow but inserting my custom viewcontroller in every row.
Any help greatly appreciated!
Apple's documentation recommends using one view controller per screen. It is possible to decompose your interface and use multiple view controllers on one screen if you have a good reason to do it, but Apple hasn't really designed their frameworks to support this, so you'll run into pitfalls if you don't know what you're doing.
In this case, I question whether each row of your grid really needs its own view controller. I find it hard to imagine a case where this would be the best choice, although it's hard to say for sure without knowing more about your app. Some things to consider:
What is your custom controller doing? Is it mostly changing the visual appearance of its corresponding grid row? If so, perhaps it would be more appropriate to subclass the UIView itself.
If this object is really behaving as a controller and not a view, consider implementing it as a subclass of NSObject rather than subclassing UIViewController. The UIViewController for your screen can capture events and delegate them to the appropriate custom controller object, or your custom views can capture their own events and notify their associated controllers of those events directly using a delegate pattern.
If you're sure you have a valid reason to implement these objects as UIViewController subclasses, check out my answer to this question.
Apple's documentation on the UIViewController class has this to say:
Note: You should not use view controllers to manage views that fill only a part of their window—that is, only part of the area defined by the application content rectangle. If you want to have an interface composed of several smaller views, embed them all in a single root view and manage that view with your view controller.
When using iAd, this is a pain. The problem is that I don't want to be managing my app's content in the same class that has methods like moveBannerViewOffScreen, didFailToReceiveAdWithError, etc. Putting those in the same class reduces modularity. Additionally, I can't have a navigation stack in which the ad remains in place when other view controllers are pushed.
I am curious if readers have encountered similar issues and if so, how you have dealt with them?
If you want modularity while keep using ivars from the view controller, create a category.
The two approaches that come directly to mind are using a non-UIViewController class as your delegate, or using a subclass of UIViewController as your view controller base class and putting the logic in there.
I want to create UI elements programmatically without using xib files. All of the examples I have found (UICatalog, ...) are creating UI elements directly in the controller methods. What is the best practice to keep up with MVC patternn and separate views from controllers?
Thanks
If I understand the problem correctly, all you have to do is to create a separate view class that will take care of creating the UI elements. Then in the controller class you simply create an instance of the view class.
zoul is correct in his answer. To aid you in doing this, these is a tool that will convert an XIB to the same Objective-C code it would take to create the view:
http://arstechnica.com/apple/guides/2009/04/iphone-dev-convert-xib-files-to-objective-c.ars