I have a grouped UITableView in class A and if you select a row in section 0, I want it to open up to another UITableView. In the first view, I have a lot of other methods and buttons and custom designed stuff, so I don't want to create another XIB for the other table view since I'll have to copy over all the methods and custom designed stuff. I was thinking creating another XIB, but subclassing the class under the original class A this way I can use the methods of class A without having to redefine them again in the new class. But I'm having problems with this. Is there a better way? Can I have two table views in one XIB, and just hide one till the other is called up? But that seems a little messy..
If you simply try subclassing the existing viewcontroller it will have the same info for the selected row, hence it would have to grow exponentially in order to make display the right UITableView.
If your concern is redefining methods, then simply create a class that will hold those particular methods and include it in the UITableViewControllers that will be using them, that way you will only define it once. This way you can simply create a new UITableViewController and push it into a navigation controller everytime you select a given cell.
As an alternative of showing all options within one UITableView you can try the following: you can probably try adding a UIScrollView inside the UITableViewCell. I would make it scroll horizontally while keeping the UITableView scroll vertically.
Related
This might be a very basic question, but I could not find the answer yet.
I have a UITableView that acts as a menu for my app. Each row on the table view, when selected, opens a different subclass of UIViewController.
At the moment my code works the same way used in the UICatlog example from Apple.
In the main view controller (the table view), each menu item is described in a dictionary in an array (menuList). Each dictionary contains an instance of the UIViewController subclass for that screen and other data about the menu item. When the user selects a row, the didSelectRow atIndexPath kicks in and calls the appropriate view controller, stored in the dictionary at that indexPath.row of the menuList array.
It seems to be very wasteful to alloc and init every single view controller when the table view first loads.
My question is: Is there a better way than the one demonstrated in UICatalog to alloc/init my view controller sublasses only when the associated row is tapped?
(I know I can use a complex if..else structure in the didSelectRow, but this results in an extremely long didSelectRow method and breaks encapsulation. I wonder if there is a cleaner way to do this, allocing and initing the appropriate view controller based on data from the dictionaries)
user1349768 try to use Storyboard, but this feature only works in iOs 4 and higher.
Just a suggestion ... put some reference to each view controller into NSArray and then initiate and segue to them when the row gets tapped on (and just get the reference from objectAtIndex:).
Although I could not find a better way to do this, the memory signature of each allocated View Controller is only 288 bytes. Since the solution suggested by apple is a lot more elegant and scalable then using a switch case statement, I left it as it is.
I want to implement custom search and have one trouble. I need to combine UIButton, SearchBar in one control in order I can refer it by pointer.Then i will dynamically add more UIbuttons to that combined control.And the most important I want to manipulate this combined control as one program entity. For instance,CombinedControl* control;
So what the common way to implement this? Or may be I can emulate this?Thanks in advance!
If you're looking to combine multiple controls into a single unit, the simplest thing to do is just to add them as subviews of a single UIView. You can do this either in Interface Builder (by creating a blank UIView and dropping the other controls on it) or in code (using addSubview:). Then you just have a variable that points to the UIView that you added everything to.
If you want to add behavior to the "combined control", then you should create a subclass of UIView (as H2CO3 suggested above) and add the controls to that view subclass.
Currently, I have an NSStatusItem that, when clicked, shows a custom view below it. The view contains some information and text fields. What I need is for a separate custom view to merge with the first and appear below it, as in further down the screen, not on top or behind the original view. This needs to be a separate view because there are actually several custom view that will be appended depending on what the user does in the first view. I would like to be able to independently add or remove each of these without affecting the others. I've dug through apple documentation but I haven't found anything about putting one custom view inside another programatically.
NSView has an addSubview:positioned:relativeTo: method you can use to add and order views to appear above or below each other. Use superview: to access this method on a container from any of its subviews.
Edit:
Try adding both views to an NSSplitView with a hidden divider. To hide the divider, subclass NSSplitView and override the dividerThickness: method to return 0;
I'm creating an iPad app based on a UINavigationController (with the bar hidden) so I can push and pop other viewControllers for navigation around the app. However, I am now wanting to add a section in which there are two viewControllers that I want to be able to switch between, so in other words they are side-by-side, rather than hierarchical.
Is it okay to use a UITabBarController for this? I am aware that on the iPhone it is recommended they are used only at the root level of the app, but since this is an iPad app I wondered if I could use it? Also, I guess I need to create an empty viewController, create a UITabBarController within it and set the delegate to it, then add the two viewControllers to it... So in effect I will have a viewController within another viewController, and when I have done that in the past the results have been very flaky.
Can I do it this way? The only other way I can think of doing it is to have two plan UIViews within a UIViewController, but that also means I shouldn't really put any business logic in them (bad MVC!), and not being able to will be a right pain in the a**.
Any ideas?
Thanks!
:-Joe
EDIT: I also need to be able to swipe-animate between the two VCs within the TabBarController, AND have a menubar over the top which doesn't animate... Can I do this?
Sure.
I do this kind of thing all over the place in an app I'm working on. I actually have several different types of "toolbars" that can be optionally shown at different times.
What I do is create a "parent" member in my toolbar's class - and when a button is pressed, I have the toolbar call a method in the parent class to do whatever needs to be done - (i.e. display another view).
This avoids the whole mess of creating a view inside another view (or viewcontroller inside another viewcontroller - or whatever) - the toolbar can take the button hits, but all the views are opened by the root view/controller.
Hope this helps/makes sense!
I have a UINavigationController. In its toolbar is a segmented control with two buttons. Each button relates to its own UITableViewController.
What I'm trying to achieve is someway of wiring up the navigation controller so that the views are switched depending on which button within the segmented control is active.
I assume I should hold on to the table controllers, because I want to preserve the scrolling position within each view, e.g., if the user was positioned at the top of table 1, and the bottom of table 2, then this information should be preserved when switching.
Any suggestions would be gratefully received!
Would it be possible to just switch the dataSource instead of having to deal with two separate table views? Preserving the scrolling position can still just as easily be done, and you end up using less memory (one table view and two data sources instead of two table views and two data sources).
With only 128MB to spare, memory efficiency is king on the iPhone.
Joel's suggestion is a good one. Another possibility is to use two different UITableViews in your view controller, and swap them out manually. There's nothing special about a UITableViewController; it's just a UIViewController with its tableView setup for you. Use a standard UIViewController, add two outlets for tables, hide one, and swap them when your UISegmentedControl is toggled.
I've used Joel's method. Very efficient.
Use the segmented control to call a method that sets a sets a variable, then sends [tableView reloadData].
Then the tableView: numberOfRowsInSection: and tableView: cellForRowAtIndexPath: retrieve their data depending on the value of the variable set by your segmented control's method.