I'm new to Swift, so I apologize for my lack of knowledge of almost anything related to Swift.
Right now, I'm developing an app that uses the ARSlidingPanel library, so now there are two ViewControllers present on the screen (Main view, with the dark background, and Panel view, which is the green background). I want to be able to set vars/call functions from the Panel view to the Main view. For example if I click a button in the panel view, I want to display some text in the main view. Right now I've started with using static vars but from my knowledge of Java/Android, I know this is probably not the right way to go. Any tips for a cleaner/more acceptable way of doing things?
There are a few different options here. However, the first thing that comes up to mind is if you really need to use two independent view controllers for the same view?.
One solution would be to use delegates. Write a swift protocol that has has the methods and functionality you want to expose, for example setting up values in the view controller's outlets, then implement the protocol in one view controller. In your other view controller, you can then create a delegate variable of type UIViewController -let delegate: UIViewController - and use that instance of your delegate to modify the view. Here's a guide on this
Even better, you can add view controllers as sub view controllers
of your view, apple provides a good bit of documentation on this, you
can find it
here.
Hope this helps.
Related
So I have a "main" View linked with my main .h/.m ViewController files.
In a process of the application, a second View is called that overlays part of my main View in a "popup" style.
I'm wondering if it's a good idea to use the original main ViewController .h/.m files for both the main View, and the second View? If not, I'm genuinely interested in why that is not to be considered a good idea. If this is in-fact a standard practice, what is the cleanest way to do so?
It's typically good practice for your view controller to "control" what comes on and off the displayed view its responsible for. If you are just presenting something very simple, it would be fine leaving it (the code) in your view controller - an example of this might be a background view with a different color.
If however, your view has many responsibilities, such as responding to touch events, you may want to create a subclass of UIView and put your code in that file. Then back in your original view controller, you would simply import that subclass and instantiate the view and present it (add subview) when needed.
Using a common pattern like delegation, your subclassed UIView would control it's own logic and perhaps via delegation, send messages back to the view controller when needed for items like dismiss, or save or any number of functions it might do. A common example of this is UITableView.
hope that helps
Is it a good practise to creates views in xcode and hide them and when required show them?
I am asking that because I prefer to create views visually and not in code.
If the view is to complex(a lot of subviews) should I create a new view controller to it?
I know there isn't a specify question here but I really need a clarification on this matter.
Regards
One of my first iOS applications had a tab bar and views that the user could switch between. Originally it was done by hiding and showing the right views depending on what the user pressed on the tab bar. This ended up being a complex disaster.
I then rewrote the app so that each tab bar view had its own UIViewController with its own set of views. That turned out to be so much easier to manage. (I also changed from using Interface Builder to straight code for creating the views, but that's beside the point and you can continue to use IB if you want.)
As for me, I prefer folowing practice:
Usually, a use storyboards,where views are placed, but if a view is complex, I create a separate XIB file, arrange all subviews there, and then in storyboard drag an UIView subclass and connect my XIB view with it.It helps to avoid mess in storyboard.
As for hiding views, I also don't recommend such practice as it can become very complex to understand your code and all those views are allocated when XIB is loaded, so the mobile developing rule "do as lazy as u can" is not met. We should try to spend as less memory as it's possible.
UIView is the best way to create iOS app, esp. if you want to reuse the code.
For example if you have same view to present in iPad n iPhone then using UIView can result in lots of similar code in View-controller
In another case if your view might need to have multiple table view it can be quite complex to handle each with delegates in ViewController. But separate view will solve this problem.
I have made my 1st open source code after learning how to use View
https://github.com/bishalg/BGRadioList
which I had learned from
http://www.raywenderlich.com/1768/uiview-tutorial-for-ios-how-to-make-a-custom-uiview-in-ios-5-a-5-star-rating-view
About the hiding view - I have used lots of hide and show view codes in my apps but believe me at one point it will become complex and unmanageable if you have lots of views.
I have a view that contains a mapview and a tableview, similar to how to the facebook nearby places screen looks in the facebook app looks.
I put the screen together using interface builder. I have outlets to the tableview and map. And, I set the UIViewController that controls the main view to be the delegate for both the mapview and table view. Everything works perfectly.
However, this main UIViewController is now pretty messy because it has to respond to methods on behalf of it's own view, the mkmapview and the uitableview. However, data is somewhat shared between the map and the table view.
I am wondering if this is where UIViewController containment comes in? Or, if I should should just make custom objects to act as delegates for those two views. I am looking for the correct design pattern to use in modern iOS. A few years ago just mashing it all into the same controller would be the way to go. Maybe it still is the way to go.
Both your ideas are good thoughts, but...
Controller containment is typically used for more navigation related purposes, like a UINavigationController.
Custom objects that do some of the delegate/datasource work, that's a good thought too, but a little clumsy to the extent that they share data with the view controller and each other. This might be a good solution especially if other view controllers will need the same delegate/datasource behavior.
A third alternative, and probably the best of the three, is to create class extensions of the view controller (see apple doc here). These can be thought of as parts of your class in different files.
I have a UIViewController having two parts:
a UIView
a bar having multiple drop down menus arranged horizontally and having thumbnail images at the top
Because second part is little complex I've decided it to be a UIViewController but now I have some concerns:
Because I have drop down menu, menu will exceeds the bounds of the bar. How can I handle it?
Is it a good way to have a UIViewController inside a UIViewController?
How can I implement a drop down menu? As far I know IOS doesn't have drop down menus.
To use a controller within another controller, you employ a custom container view controller.
See Creating Custom Container View Controllers section of the View Controller Programming Guide for iOS.
Also see the appropriate Implementing a Container Controller section of the UIViewController Class Reference.
Also refer to the WWDC 2011 video, Implementing UIViewController Containment
In iOS 6, you can set up storyboards with container views that automatically employ embed segues, saving you from needing to explicitly call addChildViewController and the like, if you're using storyboards. Check out the "container view" object in Interface Builder. If you're going to be changing the child controller, you'll have to employ the API referred to in the above links, but for the configuration of the first child, you can set that up in Interface Builder in iOS 6.
In this case, setting up a controller containment could be the right way. The only limitation is that it works for iOS 5 and greater.
Here, what you have to do:
// add as child VC
[self addChildViewController:_barViewController];
// add it to container view, calls willMoveToParentViewController for us
[_containerView addSubview:_barViewController.view];
// notify it that move is done
[_barViewController didMoveToParentViewController:self];
Here, you can find additional info Containing ViewControllers. Obviosly Apple doc is your friend. In addition, if you search for "uiviewcontroller containment" you can find a lot of tuts out there.
If your app needs to target devices where iOS 5 is not the minimum, you should rely on a UIViewController and two different views.
About drop down menus, in my opinion they don't work so well with touch interfaces. There are some alternatives, for example an instance of the UISegmentedControl class. Here you can read Apple UI design guidelines about segmented controls: http://developer.apple.com/library/ios/#documentation/userexperience/conceptual/mobilehig/UIElementGuidelines/UIElementGuidelines.html#//apple_ref/doc/uid/TP40006556-CH13-SW1. If you explain a little bit more about your desired UI functionality we could offer you a better alternative from the user experience point of view.
If you insist with drop down menus, there are some third party control libraries available out there; for example: http://www.cocoacontrols.com/
Till now, I've been using controller or controllers like UITabbarController, or UINavigation controller to manage the UiviewController hierarchy. however, in the current project, i've been presented with a situation where my friends are recommending that I do away with controller of controllers and instead instantiate sub-UIViewControllers within the RootViewController and keep them as attributes. My question is whether this is a good practice MVC wise and memory management wise? (this is for iOS 5.0 with ARC)
The project requires a screen to have a header, main content area, and footer. the header and footer present dynamic content, but are the same for all screens but in the main content area, different screens can be presented either transitioning in from the right (like navigation controller would do it) or would appear modally.
I've tried to stick to MVC with one ViewController managing one view hierarchy... the above seems to go against it, but it seems to help in the situation.. so is this the right way to go or am I missing some other more optimal way?? Pls help
Thanks for your help in advance..
Why even have to have references to the view controllers themselves if you can just keep a reference to the view they manage? Sure it breaks MVC, but I love being able to divide reusable interface classes and then simply add their view's as subviews. It works, so long as you are smart about the whole thing. Is there anything specific about this pattern you'd like help with?
Go through this blog..Hope it helps you,
http://borkwarellc.wordpress.com/2010/07/22/qff-kitchen-mvc-part-1/