I am making an iPhone app.
In this application I have to make a look like below.
I am not allowed to use collection view.
I am using tableview, and custom cells. Which I am easily able to incorporate. Means taking 3 subviews in Custom cells. And making a look.
Here the problem is In a cell, how do I distinguish each object. so that I can call each object, to set an image on image view.
Is there any Object oriented mechanism to distinguish all 3 objects in a cell ?
Try to get the data as NSArray of NSDictionary containing an array of 3 objects that you want to display on cell.
Assign tag to UImageView in the custom cell.
In cellForRowAtIndexPath, get the 3 objects and apply image using switch case.
Well everything depends on how you get the data from the server
You can use outlet collections which will give you an array of UIImageView and you can assign different tags to the imageview so you can assign to them.
You can use these guides to understand how outlet collections works:
http://nshipster.com/ibaction-iboutlet-iboutletcollection/
http://useyourloaf.com/blog/interface-builder-outlet-collections/
All the standard procedures should work to achieve this but then it only depends on how nice you want to do this.
The straight forward procedure is to expose the outlets of the image views and labels in the cell and assign the correct values to those when dequeuing/creating table view cell.
The first upgrade would be to rather expose 3 setters on the cell to simply set your model to each of them which will then internally set the images and texts inside the cell.
The next thing you may do is to rather insert an array of objects (always sending up to 3 in your case) instead of having 3 setters.
At this point you may actually rather use a collection view INSIDE the cell and make the cell a data source for the collection view. But this is totally optional.
Now since you may still dislike the table view data source you may create another model which contains an array of objects (again up to 3 in your case) and make a system that will distribute your original array of objects into the array of these containers.
If then you need to handle buttons or other touch events they may be handled with collection view delegate or 3 buttons and in both cases I advise you to handle those in the cell and create a custom delegate for the cell which will report the event with the appropriate model.
This together generates the following:
When you receive the data call a container class to distribute your array of objects (into groups of 3) and assign it to your table view data source (view controller usually)
Number of rows is the same as number of containers in the array
Cell for row assigns the container with row index to the cell. It assigns self as a delegate
Cell internally handles the object distribution either via collection view, separated outlets or outlet collections.
Cell handles actions and reports them back to the delegate (- (void)myCell:(MyCell *)cell selectedItem:(MyObject *)item;)
The cell delegate can again handle what to do upon reported actions
Also if you want to avoid a collection view inside the cell you can create a custom view using xib so you do not copy the labels, image views and such. Then simply create 3 of these custom views inside the cell. Also by using inspectable and designable these views will be visible inside the storyboard.
First I'll say that a restriction against using UICollectionView is silly. Are you still targeting ios5?
I'd look at it like this.
make your own view class for the 'subcell' let's use this term for any single instance of the 3 views per cell. I'd subclass UIImageView, adding the label for the name down the bottom and a 'setSelected:' kind of method to highlight when selected via user interaction by drawing differently.
make a UITableViewCell subclass to host and layout up to three of these subcells. I say up to 3 because the last cell may contain 1 or 2 subcells and not 3 if the total people to represent is not divisible by three.
Selection Logic: You'll need to override 'setSelected:' because you want to deselect and select only subcells, you don't want the whole cell to highlight on selection, only a third of it.
You'll also want to implement touchesEnded: in this cell so that you can figure out which of the three subcells was last touched, and you'll need to be able to query or communicate this back to the controller, probably using delegation. If the cell can communicate back whether selection was in subcell 0,1 or 2 then this together with the UITableViewDelegate didSelectAtIndexPath should map to your model nicely - selectedPerson = myArrayOfPeople[ (indexPath.row * 3) + subcellIndex ]
You'll be able to decorate your cells in cellForRowAtIndexPath: in similar fashion..
personOne = model.arrayOfPeople[indexPath.row*3]
personTwo = model.arrayOfPeople[indexPath.row*3 +1 ]
personThree = model.arrayOfPeople[indexPath.row*3 + 2 ]
Related
I have a tableview where a single prototype cell is used only 3 times. This cell has some buttons on it that trigger displaying and hiding content within the cell.
I could reuse the cells, but that requires a lot of resetting each cell so that if I expand A's content, B's content isn't expanded when it loads. Furthermore, this requires me to keep a state record in the Controller class, where I would prefer to have this all handled by the Cell itself for modularity. In other words, the amount of work to keep each cell in the correct stage seems inefficient.
What would be the best way to go about this? Do I use static cells? Is there a way to instance 3 separate cells of the same type and place them in the TableView?
You certainly can have the modular part of the code you need inside the cell itself. If you don't want to reuse the cells, then add a custom initializer with a case for each cell type. Inside your delegate method cellForRow:
return CustomCell(type: .myCustomType)
If you do it this way, you can add a switch inside the cell's initializer & set up the cells according to their types that way. And i'm assuming by "static" you mean just three instances. You "add" cells to the table by telling the delegate the number of cells that it will need, which will in turn call cellForRow x times.
I'm having the user input four pieces of information into four different UITextField's (homeTeam, visitingTeam, homeScore and visitingScore). I am very new to Swift and am trying to figure out how to connect those four UITextFields so they show in the UITableViewCell's. I feel like this should be very easy but I am very new to Swift.
I have attached an image so hopefully it makes it easier to understand. I want the information from these four textFields to be displayed in one cell of the ui table view so it shows the two teams and the score of the game. Does that help?
image
You can attach 4 IBActions to the 4 UITextFields, that update 4 different variables.
In the table, add 4 label outlets (you can make the table static, and force 4 rows if you want).
Then when you segue from one viewController to the other, pass the 4 variables into the new segue controller, and update the outlets to display the appropriate data.
Imagine this scenario:
I've 10 different and custom UITableViewCell: one with a textfield,
one with a button, one with some labels, one with a textview, one
with an imageView and so on.
I've a ViewController with a tableView where I wanna display these cells.
The number of cell displayed can vary based on some conditions (and also the height, the background color and other parameters)
The user can interact with these cells
What is the best way to design this in respect of the MVC and maintain the ViewController lightweight and maintainable as possible?
How to take advantage of Swift language in doing this?
Is there any famous and consolidate design pattern to apply?
i will try to share some of my experience:
Create separate custom UITableViewCelll as per requirement like : textfield, textview, imageview, label etc. this class must not dependent on data calculation it is only for cosmetics UI. that means there must not be any method like updateCellWithData:(someDATAObj). This logic must go in some cetegory as discussed below.
Register separate custom UITableViewCelll with your tableview.
Create separate class (NSObject) as datasource and delegate for your UITableView.
Use category to populate data in your custom UITableView Cell. some thing like updateCellWithData:(someDATAObj).
Use constant file for your constants like height for tableView Cell, reuse identifier names, notification name.
try with some code atleast, then we can help you with best.
I need to display a table with in my iPhone app:
neither the number of cells nor the contents are known at compile time, but only at run time.
Views for each cell may differ, one cell has textField and another may have some other view control.
Should I consider Static or prototype cells?
Should I consider tableViewController or viewController with tableview in it?
Any thing I need to consider before I start coding? Thanks in advance
For The issue of dynamic Number of cell at Run time, you can call reload data for table view at any time you have the data source ready.
Prototype Cells should be used with no problem.
Simple Table View will be sufficient for the task.
You have to make cell, either in code or in storyboard, for each type of cell you want, 1 table View can have multiple types of prototype cells, Just name them differently and then make the objects of only the specific cell of which the data is best suited.
It is not that difficult but do handle the data source with extreme care.
Should I consider Static or prototype cells?
If you know all possible subview combinations that your cells might need to display the data appropriately, and they are relatively few, make one prototype for each. for example:
One text field,
Two labels,
One image view and a label,
...etc.
Otherwise, just use the plain-vanilla UITableViewCell (no subclassing) and remove/add subviews at runtime when reusing them (that is, inside the method -tableView:cellForRowAtIndexPath:).
Should I consider tableViewController or viewController with tableview
in it?
The only reason I would choose UIViewController + UITableView over UITableViewController is if -for example- I needed the table view to only take up part of the main view's bounds/screen, and display some other subview in the remainder. Otherwise, you get so much "for free" with UITableViewController that there's just no point in implementing all of that from scratch.
You have to choose prototype cell, u can create different types of cell depending upon your requirement.Any think ok for u, u can create tableview controller or view controller.
I have drawn my tableView in storyBoard with static cells and multiple sections. 6 sections each has proper number of static cells. In code, in MyTableViewController I do not implement any of the datasource or delegate methods, which logically means I do not have my model in code, the array or whatever that dataSource methods will use to populate number of sections or number of rows in a section. My question is: is it possible to insert a row to any of the sections?
I read a lot of stack questions. All of them is based on having a model array or dictionary that plays its role in dataSource methods to construct the table.
I have my table already constructed in storyBoard. I can get my number of sections with tableView.numberofSections() for example. Which means the model is stored somewhere for sure. I just need a proper method to get access to that model.
There is a reason the UITableView works the way it does with the datasource protocol. It allows iOS to use just what is needed to display on the screen at any given time as you scroll through the table, making it very efficient. Without implementing the required methods, iOS will not know how to rebuild the cell if you scroll it off the screen and then back on.
If you don't need that complexity (and really, it isn't complex and you can implement the required methods in less time than it is taking me to respond), you could use a UIStackView inside of a UIScrollView. It would allow you to simply add a set of UI components vertically down the screen, complete with scrolling.
Can you explain why you don't want to implement the UITableViewDataSource protocol?