Here is an example. Remember that MaxID is for the current session and prevents the re-reading of tweets that you have already processed in the current session. SinceID is the oldest tweet you have ever received for this search query, and helps to avoid re-reading tweets that you have already processed for this search term in previous sessions. Essentially, you create a window in which MaxID is the newest tweet to get, and SinceID is the oldest tweet that you don't want to read. In the first session for this search query, you must set SinceID to 1 because you do not yet have a major tweet. After the session, save SinceID so that you do not accidentally re-read the tweets.
static async Task DoPagedSearchAsync(TwitterContext twitterCtx) { const int MaxSearchEntriesToReturn = 100; string searchTerm = "twitter";
This approach looks like a lot of code, but actually gives you more control over the search. for example, you can examine tweets and determine how many times to request based on the contents of the tweet (e.g. CreatedAt ). You can wrap the request in a try/catch to see HTTP 429 when you have exceeded the speed limit, or twitter has a problem that allows you to remember where you were and what was. You can also track twitterContext RateLimit properties to see if you are approaching and avoid an exception for HTTP 429 ahead of time. Any other way to blindly read N tweets can make you give up speed limits and make the application less scalable.
- Tip: Remember to save
SinceID for this search query, if you save tweets so you donโt re-read the same tweets the next time you search with this search query.
For more information on the mechanism behind this, read Working with Timeline in Twitter docs.
source share