lp://staging/~knitzsche/+junk/twitter-go-wip

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

76. By Kyle Nitzsche on 2015-09-29

work in progress

75. By Kyle Nitzsche on 2015-09-28

bug points out that if you have a trend dept open and change location enablement,
the chances are high that the Search() function rebuilds departments such that your
current department probably no longer exists causing a crash.

This commit fixes this by setting twitterScope.DoNotRefreshTrends to true
when a trend is displayed (in getTrend()), only refreshing trends in Search()
when DoNotRefreshRends is false, and resetting it to true in all cases thereafter.

So when viewnig a trend, you can change the location setting without having your
current department structure rebuilt, thus leaving your current department intact.

[1] https://bugs.launchpad.net/hanloon/+bug/1500563

74. By Kyle Nitzsche on 2015-09-28

clean up prints to log

73. By Kyle Nitzsche on 2015-09-28

The scope monitor calls to each twitter API in a sliding window. If the next call would exceed the rate limit one of two things happens:
--> NOT NEW WITH THIS COMMIT: If the twitter call would return results like tweets, friends, favorites etc, I display the cached results from the last successful call
--> NEW WITH THIS COMMIT: If the twitter call was for something with no cached results (like follow/unfollow & favorite/unfavorite), a "Sorry!" message displays

72. By Kyle Nitzsche on 2015-09-28

proper rate limited message to log

71. By Kyle Nitzsche on 2015-09-27

now rateCheck is used to see if the next twitter api call (through httpAuth())
would exceed the rate limit. If it would, the call is not made and, when the
type of call permits use of a cache file, for example showing home timeline,
the cache is used. When the call does not permit, for example retweeting, nothing
it done currenlty: I need to consider adding a result message to tell the user
that they could not retweet, reply, friend, unfriend, favorite, or unfavorite
due to exceeding rate limit and they should try again soon.

70. By Kyle Nitzsche on 2015-09-27

in added rateCheck(), only used now in getFavorites(), but it checks whether
the twitter rate limit would be exceeded by the next call, and if it would be,
it uses the cached last response instead. Now I need to implement this for
all twitter api calls and pass the right rate limit params per
https://dev.twitter.com/rest/public/rate-limits

69. By Kyle Nitzsche on 2015-09-25

added Followers department with Preview showing either Follow or Unfollow
depending on whether the follower is a friend

68. By Kyle Nitzsche on 2015-09-25

refactoring to more staightforwardly construct Preview buttons based on
type (tweet or friend) and other key bits like whether is a favorited tweet
and whether tweeter is a friend (for follow/unfollow buttons)

67. By Kyle Nitzsche on 2015-09-25

add getFriendIDs() which gets up to 5000 of your friend ids from twitter.
This is called on each Search() and will be used (next) to determine whether
display Follow and Unfollow buttons (which is a better method than currently
used)