MessageKit v1 Vision

I'll put together a Vision.md but for now here are some basic thoughts for v1.

Basic Features

Message Bubbles Incoming/Outgoing
Message Avatars
Basic Text Messages Support
Resizing Messages Based on Text Length
Input Bar With Send Button
Move Input Bar When Showing Keyboard

Other thoughts

Writing tests from the start is easier and provides more benefits than adding them later 👍

Feel free to discuss any thoughts on:

v1 features
API/Architecture
Anything you'd change from JSQMessagesViewController?

Please use bullet points to make things easier to digest

@jessesquires

Regarding "Input Bar w/ Send & Attachment Buttons", I'm wondering if we should implement the "attachment" functionality into this lib (assuming it would open the gallery for the user to select a photo/multiple photos). What if we didn't go with this assumption and let the developers implement it themselves?

Maybe they don't want to have a button for attachments, but rather some other functionality (lets say to record a small voice chat message). Instead what we could do, is provide an easy way for devs to add their own custom buttons and their own custom code when the user taps on it.

I'm just thinking about making MK as flexible and customisable as possible, without "hardcoding" too many things (like opening the photo gallery and dealing with the implementation, that should be up to the devs to handle it themselves imo). MK should just focus on the core UI for the actual Messages ViewController.

Another thing I could think of is making the "Input Bar" changeable. We can provide a default implementation with a basic input bar and send button, but devs can easily "plug in" their own custom implementation of it (using protocols). They might want to have fancier animations (expand and shrink the input textfield based on whether or not it is focused etc).

I don't know, it's open for discussion. Maybe I'm just over-complicating things here. :)

I would definitely be for writing tests from the very beginning. 👍

I would also like to avoid the Massive View Controller approach that JSQMessagesViewController took and break things down into smaller, maintainable classes.

@jessesquires I remember reading a few times that you wanted to update the architecture of JSQMVC eventually but never got around to it. Did you ever start with that? I guess what I'm asking is did you ever start thinking about how you'd break the huge VC down into smaller pieces? If so, it would be great if you could share your thoughts about it. :)

@jyounus

@jyounus We have to start with something small and then add features from there. Just like Rome, JSQMVC wasn't built in one day 😂

Features such as photo picking or any other complex media items are out of scope for v1.
I really just want to flesh out the core components:
- MessagesController & MessagesCollectionView
- Layout & Bubbles
- Delegate & Datasource API

Two more things:

Let's try to use bullet points to make discussions easier to digest.
Let's not ping Jesse too much 😅 He's likely immune to it but he deprecated JSQMVC for a reason.

Similar to the proposed changes in v8.0 of JSQMessagesViewController treat each cell as a section instead of a row.
Add support for message clustering ala Facebook, I've done this on my fork of JSQMessagesViewController.
Perhaps support AsyncDisplayKit? https://github.com/eBay/NMessenger is built with AsyncDisplayKit and has quite a few stars.

@ay5000

@ay5000 Thanks for bringing up the issue of treating cells as sections instead of items. These are just the things I'm looking for.

I'm not familiar with message clustering but it's something we can look at.

I'm really interested in AsyncDisplayKit but I think this would have to be an opt in feature. The goal is to limit dependencies and keep the barrier to entry low.

Do we want to force bubbles or should we allow for SlackTextViewController like cells?

@SD10

