I am working on an e-commerce based app, and the designer has passed on the mockup to me. !
This is the mockup the designer has passed.
I am working on storyboard of this mockup and I have managed to get to this level as of now.
There are several views and features which cannot be included in this storyboard now because of the limited space. I know the designer has passed on me the rendered view, which can be seen on scrolling the app.
I wonder which could be the best approach to include all these views in a single storyboard or render them in a single view.
I have looked onto using xib files and calling them from my viewcontroller class, which could be a possible solution. But, I want to know, what could be the best solution?
Best solution is use Storyboard so that you have all screens at one place. But keep one thing in mind that start doing the whole project in XCODE 8 storyboard (Because XCODE 7 and 8 storyboards are not fully compatible with each other). So that you get compatibility with previous iOS versions also (< iOS 10)
Now as far as design is concerned, I would like to suggest you use autolayouts and proportional layout.
your View controller will always have self.view. Start on that view. First add navigation controller (with root view controller as your first prefered view controller on app start) or simply add one toolbar. Then add one UIScrollView to whole remaining space. Then start with your design inside UIScrollView. Don't forget to provide contentSize of UIScrollView.
For any help, feel free to ask.
The best solution would be using a tableView with multiple prototype cells for this kind of problem. Well, going through the concept as mentioned, I could easily scroll in the storyboard and maintain my design as per the mockup.
Related
So I've been working on a project for a while that has so many view controllers, but I notice that now when I try to do a single edit in any view , storyboard hangs, or become unresponsive . what would be the solution for this issue ? is it possible at my current state to split up the whole storyboard into smaller ones ? and will that resolve the problem ? I'm using Xcode 9.3
Yes. You can have more than one storyboards in one project. In fact that's the preferred way to manage very large projects. To create more storyboards go to File Menu > New > File... and then select Storyboard from the User Interface section. Doing this should resolve your issue. However, if the issue still persist you can consider taking out the specific user interface into its own .xib file.
Update:
If I were in your position I would have considered using .xib files to create my user interface instead of using storyboards. Storyboards do have their advantages but there are some cons too if you use them. Like:
If you work in a team you will run into merge conflicts more often because someone else made a change in the storyboard.
I am still not a Guru in S/W design but, to me it seems like Storyboards violate the Single Responsibility Principle of S/W design.
You won't be using Segues in complex ui flows anyways so what's the point of having every thing in one file.
You won't be able to reuse your UITableViewCells interface. Prototype Cells are a good idea but if you have a UITableViewCell which is used in more than one UITableView you will have to replicate the UI in Storyboard.
In my experience, in a more complex and large project having everything in one Storyboard makes it even hard to comprehend the UI/UX flows as Segues from every view controller seem to connect with every other view controller to the point where it just stops making sense at all.
Yes, it is best practise to distribute viewConrollers into multiple storyboards so that you can open it quickly but it can lead your time to manage each storyboard identification programatically while accessing into code.
Otherwise, you can set storyboard View as : iPhone 5C so that it can load little bit faster than bigger devices.
Refer:
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.
I am new to iOS and have recently finished some classes.
Now, I'm onto my first app with Swift. I wanted to know:
Is it necessary to define all views/screens in the storyboard right in
the beginning, with proper navigation controllers?
What is better, define all in the beginning or keep adding as need
arises in the future?
Keep adding as needed.
You'll always be finding or coming up with new features, and at times you'll need to insert view controllers between other view controllers (adding an extra step, for example).
Within view controllers, you'll also find the need to put items into containers. That's where clicking the item/s (selecting them), and going to the menu, selecting "Editor" and then "Embed In" comes in really handy. For example, you may want to put a series of items into a scrollview after you've already laid them out properly, because they don't display properly on an iPhone (and you had done all of your testing in Simulator on an iPad first).
No it's not, you can create all views programmatically without using a storyboard at all. Its's just your choice what works better for you.
First of all, you can use storyboards for your UI (and navigation), use .xibs (only UI) or create everything programmatically. Each of these has its pros and cons. Also you can mix and match all these. For example have a storyboard, some views with .xibs and some views created programmatically all in the same project. You just have to choose what fits best your needs.
You don't have to create everything in the storyboard right in the beginning. Create only the views you need to start coding and then add more views as you progress your app development.
I have a View Controller that displays 3 custom views. My question is, would it be better to create a XIB for each subview or not?
I have been told that loading a XIB file is really expensive, so it's better to have just one XIB for the View Controller and avoid having XIB for the custom views in that controller. However, in order to avoid that, I have seen the custom views' constraints set by code (as there is no XIB for them and no way to use the IB), which I don't like. That's why I'm wondering if it's fine (both a good practice and efficient) to create a XIB for each subview and set then set the constraints using the IB.
Thanks in advance.
Unless you are planning on destroying views with a large amount of components and rebuilding them serval times a second you should not notice any performance hit. If you do, cache them.
As for best practice (in my option) you don't use XIBs for the efficiency, you mainly use them because they are quicker to build and easier to understand if you need to revisit the view at a later date.
If your going to use AutoLayout in code anyway I would use XIBs where possible as you get the advantages above. The layout engine is usually the expensive part anyway.
Hope this helps.
I am looking for some clarification with regards to view controllers and views. Should one view controller be used exclusively to control one view?
Basically, my portrait view is going to be a 4x3 grid of buttons (within a scrollview). When i rotate the view to landscape, i am going to want maybe a 6x4 grid.
Obviously the functionality for handling the buttons' clicks etc will be the same in either orientation, so it would seem a lot of effort to duplicate this for landscape.
How should i get the view controller to use the correct view xib?
Should i have two seperate xibs? I have tried every combination of autoresize masks and not having much luck.
I'm not sure of the correct way to go.
Thanks.
i do not think that the above one answered the question of joec. joec want to know, if it is bad or good to have 2 nibs (i.e. landscape.nib and portrait.nib) and manage the views in that 2 nibs with 1 uiviewcontroller.
my understanding of the mvc design pattern is, that a ViewController really SHOULD manage different views. but when i look at the internet, in cause of cocoa touch, often people says that it is BAD (whatever this means) when a UIViewController switches his view-property at runtime. thats confusing to me. why should a viewcontroller not be able to switch views ? why should i build some strange "master"-viewcontroller, which manages 2 other viewcontrollers, and everyone of this manages his own view. in case of landscape and portrait abstraction (or i.e. iphone-gui and ipad-gui abstraction) the code in the gui-business-layer (the event-code etc. in the viewcontroller) is exactly the same for different views. the style of the views is not. so that should one of the benefits of a mvc-implementation.
sorry, but that seems not logical for me, apple.
any thoughts ?
edit says:
it seems that apple provides some strange sort of workaround to solve this problem (hate me, but for me it is nothing more than that, because i see no really straight-forward design implementation for managing and handling views in the UIViewController class):
http://developer.apple.com/library/ios/#featuredarticles/ViewControllerPGforiPhoneOS/BasicViewControllers/BasicViewControllers.html%23//apple_ref/doc/uid/TP40007457-CH101-SW26
i found this link in the following stack overflow thread:
Want to use muliple nibs for different iphone interface orientations
thanks to Michal for that one.
You can also try to change your views and subviews sizes etc.
Take a look here Madhup expained It before. Changing UIView on orientation change