Question: Question:
It is supposed to be coded according to a design pattern called MVC,
Even if I look at various sites, I can't quite understand MVC.
First of all, do the following ideas fit?
-
Model
does something unrelated to the UI -
View
gets information fromModel
and displays it -
Controller
acts as an intermediary betweenModel
andView
Also, I think it is the Controller
that processes the View
event and lets the Model
do something.
Should I write View#setOnClickListener
, for example, in the Controller
?
Or View#setOnClickListener
itself in View
Is it better to write View#onClickListener
or its contents in Controller
?
Also, which of Android's Activity
and Fragment
applies to View
or Controller
?
And how much should Fragment
do?
Currently, only View
generation from xml is done, and setting data in that View
is done by another class.
Answer: Answer:
Controller
acts as an intermediary betweenModel
andView
In my case, I've done it more simply with the word input .
In other words, VC is input and output at once.
Other than that , the part of pure internal logic separated from the input / output interface is Model .
According to the commentary on Wikipedia
Such a structure that becomes M-VC is called Document-View .
that's right. I don't care about the difference between V and C , and I think it's important to want to separate M from others.
On the other hand, I think that most of Android's huge APIs are VCs , so I think the difference between V and C will come to the fore. Basically, V is also called View
on Android, so I think there is little room for hesitation.
Activity is a completely different dimension from MVC , so I think it's best not to mix it up. I think it's like how you behave around an event. MVC , on the other hand, simply separates the parts.
Currently, the display on View and the event processing of View are done in the same class, and it would be better to separate them in terms of VC, but I do not know where to separate them.
It seems that you are troubled by the boundary between V and C , but in fact, if you put one sheet between M , it will inevitably disappear. Isn't the existence of M going somewhere too much to think about the boundary between V and C ?
View simply reads from Model and displays it passively ( output ). The event to the View is actually an event to the Model , rather than thinking "to the View ", and is received to change the internal state of the Model ( input ).
So, in actual Android programming, implementing OnTouchListener
on a View
is not MVC -like. From the outside, OnTouchListener
may be set for View
, but the entity that receives the callback should not be View
, but it should be the relationship between Controller and Model .
About Model
In a simple example, Model programs an Othello (reversi) game and expresses 8×8 squares with 64 int arrays (or 8×8 with his 2D int array). Model . (Int is 0: sky; 1: white; -1: black)
View looks at this array and is always thinking only about how to display it.
The Controller only considers the role of making appropriate changes to this array due to user operations or some external factor.
By doing this, inevitably, V and C do not come into direct contact with each other, and the advantage of having a thin sheet of paper called " M " in between is obtained.
In particular, I don't think he needs to think in three steps: C → M → V. It's not procedural oriented. (As a result, it will be processed in that order)