Aral Balkan

Unable to sleep, I instead spent the last hour porting Feathers from XAuthTwitterEngine to MGTwitterEngine (see my previous post for background).

Here are a few notes to help you for when you decide to the same:

• Replace all occurrences of XAuthTwitterEngine in the code with MGTwitterEngine (and remove references to XAuthTwitterEngineDelegate).
• The designated initializer for MGTwitterEngine is initWithDelegate (as opposed to initXAuthWithDelegate in XAuthTwitterEngine) – make sure you update your code.
• Remember to call setConsumerKey:secret: on the MGTwitterEngine instance before anything else. MGTwitterEngine doesn't have XAuthTwitterEngines consumerKey and consumerSecret properties.
• Remember to call setAccessToken: on the MGTwitterEngine instance before trying to make calls (XAuthTwitterEngine doesn't have/call the cachedTwitterXAuthAccessTokenStringForUsername: delegate method to request the access token.
• Note that MGTwitterEngine takes OAToken instances (XAuthTwitterEngine used to take the HTTP response string). See the migration section, below, for more information on switching over.
• Remember that your MGTwitterEngineDelegate success and failure methods will get called for the xAuth token exchange call also.

Migrating your users

The important bit to watch out for is migrating your users from XAuthTwitterEngine to MGTwitterEngine without asking them to re-authenticate. To do this, you have to create an OAToken instance from the saved HTTP response string and save the token key and secret in the keychain. Once you've done this, you can safely ignore the legacy HTTP response string in future calls.

To translate the HTTP response bodies used by XAuthTwitterEngine to OATokens, use:

OAToken *token = [[OAToken alloc] initWithHTTPResponseBody:tokenString];

Hope this helps you while migrating.