Based on the little that i know, I tried to put together the relationships usually seen as part of MainWindow xib.
How far off am i? Kindly correct and advise.
Almost. View controllers inherit from uiwindows in the class system. And you have to think of it more like a pie chart. Everything is equally important, some are just more equal than others. On the top of the pie chart is the app delegate. It's the master of the app. It can reach into a view or Controller and pull whatever it wants. Now on the left side is a view. It's the dumb little sycophant of the whole thing. It can only recieved instructions from itself, or from the app delegate, then act on those instructions. It should never pull from the app delegate (not never, but most always) and DEFINITELY should never screw around with a controller. Finally, controllers. They are the brains of the whole app. They can't show information on screen like a view, but they can think pretty well. Controllers give the orders in your app. They shouldn't really pull from the app delegate, but they can (again, rarely). There's an excellent lecture from Standford or MIT (I'm forgetting now) in iTunes U about it. Look it up.
Related
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.
Thinking it over, this feels like a bit of a noob MVC question, but I can't come up with or find a definitive answer so I feel I should ask and get some clarity for myself.
I have a custom view that I created using a xib. It is going to be used in, currently, 4 other places in my app. Each usage has identical functionality, so I'm basically just creating a custom control object that I can reuse multiple times.
My "control object" consists of a UITextField, and two UIButtons.
The functionality I'm looking at implementing is, the first button will bring up a UIPicker and the 2nd button is essentially a done button and will just resignFirstResponder on the UITextField. As previously mentioned, this is consistent everywhere this will be used.
What I'm curious about is, is it ok for me to build this functionality directly into the custom UIView subclass since it is consistent behaviour for all instances of my control object? Or, do I need to create a custom UIViewController subclass to go along with it?
Currently, in my main UIViewController for my app I am creating instances of my custom UIView "control object" and treating them the same as any other control object. If I should actually be creating a custom UIViewController class to go along with it, well, I'll have more questions for another thread as to how I should be doing that (unless someone can direct me to a resource on this)
So far, searching the web has yielded nothing for me and from everything I've seen so far with iOS development in general, I've gotten the vibe that UIViewControllers are really only ever for a main, presentable view (that takes up the entire screen.. I might be missing some terminology for this).
My gut feeling is that no view controller is necessary in the scenario I'm describing, but I'd like to try to get some sort of confirmation, if possible.
There is no silver bullet, so no approach is absolutely right or absolutely wrong. What you describe here is just a view that changes its states. So putting everything in your UIView subclass is completely OK. It also conforms to the KISS principle.
However, as far as I understand, and correct me if I'm wrong, the input of your custom view - the text and the picked value from the picker does not really affects the view itself, but the viewController it's attached to. So you need to pass that input to the hosting viewController. This can be achieved by protocol with a default implementation. So the handling of the input data is written only once, but can be attached to whatever viewController you want.
Based off of everything that you've said, I see no need for another view controller. I can see where the answer could be a little unclear considering that the actions are something that ViewControllers usually handle, but I think you'll be just fine letting your custom view handle this by itself.
If you add more functionality or more complex operations, then perhaps it is time to explore other options but for now I think the single view will be fine.
I'm making a sample app to learn iOS dev, and I have the app create default items to populate the tableview originally, and you can add further ones as well.
If I tap on the default ones (well, there's only one) and segue to the detail view it shows all the details (Name, Location and Date) as intended. But if I add a new one, it comes up with those fields being Empty.
I can't figure out why. I have seemingly all the view refreshing methods set, and it should be setting the detail view's data object which then feeds the labels.
Could anyone help? I'd supply further code if requested, I just don't know what to supply now as I'm not sure exactly where the problem is. It's a rather simple app, though.
Project available here: http://cl.ly/3N0o272M3y1K
Ok this took a bit longer than planned - but it is a good way to learn.
I have attached the project in a zip file.
The code is a bit different then what you posted, but if you compare them side by side, you will see how they are planned and build differently.
It shows the Segue working within the Storyboard.
There where 2 big problems with your project outside of your misuses of the methods.
You need something like Core Data if you want your data to be persistant. In the example I have given you I have used Plist, this will do the trick, but is not persistant in this case.
Also your detailViewController had no labels for the text to appear, so you will need to look into Custom Cells for that - to match your design.
Good Luck and I hope this is useful:-)
Updated Project
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.
I'm making a role-playing game, and I want to have a Map View and a Battle Screen. With the possibility of other screens as well.
I thought the best way to achieve this was to use multiple NIB files.
When I prototyped this by have one view that creates content, switching to the next view, and then back, the content on the original view was reset.
How do I make it so that the first view doesn't reset the data each time it's loaded?
Your question is a little vague. A view usually does not get "reset" unless you run into a low memory warning. That said, even then it's just up to you to keep the right references and setup your view correctly. Maybe have a read through Apple documentation or provide some code. Adrian also has a good write-up about this.