Multiple Variations of UI for the same view controller - ios

I am working on an Exercise App, where UI depends on the type of Exercise. Some exercises have the question as text and answer as text. Some exercises have the question as text and answer as images. One more variation is image and text in question and image in the answer. I create a question object based on the values I get from API for a particular Exercise. That object has many fields as optional. For example, the image is optional. Now the challenge I am facing is what is the best way to handle such dynamic UI. In plain English, if it has the image, show the imageView and if it doesn't have the image, don't show the imageView and adjust other UI elements accordingly.

You can have one UIViewController subclass, and many different storyboards each with a different layout and subviews.
Each storyboard has the view controller's class set to your custom class in the identity inspector.
Your view controller has outlets for all possible subviews, and each storyboard connects its subviews to the outlets that are relevant to it.
When you need to present a particular variation of the string, you instantiate your view controller from a case-specific storyboard (programmatically or using segues and storyboard references).
If you only need to disable one particular subview in one case, you can do one of the following:
Set that subview's isHidden property to false. It will stay in place, and occupy the same area, but invisible.
Remove it from the main view by calling removeFromSuperview(). Be careful if other, remaining subviews rely on constraints against the removed subview for their layout, though.

Related

Reusing view on different scenes in IB or programatically

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

Uniform UICollectionView across multiple UIViewControllers

I want multiple UIViewControllers holding a UICollectionView to look the same in constraints, size and cells, including textFields and UIImageView inside the cells.
This is how I want my views to look (roughly):
How can I decide of a uniform layout for all Collections ? (If one is changed - all others should be changed too)
Two options depending on what you need:
You need one base UIViewContoller class that holds a collection view and search bar - let's call it CollectionViewController - and make other view controllers inherit from it. Then a change in the CollectionViewContoller will apply to the other controllers. Unfortunately this cannot be done in storyboards. You can look here: How to use single storyboard uiviewcontroller for multiple subclass - suggestions are to use either a xib file to make a view with the needed subviews or make the whole view controller in code.
Use only one view controller and change the data you load into it depending on what you need.

Uniquely differentiate UIViews

I have an application where every view controller subclasses from BaseViewController (A custom view controller that subclasses from UIViewController). I need to differentiate the subviews of a certain view controller's view from each other, from the BaseViewController. The application is pretty huge and each subview doesn't necessarily have a tag. What other ways are there to differentiate the sub views?
The application is pretty huge and each subView doesn't necessarily have a "tag". What other ways are there to differentiate the subViews?
That's exactly what the tag property is for -- differentiating between views that are otherwise similar, like each button in an array of buttons. You should only need to differentiate between the subviews managed by a single view controller at any given time; any given view should only be known by the view controller that manages its parent view, so the size of the app really doesn't change the tag property's utility.
The other obvious way to tell the difference between views is to use the fact that they're distinct objects, each with its own address. For example, say you've got a bunch of similar views representing people on a seating chart, and you want to keep track of which view goes with each person in the chart. One way to do that is to have your view controller maintain a NSDictionary where the keys are people and the values are the views.
XIB and Storyboard files are just XML. You could write a script to load the XML, put in tag attributes and save. The XML element name tells you what kind of view it is (button, imageView, etc).
Alternatively, if you can have different tags on each load, you can just programmatically tag the subviews in viewDidLoad

Creating a UIView to be displayed in multiple UIViewControllers

I am creating a simple little popup view, similar to the popup that appears when you push the volume buttons. I would like to display an instance of that popup view in different view controllers. I have been pondering a couple approaches, but I would like to know what is the best approach, taking into account MVC, complexity, and otherwise 'good' practices.
Currently, I am creating and displaying this UIView from within my UIViewController. I justified that approach since it's really a small view and I do a lot of work with it to modify its behavior in that VC, so that code was already going to be in the VC. Essentially, I make a frame, set the background, apply corner radius, add text to it, apply motion effects, then make it fade in then later fade out. I could copy and paste the code into my other VCs but that's obviously a bad approach.
I could create a subclass of UIView and I'm sure I could use drawRect to draw it, but I'm not sure exactly how to add that view to the VC exactly in the middle, unless I drag out a view to my VCs and change its class. But if I do that I can do most everything in Interface Builder anyways, which would be preferred especially if I can use Auto Layout to always keep it centered. But, I'd need to copy and paste that UIView into each VC and hide it - that doesn't sound good.
I could create a subclass of UIView and instead of drawing with drawRect, implement a method that creates the UIView and returns it. Then in the VCs I just call that method and add the view it returns as a subview. I've never done this, and I'm not sure if that's an appropriate approach.
What is a plausible approach to implementing such a view that can be thrown on screen from any of my VCs? Thanks!
Note that this view should always be the same size, in the center of the screen, not tied to any specific VC. It should remain on screen unaffected by transitions and such. It closely mimics the Volume popup.
I would like to display that same popup in multiple view controllers.
I expect that you mean you'd like to have separate instances of that same class in multiple view controllers. A given view can have only one superview, so it can't exist in more than one view at a time.
I'm not sure exactly how to add that view to the VC exactly in the middle
It's easy to center a view in its superview. To center horizontally, subtract the width of the view from the width of the parent. Divide the result by 2. That's your X coordinate. Same goes for the Y coordinate, except that you'd obviously use the heights.
An even easier method is to create a point by dividing the superview's width and height each by 2. Set your view's center property to that point.
What is a plausible approach to implementing such a view that can be thrown on screen from any of my VCs?
Don't try to reuse the same view. There's no need for that, and trying to pass it around between controllers will really complicate your code. Just have any controller that needs to display your popup create its own copy.
Remember, views are the interface to the data that's stored in your model -- they can display that data or let you interact with the model, but they shouldn't store app state themselves. Given that, there's no reason that you'd need to use the very same view in more than one view controller. As long as your pop up gets its data from the right place, you can have as many instances of it as you like.
If your popup really is separate from the content of any of your view controllers, another possible strategy is to use view controller containment. You can create one view controller that handles just the "app-wide" stuff, like this popup, and have it load and unload the various other view controllers as it's children. I'd caution against trying this, though -- it's probably more complicated than you need and surely more complicated than you should attempt right now given that you seem to still be getting your sea legs.
It sounds like MBProgressHUD is what you're looking for. FFCircularProgressView might also help.

A permanent navigation bar with UI elements

Our app has some upper view, that is visible all the time.
This bar has a UITextField, UIButtons, side scroller, and segment control, and they are dynamic.
When you hit them, the view behind them(full screen) is changing.
I was thinking about navigation control, or tab bar, but seems that they can't have a text field and a scroller on them.
So my main thought was to create some COSTUM view of my own.
Question is , how can I create a view in storyboard, and add it as a constant view, than create some other views(+viewcontrollers) that will be changed according to that upper bar?
I want to create 5 views in storyboard, and switch between them according to the bar.
Sounds like a job for a containment view controller to me. I've used technique many times to both create a set of static controls on the screen which you describe and inject reusable content into an app in several locations.
The basic concept is:
Setup you Heads Up Display(HUD) with all the UI you want (this will be your base UIViewController).
Create a UIView in it and call it your contentView or something of the like. This is where all your dynamic content will appear.
Then your backing view controller adds another UIViewController as a child and tell it to show it's view in the contentView you specified.
Your view controller continues to remove and add children putting their content into the contentView as needed.
If you are unfamiliar with the technique there are many tutorials(by NSCookbook) of do a web search for "view controller containment tutorial". There is also a good WWDC (2011) video introducing the concept Session 102 - Implementing UIViewController Containment.

Resources