Community enabling an application can be a pain – far harder than it needs to be. One of the biggest reasons for this problem is OAuth. Requiring a mobile application to open an 800×500 html window is unrealistic, exacerbated by graphic designers who think that a web page is the answer to every problem (remember the saying about how “to a man with a hammer, a screw looks like a nail”?). The sensible solution can be secure http connections with REST/JSON APIs, but it isn’t opening a web page!
So, if your problem is Twitter, XAuth is the answer – or part of it. The “standard” solution to Twitter integration is MGTwitterEngine, but it has been very slow to support XAuth. Various people have made their own forks of MGTwitterEngine in the middle of the enhancement process, and released their own “solutions” with frozen copies of half-upgraded MGTwitterEngine and other necessary components.
This forced me to work out my own solution, free of all the crud and using current versions of the standard components. But that’s not all… there is also a user experience issue, as we should be authenticating each application one time only, and enabling a separate UX that permits deauthenticating when required. So here is my solution; a demo application using two standard view controllers, one for posting, one for authenticating, with instructions on how to get your XAuth code, and how to keep your MGTwitterEngine, OAuthConsumer and HFSFKeychainUtils current – all supplied as unmodified source files. Look at the README.TXT inside the project.
The basic principle is to call TweetController modally from one of your controllers, and implement the delegate protocol to dismiss the controller when it’s done. Make sure that you have put in your application’s XAuth key and secret into the .m file, or this won’t work. If there is no OAuth secret stashed in the keychain, the TwitterAuth view controller will be displayed modally. It asks for username/password, then talks to Twitter. The details are saved to the keychain, which ensures that they are encrypted, which means that they are safe from iPhone hackers – a good ploy for any login details. The posting interface has a button to remove the authentication from the keychain, plus a button to turn on and off geolocation details – defaulting to off. There’s a simple text length counter included in the UI, and the API lets you set a starting value for the post text.
Source code (including current versions of the components, please update them!) here.
Post a Comment