I need to create a custom button, custom label, custom tableview, and custom datepicker, but it seems harder to subclass the button/label/table/datepicker than to create a HTML string inside a UIWebView and customize it there... My application would be full Objective-c except these 4 controls.
What does Apple say about customizing a control using UIWebview. Is it frowned upon?
What are pro & cons for these 2 approaches?
Should I take a quick HTML, but it feels like I'm cheating, or take a long process to subclass these controls? More importantly, will Apple approve my apps with controls that's using UIWebView?
Thanks.
I'm sure Apple would approve an app with HTML controls, but I'd strongly advise you do it right and subclass the controls you wish to customise (or create your own from scratch). In my experience, native controls are leaps and bounds above what you can achieve with HTML and CSS, and it'll be worth it in the long run.
Besides, UILabels, UIButtons, and UITableViews are actually quite easy to customise; you may have some difficulty with the UIDatePicker but it's still possible to make it your own.
Ok, just in case somebody is having the same problem as me, I finally found another easy way to "customize" the view without going into so much trouble subclassing it..
It's : Use an image to be used as the view background. Then you can place the controls in the placeholder in the image. And set the controls as transparent...
Related
I'm the programmatic guy, and I simply don't want to use Interface Builder. I feel out of control, and besides that my GUI is about 90% custom all the time.
Literally every book does everything in Interface Builder and claims that this is the one and only great way to have real MVC going on.
Example: One of those books mentions that programmatically creating an UINavigationController with an Root View Controller and everything else that belongs in there is a big mess and won't be reusable when porting to the iPad, while doing this in XIB is a clever decision. Then the port to iPad using UISplitViewController will be a simple task.
So when I make iPhone apps and want to port those to the iPad too, what strategies work to reuse as much code as possible? I'd like to learn more about how to separate my code and achieve a better overall architectural design without using Interface Builder.
For those who want to tell me I must go with IB: Again, I do a lot of custom UI where IB is often just in the way. And not to mention all the animations. I really have my reasons. For people who make default UI IB is really fine - but please, I don't want to start a fight for IB vs programmatical UI or default UI vs custom UI! It's all about how to achieve great reusable code when doing everything programmatically, and both have their pros and cons.
Although you did not ask for it, I feel compelled to make the case for why people in general (perhaps not you) should consider IB, and then address the issue of custom components.
I use a lot of animations and custom components. And I love to use IB...
The key is to use IB for its strengths, and then decide what to do with the rest from there. What then are the strongest points of IB? Connections, placement, auto-resizing and customizations.
Connections are linking aspects of views and controllers together. It's faster in IB to drag out a few connections to delegates or references, than it is to write the code that forms the connections. And, it's a quick place to review all links to the UI you are building.
Placement IB also does well at. There's a fair amount of code involved in setting up any GGRect correctly. Not only is it easier to enter and review coordinate and size details in IB, but the tool automatically sizes a lot of elements properly for the container and the control, and offers many guides to help things line up properly - that kind of thing can take a lot of repeated testing to get right.
Related is auto-resizing. Although I don't feel that many screens can actually have auto-reiszing rules that rotate the screen and come out the other side looking just right (I almost always do rotated views as a separate XIB file), there still are a lot of shifts that can occur in the course of running your application that make it really useful to have these defined just right. The best example of this is the enlarged status bar while you are on a call.
Lastly comes customization. This again can be a lot of tedious code to write; try setting up all of the properties on a UILabel manually and it'll have you yearning for quick changes in IB.
With all that said, what is a good approach to custom components? I like to use UIViews in IB screens, with the class type set to a custom UIView that then fills out the display at runtime. But at least IB helps me get composition, placement and auto-resizing just right with minimum fuss, and also wire aspects of that custom view into a controller.
The one thing that would really lend IB to use with custom components is if it would simply let me set values for any simple properties the custom view had - then I could adjust parameters like a corner radius or whatever else I had going on.
I urge you to think on IB a little more, as it's a huge productivity boost when used correctly. There should be nothing about IB that gets in the way, it's there to boost your output.
One book I really liked was Erica Sadun's iPhone Cookbook 1st edition. It did everything programmatically.
Unfortunately the second edition is bloated.
If you reuse lots of your custom UI objects, it would make sense to write a code which
reads a plist (or a more general XML file) specifying how the custom UI objects should be placed / animated
and then creates your custom UI objects accordingly.
It's like writing a mini-xib file format tailored to your UI objects; you can also feel that you're in control of everything, as an added bonus.
This is a question for iPhone development and I'm hopin someone can point me to the right direction on how i should go about implementing this.
I am trying to write a chat application that supports emoticons/smileys. Where the smiley/emoticon images are stored can be figured out later. I think few iphone applications out there are already doing this (i.e. skype + ebuddy(?)) but not sure what method they went for.
After searching around, there seems to be a few ways of doing this (i think):
bubble chat style which has been discussed before. UITableViewController with custom UITableViewCell. For emoticons, might have to do a whole bunch of calculations to determine where to stick a UIImageView for each emoticon.
Use UIWebView as the whole "window". Style it to look like bubble chat. Takes away any manual calculations on image smiley placements.
I have no idea what the performance is like for each of these two methods, how complex it can get etc, so any comments and guidance will help for sure. Cheers
If you use custom UITableViewCell, then I'd probably implement drawRect: instead of adding labels and images. One will probably take as long to implement as the other, but it will perform much better.
The UIWebView might be worth a short, although you will have to make sure that everything looks right there, too. Instead of using one big web page, I suggest simply throwing in a web view into each table view cell.
Personally I prefer the first approach, measuring and layout of text is not too complicated, but then I've never been the ultimate HTML guru.
I agree with #Eiko on making custom UITableViewCells, especially using drawRect instead of adding labels, images, etc.
If you used a UIWebView how would you handle updating it? A complete reload each time new text is sent? That seems like it will be a cause of issues. Once you get a long conversation reloading the entire UIWebView's contents will cause some flickering which isn't acceptable in my opinion. Also using a UIWebView would require you to have 2 complete copies of each conversation in memory. 1 as your backend data and 1 as the HTML. Where using a UITableView you have your backend data, and only enough of that will be duplicated that can fill 1 screen at a time.
I'm using three20 for most of my iPhone app.
One of the views I need to create is relatively complex. It needs a top bar (under the nav bar) with some controls and label, an image view below this bar (which occupies most of the body) and another bottom bar with more controls and labels (above the tab bar control).
I don't have much UI experience - my only experience with anything UI is laying stuff out using CSS, etc on websites. Apple's online doc seems to assume that the reader knows a bunch about rectangles, layouts, frames, etc or is using InterfaceBuilder. And three20 isn't too well documented either.
So my question is:
Is it possible to design something like what I describe in IB and then still have a three20-based app use it? If so, any tips/pointers on how would be much appreciated.
Can you point me to some documentation that explain how views/controls etc are rendered. I'm pretty sure I can figure it out if I find some decent explanation/tutorial for it. (Book recommendations/online references work too)
You can use IB with Three20. It's not recommended, but you can call the -initWithNib method instead of the default -init method in your URL mapping.
ie:
[map from:#"tt://dashboard/(initWithNib:)" toViewController:[TableViewController class]];
I am trying to work out (or find) a button that looks half decent for use in my app. In the image below I have two buttons at the bottom, the default button (interfaceBuilder) and one using two png images from the Apple UICatalog.
I am a little shocked that apple did not include something a little more stylish in IB. I assume that my only option is to find/use/make a suitable replacement button image. Before I fire up Photoshop does anyone know of any replacement buttons I might use?
gary
What you can do is use a segmented control with just one segment - you get the shading you want and it's not much harder to use than a standard button.
If you want to try out some button designs, you can draw them in Opacity, which includes a template for iPhone buttons. Opacity can output the button as a stretchable PNG for use in the button or as a UIView / UIButton subclass with all the Quartz drawing calls within it.
I recommend having a look into the Three20 library. It provides a TTButton class that can be customized using TTStyles, and its very easy to create your own styles. In the Three20 example app, there are a lot of styles available already, especially styles for navigation bar buttons. They serve as great examples.
I'm taking a look at this widget, and it appears to be a UIPickerView, however I haven't seen anything provided by the iPhone SDK API that allows for horizontal scrolling only. Mostly it's all done vertically. Also there appears to be a custom graphic around this picker, so it might not be that either.
I'm curious if anyone is able to determine if this is indeed a UIPickerView or perhaps a hacked up UIScrollView? The widget is handy -- and I like its use. I found it in some random groceries app in the app store.
Here is the screenshot:
Thanks all.
I'd definitely use iCarousel library:
https://github.com/nicklockwood/iCarousel
The library is really well documented, the code is clean and maintained.
That is totally custom. You could indeed do something of the sort overlaying an UIImageView and an UIScrollView. I'd guess it's a 100% custom. As with all programming, there are many ways to do any single thing.
As I recently posted in response to this question, a class for an iOS horizontal picker control (STHorizontalPicker) has just been posted on GitHub. It's nowhere near as sophisticated as UIPickerView, but it provides the basic functionality for picking numeric values and the underlying foundation is probably a good starting point for adding more sophisticated functionality (it's a UIScrollView containing a UIView with multiple CATextLayers for the markers).
It was designed to be used in UITableCellViews and currently looks like this:
This website has source code for a picker that is aligned horizontally without subclassing it.
That definitely looks like a custom component. I'd suggest getting the .app file off your iPhone, opening up the bundle, and looking to see if there's a xib file for that interface. You may get lucky and find the component sitting in there. My guess is that it's a subclass of UIScrollView, but of course there's no way I could be sure of that without personally knowing the developer or the codebase.
You will recognize pickers by their giant screen-gobbling footprint :-) This is most likely a horizontal UIScrollView with a series of fixed-width labels (or images). The tricky bit is to have the bezel on top with a transparent center pass touches back to the underlying scroll view. Or you can take the easy way out and overlay four image strips (for each edge) and leave the middle open so touch events go directly to the scroller.
It's a custom control, but it's really not that hard to build.