Major things to address from JSQMVC (some of these are noted above, but I'll reiterate):

avoid the "massive view controller" problem, in particular make dataSource/delegates separate objects, make a separate controller to handle UIMenuController stuff
make custom dataSource/delegate protocol (like JSQMVC) but do not inherit from UICollectionViewDataSource/Delegate. (yes, this would give you 2 dataSources and 2 delegates. trust me, this will be easier and more flexible. it will also allow clients to use something like IGListKit, which owns the UICollectionView... components)
I would avoid clustering and other advanced things for v1
Do not use UITextView. It has a number of problems. I'd start with UILabel, then maybe try TTTAttributedLabel (although this project is suffering from neglect, too. perhaps a new project under the MessageKit org could "re-write" this)
Make the dataSource section-based, meaning each message is in it's own section rather than having 1 section with 0 to N items. Specifically, this will make message bubble headers/footers way easier (in fact, trivial) to implement, which brings me to...
The message bubble cells should only contain the bubble (with text/image/etc) and avatar. The timestamp, username, delivery status, read status, etc. should be their own cells or supplementary views (headers/footers) for the section
As @SD10 mentions, I would try to avoid dependencies. In fact, if v1 doesn't have any, I think that would be great
RE: message bubbles above, I would not use images. I would just use rounded-rect UIView/CALayer. The image assets added bloat to the lib. If the bubble is just a view, clients can easily customize
Finally, I think the thing that really made JSQMVC great was that it provided customization hooks for mostly everything, but also provided sensible defaults. (Example: you could provide your own bubbles, or just use the default bubbles.) This made it easy to get started and have something working very quickly, with customization coming later little by little.

Hope this helps! 😊 If anything is unclear, let me know!

just discovered this, which might be of interest: https://github.com/darrarski/Messages-iOS

@jessesquires

@jessesquires This is some priceless advice 👏 👍 I'm good on every point but just a bit lost on having the 2 dataSource and 2 delegate protocols. I'm also not familiar with IGListKit... yet 😅

@efremidze I don't want to force anything. We can default to bubbles for nostalgic reasons, but the user should be able to override as much as possible.

@SD10

@SD10 so you would have:

var messagesDataSource: MessagesDataSource
var messagesDelegate: MessagesDelegate

var dataSource: UICollectionViewDataSource
var delegate: UICollectionViewDelegate

i.e., keep them all separate.

Which reminds me, I'd strongly recommend using UICollectionViewController too, actually. By default, this implements the dataSource/delegate -- however, you can create your own class that conforms to these and re-assign self.collectionView.dataSource = myDataSourceObject

Guys this is awesome! I actually made my own MessagesKit Project but I think you have a good thing going here and would love to be apart of it. I have spent the last 2 years working with JSQMessagesViewController and was supper stoked to get MessagesKit up and running. I like all the ideas that have been shared here and would encourage more discussions to be broken off of here and continued but would urge that we bring this one to a very simplistic V1. This week has been a rollercoaster trying to figure out how to get this effort started and how to get this going and after reading through what has been shared I have thought and continue to think the most important thing is ease of use.

Often times this is the first framework that people will use to get into development on iOS and there is nothing more frustrating then not being able to even get it to build. So I would propose we put together the core ideals of this project and how it will be developed.

Everything that can have a default should but also is customizable.

I would also purpose that we make it easy for people who would like to contribute to do so. Starter Tasks are a great way to grow the community and to get others to get involved. Creating Tasks that help outline what needs to be built that can be picked up by anyone would be awesome. I also think it would be nice to make sure no one gets overloaded. I know I cannot devote 8hr a day to this (even tho I want to) to get it back to where it was.

Some guidelines and code standards would be nice to get in place now before too many things get started.

I would go so far as to suggest that

Input Bar w/ Send & Attachment Buttons

becomes

Input Bar w/ Send Button

because that is the bare minimum needed to do chat.

@jessesquires

@jessesquires Sorry, I guess I was more concerned about the two sets of protocols and their relationships.

It looks like we would default to calling messageForItem(indexPath:) inside of collectionView(cellForItemAt:) and configure the cell? I'm just wondering if this relationship is ok based on your suggestions -- essentially, you're only suggesting we don't implement an inheritance relationship.

public protocol MessagesDataSource {   
    func messageForItem(at indexPath: IndexPath, in collectionView: UICollectionView) -> MessageType
}

extension MessagesViewController: UICollectionViewDataSource {

    collectionView(_ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath) -> UICollectionViewCell {
        let messageType = messagesViewControllerDataSource.messageForItem(at: indexPath, in: collectionView)
        // configure and return MessagesCell based on message type
    }
}

The only question that ever really stuck out to me is why you made the design choice to have a JSQMVCDataSource method that returns data instead of a UICollectionViewCell subclass. I have some ideas but this post is getting too long to guess.

@MacMeDan

@MacMeDan Welcome, we would love to have you!

I completely agree with you on ease of use. JSQMVC was the 2nd third party library I ever used 😃.

Starter tasks, task outlines, code standards. These are all important to me as well. I think shipping a basic v1 will set some standards and make it easier for others to contribute. It's easier to build features than the foundation.

I definitely agree with your vision of dropping the attachment button for v1. It should be a barebones core of the project.

As for making sure no one gets overloaded, this is open source, and while sometimes it may feel like a job for a maintainer -- ultimately the goal is to have fun. If anyone ever feels like too much is being asked of them, just say something 😃

@SD10

@SD10

The only question that ever really stuck out to me is why you made the design choice to have a JSQMVCDataSource method that returns data instead of a UICollectionViewCell subclass.

This was to follow the principle of "sensible defaults, but customization hooks". If you never wanted to customize cells (beyond bubble color), you never had to touch that -- just return your models. 😄

What about the idea of populating the conversation tableview from the top? I imagine a pagination from bottom to top, but the problem with dynamic cells is to maintain the offset to the cell showed when the pagination starts.

@jessesquires

Just a couple high level suggestions:

Find a way to include NSAttributedString. I don't know if this is related, but @jessesquires, can you tell us what problems you had with UITextView? The known issues may help guide some early decisions. I've met some performance issues with pushing the limits of NSAttributedString, but there is a need for data detectors (aka clickable links) from the get-go.
Small nitpick, but instead of referring to incoming and outgoing bubbles/messages, it helps API consumers to think of things as left/right. Or even better... leading/trailing. Just an observation that created a little friction when I first used it.
Although I don't have any specific suggestions, I think some philosophical discussions should be had on the customization. Like Jesse said, "customization hooks for mostly everything, but also provided sensible defaults", but I would probably dial that up just a bit. I think with Swift protocols/decorators/whatever, we can provide lots of customization and not only sensible defaults, but a plugin architecture where the community can provide nonintrusive drop-in customizations for styling and behavior.
+1 on the idea of generating the bubble with CALayer/Core Graphics instead of an image.

@SD10

Hey, @SD10 what about a Slack channel for the MessageKit community?

About slack channel see #6

I feel like the scope for v1, included in the first post in this thread is pretty great. It has all the basic functionalities needed to get the project running, and other stuff can be easily build off that.

For the level of customization for the first version, I can think of colors, paddings, margins, corner radius, and borders of message bubbles, and conversation background.

Edit: Unfortunately due to the decisions to drop Objective-C compatibility, I can't justify my (or my company's) time contributing to this project. Wishing good luck to all involved.

