Composing user interfaces without nesting viewcontrollers - ios

I am pretty new to IOS but have completed a couple of simple apps.
I have read a number of books, which have helped me getting started, but I am missing som more generel advice on how to best structure an app - especially with regards to UI.
I know this is a very general question, so I will try to put up a specific problem. Suggestions on how to structure this particular app .. or pointers on good reads regarding similar topics would be highly appreciated.
Now the UI of this particular iPad App will look as follows:
The main screen is divided horisontally in two.
Upper two thirds is a sort of canvas / work space
Lower third is a toolbox with various items, which can be dragged to the work space.
The toolbox has different views which holds items in various categories. Lets say: One view with various geometric figures and one wiew with various colors. The user can choose which category to show in the toolbox.
Finally at the top of the screen is a toolbar with a single button.
I am a bit confused as to how to structure my views / ViewControllers. Maybe a lot of my trouble stems from me not fully understanding Apples guideline as to how to use various UI Elements - please feel free to say so if this is the case.
This is how I would start out.
I would construct a main ViewController controlling a main view. The main view would hold the upper toolbar. To this view I would add two subviews. One for the work space and one for the toolbox. The toolbox view confuses me a bit. My idea is making this a tabbed view with one tab for each category of items. However as I understand it, it is bound to cause lots of trouble nesting viewcontrollers which would be the case. Does this imply that using a tabviewcontroller to control only part of the screen is against guidelines? Would it be much better to make up my own 'tabbar' and simply switch between subviews when a tab is tabbed?
Does this also imply, that having a popup view, covering only part of the screen, with a navigationcontroller is equally bad practice? Or would this have to be a modal view? And how about a tableviewcontroller with a view taking up only part of the screen? I fail to see how to accomplish these things without effectively nesting viewcontrollers.
I am sure I got something completely upside down?
Best regards
Thomas

Nesting ViewControllers is not a problem. In fact, View Controller Containment was introduced in iOS 5 to make this even easier. However, it was still possible before the new containment functions.
The easiest way to nest two ViewControllers is the following:
SubViewController *theSubView = [[SubViewController alloc] init];
[self.view addSubview:theSubView.view];
The subview will then be controlled by the SubViewController and will be "nested" in the main ViewController. (This code would be part of the main ViewController.)
To use the new(er) View Controller Containment methods you will make the SubViewController a childViewController of the main ViewController.
There is an excellent video from WWDC 2011 that goes over View Controller Containment. You will need to be a developer to access it here. It is called "Implementing UIViewController Containment."
I would not advise to use the TabBarController in a nested format, it would be easier for you to just build your own view switching method or even use a UIScrollView with pagingEnabled.
As far as popup views with NavigationControllers, this is a common practice. There is nothing wrong with creating a popup with a NavigationController inside of it for doing something like, accessing app settings, or configuring a tool from you palette, or accessing saved projects, whatever you can imagine.
I hope this gets you off to a good start.

Related

Display a ViewController inside another View Xcode

Okay so I know that you can embed a ViewController inside a view. But the situation I have is a little different
I have an app which is using an external monitor. When the monitor is connected, I'd like to display the ExternalMonitor ViewController inside another view on my iPad screen. Like a Live Preview. I can't work out how to get it to display the ViewController on both my ExternalMonitor and my PreviewView at the same time.
Basically:
1 ViewController displayed in 2 places at the same time, scaled to fit the two different views.
Is this possible. Can someone point me in the right direction?
I apologise if my terminology isn't right. I am quite new to Xcode and swift.
While someone might offer a better solution to this, you might try displaying 2 instances of the same view controller class in 2 different places. It won't work of course, if this controller should respond to user actions. They will not be in sync that way.
You can use a common UIView in multiple view controllers for e.g we do use in making common headers and footers , but according to my point of view this is not possible to use 2 instances of a view controller at the same time . It will got clashed , may be it will work sequencely one after another but not on same time.

Xcode 5 - Tabs at the top

