Represents a Twitter user

Methods
Included Modules
Public Class methods
attributes()

Used as factory method callback

     # File lib/twitter/model.rb, line 166
166:       def attributes; @@ATTRIBUTES; end
featured(client)

Provides access to the Featured Twitter API via the Twitter4R Model interface.

The following lines of code are equivalent to each other:

 users1 = Twitter::User.features(client)
 users2 = client.featured(:users)

where users1 and users2 would be logically equivalent.

    # File lib/twitter/extras.rb, line 35
35:     def featured(client)
36:       client.featured(:users)
37:     end
find(id, client)

Returns user model object with given id using the configuration and credentials of the client object passed in.

You can pass in either the user‘s unique integer ID or the user‘s screen name.

     # File lib/twitter/model.rb, line 173
173:       def find(id, client)
174:         client.user(id)
175:       end
Public Instance methods
bless(client)

Override of ModelMixin#bless method.

Adds followers instance method when user object represents authenticated user. Otherwise just do basic bless.

This permits applications using Twitter4R to write Rubyish code like this:

 followers = user.followers if user.is_me?

Or:

 followers = user.followers if user.respond_to?(:followers)
     # File lib/twitter/model.rb, line 188
188:     def bless(client)
189:       basic_bless(client)
190:       self.instance_eval(%{
191:         self.class.send(:include, Twitter::AuthenticatedUserMixin)
192:       }) if self.is_me? and not self.respond_to?(:followers)
193:       self
194:     end
friends()

Returns an Array of user objects that represents the authenticated user‘s friends on Twitter.

     # File lib/twitter/model.rb, line 214
214:     def friends
215:       @client.user(@id, :friends)
216:     end
is_me?()

Returns whether this Twitter::User model object represents the authenticated user of the client that blessed it.

     # File lib/twitter/model.rb, line 199
199:     def is_me?
200:       # TODO: Determine whether we should cache this or not?
201:       # Might be dangerous to do so, but do we want to support
202:       # the edge case where this would cause a problem?  i.e. 
203:       # changing authenticated user after initial use of 
204:       # authenticated API.
205:       # TBD: To cache or not to cache.  That is the question!
206:       # Since this is an implementation detail we can leave this for 
207:       # subsequent 0.2.x releases.  It doesn't have to be decided before 
208:       # the 0.2.0 launch.
209:       @screen_name == @client.instance_eval("@login")
210:     end