this is my first question here at Stack Overflow.
I've been looking for a way to do this ever since I started programming for iOS (which was really not that long ago, about a month) but I haven't been able to find any concrete explanation, so I decided to ask you.
I've seen many apps that have custom artwork in them (e.g. wooden textures, backgrounds with noise, custom table view cells, etc.) and I would like to add some to my own apps, are there any properties that I can access, say for example, on a tab bar?
Check out Wunderlist or ReadMore, these two are great examples of what I mean.
Wunderlist was made using Titanium, obviously editing backgrounds and customizing table view cells and table view backgrounds is easier in JavaScript, but if Titanium has a way of doing it then there must be a way of doing it natively in Objective-C, right?
Thank you in advance, your help is very much appreciated.
There are a number of ways to create a custom UITableView and associated cells.
As a general overview, the Cocoa with Love Easy custom UITableView drawing blog post is pretty good and there's also a more recent (and complex) UITableView construction, drawing and management (revisited) post on the same site if you really want to go for it on the customisation front.
there a few ways of customizing UITabelViewCells.
Table View Programming Guide for iOS
Interessting Chapters:
Programmatically Adding Subviews to a Cell’s Content View
Loading Custom Table-View Cells From Nib Files
Subclassing UITableViewCell
Related
Perhaps I'm searching for the wrong keywords, but I'm surprised there wasn't already a similar question. If there is, please let me know and I'll delete this question.
What's the best way to customize all table views in an app targeted for iOS 5 or later?
UIAppearance has proved to be very useful for customizing all navigation bars, tab bars, and the like throughout an app. Is there a similar way to customize table view and table view cells?
So far I've been programmatically configuring each table view separately. This might not be the best idea as I plan to have different themes the user can select. I've been thinking about creating a separate class that returns the appropriate image for the table view (or cell) based on the theme the user has selected. Would this be a suitable approach (if there's nowhere to easily customize all the table views)?
The most used way to customise table views is through defining table cells in the nib files:
http://www.galloway.me.uk/tutorials/custom-uitableviewcell/
or storyboards:
custom uitableviewcells in storyboard
I haven't do any tweaks by appearance class yet, but it may be helpful. If you want to to this programatically, use the decorator pattern to ease your and further user's life in joining produced code into the project:
http://sourcemaking.com/design_patterns/decorator
I hope this is helpful
I Know this question has been asked a lot in a hundred different ways (and thats just on this site). But I'm struggling to put all the pieces together.
I would like each UITableViewCell to look like this:
It has multple legends and several fields. The legends are static and wont change but the corressponding labels will vary in width and height. Therefore so will the cells. I need the legends to always align with their labels.
I have tried to do this using the Interface Builder but don't really understand the autoresizing. Though I'm happy to do this in code.
Does anybody know how to do this or at least have some good links to tutorials, source code etc?
Putting a full table view inside a cell is crazytalk. Maybe somebody got it to actually run - that doesn't mean it's best practice or good practice.
I will answer your question after making one very down to earth suggestion. Please consider following Apple's guidelines by putting just a summary of each event in your cells for this table, and allow the user to push down to another view controller to see the details of a particular event. This will probably help you develop your app faster and get to market, then you can think about advanced stuff like customizing individual cell heights at runtime.
That being said, if you insist on putting all your eggs in this basket, then I think you will need to implement your table view cell in IB, note the details for all of your content label frame dimensions, then, at run time, use one of NSString's sizeWithFont:constrainedToSize: methods to determine how big your labels will be. Make them that big. Then from that data compute the height of your cell, and return that value from your table view's tableView:heightForRowAtIndexPath:. This is how I implemented this functionality in an app a few years back. (Frankly I'm not sure that it's still working.) There may be some better methods for figuring out the label size in CoreText, I haven't looked.
A better bet will be to constrain yourself to a limit on the length of text you can put in each label. Then you can just define the labels statically and use a constant-sized cell. Putting it together in IB isn't tough. Just lay everything out, and make sure that you create an IBOutlet and XCode/IB connection for each object you want to manipulate in code.
Good luck!
Add a tableview to each UITableViewCell. The outer tableView will be responsible for holding all your cells and each cell will be a Event with cells for each parameter.
This tutorial will give you insight on how to set that up.
http://iosstuff.wordpress.com/2011/06/29/adding-a-uitableview-inside-a-uitableviewcell/
With the introduction of storyboard, I wouldn't select to create a .xib/.nib when I create a subclass of UIViewController, because I can just drag out a viewcontroller in interface builder and assign it to the new class.
So, with storyboard, when would i need to use the .xib/.nib file?
Thank you.
Storyboards don't completely remove the need for NIB files. One common example is when creating subviews to go inside a UIScrollView. You can't create the subviews separately in a storyboard; instead you have to create separate NIB(s) for the subviews and attach them to the scroll view programatically.
In fact, on almost any occasion where you have a need for subviews which change at runtime you'll want to use separate NIBs.
Storyboards are great for certain kinds of apps, but for anything even remotely complicated the old way works very well still. An additional benefit is that they co-exist nicely. You can put placeholder views in your storyboard and fill them programatically with NIB-defined views later on.
I guess, storyboard contains the .xib/.nib files for all your views. It present relationships between them and helps you to avoid confusion if you have a LOT of views. Also it saves your time and nerves when writing code.
I have tried out storyboarding lately and I do have mixed feelings about its use:
Pro's
Convenience: You might have to write much less code. So you can for example show a static view without having to write any code.
Overview: You can quickly see how the ViewControllers relate to each other
Efficiency: For the simple use cases I find the Storyboarding much more efficient than "the old way".
Example 1: Editor > Embed In > Navigation Controller and voilà, no more instantiating and configuring is required.
Example 2: You can make "Prototype Cells" for TableView which speeds up the creation of static table views dramatically. AFAIK this is not possible with nib files
It's cool :-)
Con's
I find that the re-usability somehow suffers with storyboards. Although I can segue to a given ViewController from multiple points, it is still limited since in one case I might use the VC as a Popover and in another as a Master-ViewController.
Assuming that you are working in a big team and different people are changing different parts of your application, having one monolithic storyboard which you then have to merge might pose a big problem team-work-wise.
I really would like to have some mechanism to include or reference existing nib files into the storyboard which is currently not possible.
So considering these points I still find storyboarding very appealing but it makes sense to combine both approaches which is not really a big deal. Additionally, this technology it is still quite new so it might improve in the (near) future.
If you use storyboards, you generally won't need to create separate .xib files. You can still use a .xib file if you want to -- it might be useful e.g. if you have a particularly complex view that you'd like to configure by itself. Most of the time, though, there won't be a need to do that.
looking for some advice on what type of view can be used to build a screen with the following elements:
2 labels followed by 2 buttons.
Then a small table view with 3 rows.
Should a UIView be used or a UITableView?
I've attempted using a UITableView - however I couldn't add the labels or buttons.
So I've now built the view using a UIView. I added the labels and buttons and then a UITableView from the library. However I have no idea how to populate the rows in the table?
Any ideas?
Regards,
Fiona
You could always create the view that you want and return it in the table view delegate's -tableView:viewForHeaderInSection: method. That would give you your table view rows that you want plus your custom view above it.
You need to learn how to use the UITableView before going any further. Time taken now will pay off later on.
There are plenty of tutorials about the UITableView, but I found the best learning I had was from the free iTunes U Standford iPhone course. You don't need to watch it all, but at the very least you should watch the episode on UITableView, as it'll cover everything you need to know. I strongly recommend watching it all, especially the first 8 or so lectures, as it covers the basics of what you need to know really, really effectively.
The ones they use with grouped table view.
I'm using a table view that links to another view that has text on it. To make it look less 'plain' I wanted to add that striped background and then put something like a white 'text box' on that.
Do they allow it to be used?
Yes, they do allow that. I've done so in an application that has been updated and re-approved several times over. The pattern is available as [UIColor groupTableViewBackgroundColor].
sure.
For more details you may want to look at Apple's Human Interface Guidelines.
No, they don't mind. Why would they?
It shouldn't be a problem.
If you start doing something more complicated than a text box, say a button that you click that slides in another view controller, you're going to be duplicating a lot of UITableView/UITableViewController code, and you're better off just creating a UITableView with a controller and couple of singleton UITableViewCells in your nib file.