07-06-2011 04:00 PM
Are there any future developments with regard to registering a custom protocol handler for your Playbook Tablet app like there is with Android?
After looking at the Web Works docs it would seem all device specific calls are available already through a custom protocol called webworks://
I think there should be a way to define these in the descriptor to use with things like OAuth2. Currently the userr journey on an OAuth2 implementation is rather difficult on the Playbook. A custom protocol would mean one can specify this as the redirect_uri parameter and the browser will automatically redirect back to your app.
07-26-2011 12:35 PM
Can you provide more details in your difficulty in implementing our custom protocol handler, and in comparison to android, how it can be made easier so that you could implement an OAuth2 protocol.
Can you also provide some possible use cases so I can better understand the context.
Looking forward to your reply.
07-26-2011 12:52 PM
A custom protocol handler is not needed for OAuth/OAuth2. You can add a StageWebView (or the QNX equivalent) in your app, and use that to show the user the page. Listen for navigation events, and examine the URL to see whether it matches your callback page. If so, cancel the navigation and continue your OAuth procedure. The protocol oft the callback page does not matter, it will never be loaded.
08-09-2011 10:16 AM
That sounds like a possible work around but a bit of hack no? Also how would that work for a Web Works app that is running "local" HTML files?
If oath2 supports callback redirects then the appropriate mechanism to do this would be using a custom protocol handler. Not only do you solve the horrible user journey but also the implementation for a Web Works application.
The way I see it the following usecase applies:
My gripe at the moment and what was presented by Adobe, is that oauth2 implementation requires a static login which leaves the user looking at a page with a random number on. This number then needs to be copied to the clipboard and pasted into your app should you wish to make API calls.
Nevertheless I may give this a go using StageWebView for an AIR application.
08-09-2011 10:31 AM - edited 08-09-2011 10:33 AM
Certainly not a hack, it's standard practice in AIR and actually a much better solution.
A protocol handler would be system-wide and would be much more prone to errors, whereas this can be local to a specific view or screen in your app. If your app uses OAuth with multiple services (e.g. for Facebook, for Twitter, for Google) then you'd want it to be local.
For the user this experience is seamless. Try it out with the Google Docs connector in Files & Folders. You tap the "Google Docs" button, which takes you to Google. There you log in with your Google account and tap the "Grant access" button. Files & Folders detects the callback URL and extracts the token granted. No random numbers in sight.
The only drawback is that the user needs to log in even if he was logged in before via the browser, because the StageWebView has its own cookies.
As for WebWorks... this is the Adobe AIR forum. No WebWorks here.
08-09-2011 10:52 AM
I appreciate your response but spare me the "this is the AIR forum" lecture. I posted a generic question which was moved here after it was dismissed in the previous forum. If you read my original post you would notice I mentioned Webworks already has a protocol in place. So I don't see why this should be a problem for AIR.
I will give the StageWebView approach a go.