Customizing typing indicators.

[sveinhal]

Hi, @dzenbot

I created an issue before creating a pull request, because I want to discuss solutions before submitting anything. I am willing to produce the code necessary to close this issue, once consensus has been reached.

I want to customize the typing indicators to show small avatars instead of the user name list as the current design encourages. The SLKTextViewController currently instantiates and hold a reference to a SLKTypingIndicatorView. However, except for an isVisible and an canResignByTouch property the view controller couldn't really care much what kind of UIView subclass this view is (and long as it knows when to show/hide the view).

I'm thinking that we could extend the view controller to also have a method called registerClassForTypingIndicatorView: similar to registerClassForTextView:. But I'm not sure it's necessary to have it be a subclass of SLKTypingIndicatorView? I think that the view controller can observe changes to the hidden property instead of relying on the custom notifications. This also uses hidden rather than visible, which is more cocoa-y. And for the canResignByTouch property, we can either have the custom class implement a protocol, or move the logic to be a property of the view controller instead.

Alternatively, we could require that the custom class must be a subclass, but personally, I'm not really using any of its features.

What do you think?

[sveinhal]

Hmm.. Making the typingIndicatorView be of type UIView * will break code like this:

[textViewController.typingIndicatorView insertUsername:@"some user"];

Bah. Maybe a subclass must be required for backwards compatibility of the API.

[dzenbot]

Thanks @sveinhal for bringing this up. I've been wanting to decouple the typingIndicatorView to allow further customization too.

registerClassForTypingIndicatorView: sounds like a good starts, following the same pattern than registerClassForTextView:, and this way, opt-in for a custom view.

I don't think it would be necessary to subclass SLKTypingIndicatorView to allow this, since SLKTextViewController isn't so coupled to that class. Instead, we could create a generic protocol wrapper:

@interface SLKTypingIndicatorView : UIView <SLKTypingIndicatorProtocol>

These would be the required accessors to conform to SLKTypingIndicatorProtocol:

// To let its parent controller (aka SLKTextViewController) know is visibility state and allow backwards compatibility.
@property (nonatomic, readwrite, getter = isVisible) BOOL visible;

// To allow a good auto-layout compatibility
- (CGSize)intrinsicContentSize;

I think this should make the changes pretty straightforward, and also, deliver a simple to use API to any user that would like to extend the built-in typing indicator by creating its own approach.

What do you think?

[sveinhal]

Is API backwards compatibility a requirement? If so, some people may have called insertUsername: directly on the return value from typingIndicatorView on the view controller. If we change it to have type UIView<SLKTypingIndicatorProtocol> it will no longer compile. The user would have to cast the return value to the appropriate implementation, or insertUsername: et al must be added to the protocol.

[sveinhal]

… or we break source code compatibility.

[dzenbot]

Good point. I will think about this, since I wouldn't like to add all the properties and methods to the new protocol. Any suggestions?

[kousun12]

+1 on this, would love to see some flexibility here. I think as this project gets more popular, it might make sense to think more about generalizing a little outside of the context of messaging, which I think might inevitably call for some breaking API changes. Though no easy answer to how to go about deprecating/breaking a new major release.

I'd like to use it as just a generic indicator view, semantically detached from a concept of user typing. So in that sense the current api of <insert>|<remove>Username is a more restrictively opinionated than ideal for my use case. A bit more concrete in my example -- I'd love to put something like an indicator for sound coming out of the microphone in that spot. I could see a protocol like IndicatorView that requires intrinsicContentSize (and maybe canResignByTouch?) working out, but really I'd be a fan of the indicatorView property of SLKTextViewController to be Plain Old UIView. Thoughts?

[sveinhal]

Suggestion: Add a general indicatorView of type UIView<SLKIndicatorView> property of the view controller, but keep (for backwards compatibility, but possibly deprecate) a typingIndicatorView of type SLKTypingIndicatorView that uses the indicatorView under the hood. That is, accessing the typingIndicatorView will lazily load the current implementation if indicatorView is nil.

[dzenbot]

Sounds like a good plan!

[sveinhal]

Ok. I'll make a first take on an implementation, and create a pull request :-)