How to make a Message framework? Beginning and planing

Let's make a Message framework and do some practice on architecture.

What we will cover in this series?

• Planing and architecture of a framework
• Kick start a project
• Dirty work of setting up a CI
• Make a Messaging framework

Planing

We are going to write an open source project about Messaging framework.

Literally, which mean, we already have some implicit requirement:

• A modern Messaging UI
• Extendable feature therefore
  • Everyone can benefit from it
  • Everyone can benefit it
• Customisable
• Easy to use and understand
• Easy to debug...

 

TL;DR Jump to summary.

A modern Messaging UI

What make a modern Message UI since the definition of "modern" will be changed by time?

What I think is, there are 2 major things.

First, at least for now, this decay, or just this few  years, it will not feel outdated. So for this designing problem, we should keep our framework as lean as possible, since one extra design will lead to one extra future concern.

Second, which mean our design will need to be evolved time by time, easily. What it should do is, the design will be easy to be changed without affecting the features. And thats the architecture problem.

 

Extendable feature

Extendable, or in other word pluggable, means, we should allow people make new feature and use it in our framework. But which should be pluggable and which should not be? Before we do some vertically or horizontally boring stuff, let's talk about some other Messaging app.

All of us should have tried like 2, 3 or more messaging app, it's how nowadays peoples life, correct?

Then we will have the idea of what things always changed. The first thing we will easily notice is, the sharing thing.

Once upon a time, we have only. Then mms allow you to send music, video, then iPhone born, Android born, before What's-app  dominate the world, we used to have like some other messenger... In that time, mobile messaging evolve from can only send some text and image to have record voice, location sharing, file sharing, album sharing, web sharing with snap shot, share heart beat(😅), or even life board casting.

Can anyone tell what will be next? I guess no, none of us can tell what people want to share through sending message. Therefore, the sharing features is a always changing requirement.

Therefore we can see which will be the first necessary thing we should make it extendable, sharing (indeed, this is still messaging if we think in a high level way).

As we know, sharing is compose by 2 part. First is input, second is output... In fact, maybe it sounds ridiculously too simple, but yes, the sharing, literally is just an IO. On a pure data level implementation, it's just an alignment of data structures. On UI level, it the flow to gather data and display data. When we narrow it down to a Messaging UI, we have limited entrance of that sharing, and the output, is a cell on the message list.  So what exactly parts should be extendable? The sharing entrance and the message showing. We will talk about how to achieve it later.

 

Offtopic section

And it will lead us to think about what's static, in other word what make a Messaging framework worth to be existed. Why should we care? We know, a very important reason of why a framework is created, is to re-use, that re-use can be platform to platform, person to person, project to project. It make sense only when we have Common needs. Those common needs, are expectations of general usage of a component. What a Messaging UI can solve in general, is what make it exist, otherwise, it should not be a framework.

The most simplest answer to this questing is the Message layout. What people want is a easy to use message layout, which we all will have when we looking for a Messaging Framework because it can be super complicating and boring to have a good implementation. (For that "Message layout", is a combination of message listing, inputing)

This is what we should focus, this is the backbone of our framework.

 

Customisable

Customisable is a very basic need, just consider it when we do implementation. We want our framework can be re-use in all of our projects or someone elses' project. Think about theming, wording, style stuffs.

 

Easy to use and understand

Easy to use in this context means, as simple as necessary. We don't want to make a burden to use the framework, but we also don't want our framework be strongly tied to another project.

We don't want to use, like 100 lines to just to bootstrap the things and make it work.

But we also don't want our user to have any extra hard dependency other than the framework itself.

We want our user can switch to this framework in anytime.

We also want them to be gracefully switch to other project without harm of existing logic.

Therefore, the way how this project work should be as transparent as possible. API should be as clear as possible. We want to make our thing predictable, we want our user know how things work, easily navigate in the project, know where to work for an improvement, not only under Xcode...

 

Easy to debug

First, try to make fewer bug. For example, we all know strong coupling can introduce a lot of un predictable bug after iterations, we should try our best to avoid it. Try to write strong code, make fewer assumption, make it easy to understand, make it easy to locate, make it safe to be replace...

Then, unit testing, no matter what style, try to prove things are work well or wrong.

Finally, provide good log, debug information.

 

Sumary

To fullfil all those requirements, is already a lot for us to digest. So let's stop the detail and make a quick summary what we gonna do.

To have a modern Messaging UI. We should keep it simple when we kick start that project.

Extendable feature, we should draw the boundary of our framework, have a architecture plan.

Customisable, make things flexible

Easy to use and understand, clean design, clean flow.

Easy to debug, strong code, unit testing, good debug info.

To be continue