Chris, I've implemented this in my client, which you are free to look at if you feel it would be helpful (http://code.google.com/p/quitter- client).
I do a read of the "Friends" timeline, and display to the user only those tweets from members of the selected group. I do this by checking each status in the timeline to see if it should be displayed or not and setting a Boolean value accordingly. The "display" code reads the entire timeline and only displays those tweets that are flagged as being from a member of the group. Regards, Duane On Aug 20, 11:32 am, Chris Babcock <cbabc...@kolonelpanic.org> wrote: > On Thu, 20 Aug 2009 07:20:28 -0700 (PDT) > > > > > > Ryan Bell <ryan.j.b...@gmail.com> wrote: > > > Twitter Groups: I am adding the ability to create custom 'groups' of > > twitter users to my site. My current approach seems very processor/ > > twitter api intensive. Can anyone make a recommendation or refer me > > to a link where I can find information on how I might more efficiently > > code this feature? > > > Any help is appreciated. > > > Current Approach: > > 1. User can put n users in a group > > 2. User clicks their group to view the timeline > > 3. Iterate through all 'n' users in the group and get the respective > > user's timelines > > 4. Merge the timelines into a collection. > > 5. Sort the timelines by date > > 6. Bind this collection to the display grid. > > 7. This timeline is immediately out of date of course so a click of > > the 'refresh' button triggers the need to do the entire process again. > > You need a local data store - at least as a cache even if you don't > provide permanent storage. > > You can take a queue from the Twitter API and cache compiled results so > that the user isn't causing your site to poll Twitter more frequently > than Twitter is willing to give you fresh results. > > Don't poll each group member's statuses individually. Poll the user's > friends/home timeline in aggregate, remove non-members, then merge in > those who are member's of the group that your user is not following. > > Use the "since_id" parameter to only fetch new statuses. > > Choose a sort algorithm optimized for a merge of previously sorted data > streams. > > Don't fetch all your streams then sort. Merge your most recent fetch > operation while you are executing the next fetch. > > Find a good book on data access patterns. > > Best, > Chris Babcock