@mszaro

@mszaro I'm sorry but I don't think Obj-C friendly APIs will be a core goal of this project. For those who need an Obj-C messaging library, JSQMessagesViewController will still be great for a long time to come. The goal is to write this project with an idiomatic Swift API. That being said, this is a community and I'm open to discussion. It's just low priority for me right now.

@SD10

Just to carryover my comments from #1 into this issue so it is properly accounted for here since not everyone reads every comment on issues.

I am in complete agreement with @SD10 about making this 100% focused on Swift and not Objective-C.

Every discussion on these issues is about JSQ. Sure, that is a prime inspirational basis for this project, but does that mean we let the muse dictate the future instead of the artists?

We need to ask ourselves: what would a luddite do? Then go with the opposite.

Just a few more things to go for v0.1.0:

Move Input Bar When Showing Keyboard
Clean up access control
Deciding what to expose via delegates for customization

@SD10

@SD10 you don't have to manage input bar's layout manually. You can add it to view controller as a input accessory view. It will stick to the keyboard as in stock Messages app. You can check my example implementation.

@darrarski

@darrarski interesting 👍 but you don't seem to have the input bar pinned to the bottom of the UIViewController, do you? The input bar can't be both a subview of my main view and an input accessory view.

@SD10

@SD10 that's correct. I didn't added it as a subview to view controller's view. If you use it as a input accessory view, it will appear just like in Messages app. I think this is the best way to achieve correct behavior of the input field.

@darrarski

@darrarski wow I'm behind the times 😅 thanks for the tip!

Thank you everyone for your suggestions ❤️
I just released v0.1.0 and I'm closing this in favor of #12.

Merge pull request MessageKit#2 from Health2Sync/main-justin

Navigation Menu

Repository navigation

MessageKit v1 Vision #2

Basic Features

Other thoughts

Feel free to discuss any thoughts on:

1 remaining item

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

MessageKit v1 Vision #2

Description

Basic Features

Other thoughts

Feel free to discuss any thoughts on:

Activity

jyounus commented on Jul 19, 2017

SD10 commented on Jul 19, 2017

ay5000 commented on Jul 19, 2017

SD10 commented on Jul 19, 2017

efremidze commented on Jul 19, 2017

jessesquires commented on Jul 19, 2017

jessesquires commented on Jul 19, 2017

SD10 commented on Jul 19, 2017

jessesquires commented on Jul 19, 2017

MacMeDan commented on Jul 19, 2017

SD10 commented on Jul 19, 2017

SD10 commented on Jul 19, 2017

jessesquires commented on Jul 20, 2017

pmusolino commented on Jul 24, 2017

1 remaining item

dusty-commits commented on Jul 24, 2017

LucianoPAlmeida commented on Jul 25, 2017

towry commented on Jul 25, 2017

ampatalas commented on Jul 25, 2017

mszaro commented on Jul 26, 2017

SD10 commented on Jul 26, 2017

TheDarkCode commented on Jul 26, 2017

SD10 commented on Jul 26, 2017

darrarski commented on Jul 26, 2017

SD10 commented on Jul 26, 2017

darrarski commented on Jul 26, 2017

SD10 commented on Jul 26, 2017

SD10 commented on Jul 27, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions