I'm new to IOS development, I have a few questions.
1) What's the purpose of property rowheight on table view cell, I mean it does nothing even if I change its value, it always takes the value from its parent view i.e a tableview property rowheight? It visually changes in the IB but nothing happens when I run the app.
2) What's the purpose of Content View why is it even there? Let's say If I have to make some image equal to the height of the cell it restricts me. Or is there any way a content view can be changed to be equal to the cell height & width? I have to put constraints on the image in relation with the cell which is not the immediate parent of the image and I don't know if this is the correct way to do it.
3)How does Xcode Autocomplete works? like if I want to write a function tableview(_:tableview didselectrowwithindex:IndexPath) and I type tableview it shows a list, what to do next? I mean I can't type the whole fucntion with params or find the func in the huge list.
The height of the cell set at the IB is primarily used for simulation, the views described at IB are normally resized when actually used. E.g. you can set rows height to be 100 for the table view, 30 for some of the cells and keep the whole controller simulating a nice screen of iPhone 6. The same view will be used for all devices and will be scaled accordingly as well as the cells with the help of your delegate.
The content view is there for the reasons directly related to your additional requests. It holds all the content while there other views that accompany your content and are part of the cell like separators, accessory views, slide action views. Without a content view the responsibility of managing all the additional parts would most likely fall on you as a developer and while you might think that that is fine at the simple layouts, a simple enhancement to it would make a huge impact.
Fuzzy autocompletion at Xcode seems to be something Apple is working on now. If you can't wait and find it too difficult to navigate through the list, there are Xcode plugins available that provide fuzzy autocompletion.
Answering the question in the topic:
example: tableview(_:tableview didselectrowwithindex:IndexPath)
if you write tableview it will show all the symbols that start with tableview. For functions, it will show all the functions sorted by the second parameter name (didSelectRowWithIndex).
[EDIT]
it will autocomplete as far as the answer is unique and then show you a list full of options. I don't know any tricks to skip looking through the massive list. But after a while you'll know what you're looking for and it gets faster.
[\EDIT]
when you press tab, it
by the way: the delegate functions names start with the name of the object they're related to.
So UITableViewDelegate functions start with tableview.
as for your first two questions there are tons of answers for those questions on SO. This one seems closely related to yours.
Related
I'm trying my first steps in iOS development, and so far my app is going well. However, I've reached the point where simple UITableViews are just not cutting it.
For starters, I have a table view with two sections. I've implemented the method providing each section's title. But when I compare it to, for example, iOS's Settings screen, Apple's style (which I've seen implemented in other apps) looks much better, with better styling in the "section titles" and complex controls in the "table cells":
Now in my app, in some screens I would like to implement something similar to WhatsApp's settings screen. In this case, each "cell" does not have anything very noteworthy layout-wise, but I like the spacing between the different sections:
My last question is: when I am composing a cell, it is very clear to me how to implement a layout, its constraints, etc. Now imagine that I want to show a Table View showing a list of teams, and for each team I want to show the team players underneath, one player by line. It is not yet clear to me how I define layout contraints with an arbitrary number of elements. How would I approach doing this? Grid inside cell?
To sum it all up, my question is: are these screens TableViews with fancy styles and cells and more complex implementations? Or a different View that I am not aware of? Or even an empty canvas that they then compose "by hand"?
For context, I am developing with XCode 9, Swift, on a project with storyboards.
They are custom UITableViewCell cells (like the volume and profile avatar) or standard cell prototypes (WhatsApp settings are UITableViewCellStyleDefault with cell.imageView.image set.
So I have a unique iOS project (read as clients accepted a design before I started working here and the design contains checkboxes, dropdowns, tabular data (rows+columns,etc.) which requires a long tableview which contains 3 sections, the sections themselves vary from 50-700pt.
It appears this wasn't something Apple took into account as the table view does not scroll properly to all cells, specifically, when the keyboard is not yet open and I click on a textfield at the bottom of a long section it scrolls to entirely the wrong section.
I'm curious if there is something obvious I'm missing, I've tried using the library TPKeyboardAvoiding to no avail, it sounds very promising but also doesn't handle my situation.
I'd prefer to stick with a table view instead of a scrollview as I've already built out and handled headers, certain events, etc.
ALSO, after reading other posts it may be pertinent that I'm in landscape mode only on iPads and this tableview + controller is inside a container controller so it's size is fixed at 984x543
I'm new to iOS and MonoTouch, and I have a pretty basic need - I have two vastly different views to display in the same table cell depending on whether it is selected or not. When you load the app I'll present a list of products in a custom UITableView, with all the rows deselected and each row basically just showing the product names in a label. As soon as a user taps one of the rows and selects it, I show a very different view with more of a shopping cart layout. Since the two views are so different they have vastly different sizes. What i need is for the cell itself (or row?) to grow and shrink according to the natural height of whichever view is currently being displayed.
I'm using descendants of UITableViewController, UITableViewSource, and UITableViewCell for the solution. What I do is add both versions to the cell's ContentView, then set the Hidden property as needed when the cell/row is selected/deselected to show the right layout. That works well. I'm in demo mode right now, so I'm not overly worried about efficiency or responsiveness, that will have to come later.
I know that GetHeightForRow is responsible for sizing the rows but it only gets called once, when the cell is first shown. It seems to me that I need to alert the TableView to re-poll the source for a new size as the views are changing, but I can't figure out how to do it.
I tried (rather hopefully) to cause GetHeightForRow to be invoked again manually using Cell.SetNeedsLayout and Cell.SetNeedsDisplay, hoping that would cause the table to re-query the source for new dimensions, but no joy.
I tinkered with the direct approach, trying to size the contentview itself but it didn't seem as if it was leading anywhere. I feel as if the table needs to be told to query for a new row size, but I'm open to any suggestions.
Surely I'm not the first to attempt this? What am I missing?
Try forcing GetHeightForRow to be called again by calling ReloadRows instead.
You may or may not have to specify begin/end updates (this might just be for animation, though?)
tableView.BeginUpdates();
tableView.EndUpdates();
This is related to this question
ios filter options similar to the apple store (dropdown list)
I tried using a uitableviewcontroller instead of a pickerview as I couldn't understand how to use the picker view if I need it popping out (any info on it would be appreciated).
Now this is what I did.
I have a VC that calls out a "FilterVC". I only have one FilterVC that is called by 3 different "filter buttons", and I will just populate the VC depending on the button. The issue is, one button might have just 2 items that is needed to be shown, another one might containg up to 50. Was wondering how do I adjust the height of the popovercontroller that contains the uitableview? Also, is this the right way in dealing with popovers, 3 segues connected to one VC??? (It needed an anchor point)
Here's what it looks like
As a follow up question:
Is this the right way to do it on an ipad? I feel like most people prefer the uipicker. The guy that answered my first question said it's more of a design thing. Now since I'm no designer, as a user, do you think uitableview is more appealing?
Thanks for your time!!
In the view that you're showing in the popover, set self.contentSizeForViewInPopover as soon as you know the size and before the view is displayed.
The main benefit of using a table view over a picker is that it has a scroll indicator so you can see how long the list of options is. Also obviously that you can control exactly how the list is displayed. So the table view should be better if it fits in with your UI style and particularly if the list of options is long.
I am currently working on an iPad application that uses a table view to present data, I was inspired by the iTunes application in iPad that present it's data in multiple columns in a very nice and neat manner, and the most interesting thing is that during the portrait mode the itunes application displays data in 2 columns but when the user switches to landscape mode, it switches the display to 3 columns (since there are plenty of space to display data horizontally).
This is what i'm talking about:
but i found out that iOS SDK only supports single column for tableview (it would be nice to utilize the entire space provided on iPad screen to present data), i did some research and i found out that the best way to present data in multiple columns yet like spreadsheet style is to use datagridview instead, but iOS SDK did not provide any data grid view controls for iOS developers.
I found out over the internet some customized tables like:
AQGridView.
DTGridView.
and also the one from this:
http://usxue.is-programmer.com/posts/14176.html
and the one from this:
http://xebee.xebia.in/2011/04/14/building-editable-gridview-for-iphone-apps/
But sadly none of these ever met the requirements of the application i was working on.
Could you guys provide me some ideas or share some sample codes or links on how to display data in somehow-data grid view, to achieve similar effect used in iTunes application (as shown above).. Any form of help would be pretty much appreciated. Thank you guys!
The summary answer is, place multiple data "views" across in a single cell.
The more detailed answer:
Create custom views that represent the single cells you want. You can for this purpose make them resizable enough to work two across or three across (they will get loaded into 1/2 or 1/3 of the cells bounds).
Then make a custom UITableView cell, that can take two or three data items - load up an instance of the custom view previously created in the cell for each data item you have, placing them next to each other. You can have the cell do the view layout when groups of data items are added.
In the cellForRow code in the table delegate/datasource, you use your data source in groups of two or three (and report the row count accordingly) to pass along to the custom cell.
Sorry I can't share code, but I have used this technique before in other applications.
What's wrong with creating a UIView class to represent a single cell, and another that lays out an array of those cells in a grid? Put your grid view in a UIScrollView and you're about done.
UITableView is obviously a pretty complex class. Much of that is to make it very general, very reusable, and able to support a huge number of rows. Your class doesn't necessarily need to be that complicated -- if you have a fairly small number of cells, your "grid" could really just be a UIView in which you lay out cells in rows and columns. UITableView removes cells that aren't seen in order to save memory; you might need to do something similar if you have hundreds of cells, especially if they're large, but a few dozen probably won't require that.
In short, since you need a grid view for a particular use, you don't need to do all the extra work that would be required for a general, reusable solution.