View Polymorphism in iOS - ios

What is the correct way to do view polymorphism in iOS? For example, I have custom table view cells that need to contain either a custom BarChartView or LineChartView. I decide at run time whether the table view cell will hold a line or bar chart. Ideally, I want to only create one xib file for the table view cell that layouts the bar/line chart view with other things (like labels for chart title, etc), and I can decide at run time whether the view that holds the chart is going to become a BarChartView or LineChartView. Is it possible to set the morphing view in the xib file in Interface Builder to be one of the superclasses, for example UIView, and then later programmatically decide which subclass it should become? If so, what's the best way to do that?

Step 1. Make two view in custom cell xib file for BarChartView or LineChartView.(Both in single xib only)
Step 2.Write conditions in cellFoRowAtIndexPath to get either BarChartView or LineChartView view to Show.
Note:- Now,there might be condition ,weather to show/hide tableview ,depends on you.
But once tableview need to be displayed, use Step 1 & 2 to dynamic view loading.

maybe have a custom view inside contentView of your cell and just add barChartView or lineChartView to that view. So, even If you need to support more Chart types that'll be doable

Related

Create a photo booth from library to pick images

I'm new to xcode. I am trying to create a photo booth which appears at the bottom (as the one in the image) so that i can make multiple selections and view the result at the top. Any knows how this can be achieved?
You have to implement UICollectionView for photo booth.
For UI design follow the given steps,
Create a UIViewController
Add UICollectionView on UIViewController
Set constraint according to your UI design
Set UICollectionCell height and width same and set mini spacing whatever you want in For cells 5 and For lines 5
and for programming part,
Take data from where you get json parsing or your static data.
Store in one array and reload UICollectionView
Then assign data to your UICollectionView using their delegates and datasource methods.

Static table cells with detail

I'm trying to make an iOS 'information' or 'guide' app in Swift. I wanted to utilise the Master Detail template so that when the user clicks a cell it will take them to a relevant ViewController with either basic text labels or a PDF file.
From what I understand, Dynamic Cells can be dynamically changed whilst the app runs however I want to set static cells from the storyboard (or programmatically) and their relevant content/PDF files so the user can view each one. I don't want any "new cell" or "editing" functionality.
How can I make this work? I would post my code so far but it's almost identical to the Master Detail template so I don't see any use. I know this is quite a vague question but I need help and don't know where to start.
Any help will be so appreciated!
A static table cell can entirely be created via storyboard. In the storyboard once you add a tableviewcpntroller you can prototype call added to it.You can add as many prototype cells to your table ( not necessarily every one should have common layout). After all cells are added you can assign individual tags to the cells if you need identify these cells from your code.You can add segue from each cells to move to different page.
Let me know if something more is needed.
In Interface Builder set the Content of the table view to Static Cells.
Drag as many table view cells as you need into the table view.
In the controller create IBOutlets for the labels and the other UI elements.
Connect the outlets in Interface Builder.
Rather than using the datasource methods assign the values directly to the UI elements via the outlets.

Swift custom cells layout TableView decision

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.

Access child views in custom UITableViewCell

Background:
I am trying to create a table view with around 4 types of different cell layout.
At first, I considered using static table view to solve the issue since the number of rows are somewhat fixed (nor more than 10)
But, after some thinking, I decided that I don't really want to be tied up to the UITableViewController. Thus, I tried to implement it with dynamic table view.
Question:
After I create 4 prototype cells, I found out that I'll need to access the child views in cell (to update their value). But the only possible ways I know seem to be:
1. Create a subclass for each prototype cell, and create `IBOutlet` to the child views
2. Assign `tag` for each child view for later access
But I don't really like these two methods...
The first one is too cumbersome, and the tag in the 2nd solution does't seem to be very sepcific (access the child view by just some magic number..)
So, I would like to know:
Is there any better practice for implementing this kind of
tableview. (multiple cell prototypes, and fixed row numbers)
Is static table view a better way to do it? If yes, will there be
any limitations when I am tied up to UITableViewController?
For example, if I need more complex UI, and decide to add more views on to it, will UITableViewController be less flexible than UIViewController
Thank you so much!
If the cells are very similar but with different layouts they could share a common UITableViewCell subclass provided the class doesn't need to know the layout it is in just configure the available outlets.
If the code does need to be aware of the layout used then it is probably best to make them separate subclasses.
For Swift use is or as? to confirm the correct subclass for the cell (for Objective C it would be the isKindOfClass method).
1.You do need to subclass the UITableViewCell if you want to access his IBOutlets.
In order to distinguish between the cell just use isKindOfClass
2.It depends how different your cell are from one another. If they have slightly different structure you might want to consider lodging the elements in cellForRow. Try to take a look at the built in structure cause it might save you some subclassing.
These structures have built in parameters such as: image,text etc.
Their structure is more strict though
Theses are the available types:
UITableViewCellStyleDefault, // Simple cell with text label and optional image view (behavior of UITableViewCell in iPhoneOS 2.x)
UITableViewCellStyleValue1, // Left aligned label on left and right aligned label on right with blue text (Used in Settings)
UITableViewCellStyleValue2, // Right aligned label on left with blue text and left aligned label on right (Used in Phone/Contacts)
UITableViewCellStyleSubtitle // Left aligned label on top and left aligned label on bottom with gray text (Used in iPod).
I don't really understand why you want to use tags?

Appropriate way to add multiple UIPicker controls on page

iOS Proficiency: Beginner
If I have a Xib with multiple fields that all need their own Picker View, what's an appropriate/canonical way to add multiple picker views on the page without getting the Design View all cluttered up?
1) Only add the PickerView programmatically and not via the XIB?
2) Use only 1 Picker object and populate it with different values based on the field
selection? (Possible memory benefits?)
3) Place the UIPickers on the View with a tiny height/width and then programmatically adjust height when necessary? Not even sure if the height is adjustable.
4)Combination of some of the above?
You can see in the image below, how cluttered it looks already even with just one picker view:
The view that you have with the text fields and picker views would lend itself to be part of a UITableView.
See the calendar app when you add an event.
You can set this up fairly easily by using a static UITableView.
I'm replying on my phone at the moment but will look for a tutorial if you would like.
If only one pickerView will be visible at once, then you should consider using only one pickerView and configure it's delegate/datasource so that you can give it a different datasource for each field.
Unless more than one is visible at once, there really isn't any reason to use more than one in your nib file. And even if you used more than one, you would still have to configure you delegate/datasource methods to handle each individual picker.
Hope that helps.
EDIT: It would be a little bit of work, but if you wanted the pickerView to animate in and out of the view whenever you need and if you wanted to clean your Xib up even more you could do the following:
Create a subview containing your pickerView
Set up a protocol on the subview to allow you to pass the selected value back to the view controller.
Set up your viewController to conform to the protocol on your picker subview.
Set the pickerView to be each textField's inputView.
Set the textField's delegate methods to configure the dataSource of your subview when editing begins.
By doing this, you have set your textField so that when it receives firstResponder that it will display the pickerView instead of a keyboard.

Resources