“SVC” the better pattern against “MVP”

few days ago I wrote intro about “SVC”
It’s about 4 reasons why “MVP” is not good enough
And now I’m going to show you “SVC”

https://medium.com/@bansooknam/intro-svc-the-better-pattern-against-mvp-138e6e790bbc

And now I’m going to show you “SVC”

Definition of “SVC”

Each alphabet stands for.

S — Screen

V — Views

C — Control Tower

In addition, I want to introduce an optional interface“ViewsAction”

ViewsAction — the listener which “Views” calls and “Control Tower” receives.

Screen

Screen is the region of the display in the device.
It can occupies the entire device screen. Or the part of the screen.
In Android there are 3 main components for screen.

Activity, Fragment, Dialog

Activity : occupies the entire screen. (Of course you can make some region transparent but you cannot interact behind of it)

Fragment: It occupies the entire screen or part of it.

Dialog: occupies the entire screen. But most of the case we make the main frame small and make transparent background to show the context of flow.

There are “3 main jobs” what screen should do (In fact There are lots of jobs they do.)

1. change screen (startActivity, startActivityForResult, change Fragment on view container)
2. initialize parameter from intent (or Bundle arguments)
3. save and restore essential parameters.

Views

Every Screen has views. (some fragment has not view but I’m talking about usual case)

There are “3 main jobs” what views do

1. Show Information
2. Receive User Interaction (Click, Swipe, Drag, Fling, EditText typing…)
3. Send User Interaction events to ControlTower

“Views” has only logics about “3 main jobs.”

Control Tower

It means the “Control tower” of the “Screen”.

There are “2 main jobs” what CT(Control Tower) do

1. It’s dealing with lifecycle of “Screen” includes initializing the first data.
2. Handles user interaction events which views receives.

ViewsAction

It’s the action of the “Views” which user interact with “Views”
For people who used “MVP” before it can be confused with “View & Presenter”

In ViewsAction interface, you should declare functions which “Control Tower” need to know.

interface MemoViewsAction : ViewsAction {
    fun onClickSave()
    fun onClickRemove()
    fun listReachedToBottom()
    fun onClickMemoItem(item:Memo, position: Int)
}

If the screen has no User Interaction. You don’t need “ViewsAction” interface for the screen. (means that Screen is only showing Information without click events or data not depends on user interaction)

(Concept of “ViewsAction” is suggested by Wonseok Lim, It was named EventDelegate at begining)

Diagram

As you can see. “Views” and “ControlTower” is not totally divided. They have each other.

However in the “Views” perspective it doesn’t know everything about “ControlTower”. It knows only as “ViewsAction”.

With this concept. When we write “Views” code, we don’t have to think about business logics, we only think about what view event should send to as “ViewsAction”. So we can divide business logics from the View.

Summary

“SVC” pattern divides logics in 3 parts. Screen, Views, Control Tower.
Later, I’ll give you more details about those with concrete code & guide examples for you. So hang tight.

You can see code secretly, if you can’t wait.

https://github.com/naver/svc
https://github.com/naver/svc-template
https://github.com/BansookNam/android-architecture