Hey Zac, That's what I decided to do too.
Interested in your point of concern given as an example though. MGTwitterEngine gives you a UUID for each request right? So you should be dropping those into an array for your tracking purposes so you know where they came from and what for (and which account), and then respond appropriately? One of the things I didn't like about it is that I couldn't find an easy way to gain access to the response body if an error occurs. I realized the subset of API calls I need is so small that I should just roll my own anyway though.. Tim. On Thu, Nov 12, 2009 at 10:26 AM, Zac Bowling <zbowl...@gmail.com> wrote: > I give mgtwitterengine credit for being there (was there for me in a snap > once) and being there first for cocoa devs to drop in, but there are some > nasties to it. It's async callback/delegate pattern is odd (try supporting > multiple accounts with it and you understand quickly that you don't where > the data is coming from because there is no handle back to the account). > Twitter's api isn't overly complicated so it's easy enough to roll your own > API wrapper, which is what did in my own project. > > Zac Bowling > @zbowling > > On Nov 10, 2009 3:01 PM, "Tim Haines" <tmhai...@gmail.com> wrote: > > Hey guys, > > Has anyone added list support to @mattgemmell's MGTwitterEngine yet? > > Cheers, > > Tim. > >
