I have a TableView managed with CoreData and NSFetchedResultController. I want to add a TabBar to my TableView and add some items like: favourites, search and something else. Do I need a ViewController for each item? or Could I add each Item to a function in the tableViewController and manage the fetch queries there and reload the Table with the new fetch query?
Is this better to be manageg with a ToolBar instead of a TabBar?
You probably want a UITabBarController as it works with an array of child ViewControllers. You can write a custom container controller (more work), but I'd first read through the docs to get a better handle on how it operates and see if that's what you really want.
https://developer.apple.com/library/ios/documentation/uikit/reference/UITabBarController_Class/Reference/Reference.html
Related
I am having a collection view and its collection view cell. Is there any possibility to add a collection view within that collection view cell? Can anyone please help with this.
Yes, you can do that, though i might be tempted to use a table view where each cell has a collection view in it.
I'd also look at creating a view controller to manage each cells content and making those controllers children of the main VC.
Be careful how you reuse cells and how many child VCs you keep alive or you might use too much memory.
Still completely new to this whole xcode thing so bear with me..
Im using xcode 4's 'master-detail' template with core data. When you click a cell in the table of the rootView, it segues to a detail view passing selectedItem as managedobject "detailItem".
I want to add a "next" Button (or a swipegesture preferably, if possible) that will display the next cell/detailItem, from the table in rootView, in the detailView
(exactly like the notes.app)
Do i need to recreate a fetchedresults controller and pass the objectIndex then fetch index+1 And display that as next object?
Or is there an easier more efficient way that wont drive me crazy trying to fabricate???
any help would be Most appreciated. And hopefully detailed as i would barely understand it
I would create a delegate relationship between the master and detail view controllers. If you don't know how delegates work, check documentation in that link, and plenty of good tutorials are a Google search away… this one's not bad. Here's the high-level approach:
On the detail controller, you'll create an (id) delegate property, and a "DetailViewControllerDelegate" protocol with methods like -(BOOL)detailViewShouldShowNextItem:(DetailViewController *)detailViewController and a similar one for previous.
On the master controller, declare support for the protocol in the header, and then implement the delegate methods so that they select the previous or next item in the list, loading it in the detail view.
Finally, after the detail view controller is instantiated, set its delegate to be the master view controller.
so i want to achieve something like this:
when clicking on this cell, there should pop a new tableview with the items availible, by clicking one of these items, it should go back and update the cell. normal stuff i think.
but i'm not shure how to do it the best way.
first i need to subclass a uitableview cell , because there is no default one for this, right?
and the rest?
should i set an ivar to the new popped tableviewcontroller with the selected cell and update the content after an item was selected? but then i had to reload table data , don't i ? wouldn't this break my selection, the scrolled way and all this stuff? would be a bit weird while the navigation-controller goes back to this tableview.
please help me with some best practices for this.
thanks and please leave a comment if something is unclear.
That cell style is UITableViewCellStyleValue1.
I would write a custom delegate protocol that the parent controller implements so that the child controller can inform it when the user has made the selection. But you can also use a property on the child controller. Or use a notification.
To update the cell in the parent view controller, just call [tableView reloadRowsAtIndexPaths:withRowAnimation:]. No need to reload the entire table.
I am new to iPhone development, and I am working on modifications to an existing iPhone app. The high-level overview of the issue is this.
I have a button displaying a pop-up containing a UITableView.
I'd like to click on a menu item and display a second UITableView with sub-items, including a back option. If the user clicks back, they go the original UITableView. If the sub-item has additional sub-items underneath it, it should (when clicked) launch another UITableView with these options. There is also a back button as a menu item that will allow the user to navigate to the previous menu displayed.
The challenge here is that I am not using a navigation controller. the original developer only wants to add UITable Views to the stack, add transitions between them as you go from one menu to the other. Most of the tutorials I have seen and tried utilize a navigation controller and Interface Builder to associate the UITableViews.
Right now, I have an XML data source populating the menu, and when I click on a menu item, the titles change correctly, but still uses the same UITableView to display the options - this has consequences of course, as some of the sub-items may not fit on a screen.
any thoughts on how this can be done? I can post some code if necessary, although I think the general description should be able to ring a bell with one of you smart guys!
This can be done in numerous ways.
I haven't done this first one, but you can probably create a UINavigationController and set its view to the appropriate frame (inside the bubble) hide the navigation bar and set the action of your back button to pop the current view controller.
Another method is to have multiple tableviews on one controller, the delegate and datasource methods have the UITableView as an argument so you can distinguish them when setting the height of your rows, headers etc and when returning a UITableViewCell.
The way I've chosen to deal with such configurations is to have one UITableView and have only the datasource change. When you reload, insert, delete rows or reload the whole table, you can change anything you want depending on the current datasource level. The easiest none animated way is to reload the whole table.
a) If your "options" go off-screen height wise (you want fixed height) table change the - (CGFloat)tableview:(UITableView *)table heightForRowAtSection:(NSInteger)section return value
b) If your "options" go off-screen length wise either make your cell's default textLabel flexible: cell.textLabel.adjustsFontSizeToFitWidth = YES; cell.textLabel.minimumFontSize = 14; or have custom cells (lookup subclassing UITableViewCell, which is recommended) for each datasource level.
If you subclass TableViewCells remember to have different dequeue cell identifiers for each level, so the table doesn't provide you with another level's cell class.
For the "stack" of tableviews or datasources, you can have an NSMutableArray with addObject for push and removeLastObject for pop.
For animations, UITableViews can animate their rows/sections for 3. (see documentation for insert, delete, reload - Rows/Sections UITableView class reference), for 2. you can even have UIView (if not CoreAnimation as Grimless suggested) animations, that move the current tableview to the left (setFrame:) and the next tableview from the right (setFrame offscreen before animation and then in place in the beginAnimation-commitAnimation clause), but make sure you add the tableviews in a container view (the bubble interior) that clips its subviews.
Oi. This is gonna be a tough one. My suggestion would be to maintain your own stack implementation. Then, use CoreAnimation to add/remove UITableViews from your main view controller to get animated effects. So whenever the user clicks on an element in the current table view, the appropriate controller creates a new controller and table view, and then your custom navigation controller pushes the old one onto the stack, removes the old table view from the main view, sets the new controller as the current one, and adds the new table view to the main view. Kinda messy, but I think it will work.
I have a UIViewController that should be capable of displaying tableViews with multiple data sources. The UITableView spans about half the size of the screen, and there is and up and down button that allows you to go through different data. Everytime the up and down button is hit, I'd like to ultimately use UIViewAnimationTransitionCurlDown or something similar to display the next UITableView.
The question is: do I need multiple UIViewControllers to do this, with a tableView embedded in each one? Should I just create one instance of UITableView and change its data source when an up or down button is hit? If it's only one instance of UITableView, how do I manage to get a curl transition over the portion of the screen it takes up to make it look like a new tableView is coming in?
Why not have each table view belong to its own UITableViewController, and nest these within the current screen's view controller? This way the screen's view controller is responsible for swapping out its subviews, each of which have a table view controller containing the necessary logic to show their data.
In the end, it comes down to what your functionality and data sets look like. It may end up being easier to implement the table view datasource & delegate code once, injecting an actual data source into this class - or it may be easier to write custom datasource code for each table view.