Re: [twitter-dev] Re: Tweet button and iphone
On Jul 27, 2011, at 3:43 AM, Victor Ruiz wrote: On Android, working with intents and after sharing successfully, the window closes automatically so it returns to the previous page. The window that automatically closes should have set up a timeout because it takes some seconds to be closed. If for example client browser doesn't support Javascript, there is a cancel button that also works perfectly. On iPhone, is different than in Android, because after sharing successfully, you don't have possibility to close and return back. I guess Twitter detects the user agent and show different pages in Android and iPhone, isn't it? iPhone and Android both have the same Web Intents UI (as do all devices, actually.) The behaviour you describe for Android, where the Intent page automatically closes and the browser takes you back to the original page is the correct behaviour. You should get the same experience on Android and iPhone. The behaviour you're seeing on iPhone there is odd, but could occur (on any device) if the Tweet Intent is invoked in a different way (either without JavaScript, or without a window.opener being set.) Can you link to the specific case where the iPhone UI isn't behaving as expected? I'll take a look to debug it. Thanks, Ben On 21 jul, 07:21, anaj...@ibs.com.jo anajjar %ibs.com...@gtempaccount.com wrote: It's working perfectly,Thanks Ben Note: This issue is also noticed in another url,please check my other thread here: https://groups.google.com/group/twitter-development-talk/browse_threa... -- Have you visited the Developer Discussions feature on https://dev.twitter.com/discussions yet? Twitter developer links: Documentation and resources: https://dev.twitter.com/docs API updates via Twitter: https://twitter.com/twitterapi Unsubscribe or change your group membership settings: http://groups.google.com/group/twitter-development-talk/subscribe -- Have you visited the Developer Discussions feature on https://dev.twitter.com/discussions yet? Twitter developer links: Documentation and resources: https://dev.twitter.com/docs API updates via Twitter: https://twitter.com/twitterapi Unsubscribe or change your group membership settings: http://groups.google.com/group/twitter-development-talk/subscribe
Re: [twitter-dev] Re: Tweet button and iphone
Hi Anajjar, On Jul 17, 2011, at 7:35 AM, anaj...@ibs.com.jo wrote: Thank you very much,can you please inform me when it's going to be deployed this week? or at least update me on this thread once it's deployed? Thanks again This fix is live now. You should now find that cancel buttons link to the original_referer where appropriate. Ben -- Have you visited the Developer Discussions feature on https://dev.twitter.com/discussions yet? Twitter developer links: Documentation and resources: https://dev.twitter.com/docs API updates via Twitter: https://twitter.com/twitterapi Unsubscribe or change your group membership settings: http://groups.google.com/group/twitter-development-talk/subscribe
Re: [twitter-dev] Re: Tweet button and iphone
Hi Anajjar, The fix for the cancel button links is done, and should be deployed next week. Ben On Jul 13, 2011, at 11:05 PM, anaj...@ibs.com.jo wrote: Can someone please respond on my issue? Why the support doesn't follow up with my issue to the end?!! :\ ,Is there any other place to get better support than here ? -- Have you visited the Developer Discussions feature on https://dev.twitter.com/discussions yet? Twitter developer links: Documentation and resources: https://dev.twitter.com/docs API updates via Twitter: https://twitter.com/twitterapi Unsubscribe or change your group membership settings: http://groups.google.com/group/twitter-development-talk/subscribe -- Have you visited the Developer Discussions feature on https://dev.twitter.com/discussions yet? Twitter developer links: Documentation and resources: https://dev.twitter.com/docs API updates via Twitter: https://twitter.com/twitterapi Unsubscribe or change your group membership settings: http://groups.google.com/group/twitter-development-talk/subscribe
Re: [twitter-dev] Re: Tweet button and iphone
Hi Anajjar, On Jul 7, 2011, at 6:28 AM, anaj...@ibs.com.jo wrote: the login page will appear and you can see the cancel button,click on cancel button,now it should return the user back to that link and as you can see the link has a querystring original_referer with the original url so the cancel button SHOULD return back to that url,but you will notice that it doesn't return the user back to that page and instead it redirects to twitter homepage Ah, you've found a bug. Thanks! I'll fix that. The cancel button there should behave the same way as cancel buttons elsewhere (e.g. in the after-Tweet screen) and redirect to the original referrer. On Jul 2, 2011, anaj...@ibs.com.jo wrote: In Safari I don't have any issues,but I do have issues with tweet button within the container,once the login window of twitter appears and user clicks on cancel it doesn't return the user back to my page,instead it redirects the user to twitter homepage,Is there any solution for this? For what it's worth, this is the full cascade of behaviours that Cancel buttons have within Web Intents: 1. If the intent is a pop-up window (e.g. if `window.opener` is available) then clicking a cancel button will close the window. On desktop, this closes the window as you'd expect. On mobile platforms such as the iPhone, this closes the page and flips the user back to the page that invoked the Intent. 2. If `window.opener` isn't available, then the page is assumed to have been navigated to conventionally. In this case, the destination of cancel links is (or should be) set with the following priority: 2a. To the original_referrer, if available and valid. 2b. If original_referrer is not set, or if the original_referrer is an invalid URL, or that URL falls foul of our known-malware-URL filter, then the cancel buttons will simply point to twitter.com. Finally, note that if you “pop up” an intent within a WebView in a native app, that does not set `window.opener`, so the page will believe it's been invoked directly in a browser (because it has.) If you want to handle the close event, you'll need to watch the source URLs. If it's possible to create a WebView on your platform of choice, and set a default window.opener *and* override window.close() with a call to native ‘close the WebView’ code, then you may be able invoke the Intent in a WebView and have all the autoclose behaviour from the web work. I've never tried this though. Ben -- @benward Twitter, Web Intents developer -- 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
Re: [twitter-dev] Unwanted T.CO shortening
On Jun 10, 2011, at 1:21 PM, Kosso wrote: The massive trouble I have with all this is that I like to know what the hell I'm clicking on before clicking a link. It's kind of my right as a citizen of the web. I personally can't stand it when, for example a link fires up iTunes or goes to some site I don't want to waste (possibly mobile and limited) bandwidth on. I like to choose WHO I give MY visit/traffic to. To be clear, the API returns all the information for all clients to display the original short URL, and navigate via t.co. We also look up the full destination URL and return that too, allowing even clearer navigation of where you as a user will end up when following a link. You can see this implemented on twitter.com today: https://twitter.com/joshtpm/status/79283124747501568 * The URL destination points to t.co * The displayed text of the URL is a cropped and shortened version of the real URL * The title (tooltip) of the URL displays the full address of the destination. I've further illustrated it with a screenshot here: https://skitch.com/benward/frff8/ The documentation for the URL entities that provide all of this information in the API response is here: http://dev.twitter.com/pages/tweet_entities Ben -- Platform Developer, Twitter -- 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
Re: A Problem with the web view. [was: Re: [twitter-dev] Please confirm this OAuth flow ...]
Hi Andrew,
On May 27, 2011, at 7:02 AM, Andrew W. Donoho wrote:
My question: Am I in error? Does Twitter return a different callback value
for the No, Thanks case. If not, I humbly request that Twitter add this
important, for a better user experience, notification.
We actually do have a simple callback format for when the user denies access.
It's not an automatic redirect, but we've always provided a link for users back
into the app.
It works like this:
When a user doesn't click authorize they go to a screen informing them either
that the application does not have access to their account, or that the
application *does* still have access to the account (if they choose ‘Cancel’ on
the `/authenticate` flow for an already authorized, for example.) This callback
is the same URL as for the success case, but returns without an
`oauth_verifier` parameter (since there isn't one) and with an additional
`denied` parameter, in which we pass the value of the `oauth_token` that the
request was originally made with.
Now, on the cancellation pages as your currently see them there's a link back
to the app that is neither big enough or obvious enough for users to respond
to. Therefore, we already have a design tweak implemented for next week that
makes it a much clearer “Return to {{Application}}” button on the denied and
cancel screens. Nothing is changing about the callback structure itself, which
you can already access for testing.
This should keep both ends of the flow hooked into all kinds of apps. As ever,
let us know if there's ways we can improve it for you; I'm particularly
interested in suggestions of extra data to send through in that callback to
improve the feedback in apps.
Thanks,
Ben
--
@benward
Platform Developer, Twitter
--
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
Re: [twitter-dev] Re: Visual refresh of the OAuth screens
Clive, Congratulations on the new release—it works great! And thank you so much for writing up your implementation in this detail. I'm glad it's come together and I'm glad you've been able to use the callbacks mechanism to improve the flow. Hopefully we're at a point in mobile platform development now where OOBs become a real rarity for users, and we can use callbacks for better app integration in all sorts of ways. Also, thanks for your patience and enthusiastic working with me to get the problem diagnosed. It was incredibly helpful to get your feedback and assistance, and took a bit of stress out of that weekend! I really appreciate it. On May 25, 2011, at 3:53 AM, bitrace wrote: The main reason we opted for the embedded UIWebView was because our TweetIgnite App allows the user to add multiple accounts, and we found that the cookies twitter sets after adding the first account makes it difficult to add a second, as the first account is still logged in and there is currently no option on the new screens to log in as different user. For what it's worth, the `force_login` parameter which we'll release soon on the authorize flow is a solution to this problem. (As mentioned in some of the other threads.) Regards, Ben -- @benward Platform Developer, Twitter Thankfully, we have now fixed the issue that caused the new OAuth templates to break our iPhone App and an update is now live on the App store. I thought I'd share our findings as they may prove useful to anyone else who has experienced problems or who is currently migrating from xAuth to oAuth in order to meet the new Direct Message access requirement. The problem we experienced following the rollout of the new OAuth screens occurred when a user tried to add their twitter account using the in-App UIWebView. This rendered blank instead of prompting the user to enter their username and password. We traced the problem to how our OAuth helper was interacting with the UIWebView. In our initial implementation the OAuth helper code was both creating and issuing the OAuth requests, and passing html responses back to the UIWebView, as text to be rendered. Although this worked fine with the old style screens, changes to twitter's anti- click jacking implementation in the new templates resulted in the UIWebView being rendered blank. The solution was simply to get the OAuthHelper code to create the OAuth signed requests, and pass the NSURLRequest directly to the UIWebview for loading directly. Our initial OAuth implementation made use of a PIN based out-of-band flow, however, as part of our redesign we found that we were able to move over to an OAuth callback implementation, which provides a much slicker user experience. To do this: 1. Login in to twitter's developer page and change your applications settings to browser and register a nominal callback URL, say your twitter page (this callback URL is not actually used). 2. Back in your App, define a protocol specific callback url e.g. yourappname://oauth/callback ours was tweetignite://oauth/callback 3. Define the oauth_callback as your protocol specific url in the RequestToken request. [Take care not to over URL encode the callback URL in the header - a big time waster! 8-( ] e.g. OAuth oauth_callback=tweetignite%3A%2F%2Foauth%2Fcallback, oauth_consumer_key=x, oauth_nonce=C8612F28- D307-446B-88E6-4804282CCB4F, oauth_signature=xOKzHrQk4HwhOzdGEdWalVPxF6E%3D, oauth_signature_method=HMAC-SHA1, oauth_timestamp=1306318989, oauth_version=1.0 4. Append the protocol specific url as an oauth_callback parameter in the Authorize URL e.g. https://api.twitter.com/oauth/authorize?oauth_callback=tweetignite%3A%2F%2Foauth%2Fcallbackoauth_token=xxx Once you have implemented this in your OAuth code there are two choices for implementing the webview. You can either spawn the request externally in mobile safari, and add your protocol specific callback URL to your Info.plist, which will cause your app to re- launch when it gets the callback. To get the tokens add - (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url to your AppDelegate and grab the tokens from the oauth_verifier to complete the flow. Or alternatively, as in our case continue to use the embedded UIWebview, which actually receives the callback URL directly in -(BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest: (NSURLRequest *)request navigationType: (UIWebViewNavigationType)navigationType here you can grab the tokens from the oauth_verifier to complete the flow. With the embedded UIWebView approach you need to programmatically clear any cookies twitter sets, before launching a new UIWebView so a new account can be added. Thanks to Ben at twitter for his help with this, and hopefully this will be useful to others migrating from xAuth to a full OAuth flow. Best regards,
Re: [twitter-dev] window.open() and OAuth
Hi Corey, Thanks for your feedback. On May 5, 2011, at 8:15 AM, Corey Ballou wrote: Your new OAuth authentication handler does a check to determine if the window has been opened in a new window and triggers a resize. I'll preface this message by saying that I have a high res monitor at 1920x1600. I currently have handling to center the window. Your new JavaScript is essentially resizing the window outside of the viewport, giving no consideration to the end user's window height or current window position. Is this something that can be resolved? It's kind of a nuisance. I'll repost in the tracker. The auto-resize is not something I'm a massive fan of either, but we implemented it after the redesign because we found that whilst a lot of OAuth implementations are using pop-ups of a fixed sized, a great number of them are also invoking those pop-ups with scrollbars disabled at the window level, which makes important parts of the interface impossible for users to access. Alas, though I appreciate that centering the window is aesthetically desirable, content hidden through disabled scrollbars was a bigger problem, so it's been patched for now. I emphasise ‘for now’ because I know and agree that this isn't an ideal solution. Web content is by its nature of variable length. In this case: • Additional status messages can be displayed in the content. The authenticate flow has an extra header message, and users adding their first app are also given a special greeting message, and offered a link to the help section to explain what apps are. • Items on the page, and in the permission list may be changed, shortened, lengthened or removed outright based on feedback and experience. And, of course, Twitter will add new features over time, or might redesign the site again some day. These are all changes that developers should expect to happen to every web service, not just Twitter, and should code for defensively. What's more, users can, will, and do use browser features such as resizing page text based on their needs, which throws all page size expectations out of the window. Given all of this, it mystifies me slightly that browsers allow scrollbars to be disabled at all, but here we are. I'm keen that we assemble issues like this into a best practices guide. Not disabling scrollbars, and keeping the address bar (and SSL verification stamps) visible are important. There's more too, and I'd like to collect the feedback and experience of developers to help assemble thorough and relevant advice. (Please write in to the usual address.) (This one.) My hope and preference is that after documenting these issues and encouraging their adoption, we can remove the janky resize code and return all pop-up size and shape related issues entirely to the domain of the app developer. Thanks, Ben -- @benward -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] OAuth Authorization screen on Windows Phone 7 (WebBrowser control)
Hi Chris, Matthieu and any others running into this issue: On May 3, 2011, at 5:00 PM, LoungeFlyZ wrote: Something has changed in the last few days and now the page is rendering a little better but scrolling/panning/zooming isnt working i cant enter text in the username or password fields. Is there anything i can do to help diagnose this issue? The update we put out this morning fixes the general rendering of the OAuth screen in WP7 (there's a couple more minor layout improvement tweaks coming as well, but the blocking problem is rectified.) It now works perfectly in Mobile IE on the phone, but for reasons which are inexplicable, loading the exact same page within a phone:WebBrowser control in an application suffers from cropped rendering and the no-scrolling behaviour described here. Having spent a few hours in Visual Studio, and reproduced it, it appears you can work around the issue by setting IsScriptEnabled=False on the control. I'll continue to investigate what's causing the render bug, but the above fix should hopefully set everybody running again. Thanks for your patience, and to Chris and Matthieu for corresponding with me on Twitter whilst debugging the issue. Ben -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] New oAuth Authorization screen is unusable on phone webbrowser control
Hi Bob, Tom, and others, On Apr 29, 2011, at 11:50 PM, Bob12345 wrote: I've been using a WebBrowser control in my Window Phone application to login into Twitter. Today I noticed that the login/authorization page format had changed and it is now unusable in a web browser control that my application displays. The text on the page is squeezed together, and the page unscrollable. I've seen a couple of reports of this concerning rendering in the current browser on Windows Phone 7. This is obviously unintended and I'm working on a fix. On Apr 30, 2011, at 9:09 AM, Tom van der Woerdt wrote: It sounds like all UIWebView, WebBrowser and probably Android's WebView are blocked. This is definitely a *good* thing for security reasons. The workaround I recommend: launch the actual browser, using a yourapp:// link (something like myapplication://tokenDone) as the return URL. This is a LOT safer for the users. Although I'm personally a strong advocate of the protocol redirects, I can assure you that we have not actively blocked access to the OAuth screens in any context or browser with these updates. If you're having trouble with the auth screen in a web view, I'm going to need more information from you because there's no debugging tool for a UIWebView in third party apps. If you can trap any rendering or script errors from a browser view control in your development environment, please send them to me and I'll use them to look for any problems. Email me directly if you prefer. Thanks, Ben / @benward / Twitter platform developer -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
