Magic! Now it works.. thanks a ton Isaiah :)
On Jul 25, 4:40 am, Isaiah <supp...@yourhead.com> wrote: > > Thank you for your prompt reply Isaiah, > > No worries. Glad to help out. > > > Thank you also for the offer of emailing you directly, but I think > > your code is also precious for other newbie like me who want to know > > more about this OAuth thing :) > > It wasn't so easy to figure out a nice way to do this stuff. I > figured it would be a good thing to share. Glad it's helped. > > > About changing application type to be "Browser", then there is > > "Callback URL:" box that I have to fill, which I have no idea what do > > I have to fill in there. > > But I tried it anyway, and same result. > > The callback URL can be any URL you like. After a successful > authorization this is the URL that's loaded. You should specify the > URL both in the twitter app setup and also as a constant in the > YHTwitter.m file on line 25: > #define kYHOAuthTwitterCallbackSuccessURL @"http://twitter.com/" > > Through the browser delegate methods the client will know that the > callback URL was reached and the authorization was granted by the > user. This triggers the example app to close the browser window and > save the OAuth info to the keychain. > > Although I would imagine you would want to change it to your own web > site for practical reasons, leaving it ashttp://twitter.com/should > *work* at least for testing purposes. > Isaiah > > YourHead Software > supp...@yourhead.comhttp://www.yourhead.com > > > > > On Jul 24, 2009, at 1:06 PM, Fares Farhan wrote: > > > Thank you for your prompt reply Isaiah, > > > Thank you also for the offer of emailing you directly, but I think > > your code is also precious for other newbie like me who want to know > > more about this OAuth thing :) > > About changing application type to be "Browser", then there is > > "Callback URL:" box that I have to fill, which I have no idea what do > > I have to fill in there. > > But I tried it anyway, and same result. > > > Fares > > > On Jul 24, 10:58 pm, Isaiah <supp...@yourhead.com> wrote: > > My example was built right as the pin code method was invented/ > > implemented in the API. So my example still uses the "Browser" method > > that doesn't require a pin code. > > > If you go to your application settings page in twitter and set your > > Application Type to be "Browser" you should be good to go. > > > As I understand it the PIN code was invented to help "clients" that > > couldn't detect if the browser had been sent to the success callback > > URL. However, my example doesn't have this issue. > > My example embeds the browser and communicates directly with it to > > determine when the callback URL is sent. This technique obviates the > > need for the pin code. > > > I like to think of my example as a "hybrid app" -- neither purely a > > desktop client nor really a web app -- but a little bit of both in the > > right places. ;-) > > > I've considered adding the pin code, but it seemed to further > > complicate an already challenging UI without adding any value. > > > If you have any other issues with the example code, please feel free > > to email me directly. I'd be happy to help out. > > > Isaiah > > > YourHead Software > > supp...@yourhead.comhttp://www.yourhead.com > > > On Jul 24, 2009, at 12:04 AM, Fares Farhan wrote: > > > Dear Twitter developers, > > > First, I apologize if I misplace the question. > > > I've cloned Isaiah's git repository of his AOuth implementation from > >http://github.com/yourhead/OAuth_ObjC_Test_App/tree/master > > > but I experienced an issue that after the web sheet closed, there is > > no place that I can put the PIN retrieved from the authentication > > result, or anywhere in the code that I need to pass the oauth_verifier > > parameter along with other params. > > > the debugger said that ther is "Operation could not be completed. > > (NSURLErrorDomain error -1012.)" > > > Thank you in advance for any response, > > > Cheers, > > > Fares