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.com
http://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

Reply via email to