2022/08/09
context
[Android] 안드로이드 Context란?
https://shinjekim.github.io/android/2019/11/01/Android-context%EB%9E%80/
[Android] Context, 너 대체 뭐야?
https://velog.io/@haero_kim/Android-Context-%EB%84%88-%EB%8C%80%EC%B2%B4-%EB%AD%90%EC%95%BC
Android Context란 무엇일까?
//
위 글(https://blog.mindorks.com/understanding-context-in-android-application-330913e32514)의 저자 Amit Shekhar는 컨택스트에 대해 다음과 같이 설명하고 있습니다. - What is Context in Android?
The Context in Android is actually the context of what we are talking about and where we are currently present. This will become more clear as we go along with this.
Few important points about the context:
- 애플리케이션의 현재 상태를 나타낸다.
- 액티비티와 어플리케이션의 정보를 얻기 위해 사용할 수 있다.
- 리소스, 데이터베이스, shared preference 등에 접근하기 위해 사용할 수 있다.
- 액티비티와 애플리케이션 클래스는 Context 클래스를 확장한 클래스이다.
컨택스트는 다시 크게 두 종류로 나뉩니다:
- Application Context
- Activity Context
//
거의 결론에 다다른거 같습니다. Context 는 어플리케이션과 관련된 정보에 접근하고자 하거나 어플리케이션과 연관된 시스템 레벨의 함수를 호출하고자 할 때 사용됩니다. 그런데 안드로이드 시스템에서 어플리케이션 정보를 관리하고 있는 것은 시스템이 아닌, ActivityManagerService 라는 일종의 또 다른 어플리케이션입니다. 따라서 다른 일반적은 플랫폼과는 달리, 안드로이드에서는 어플리케이션과 관련된 정보에 접근하고자 할때는 ActivityManagerService 를 통해야만 합니다. 당연히 정보를 얻고자 하는 어플리케이션이 어떤 어플리케이션인지에 관한 키 값도 필요해집니다. 즉, 안드로이드 플랫폼상에서의 관점으로 샆펴보면, Context 는 다음과 같은두 가지 역할을 수행하기 때문에 꼭 필요한 존재입니다.자신이 어떤 어플리케이션을 나타내고 있는지 알려주는 ID 역할 ActivityManagerService 에 접근할 수 있도록 하는 통로 역할 정리하자면 이렇습니다.
안드로이드/Android Context 란?
https://arabiannight.tistory.com/284
일반 OS 플랫폼에서 어플리케이션은 곧 Process 입니다. 특정 어플리케이션이 OS 에게 내가 어떤 Process 인지만 알려주면 어플리케이션 관련된 정보를 얼마든지 획득 할 수 있습니다. 이른바 자신의 존재 자체가 자신임을 증명해주는 '지문인식' 혹은 '홍채인식' 등의 '생체인식' 과 비슷한 개념이기 떄문에 Context 와 같은 애매한 중간 매개체가 존재할 이유가 없습니다.
하지만 안드로이드 플랫폼은 조금 다릅니다. 비유하자면 '생체인식' 보다는 'ID카드' 를 통한 보안 시스템과 유사한 구조입니다. 특정 어플리케이션이 자신이 본인임을 확인 받을 수 있는 방법은 자신이 작동중인 Process 를 보여주는 것이 아니라, 자신이 건네받은 ID카드를 제시하는 것 입니다. 이때 ID카드의 역할을 수행하는 것이 바로 Context 이고, 당연히 이 카드는 위변조가 가능하기때문에, 자신의 권한을 제삼의 어플리케이션에게 넘겨주는 PendingIntent 와 같은 기능도 가능해집니다.
Context 는 언제 태어날까?
Context 에 관한 마지막 질문은 약간의 부록과도 같습니다. Context 는 언제 태어날까요? 대답은 당연히 어플리케이션이 태어날 때입니다.
그렇다면 하나의 어플리케이션을 구성하는 각종 컴포넌트들 - Activity,Service,BroadcastReceiver 들은 모두 동일한 Context 를 공유해서 사용하고 있을까요? 저도 처음에는 그렇지 않을까 생각했었는데 알고보니 그렇지는 않더군요.
Activity 와 Service 가 생성될 때 만들어지는 Context 와 BroadcastReceiver 가 호출될 때( onReceive() ) 전해지는 Context 는 모두 서로다른 인스턴스입니다. 즉, Context 는 어플리케이션이 시작될 때는 물론이요, 어플리케이션 컴포넌트들이 생성될때마다 태어나는 셈입니다. 물론, 새롭게 생성되는 Context 들이 부모와 완전히 독립되어 있는 존재는 아니고 '거의' 비슷한 내용을 담고 있습니다.
어째서 동일한 Context 인스턴스를 어플리케이션 컴포넌트들이 공유해서 사용하지 않고, 모두 서로 다른 (그러나 알고보면 알맹이는 거의 같은) 인스턴스를 만들어 사용하고 있을까요? 음... 어려운 문제입니다. 잘 모르겠네요. 일단 한 가지 분명한 원인이 있습니다.
Context 의 기능 중, 시스템 API 를 호출하는 기능과 관련되어 한 가지 문제점이 있습니다. 어떤 어플리케이션 컴포넌트가 시스템 API를 호출하느냐에 따라서 서로 다른 결과가 나타나야 한다는 점입니다.
예를들어, Service 에서 Activity 실행하기포스트에서 언급한 것 처럼, 동일한 형태로 startActivity 메서드 호출하더라도, 일반적인 Activity 에서는 정상적으로 새로운 Activity 를 시작하게 되지만, Service 에서 호출할 경우에는 예외가 발생합니다. 만일 어플리케이션을 구성하는 Service 와 Activity 가 서로 동일한 Context 인스턴스를 공유하고 있다면 동일한 메서드 호출에 대하여 서로 다른 결과를 나타내도록 구현하지 못했을겁니다.
따라서, 현재 안드로이드 시스템은 어플리케이션 Context 를 기반으로 컴포넌트를 위한 Context 를 생성할 때 해당 Context 가 어떤 종류의 컴포넌트인지 알 수 있도록 약간의 표시를 해두곤 합니다.
또 한가지 안드로이드 개발팀의 코딩 스타일과 관련된 문제가 아닌가 하는 심증을 갖고 있습니다. 안드로이드 어플리케이션 컴포넌트들은 Context 를 포함하는 대신 상속받은 방식으로 구현되어 있습니다. Context 를 포함하는 방식이였다면 아마 작성해야할 코드량이 제법 늘어났을 것으로 짐작됩니다 (개별 컴포넌트 클래스마다 추상 API 들을 반복해서 구현해주어야 하니까...).
하지만 포함대신 상속받는 방식이 적용된만큼 당연하게 어플리케이션 Context 인스턴스를 어플리케이션을 구성하는 개별 컴포넌트들이 동일하게 사용하는 것은 어플리케이션 클래스 자체를 엄청나게 복잡하게 구현하지 않는 이상 불가능한 일이 되어 버렸습니다.
마무리
결론! 결국, 안드로이드 Context 는 여러가지 이유로 기존 플랫폼과는 다른 방식으로 어플리케이션을 관리하고 있고, 때문에 기존 플랫폼들에서는 단순하게 시스템 API 를 통해 할 수 있는 일들을, Context 인스턴스라는 조금은 귀찮지만 강력한 녀석을 통해 대행 처리하고 있다고 할 수 있겠습니다.
[번역] 안드로이드의 멀티태스킹 (Multitasking the Android Way)
https://blog.naver.com/huewu/110085391353
무슨 말인지 잘 모르겠지만 왠지 좋은 글 같아보임 ㅎ
헤어나오지 못하는 배너 만들기
[Android/Kotlin] 많이 쓰이는 홍보 배너 형태의 뷰 만들기 : ViewPager2
Retrofit을 적용해서 데이터 불러오기
https://in-idea.tistory.com/25
핑크사과 블로그
(android) bumptech - Glide
https://no-dev-nk.tistory.com/77
[Android] Glide 라이브러리 사용하기 (ImageView에 이미지 리소스, GIF 넣기)
https://gwi02379.tistory.com/10
[Android Studio] 인텐트로 URL 웹사이트 팝업 열기 Intent url website popup
https://devsmin.tistory.com/38
- 웹사이트 열기
val intent = Intent(Intent.ACTION_VIEW, Uri.parse("URL"))
startActivity(intent)
MVC 모델
https://junhyunny.github.io/information/design-pattern/mvc-pattern/
1.1. 모델(Model)Permalink
DATA, 정보들의 가공을 책임지는 컴포넌트를 말합니다.
모델(Model)은 어플리케이션의 정보, 데이터를 나타냅니다. 데이타베이스, 처음의 정의하는 상수, 초기화 값, 변수 등을 뜻합니다. 비즈니스 로직을 처리한 후 모델의 변경사항을 컨트롤러와 뷰에 전달합니다.
모델은 다음과 같은 규칙을 가지고 있습니다.
- 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 합니다.
- 뷰나 컨트롤러에 대해서 어떤 정보도 알지 말아야 합니다.
- 변경이 일어나면, 변경 통지에 대한 처리 방법을 구현해야만 합니다.
1.2. 뷰(View)Permalink
사용자에게 보여지는 부분, 즉 유저 인터페이스(User interface)를 의미합니다.
MVC 패턴은 여러 개의 뷰(View)가 존재할 수 있으며, 모델에게 질의하여 데이터를 전달받습니다. 뷰는 받은 데이터를 화면에 표시해주는 역할을 가지고 있습니다. 모델에게 전달받은 데이터를 별도로 저장하지 않아야 합니다. 사용자가 화면에 표시된 내용을 변경하게 되면 모델에게 전달하여 모델을 변경해야 합니다.
뷰는 다음과 같은 규칙을 가지고 있습니다.
- 모델이 가지고 있는 정보를 따로 저장해서는 안됩니다.
- 모델이나 컨트롤러와 같이 다른 구성요소들을 몰라야 됩니다.
- 변경이 일어나면 변경통지에 대한 처리방법을 구현해야만 합니다.
1.3. 컨트롤러(Controller)Permalink
모델(Model)과 뷰(View) 사이를 이어주는 브릿지(Bridge) 역할을 의미합니다.
모델이나 뷰는 서로의 존재를 모르고 있습니다. 변경 사항을 외부로 알리고 수신하는 방법만 있습니다. 컨트롤러(Controller)는 이를 중재하기 위해 모델과 뷰에 대해 알고 있어야 합니다. 모델이나 뷰로부터 변경 내용을 통지 받으면 이를 각 구성 요소에게 통지해야 합니다. 사용자가 어플리케이션을 조작하여 발생하는 변경 이벤트들을 처리하는 역할을 수행합니다.
컨트롤러는 다음과 같은 규칙을 가지고 있습니다.
- 모델이나 뷰에 대해서 알고 있어야 합니다.
- 모델이나 뷰의 변경을 모니터링 해야 합니다.
[아키텍처 패턴] MVC 패턴이란?
비지니스 처리 로직과 사용자 인터페이스 요소들을 분리시켜 서로 영향없이 개발 하기 수월하다는 장점이 있습니다.
Model은 어플리케이션이 “무엇”을 할 것인지를 정의 합니다. 내부 비지니스 로직을 처리하기 위한 역할을 할 것입니다.
처리되는 알고리즘, DB 와 상호작용(CRUD Create Read Update Delete), 데이터 등등..
Controller는 모델이 “어떻게” 처리할 지를 알려주는 역할을 할 것이고, 모바일에서는 화면의 로직처리 부분입니다. 화면에서 사용자의 요청을 받아서 처리되는 부분을 구현되게 되며, 요청 내용을 분석해서 Model과 View에 업데이트 요청을 하게 됩니다.
사용자로 부터의 입력 을 받고 Model 또는 View중개인 역할
View는 화면에 “무엇” 인가를 “보여주기 위한 역할”을 합니다. 컨트롤러 하위에 종속되어, 모델이나 컨트롤러가 보여주려고 하는 모든 필요한 것들을 보여줄 것입니다.
최종 사용자에게 “무엇”을 화면(UI)으로 보여줌
그리고 Controller는 Model과 View가 각각 무엇을 해야 할 지를 알고 있고, 통제합니다. 비지니스 로직을 처리하는 Model과 완전히 UI에 의존적인 View가 서로 직접 이야기 할 수 없게 합니다.
