How can storyboard handle two segues for a table cell? - ios

I'd like a master/detail kind of UI, but with the option of going to a different detail page depending on the data in the table cell. Can storyboards do this? If so, is there a tutorial or somewhere that explains? As an alternative, if I mix table cell types in the same table, can I define different detail pages that way?
Also, just an observation, does anyone find the Apple tutorials get very complicated very quickly? I'm having trouble trying to get through even with the first iOS app tutorial. So many control clicks and command drags and whatever and to non-intuitive targets. Like, who would expect a drag from a graphical element to a specific line in a source file? It doesn't make any sense.

I think what you're looking for is didSelectRowAtIndexPath. In the .m file for the view controller you have your UITableView on, whenever the user clicks a row, it will trigger the code in didSelectRowAtIndexPath. Typically, you have an if block that checks which row was clicked, and does different things (like display different detail views).
As far as detailed tutorials, I find YouTube to be the easiest to learn from, especially for simple or common tasks. If you search for "Master-Detail Xcode" on there, I'm sure you'll find tons of results ( http://www.youtube.com/watch?v=S_J_r8AKw0k I think was one of the ones I found useful).

Related

How to create a table in swift with segue?

I'm brand new to Swift but I want to create an app that has a table and each entry in that table will lead to a new screen (but this new screen is the same for all the table entries) but depending on which table cell you click on, that screen has different information posted on it.
What are the steps I need to do to complete this? I have my story board I'm just not sure how to put this all together with code
Thanks in advance!
Well your question is very broad and not very specific. Therefore it is not easy to give a helpful answer. What I would do:
Create a UITableViewController that holds your "table".
Define a UITableViewControllerDelegate for the UITableView that will be informed about UserInteractions (especially when the user
didSelect a certain row of the table).
Based on the specific row (that was selected) you can create a second UIViewController class the shows your intended information.
I can not show some code samples because your question is to broad and things depend on a lot of things (especially on the kind of data you want to show) and how you implement your UIElements on the ViewControllers in InterfaceBuilder.
And if you are not yet familiar with the concept of a UITableViewController and its Delegate, than you should find some tutorials first about that basic technique in developing iOS apps.
You want to use the master/detail pattern. I suggest doing a search on that.

Parse PFTableViewController vs regular UITableView with PFObject as data source

I am new to iOS development, and I have been doing a fair amount of research. Unfortunately, as the title of my post suggests, neither possibility seems exactly suited to my needs.
I need a lot of customization with respect to the look and feel of each individual table view cell, and I need for my table to have header sections which are clickable. I would actually like for the section headers to have the drill down quality and not the cells beneath each section header.
To my knowledge, the problem with PFTableViewController is that it doesn't easily allow for multiple sections (even less so if I need for these section headers to be clickable and of a different look and feel from the regular cells.) Furthermore, customizing the PFTableViewCells doesn't seem terribly simple either.
However, if I use the regular UITableView even with Parse as my backend, won't I run into some difficulties with respect to loading, pagination, etc...?
I have a pretty good idea of how I would implement this app with regular UITableViews so I guess here is my question: is it worth it for me to try and figure out all of this PFTableViewController stuff?
I should also mention the fact that my table view controller will not take up the entire view but only half of the screen.
Thanks in advance for any and all advice
It seems that a normal UITableView will suit your needs. If you want to customize the look and feel of individual cells, you can just subclass a UITableViewCell and modify it.
In terms of your needs with the headers, it's hard to say without knowing more about your app, but you want to follow standard user interface conventions. Users don't expect headers to be clickable. Instead, they attempt to traverse information hierarchies by selecting table view cells, which then bring them to new views with more information. Based on your, needs I think that a standard table view controller with some customization is what you want.

When I transfer from my master view to my detail view after adding a new item, my detail view is empty

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

iphone/ipad how to handle lots of input fields?

I'm writing a app that contains quite a bit of input fields for collecting data.
and im wondering what are some good methods to display these kind of input fields, if there are too many to fit on a screen? so something like the add contact screen... where u can scroll down and there are fields there
my initial idea is to put them in a scroll view and then i can scroll through them, is there a tutorial to do this? it seems like the scroll view is more for dynamically displaying data like a text view, and not for static forms like i was describing.
if anyone has any different methods for doing this please post.
UITableview will match perfectly for what you need.
My friend wrote this which is a container view that automatically helps with moving fields out of the way of the keyboard - It will certainly save you some time if you don't want to use a UITableView:
https://github.com/mackross/GTKeyboardHelper
The other way as H2CO3 suggested is to use a UITableView. If it is a UITableViewController, then you get the moving out of the keyboards way automatically. You could build custom table view cells that are styled to have a prompt and a UITextField for input. You can also set the selectionStyle to UITableViewCellSelectionStyleNone to prevent these cells from highlighting when selected.
I think the third way is to do this with a UINavigationController (or a UIPageControl) and build a kind of wizard, where you go through various pages of related data. This might be the neatest way depending on how many fields you have and if you can group data into common sets (e.g. personal information, work information etc)
I had the same problem and found GTKeyboardHelper to be an easy way out.
After drag and drop the framework in your project, include the header file.
Download and open the example project, then drag the "Keyboard Helper" object from the objects section in the xib to the objects section in your project's interface builder.
Drag and drop all your views to be children of the "Keyboard Helper".

Two Tablew in One Screen

I want to have two tables and a webview in one iPad screen from the following:
The first table will parse items from an RSS feed, and will have an option for a
checkmark
The second table will be comprised of all checked items
The webview will be the content from didSelectRowAtIndexPath from the first table (so basically the first table gives the opportunity to display content from didSelectRow, AND check a box (or whatever) to create the secondary table.
I am told for the second table, I should have the checks write to a plist with NSMutableDictionary, and then the second table will just be a table of the plist...but really, what's the code for this?...where do I put it?...etc etc etc. And if the user unchecks the items, the line in the plist will be cleared, right???
I PRESUME I can show all three classes in one screen with something like
[viewController.view addSubview:someOtherViewControler.view];
Is there any reason why I should not do this??
Thanks so much!
XOXO
There is no reason you shouldn't do this, and you will be happier with your proposed approach than you would be if you tried to do it all with one view controller.
Organizing with design patterns is done to simplify design and maintenance of your software. What you have described is clearly three independent data sources each with their own independent views. You can use the MVC design pattern independently on each one of them. This independence lends itself to having separate view controllers that are easy to design and maintain.
The fact that they are collected into one main view for your application is outweighed by the simplification in maintainability that you will obtain with separate view controllers.

Resources