I wanna put "tabs" at the top of the view and I don't find in object library... does anyone knows? Thanks for the help.
Examples here:
http://imagizer.imageshack.us/a/img829/1808/47bw.jpg
http://imagizer.imageshack.us/a/img822/7048/oaum.jpg
There's a difference between navigational tabs like the second screen shot has and just a "tabbed" division of information like the first. The first one stays a single screen while the second one could also be considered an application that has different subviews under that tabbed navigation. The first screen is trivial and you should do this with UIViews with UILabels nested into them.
The second screen is more interesting. I don't think it's a good idea to use the built in tabbed navigation handlers because it's just not a good fit for that kind of layout. You could do it but you're writing a lot of code to get it completely like you want it. But if you would want to you could divide the screen with custom containers and trigger segues in the bottom part from the UIButtons you put on top and it's a pretty good way to handle those kind of segues from within Interface Builder.
More information:
http://sandmoose.com/post/35714028270/storyboards-with-custom-container-view-controllers
https://developer.apple.com/library/ios/featuredarticles/ViewControllerPGforiPhoneOS/CreatingCustomContainerViewControllers/CreatingCustomContainerViewControllers.html

Best Practice: UIViewController or UIView

I am gonna design a component in IOS, in which we will have Table view and Grid View; means user can see his data in table or grid. So what i am doing is i added a UIViewController and added two child view controller one for table and another one for collection view. I am handling everything using UIViewController only. Its means when user wants to use my component he has to add as a child view controller only. My question is that "Is it the best practice to use UIViewController like i am doing or Should I convert everything to UIView because UIView is light weight." I am gonna write only presentation logic in my component. We will get data from outside using delegate. And if i should use UIView then when should i use UIViewController?
Thanks
Your current approach is correct.
UIViews should do one and only one thing: paint a view when asked to.
UIViewControllers are more complex. They are are responsible for setting up views with any data they need to do their job, compositing multiple views (or view controllers) together if needed, responding to events from view components or from the device in general, and communicating with the rest of the code/system.
Because your code wants to show two different kinds of information, it fits the UIViewController much better than the plain UIView style.
As you've pointed out, Apple themselves have many examples of UIView subclasses that have delegates and do complex things. However, if you're writing a new component and it is complex (as yours is), I seriously recommend going for the UIViewController approach.
A note on history: Apple used to be of the advice that UIViewControllers should only show/composit UIViews and not other UIViewControllers (even though, confusingly, they didn't always follow their own advice!). This would align with their making of some quite complex UIView subclasses. However, they changed this stance a while back, and added support to UIViewControllers for compositing other UIViewControllers' views inside them. If Apple's stance had always been as it is now, you might find that some of their UIView subclasses were implemented as UIViewControllers!
As an experiment, it would probably be quite educational to try and implement your component both ways. I predict that you'd find UIView approach more unwieldy, with you having manually re-plumb some of the 'wiring' that you'd get 'for free' with the UIViewController approach.
Avoid putting logic in UIView subclass.
As I think you can make grid view by using table view just simply add multiple views on each cells
at time of switching grid to list or list to grid simply check your type and reload tableview

Slide out UIViewController on IOS [duplicate]

This question already has answers here:
iOS horizontal SlideView with vertical menu
(5 answers)
Closed 9 years ago.
How do you make a viewcontroller that slides out and takes up part of the screen such as ones which may be seen on popular apps like Facebook, Rdio and Tinder? So you do a side swipe and a viewController will slide out and take up approximately three quarters of the screen and may have a tableView within it? Also, would this design be made using storyboard or interface builder?
What i used in my project was MMDrawerController (Mutual Mobile Drawer Controller)
https://github.com/mutualmobile/MMDrawerController
it provides full control and variety of effects, transitions, guestures. also you can slide the panel from either left or right side.
There are a very large amount of frameworks that do this. The two most popular ones are JASidePanels (which I personally use) and ECSSlidingViewController. You could also implement it yourself, but this will be more complicated. A place to start is to have a "bottom view controller" that loads and manages the other view controllers, or at least manages their views. If you have the patience, this route is obviously preferable as you can then really control the behavior of your app. That being said, these are great starts.
In these examples they use a combination of both programmatic management of view controllers, and the story board. It really depends on how you want to manage it personally. I personally like to "paint" my view controller basics in the story board and instantiate them using their storyboard IDs in order to give myself a good idea of what is going on visually.
You should Tate a look at ViewDeck. Just download it and take a look at it it's higly customazible and it's Identical to the facebook app

One UIViewController or Two for portrait / landscape views

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

Resources