The problem was that my WebViewController had an empty stub "loadView"
though the actual work was done in ViewDidLoad. When i read the
documentation it does say that when you load a ViewController using
initWithNiBName use ViewDidLoad and not loadView. But i did not know that an
empty loadView could cause problems like this :-)
Thanks for your debugging tips.
-mohan
On Wed, Jan 7, 2009 at 6:20 PM, Robert Marini <r...@pinchmedia.com> wrote:
> Not to sound too much like tech support, but did you wire up your instance
> of a UIWebView in your xib to an IBOutlet property in your view controller?
> I tried this scenario out juts now and it behaved as expected with
>
> // Implement viewDidLoad to do additional setup after loading the view,
> typically from a nib.
> - (void)viewDidLoad {
> [super viewDidLoad];
> [webView loadRequest:[NSURLRequest requestWithURL:[NSURL
> URLWithString:@"http://www.apple.com";]]];
> }
>
> Some general tips about debugging these scenarios - UIWebView has a
> delegate protocol that you can implement, I would do so in the view
> controller and then check in the delegate methods to see if there is an
> error with the URL for instance (which was exactly what I did when I wrote
> this test app, `htttp` isn't any protocol I know of). You, of course, need
> to let IB know what object is the delegate (link the delegate outlet of the
> web view instance to the file's owner).
>
> IB is actually particularly useful for handing web views as you can create
> buttons and wire them up to common function directly with no code (back,
> forward, reload, etc).
>
> -rob.
>
> On Jan 7, 2009, at 4:01 PM, Mohan Parthasarathy wrote:
>
> Hi,
>>
>> I agree that IB is useful but sometimes does not work as expected (mostly
>> because i am doing something wrong). I am new to Cocoa Application
>> development and perhaps takes times to get used to it.
>>
>> Recently i was trying to use UIWebView (one of the views in my navigation
>> hierarchy). And my viewDidLoad method sends the URL request to load. This
>> just does not work. It looks like i have done all the right things. Instead
>> doing this programatically by creating a UIView etc, in loadview just works.
>> As there are no error messages etc.,it is hard to find what mistake i am
>> making with IB. Sure, one could make mistakes in writing all the code but
>> somehow seems more reliable ;-)
>>
>> -mohan
>>
>>
>> On Wed, Jan 7, 2009 at 5:46 AM, Robert Marini <r...@pinchmedia.com> wrote:
>>
>> Martijn -
>>
>> I don't necessarily know that I'd agree with that though it could be
>> because I'm more accustomed to IB than programmatic layout. In general,
>> anything you'd represent in code as a UIView subclass is something you'd
>> create in a xib file in Interface Builder. That xib file would be "owned"
>> then by a subclass of a UIViewController (yes, you should be using view
>> controllers heavily on iPhone). Each instance of a control in IB can then
>> be accessed programmatically from your view controller by IBOutlet and
>> IBAction declaration which enable you to add custom behavior. It's a
>> different way of thinking than programmatic layout and while the constant
>> going back and forth between IB and Xcode can seem daunting, it's generally
>> worthwhile as your codebase's size will be cut by a large amount (in one
>> project I worked on, by 60%).
>>
>> There are, of course, times when I would fully suggest doing views
>> yourself in code (fast drawing in a flattened view hierarchy for
>> UITableViewCells for example) but really, there hasn't been a reason to
>> avoid IB since ~beta 4 of the SDK. While it's true that a lot (most) of the
>> sample code provided use programmatic layout examples, to a great extent it
>> is as simple as imagining that the 20 lines of code used to set up a
>> UIToolBar are just a drag and drop operation in your xib. I'd strongly
>> advise taking a look at doing your view work primarily in IB if only for the
>> fact that it makes that type of code much more maintainable.
>>
>> -rob.
>>
>>
>> On Jan 7, 2009, at 4:00 AM, Jonathan Hess wrote:
>>
>> Hey Martijn -
>>
>> If you could file bugs at http://bugreport.apple.com/ about the concepts
>> that you find confusing it would help us improve the usability of the tools.
>>
>> Thanks -
>> Jon Hess
>>
>> On Jan 6, 2009, at 11:47 PM, Martijn van Exel wrote:
>>
>> Thanks - I looked into the TableSearch sample project and it seems to give
>> me enough pointers to implement what I want.I'm also learning a lot from
>> the
>> UICatalog sample. I tend to stay away from Interface Builder, as is
>> provides
>> more confusion than solutions, IMO.
>>
>> Martijn
>>
>> On Wed, Jan 7, 2009 at 06:44, Robert Marini <r...@pinchmedia.com> wrote:
>>
>> UISearchBar is a standard cocoa touch control.
>>
>> -rob.
>>
>>
>> On Jan 6, 2009, at 7:35 AM, Martijn van Exel wrote:
>>
>> Hi all,
>> I'm looking to implement a user selection from a large number of items
>> contained in a deep hierarchy (a taxonomy of species) for the iPhone.
>> The hierarchy is too deep for a drill-down of TableViews, so I thought a
>> control like the App Store iPhone application's Search tab would be a good
>> idea.
>> Is this a standard control in the iPhone SDK or is this something to
>> implement from scratch? Any other suggestions on how to approach this UI
>> challenge?
>>
>> Thanks,
>> --
>> martijn van exel -+- mve...@gmail.com -+- http://www.schaaltreinen.nl/
>> _______________________________________________
>>
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/cocoa-dev/rob%40pinchmedia.com
>>
>> This email sent to r...@pinchmedia.com
>>
>>
>>
>> _______________________________________________
>>
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/cocoa-dev/mvexel%40gmail.com
>>
>> This email sent to mve...@gmail.com
>>
>>
>>
>>
>> --
>> martijn van exel -+- mve...@gmail.com -+- http://www.schaaltreinen.nl/
>> _______________________________________________
>>
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/cocoa-dev/jhess%40apple.com
>>
>> This email sent to jh...@apple.com
>>
>>
>>
>> _______________________________________________
>>
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/cocoa-dev/suruti94%40gmail.com
>>
>> This email sent to surut...@gmail.com
>>
>>
>
> _______________________________________________
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/suruti94%40gmail.com
>
> This email sent to surut...@gmail.com
>
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
