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

Reply via email to