Ting 이네 Software 이야기

MVC Pattern에 대한 다양한 종류의 해석/적용이 있긴 한데... 일단, 내가 생각하기에, 일반적인 SW에서 좋다고 생각하는 구조는 아래와 같다 (Web SW나 기타 여러 case가 존재하고, 각각에 맞는 다양한 해석이 존재할 수 있으니, 정답은 없다.)
물론, 아직 나 자신이 MVC Pattern에 대해 미숙하기 때문에 확신할 수는 없으나...


+-----------+     Query(write/read)         +------------+
|           | <--------------------------   |            |
|   Model   |                               |   Control  |
|           | --------------------------->  |            |
+-----------+   Response/Data for query     +------------+
   |                                          |       ^
   |                                          |       |
   |        Feedback to user(ex. select view) |       | User interaction event
   |                                          v       |
   |                                        +------------+
   |                                        |            |
   +--------------------------------------> |    View    |
  Read data / (Observe changes - optional)  |            |
                                            +------------+

Pros : MVC간 연결이 최소화 되어 있어 각각에 대한 독립성이 잘 보장되어 있다.
       Model부분이 최소화 되므로, Data 부분에 대한 안정성을 높이기 유리하다.
Cons : Control부분의 역할이 Model, View에 비해 압도적으로 복잡할 가능성이 높다.
       따라서, 복잡한 UX를 가질 경우, Control 부분의 통제가 상당히 어려워질 수 있다.
일단 가장 좋은 점은, Model에 대한 update가 Control로 제한되어 있기 때문에
(View -> Model로 write path가 없다.), Data에 대한 관리가 일원화 되어 있다.
또한, Control이 Model의 data를 update하므로, View는 Model의 Data가 바뀌는지 아닌지 굳이 Observing할 필요가 없다.
(필요에 따라 Observing하는 것도 괜찮다.)


.
.

Rough Block Diagram
[Display Device] <>--- [Logical Display] <>--- [WindowManager]

DisplayInfo
has followings (Initial values are set as information from display device).
:logicalHeight
:logicalWidth
:appWidth
:appHeight

DisplayDevice
has followings
:mCurrentLayerStackRect
:mCurrentDisplayRect

                                   shown on the display.
                                           |
                                           v
[LayerStackRect] ---(project to)---> [DisplayRect]
        ^
        |
   This value is outbound of WindowManager.

Above information is very rough and... NOT strictly verified.

Here is useful tool supported by Google to handle displaying area and density - wm.
You can find it at '/system/bin/wm'

root@generic:/system/bin # ./wm reset
usage: wm [subcommand] [options]
       wm size [reset|WxH]
       wm density [reset|DENSITY]
       wm overscan [reset|LEFT,TOP,RIGHT,BOTTOM]

Very useful isn't it!

'Segmentation fault' is very familiar error for C developer.

Then, when this runtime error is issued?

At the moment of accessing not-allocated-memory?

This may be right, but this is NOT strict enough.

'Segmentation fault' is issued by kernel through signal to notify that,

"You - user process - try to access not-permitted memory area. And usually, this happens when it tries to access not-allocated-memory - for the user process (In case of ARM architecture, it is triggered by Data Abort cpu exception).

Let's see below code.

#include <stdio.h>
#include <stdlib.h>

int
main(int argc, const char *argv[]) {
        int i = 0;
        char *s = malloc(1);
        s += 1;
        for (i = 0; i < 1024 * 1024 * 1024; i++) {
                printf("%d\n", i);
                s[i] = 4;
        }
        return 0;
}

Do you think when this process is stopped by 'Segmentation fault' signal?

"i == 0" ? (that is at the first moment of trying to access not-allocated-memory-by-malloc).

It, is totally up to malloc implementation.

But, at above case, this is definitely NO.

The reason is, kernel(linux) allocate memory for user process at least 1-page.

So, above code will run even if i > 1024 especially on the Linux machine.

And, there are various implementation(algorithm) of malloc.

So, we cannot expect exact value of i for above code.

Important thing to know here is, answer the question - "What exactly does 'Segmentation fault' mean?"