I have a class with 5 subclasses. these classes have many views in common. but all of them have a view which is just for them.
I created a view controller with xib file and I added the common views to that xib file (general.xib)
and for each subclass, I created a specific view for itself.
I don't know about the best practice.
is it good to have a UIStackView in general.xib for this situation?
UIStackView will arrange all its subclasses equally/ratio according to our specification. If you want them equally align within you super without any scroll, it's a good one.
Related
I have a project which is based on storyboard. The problem is some views are repeated in some view controllers.
I created xib file for these repeated views and then I use don't create theses view again. I just add a uiview and set its class to the custom view I have created.
It work ok as it avoids repeated view changes.
But I don't know if this cause performance or any other problems later.
And I cannot change the whole project to only use with xib files.
one of the clean code goals is to reuse your code. so base on this, xib file is a good solution, but about performance, using interface builder has less performance than implementation through code. if you are concern too much about performance, use the code, if not, your implementation is ok.
If your project has similar kind of design or view then yes using xib with storyboard is good. you can reduce redundancy by taking similar kind of view or Tableview cell or collectionview cell. that will also make your storyboard neat and clean.
you can check this and based on that you can use as per your requirement.
Which is more efficient way? StoryBoard or XIB?
Does anyone know if we can design our custom UIViews in Xamarin's storyboards ? I would like to use autolayout and size classes for a custom View that I need to develop. I am not much comfortable with Xcode, having been so attached to Xamarin's IB. So I would prefer to design it in Xamarin storyboards than going for XIB files. I know we can prototype UITableViewCells in storyboards, but that is not what I want. I want a standalone custom UIView, with a code-behind class that I can re-use.
I am a bit confused as to what you are asking.
Are you wanting to design XIBs in the Xamarin Designer?
Currently, it is not possible as storyboard's XML and XIB's XML are completely different. But it looks like Xamarin is thinking about supporting it as it is on UserVoice here. So you could vote for it and hope it gets added in.
Another option is to start using Xcode.
I have found out a way. But it is kind of a hack and will increase bundle size and thus a memory-inefficient way. First add a View Controller to the storyboard and give a class name to create a code behind, say "DummyViewController". Then drag a UIView to DummyViewController and in "properties" pane give "class" name as the name of the Custom View as shown in the image.
A code behind for this View will be created in project folder, MyCustomView inheriting from UIView. Now we can design the view from within XS storyboard with AutoLayout and Size Classes without a separate XIB file.
I do not recommend this unless you really want it to be done this way. Hope Xamarin will come up with a solution to design Custom Views from within XS soon.
Is there some "best-practice" way to add subviews to a UIScrollView?
For Example:
I have a UIViewController which loads images with corresponding description from a server.
Those images+descriptions should be added in a horizontal scrollView.
When the data is loaded, should I create a method in my UIView to handle this stuff,
or is it more convenient to do this in my UIViewController?
Your view controller would be an most appropriate place to handle this, as controllers should connect your view (the scroll view) to the data (the images).
If the scroll view's layout is simple, it could be done entirely with the controller. But, if the layout is complex, you may want to consider subclassing UIScrollView and handling some of the layout there (similar to how UITableView works).
For more info on standard application architecture, read Concepts in Objective-C Programming on Apple's developer site.
By my way of looking at it, the separation of concerns would break down like this:
the UIViewController is responsible for getting the images and handing them to the UIView
UIView is responsible for displaying them.
So the -addSubview: is a view implementation detail, should go in the view, and be opaque to the controller.
There is plenty of opinion that both UIViewController and UIView are confused and intertwined in such a way to make them both part of the conceptual "view" (in a MVC sense), but I think it's still cleaner this way.
As you can see, opinions differ. :) Personally, I despair of MVC, and think Model-View-ViewModel to be a much clearer, cleaner, and more sensible way of approaching all this.
UICollectionView is same as that of UITableView except it is meant to display Images and its description.
Here is what you can do.
Create a UICollectionView, it is the subclass of UIScrollView. SO there is no need of UIScrollview.
Since you need image and description both for each item, I will recommend delete the UICollectionViewItem from UICollectionView.
Create a seperate custom UICollectinViewItem class, define UICollectionItem in .xib file (UIImageVIew and UILabel).
When you define the datasource method "– collectionView:cellForItemAtIndexPath:" define the UICollectionVIewItem class here. Exactly we defines custom UITableVIewCell.
I went through lot of similar questions but still have not clearly understood this.
In terms of better design - what is right way - creating all the UIButtons, UILabels etc in the view controller itself and then add them as subviews, or should I create a custom view (#interface MyView : UIView) with all the required buttons/labels etc and then assign that view to the view property of View controller? I am not using interface builder.
Is there any real need/advantage of creating a custom view like this or adding everything in view controller itself should be okay/good idea? Sorry I am very new to iOS app development :-)
If someone could explain it to me - would be really helpful.
Some advantages of subclassing a view are:
Code separation. If you have a complex view and want to keep your viewcontroller clean, subclass and separate it out.
Reuse. If you reuse the view anywhere else it is possible with minimal effort when the view is it's own class.
You can choose what setup and methods to expose for setup
Some disadvantages of subclassing a view are:
View no longer will have access to view controller ivars.
View controller will no longer have direct manipulation on the view
You are constrained to what the view publicly exposes in terms of setup and config (may be a good thing).
Overall, there is no single best answer, it all depends on your setup and how you like to keep your project organized.
My non-answer : the answer lies in between these 2 opposite sides :
putting verything in the view Controller, using just basic views
using very elaborate views that abstract away some tedious graphic work.
To get an idea of what I'm talking about : one might implement a UITableView behaviour directly into a UIViewController with just a UIScrollView, and handle all the indexPath computation (depending on the amount of scrolling), views recycling, etc... in this very viewController.
But, as lists are a common way to visually display information, all this 'recycling view', 'setting content for currently displayed cells' has been moved into a custom view class : UITableView, and delegate and datasource patterns have been use to make this class behavior easily customizable.
Creating abstractions has its advantages and disadvantages.
I try to do things incrementally :
hold the most you can in viewController
when code becomes too complex, or if you see yourself needind the same kind of 'component' elsewhere : the create a custom view, and try to define its API (what properties it exposes, what implementation it hides)
View controllers are a nice way of separating the things that a view must do in the strict sense (handle input, render output) from the larger hierarchy, manipulation, and information routing of views around it, which the view controller coordinates.
Striking the right balance depends on a number of localized factors. A view which contains a label and an image (like a cell) could certainly "own" its subviews and appear to the controller like one container unit. But note in this case that the subviews are also supporting the input/rendering of the "cell" unit.
In that sense, if you have a large canvas with a set of actual controls that are "on top" of that canvas but not necessarily "owned" by it, the view controller would probably want to create and attach these into the view hierarchy.
In my UI, there are three different table view cells. Well,not THAT different, they have some elements in common. So a base class capturing common elements would be in order.
How to apply basic OOP principles when I have the base class with XIB file?
How would I then add missing differing elements in respective subclasses if they ALSO have XIB files? (I want them to have XIB files as I am too lazy to edit frames and other properties of those elements in code..who has time for that nowadays...)
I mean how do I solve this superXIB - subXIB relationship thing?
Interesting.. But there is no way you can load multiple xibs from the bundle for a view or merge multiple xibs into one! :)
So I think you cannot have a superXIB - subXIB relationship.
You can create a base Table cell with no xib, containing some common things. Other tableview cells derive this. Have separate xib's for these subviews so that you can set frame and stuff.