Using single storyboard views for static table view in iOS5+ instead of using storyboards for the entire app? - uitableview

Recently I was searching for an useful approach for static table views without using storyboards for my entire app. I found this answer:
Static table view cells are only available when using storyboards. However, if you aren't using storyboards for your entire UI you can still use them for individual screens instead of a collection of strings.
To do this you can create a UIStoryboard file with a single view controller on it that has it's File's Owner set to your custom view controller subclass. Set the VC's identifier to some value. When you want to display this, get the storyboard and then instantiate your view controller subclass by creating the VC from your storyboard.
Is it a good approach? Or is it better to implement it the iOS4 way?
What should be preferred in case of performance and maintainable code base?
Thanks

Maintaining code base is pretty easy in Storyboard for static pages.

Related

Creating component of UICollectionView/UICollectionViewController by using Xib and Implement it in UIViewController

I'm trying to develop a component of UICollectionView or UICollectionViewController which I can use multiple time in my current project and also can be used anywhere by simply copy-pasting whole folder.
Requirements:
- Create an Xib of either UICollectionView or UICollectionViewController (which one is easier).
- Embed that CollectionView xib in my UIViewController, In my that UIViewController there are some graphs and also some pics that I've to show(collection view is for that).
- Basically I want to send a JSON file and some parameter if needed to that component and make the collection view running within that View controller.
I'm facing a lot of problems embedding both of UICollectionView and UICollectionViewController so what should be the best way and proper approach to do it?
You could use a container view to embed a view controller inside another view controller.
This is from Apple documentation:
Container view controllers are a way to combine the content from
multiple view controllers into a single user interface

What is the reason for storyboards?

New to iOS, just wondering if someone could explain the point of the storyboard.
If i create a view controller and programmatically add to it, what do i need a storyboard for?
Is it only for custom views? custom tables? etc
Thanks.
Long story short, my understanding of storyboard purpose is as follows:
Less code -> less bugs
Visual representation of UI layout simplifies UI creation (views hierarchy, autolayout constraints)
Extremely simple way to set objects' properties (e.g. delegates, gesture recognizers) just by control-drag
From Apple's Document:
Storyboards
Storyboards are the recommended way to design your app’s user interface. Storyboards let you design your entire user interface in one place so that you can see all of your views and view controllers and understand how they work together. An important part of storyboards is the ability to define segues, which are transitions from one view controller to another. These transitions allow you to capture the flow of your user interface in addition to the content. You can define these transitions visually, in Xcode, or initiate them programmatically.
You can use a single storyboard file to store all of your app’s view
controllers and views, or you can use multiple view storyboards to
organize portions of your interface. At build time, Xcode takes the
contents of the storyboard file and divides it into discrete pieces
that can be loaded individually for better performance. Your app never
needs to manipulate these pieces directly. The UIKit framework
provides convenience classes for accessing the contents of a
storyboard from your code.
For more information about using storyboards to design your interface,
see Xcode Overview . For information about how to access storyboards
from your code, see the UIStoryboard Class Reference .

Create View Programmatically in Objective-C Xcode 5

How should I go about creating a View for the storyboard programmatically? I want to access the labels from the first ViewController object made(automatically to call the IBAction methods of VC). I know that this first object of VC is the one linked to the view in the storyboard(?) and I need to change a label form another file, besides VC. I'm pretty sure the only way to do so would be to access the VC object that is linked to the view, or create one and not go with the default one that is created. If not, how would I go about accessing the labels of the view from another file?
You don't create storyboard objects programmatically. A storyboard is very basically an XML file Xcode uses to call different view controllers. The biggest advantage of using storyboards over NIBs is you can layout transitions or segues, and the advantage of NIBs or storyboards over initiating view controllers by code is obviously the visual interface. So your question doesn't really make sense.
If you want to reference a particular view controller's label from your storyboard you need to create a pointer to that view controller first, but changing it programmatically doesn't make sense because that's what storyboard is for.
That said you may just need to go look for your class name in your view controller's Identity Inspector in storyboard and then edit your label programmatically through an IBOutlet property.

iOS PageViewController with different page layouts using storyboard

I am trying to use the PageViewController with different layouts but I dont know how to accomplish that. Currently Im using the page-based application provided as a template for new projects in XCode 5 for iOS. This application uses the same view controller for all pages, and I want different pages. Is this even possible? And how can I add a different view while using this template and storyboard. I couldnt find any tutorials that uses storyboard and adding different pages.
I have also tried UIScrollView with paging enable. But those tutorials I found required to turn off auto layout in settings, such as this one:
http://www.iosdevnotes.com/2011/03/uiscrollview-paging/. And that is not the correct way of doing it.
Since I havent found any examples, I start to wonder if this is even possible to do in a simple way?
I don't think this is possible using storyboards in the straightforward way you want, but it can be achieved with relative ease. You can create all your different view controllers in the storyboard (these will serve as pages) and give them identifiers. Now in code, have the view controller that displays the page view controller be its data source.
Now, in – pageViewController:viewControllerBeforeViewController: and – pageViewController:viewControllerAfterViewController:, implement logic that decides which view controller to load, and use the storyboard's – instantiateViewControllerWithIdentifier: to return an appropriate view controller.

