- Just one capture session per input component.
- Avoids starting/stoping capture during collection reloads, which can make the live camera take longer to capture or even hang.
- Moves creation/destruction of capture session to the background: when opening/closing the input component many times it was resulting in capture start / stop blocking the main thread for some seconds on iOS 8
- Queues updates in the collection view: doing a reloadData right after reloadItemsAtIndexPaths (update video) results in the visible cells not being refreshed
Adds more customizable options to the input bar
Bar with icons gets customizable height
Buttons get customizable intrinsic contentSize, so they can be bigger and easy to tap
Buttons get customizable images for any UIControlState
Send button gets customizable text colors for any UIControlState
Also allow user to override layoutConstants in
BaseMessageCollectionViewCell and allow user to specify
VerticalAlignment of avatar: Top, Bottom or Center
Now DataSource is responsible for notifying the exact type of change. This implicitly allows more flexibility in the dataSource ( like ignoring such a request! ) and reduces entry points from where changes are enqueued
MessageModelProtocol should not require setter for status property.
MessageViewModelProtocol should not require messageModel property.
Both are convenience shortcuts for DemoChatApp and should be removed since they are not used by ChattoAdditions framework.
Previously, due to the mapping between chatItem instance and presenter, a new presenter would be created. This fixes:
1) That new presenter will have invalid itemVisibility property (would cause a crash when long pressing a text cell)
2) If a new chatItem instance is returned by the dataSource for a previous existing message, but the previous chatItem is leaked, then the presenter would leak too (and it might try to update its cell, as in downloading an image)
This introduces ChatItemCompanion, a structure which attaches a ChatItem with its presenter and decoration attributes. This solves 1) and 2). Still new instances of presenters will be created for new instances of chatItems --> Presenters should avoid keeping any state in its internal storage.