better documentation for sender property, change to senderId, add senderDisplayName

[jessesquires]

see #328

I don't see it documented that sender has to be unique. What it says is "The name of the user who sent the message" which leads you to think it really is just the user's name, which doesn't necessarily imply uniqueness. Coupled with the text property of JSMessageData, I think most people are going to assume that sender is intended for display purposes.

The same applies to the sender property on JSQMessagesViewController. It is documented as "The name of the user sending messages". It's supposed to be a unique string as well, right?

And the demo uses display names for sender, which again doesn't imply uniqueness.

I'd suggest better documentation or rename sender to senderID.

[jessesquires]

Fix:

1. change sender to senderId as NSUInteger NSString
2. provide senderDisplayName as NSString
3. update docs to reflect uniqueness requirement

[wdcurry]

I thought this was purposely set this way because the library is agnostic of the data storage medium, and it is our responsibility to translate the inbound data object into the message itself. This may provide a bit of fuzziness, even if the uniqueness is more apparent. Frankly, it need not be unique as "Sue" could chat with "Sue" ..
Not convinced this is worth it.

[laynemoseley]

I don't think this has much to do with the data storage medium, but with the fact that you shouldn't be identifying someone uniquely by something that's inherently not unique. There is uniqueness logic around this value, but the value itself has no guaranteed uniqueness. I think this is a good change.

[jessesquires]

@wdcurry - that's correct, this lib is data-agnostic. My comment above applies to changes that will occur in the JSQMessageData protocol. It's an extremely minor change.

[markkrenek]

Excellent.

[isaced]

Yes, I need senderId and senderDisplayName property!

[pflenker]

Also, the example project isn't clear enough on that self.sender needs to be set in order to display the avatar on the correct side. While the documentation states that this value must not be set to nil, the implications of not setting this value are unclear - thus, it's hard to debug if the avatars are all shown on the left side, even on outgoing messages.

[jessesquires]

Completed and set for 6.0 release. See branch release-6.0.

See release 6.0 milestone details here

[rahulgautam]

Hii @jessesquires ,

I would prefer that senderId property should be NSString rather than NSUInteger.
As senderId could be anything for an API User that uniquly identify its app-users, In most cases these days, it is in form of UUID.

[jessesquires]

hey @rahulgautam - that's how I ended up implementing it (NSString), the comment above has been updated to reflect this.