Using multiple nib files with a single view controller?

Background
I'm using interface builder to create the UI for an app I'm working on. The app has a single screen that displays a series of buttons. Clicking on a button displays an associated view which overlays the buttons. Clicking another button hides the previous overlay view and displays another one.
Too make managing the UI easier in IB I've decided to create multiple nib files for each sub view that is to appear when clicking the relevant button. I'm then loading the sub view's nib file in the view controller's viewDidLoad method using the UINib class.
The idea behind this was to avoid having multiple views stacked on top of each other in a single nib file as this would be hard to manipulate in IB. I could have created all the views in code but this would require a lot of tedious coding as the layouts of each sub view are quite complex (with multiple child views).
Example code loading a sub view from a nib file.
- (void)viewDidLoad
{
UINib *aSubViewNib = [UINib nibWithNibName:#"aSubView" bundle:nil];
NSArray *bundleObjects = [aSubViewNib instantiateWithOwner:self options:nil];
// get root view from bundle array
UIView *aSubView = [bundleObjects objectAtIndex:0];
[self.view addSubview:aSubView];
...
The code above is repeated for the other views.
To summarise I have a single screen iPhone app that has layered views that are shown/hidden by clicking buttons. This is achieved with a single view controller with an associated nib file and a series of additional nib files for the sub views which are loaded in the view controller's viewDidLoad method.
Questions!
Sorry for the long introduction but I wanted to be very clear what it is I am doing.
Is my approach bad or unusual?
Are there any potential issues to doing it this way?
What have other people done when they need a dynamic interface and
still want to keep everything in Interface Builder?
Notes
Before anyone asks why don't I just display the sub views on a new screen and use the navigation bar, let me say that I have very good reasons and I do understand iOS UI guidelines. The above use case is not exactly my use case but it's one that clearly describes the problem without getting bogged down in my development app.
Also I know I could have written all the sub views as code but each sub view has a complex layout of child views and it would be a lot of code and messing around to try and get them looking right.
Thanks in advance.
There isn't necessarily a 1-to-1 relationship between view controllers and views. Most views contain many subviews, which are views themselves, so this literally doesn't make sense.
However, depending on the complexity of the views (including their content), you may want separate view controllers... or not.
For example, if you have two sbuviews that are each tableViews, you may want to have one view controller for each tableView. This is because each tableView is looking at the same delegate methods, and if they are in the same viewController, then the delegate methods have to differentiate between the tableViews. The delegate methods have signatures that allow this, but, in my experience, it can really make for a messy code design that is hard to follow and hard to manage.
On the other hand, you may have two tables that are managed by the same viewController, where one table is filled with meaningful data and the other is simply a place holder (as when the data source is empty). One might be visible while the other is not. Why make you life complicated by creating two view controllers when both are driven by the same data source (the model)?
In my mind, it comes down to how difficult it is to follow and manage the code. If the complexity of using a single view controller becomes burdensome, consider using more view controllers.
UPDATE
By the way, I have an example that I am currently working with that may illustrate a similar situation. In the InAppSettingsKit, that a lot of developers use, there are several xib files for pieces of the main view. You can look at the structure here on github. There is one main view controllers and several xib files. (There is also what I would call a "helper" view controller and an email composer view controller.) In this example, the xib files may be used multiple times to specify the layout of table view cells. There is no view controller for each xib file, though. (The documentation for InAppSettingsKit is sparse, so these things may not be obvious just by taking a quick look at it.)
Every View should have a corresponding UIViewController. Using one ViewController to "Control" more than one view breaks the MVC paradigm. "Controlling" multiple "views" from one controller will make it much harder to change one thing without breaking something else. The choices you make on how to present the content to the end user will be different for every individual. So if you say a NavigationController won't work in your case, maybe a Modal view is the answer or, you might just instantiate your custom UIViewControllers and add them to your view ([addSubview:]), if thats the road you want, but like I said, it would be beneficial for you to make a "controller" for each view object along with the corresponding xib. If you need information sent back, use a delegate or use Notifications to send the message back to the parent view. I learned the hard way that not following MVC paradigm, will make you life miserable. Try and keep your code as decoupled as possible. And read up on the MVC design pattern, you won't regret it.
actually its possible to do this.
Open your .xib file,select File’s Owner(in placeholder) -> "identity inspector" (utilities) -> change class name to your controller classname -> press control and drag file's owner placeholder to View object, select "view" in dialog.
Now you can customize your view.
p.s. you can use the same outlets as first xib, you need only to drag them to the new xib(+control sure).
here is an explained tutorial:
http://irawd.wordpress.com/2013/09/05/how-to-link-a-xib-file-to-a-class-and-use-2-xib-files-for-iphone4-and-iphone5/

Resources