Can you name a modern device on which people will want a client with access to direct messages, without a webbrowser? I can't.

Tom


On 5/19/11 5:17 PM, Adriaan Pelzer wrote:
Understood. In other words, there is no way to consume the authenticated parts of the Twitter API on devices without web browsers anymore?

This severe limitation will haunt Twitter in future, without a doubt.

Adriaan Pelzer

 //))//\\//\\||//
//\\//7//7///\\

putting you in touch with your crowds
http://www.wewillraakyou.com
twitter: http://www.twitter.com/adriaan_pelzer
linkedIn: http://uk.linkedin.com/pub/adriaan-pelzer/4/874/860/
skype: adriaan_pelzer
+4478 7978 1743



On Thu, May 19, 2011 at 4:00 PM, Tom van der Woerdt <i...@tvdw.eu <mailto:i...@tvdw.eu>> wrote:

    Like I mentioned in my post - use the actual browser which
    includes an address bar (that's what it's about - without the
    address bar the user doesn't know it's actually twitter.com
    <http://twitter.com> and you might just as well use xAuth, lol).
    Use a callback URL which includes a custom scheme
    (myapp://oauth_redirect, for example) and catch this URL in your code.

    Tom



    On 5/19/11 4:58 PM, Adriaan Pelzer wrote:
    If using a UIWebView is against the TOS, how should app
    developers (standalone apps, that is) authenticate without xauth,
    in the light of yesterday's announcements?

    Adriaan Pelzer

     //))//\\//\\||//
    //\\//7//7///\\

    putting you in touch with your crowds
    http://www.wewillraakyou.com
    twitter: http://www.twitter.com/adriaan_pelzer
    linkedIn: http://uk.linkedin.com/pub/adriaan-pelzer/4/874/860/
    skype: adriaan_pelzer
    +4478 7978 1743



    On Thu, May 19, 2011 at 3:53 PM, Tom van der Woerdt <i...@tvdw.eu
    <mailto:i...@tvdw.eu>> wrote:

        1. Yep
        2. NO. There's no difference in oauth/authorize and
        oauth/authenticate, except that authenticate will simply pass
        the "accept/deny" screen if the user has already accepted the
        app. Also, don't display it in a WebView, use the normal
        browser instead and use a callback URL with a custom scheme -
        for example myapp://. Let the browser redirect this URL back
        to the app. Again, do NOT use a UIWebView - I'm pretty sure
        that that's against the TOS, and if it's not, it soon will be.
        3. Yep
        4. Yes, you will need to store the consumer token and secret
        in the code, and store the user's token and secret in the
        keychain (or somewhere else, secure).

        The OAuth flow is no different for mobile devices than for
        desktops.

        Tom



        On 5/19/11 4:45 PM, Andrew W. Donoho wrote:
        Gentle Twitter Support Folks,

        There is an ambiguity in the OAuth flow for mobile
        devices. As I now have little time to move from xAuth to
        OAuth, I would appreciate it if Twitter Support would
        confirm the following OAuth flow which uses your routes.

        1) Use "POST oauth/request_token" to get the access token
        needed for the user web dialog.

        2) Upon receiving the request token, open a web view using
        "GET oauth/authorize". This is the ambiguous path for mobile
        devices. It is specified that this path must be used for
        desktop devices. As a mobile device is really a wireless
        desktop device, I believe Twitter wants me to use this route
        in lieu of "GET oauth/authenticate". Other vendors also
        allow the specification of whether this is a mobile device.
        They then provide a web authorization dialog appropriate for
        a narrow screen. It does not appear that Twitter offers this
        functionality. Could you please confirm this? Finally, as my
        app runs on an iPad, what is the preferred web view width?
        (To support both portrait and landscape orientations, it
        needs to be less than 768 pixels. 600 pixels is a common,
        Apple suggested, width.) Could you please enlighten me to
        what is Twitter's preferred authorization web view width?

        3) Use "GET oauth/authenticate" to acquire the access token
        and access secret.

        4) As I haven't yet requested my new consumer key and,
        hence, do not know some things, will I also be maintaining a
        consumer secret for my OAuth signature mechanism?

        Thank you for your support.

        Anon,
        Andrew


        P.S. Thank you for the two week extension for our xAuth to
        OAuth transition. Because Apple may still reject my app for
        unrelated to Twitter issues, four weeks is still a totally
        inadequate period to ensure a zero downtime transition.
        Please recognize both the risks to our business and the
        hardship you are imposing on small organizations.
        Furthermore, Apple's WWDC conference occurs in the middle of
        your current conversion schedule, this only allows me, in
        effect, 3 weeks to make this change. You can really hurt us
        with your imposed schedule. While I doubt that is your
        intent, it is, nonetheless, a likely outcome. Please double,
        at least, your conversion period to 8 weeks.

        ____________________________________
        Andrew W. Donoho
        Donoho Design Group, L.L.C.
        a...@ddg.com <mailto:a...@ddg.com>, +1 (512) 750-7596,
        twitter.com/adonoho <http://twitter.com/adonoho>

        "When you can't imagine how things are going to change,
            that doesn't mean that nothing will change.
                It means that things will change in ways that are
        unimaginable."
                    Bruce Sterling, January 02, 2009







-- Twitter developer documentation and resources:
        https://dev.twitter.com/doc
        API updates via Twitter: https://twitter.com/twitterapi
        Issues/Enhancements Tracker:
        https://code.google.com/p/twitter-api/issues/list
        Change your membership to this group:
        https://groups.google.com/forum/#!forum/twitter-development-talk
        <https://groups.google.com/forum/#%21forum/twitter-development-talk>

-- Twitter developer documentation and resources:
        https://dev.twitter.com/doc
        API updates via Twitter: https://twitter.com/twitterapi
        Issues/Enhancements Tracker:
        https://code.google.com/p/twitter-api/issues/list
        Change your membership to this group:
        https://groups.google.com/forum/#!forum/twitter-development-talk
        <https://groups.google.com/forum/#%21forum/twitter-development-talk>


-- Twitter developer documentation and resources:
    https://dev.twitter.com/doc
    API updates via Twitter: https://twitter.com/twitterapi
    Issues/Enhancements Tracker:
    https://code.google.com/p/twitter-api/issues/list
    Change your membership to this group:
    https://groups.google.com/forum/#!forum/twitter-development-talk
    <https://groups.google.com/forum/#%21forum/twitter-development-talk>

-- Twitter developer documentation and resources:
    https://dev.twitter.com/doc
    API updates via Twitter: https://twitter.com/twitterapi
    Issues/Enhancements Tracker:
    https://code.google.com/p/twitter-api/issues/list
    Change your membership to this group:
    https://groups.google.com/forum/#!forum/twitter-development-talk
    <https://groups.google.com/forum/#%21forum/twitter-development-talk>


--
Twitter developer documentation and resources: https://dev.twitter.com/doc
API updates via Twitter: https://twitter.com/twitterapi
Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk <https://groups.google.com/forum/#%21forum/twitter-development-talk>

--
Twitter developer documentation and resources: https://dev.twitter.com/doc
API updates via Twitter: https://twitter.com/twitterapi
Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
https://groups.google.com/forum/#!forum/twitter-development-talk

Reply via email to