Yesterday I updated the main branch of MGTwitterEngine by combining my fork with tarasis and alexrepty forks. With over 35 some commits in all, I felt lucky there was very little manual merging required.
Since Matt has created and official source of MGTwitterEngine I feel like it's gained a lot of momentum. There are 8 active forks, feature requests and bugs reports starting to accumulate in the issues list, and over 180 watchers.
I've been adding support for the Github API to my fork of CocoaREST. Right now I've added:
In addition I've added a tab to the demo app to show some of these. In it you can view user information by name (SDGithubTaskUserShow) and get a list of repositories (SDGithubTaskGetRepos). The tableview is set run a new task to find forks of the selected repository (SDGithubTaskGetRepoNetwork) on selection change.
The GithubDelegate is kind of a cumbersome class in that it handles all of the task results even though the API returns different results for each task. Ideally I would use a specialized class to delegate for each task, but it's just for demonstration.
My latest tinker project is a Twitterific like application that monitors your Github dashboard, showing both updates to who you follow and updates on any repositories, yours or forks of yours. From what I've seen Github's API supports all of this.
To accomplish this I'm extending Steven Degutis's CocoaREST framework to support the Github API in my fork of the project. So far I've got repository listings by username, and showing forks in the network setup. There's a lot more to integrate but I'm not sure how much I want to demo in the UI.
I also added a tab strictly for Github, with the idea being a tab for each API supported, but I haven't dug into any other API beyond Twitter or Github's I'm not sure when those will come. Patches welcome of course.
Today I posted my update to ctshryock/MGTwitterEngine which allows you to use the API's update_profile_image and update_profile_background_image. I added to the demo app a window that lets you select an image for either profile image or background image to see it in action.
I had to modify some of the internals to get this to work... originally the _sendRequestWithMethod:path:queryParameters:body:requestType:responseType: method built the NSMutableRequest object internally, but to minimize code duplication I split the initial creation of the request into a new method _baseRequestWithMethod:path:queryParameters: to do that, and added a new method _sendDataRequestWithMethod:path:queryParameters:filePath:body:requestType:responseType: . Both _sendRequest... and _sendDataRequest... call _baseRequest... to start, with the latter adding the needed form/multipart data to the request.
I originally found EMKeychain a few months back and added it to my project to take over managing interactions between my app and the Keychain. It worked well until I updated to Snow Leopard and started using the LLVM GCC 4.2 compiler. Doing so threw some new errors about non-explicit casts and deprecated methods. I went in search of an update on Extendmac's site and by chance found @sdegutis's fork of the project on GitHub.
I forked the project here and started replacing my current EMKeychain setup with this new one. The newer isn't terribly different but it went from 4 files to 2, and we're not using "proxy" object anymore instead just class methods for getting / creating keychain items.
One thing I did notice is the inconsistent results, but I don't think it's due to this newer version. I created a temp project and ran a loop getting and printing a specific keychain password 10 times and got the actual password, null, or the password with some extra characters at random times. Not encouraging.
Luckily I did track down the issue; the raw char password wasn't being converted to an NSString object correctly, so I was able to write a patch using the C strncpy method. You can check out my *fixed* version with the link above, but I did find in the network what is probably a better fix with user irons fork, which I plan on integrating soon.
