Android 기본개념1

1. Android 기본

• Application클래스란?

• 어플리케이션 앱 프로세스가 실행되면 가장 먼저 생성되는 객체
• 하나의 어플리케이션 객체는 하나의 앱 프로세스와 대응됨
• 안드로이드의 Application Class 는 액티비티 및 서비스와 같은 다른 모든 구성 요소에 접근 가능한 기본 클래스
• 앱이 백그라운드로 내려가도 앱 프로세스는 계속 살아있기 때문에 어플리케이션 객체도 살아있다
• 그렇기 때문에, 보통 앱 전역에서 일관성있게, 사용하는 요소들을 등록하여 사용

• Context란?

• 현재 사용되고 있는 안드로이드의 컴포넌트들에 대한 포괄적인 정보를 지니고 있는 객체
• 다른 Context 와 다른 중요한 점은 애플리케이션에서 현재 실행되고 있는 환경을 가지고 있다는 것이다
• 각각의 컴포넌트들(액티비티, 서비스, 브로드캐스트 리시버 등)은 자신만의 컨텍스트를 가지고 있습니다.
• 컨텍스트 내에는 (1) 어플리케이션의 정보(패키지명 등), (2) 컨텍스트가 실행되는데 필요한 정보(테마 등)를 얻거나 (3) 시스템 서비스(윈도우 매니저, 레이아웃 인플레이터 등)를 구동하는데 사용됩니다.

• Application Context란?

• 애플리케이션 라이프 사이클에 종속되어 있다.(애플리케이션이 만들어지고 유지되다가, 종료될 때 없어진다) 애플리케이션 컨텍스트는 라이프사이클이 현재 컨텍스트와 상관없는 다른 컨텍스트가 필요하거나 액티비티 활동 범위를 벗어난 컨텍스트를 필요할 때 사용할 수 있습니다.
• Ex) Dialog 는 액티비티 Context 가 필요하고, Toast 는 Application Context 로 사용할 수 있다. (Toast 는 액티비티와 별개로 Window 를 가지고 있다)

• Activitiy Context란?

• 액티비티 안에서 사용할 수 있는 Context 로 액티비티 라이프 사이클에 종속되어 있다. 액티비티의 라이프사이클과 맞물리는 작업에서 필요할 때 사용한다. 제일 많이 사용하는 화면이동에서 A 에서 B 로 이동할 경우, 이때 A 의 액티비티 컨텍스트가 필요하다. 물론 Application Context 로도 화면을 실행시킬 수 있지만, 이때는 인텐트에 Intent.FLAG_ACTIVITY_NEW_TASK 플래그가 필요하다

• 인플레이션(inflation)이란?

• xml 레이아웃 파일로 정의한 정보를 런타임에 setContentView 메소드가 호출됨에 따라 메모리 상에 객체로 만들어주는 과정을 말합니다.
• 이 과정에서 xml 레이아웃 파일에서 뷰에 id를 설정하고 해당 id가 R.java 파일에 주소 값으로 환원되며 findViewById 메소드와 id를 이용하여 코드 상으로 뷰 객체를 가져와 제어할 수 있습니다.

• LayoutInflater란?

• XML에 정의된 Resource(자원)들을 View의 형태로 반환해 준다. 자바코드에서 View, ViewGroup을 사용하거나 Adapter의 getView() 등 배경화면이 될 Layout을 만들어 놓고 View 형태로 반환받아 Activity, Fragment에서 실행하게 된다.
• 보통 Activity를 만들면 onCreate()메서드에 추가되어 있는 setContentView(리소스.id) 메서드와 같은 원리다. 이 메서드 또한 xml파일을 View로 만들어서 Activity위에 보여주는 방식이다.

• 안드로이드의 크기를 표현하는 다양한 표현방법?

• 픽셀(px) : 화면의 픽셀을 의미합니다.
• 밀도 독립적 픽셀(dp, dip) : 160dpi(160인치에 들어가있는 픽셀 수) 화면을 기준으로 한 픽셀을 의미합니다.
• 축척 독립적 픽셀(sp, sip) : 가변 글꼴을 기준으로 한 픽셀을 의미합니다. 글꼴의 설정에 따라 차이가 있습니다.
• 텍스트 크기(em) : 글꼴과 상관없이 동일한 텍스트 크기를 표시하기 위한 단위입니다.
• 그 외 인치(in), 밀리미터(mm)가 있습니다.

• 안드로이드의 메모리 관리 방식

• 안드로이드는 액티비티, 서비스, 리시버, 프로바이더를 실행하기 위해 앱이 실행되는 과정에서 프로세스를 생성합니다.
• 실행중인 모든 앱은 컴포넌트가 모두 종료되어도 다음에 이 앱을 다시 실행할 가능성이 높기 때문에 프로세스를 바로 제거하지 않습니다. 바로 종료하지 않는 이유는 앱을 실행하기 위해 프로세스를 생성하는 과정에서 딜레이가 발생하는데 이 딜레이를 줄이기 위함입니다. 따라서 사용자에 의해 다시 앱이 실행되면 남아있던 프로세스가 존재하는 경우 바로 실행됩니다. 이 과정에서 쌓여있던 많은 프로세스로 인해 메모리가 부족해지는 경우 프로세스의 우선순위(사용빈도)에 따라 프로세스를 종료하여 메모리를 확보합니다.

 

2. Android 빌드 및 실행환경

• 안드로이드의 실행환경에 대해서 설명
  • 안드로이드는 크게 4가지 실행환경으로 구성되어있습니다. 가장 하단부터 리눅스 커널, 라이브러리, 어플리케이션 프레임워크, 어플리케이션 순서입니다.
  • 리눅스 커널은 OS로 안드로이드 스마트폰의 다양한 하드웨어(화면, 카메라, 블루투스, GPS, 메모리 등)를 관리합니다.
  • 라이브러리는 안드로이드에 있는 다양한 기능(UI 처리, 미디어 프레임워크, 데이터베이스, 그래픽 처리, 웹 킷 등)을 소프트웨어적으로 구현해 놓은 환경 뿐만 아니라 안드로이드 앱을 구동해주는 dalvik 가상머신과 코어 라이브러리까지 포함하는 영역입니다.
  • 어플리케이션 프레임워크는 사용자의 입력(액티비티, 윈도우, 컨텐츠, 뷰, 노티피케이션 등) 또는 특정한 이벤트에 따라 출력을 담당하는 환경을 말합니다.
  • 마지막으로 실제로 동작하는 앱이 설치되는 환경인 어플리케이션이 있습니다.
• ABI(Application binary interface)란?
  • 예 : ARM64-v8a(64), ARMv7, ARMx86 등..
  • 안드로이드 디바이스는 다양한 CPU 를 사용하여 만들고, CPU에서 제공하는 명령셋은 다양하다, 대표적인것이 ARMv7 이 있고, 우리가 작성한 코드가 javac에 의해 바이트 코드(.class)로 바뀌고, Dalvik VM(현재는 ART VM) 안에서 JIT 컴파일을 통해 기계어로 번역 되는데, 이때 이 기계어를 해석하고 명령하는데, 이때 CPU 마다 명령을 실행하는 방법이 다르고, 실행 가능한 바이너리 형식, 명령 집합 등이 정의되어 있는 것이 애플리케이션 바이너리 인터페이스(ABI) 이다.
• 바이트 코드를 안드로이드에서 바로 실행할 수 있나요 ?
  • 바로 실행할 수 없다. Java 바이트 코드를 실행하려면 JVM (Java Virtual Machine)이 필요하지만,  안드로이드는 JVM 대신 Dalvik VM 을 사용하여,  메모리, 배터리 수명 및 성능에 더 초점을 맞춰 개발이 되었기 때문에 실행할수 없다.(라이센스 문제도 있었다고 한다.) 또한  dx 라는 안드로이드 도구를 사용하여 Java 클래스 파일을 Dalvik 실행 파일(.dex 파일)로 바꿔 실행한다.
  Dalvik VM : 32비트만 지원 (JIT 컴파일러 - 실행하면 만들어 놓고)
• ART VM : 32비트, 64 비트 모두 지원 (AOT 컴파일러 - 미리 만들어 놓고)
• 빌드타입이 무엇인가요?
  • 빌드타입이란 현재 사용하고 있는 라이브러리, 모듈 등의 빌드 방법을 정의하는 것이다. 안드로이드 앱이 패키징 되고, 빌드 될 때 그래들을 사용하여 빌드 타입을 정의할 수있다. 빌드할 때 추가되어야하는 리소스를 분리하여 적용할 수 있다. 또한 build variant 와 다양하게 조합해서 제품의 flavours 나 build type 을 정의할 수 있다.
  • Ex) flavor = [local, dev, stage, real]
  • Ex) buildType = [debug, release]
  • localDebug, localRelease, devDebug, devRelease, stageDebug, stageRelease, realDebugm realRelease 등.
• 안드로이드 빌드 과정?
  • 첫째로 Android asset packaging tool (AAPT) 를 사용하여 리소스(/res 이하 파일들)를 컴파일한다. 이때 R.java 라고 불리는 하나의 클래스로 컴파일 되어진다.
  • 두번째로 .java 파일들이 javac 로 부터 .class 파일로 컴파일 된다. 그리고 클래스 파일들은 dx 툴(Android SDK tools 아래 포함되어 있다)에 의해 달빅 바이트 코드(classes.dex)로 변환된다.
  • 마지막으로 APKbuilder 에 의해 apk(android packagin key) file이 만들어 진다. 현재는 각 디바이스의 해상도, 언어, abi 타입등으로 나눠 들어가 있는 apks 로 제공되어 나중에 디바이스에 필요한 리소스만 가지고, 애플리케이션을 만드는 AAB(android app bundle) 로 사용되기도 한다
• 런타임 권한요청?
• 앱이 동작중이지 않을 때 푸시 수신시 내부 동작은 어떤 식으로 이루어 질까요?
• Compile Time and Run Time
  • CompileTime : 개발자가 작성한 언어를 컴퓨터가 인식할 수 있게 기계어 코드로 변환(즉, 컴파일러가 타입을 검증해줌)
  • RunTime : 컴파일 과정을 마쳐서 사용자에 의해 실행되어 짐(컴파일 시 걸러내지 못하고 실행 시점에 오류가 발생)
• 메모리릭 (메모리 누수)란?
  • 앱을 개발할 떄는 제한된 메모리를 어떻게 사용해야 좋은 성능을 낼 수 있는지 항상 고민해야한다. GC을 통해 알아서 메모리를 관리해 주지만 능사는 아니다. 아무리 관리를 해준다 해도 개발자가 신경을 쓰지 않으면 메모리릭과 ORM이 발생하기 마련이다.
  • 사용이 끝난 메모리를 반환하지 않은 경우 메모리 릭이 발생한다. 이렇게 사용하지 않은 메모리 양이 계속 증가하게 되면 최악의 경우 ORM를 발생시키고 앱이 강제 종료되면서 할당되었던 메모리가 시스템으로 회수된다.
  • 메모리 릭의 원인은 무엇일까?
    1. 정적(Static) view/context/activity 사용
    2. Register and unregister listeners
    3. Non-Static inner class
    4. Wrong use of getContext() and getApplicationContext()
    5. 일반적인 메모리 누수는, 모든 연관 참조가 범위(일반적으로 메서드 완료나 객체의 소멸)를 벗어나기 전에 할당한 메모리를 해제하지 않는 경우에 발생한다. 일반적인 메모리 누수와 다르게, 논리적인 메모리 누수는 앱에서 더는 필요 없는 객체의 참조를 해제하지 않은 것의 결과이다. 객체에 강한 참조(strong reference)가 있는 경우에, 가비지 컬렉터는 메모리에서 객체를 제거할 수 없다. 만약 한 컨텍스트(Context)에서 누수가 발생한다면 안드로이드 개발에 특히 문제가 된다. 액티비티(Activites)와 같은 컨텍스트는 많은 양의 메모리에 많은 참조(예로, 뷰 계층과 기타 자원 등)를 가지고 있기 때문이다. 컨텍스트가 누수된 경우, 컨텍스트가 가르키는 모든 것들 또한 누수된다. 대부분 안드로이드는 제한된 메모리를 사용하는 모바일 기기에서 실행해서, 누수가 많이 발생하면 앱에서 사용할 가용메모리가 전부 소진될 가능성이 매우 크다.
• ANR 이란?
  • Application Not Responding(애플리케이션 응답 없음) 오류
  • 원인은?
    • 메인스레드(UI 스레드)가 너무 오랫동안 차단되었을 때 발생
      • UI가 있는 input 이벤트에 5초안에 반응하지 않을 때
    • UI가 없는 포그라운드에 10초안에 활동이 없을 때
      • BroadcastReceiver가 상당한 시간 내에 실행을 완료하지 못했을 때
  • ANR 예방하려면?
    • 시간 소모가 많은 작업은 스레드를 통해 처리
    • 사용자에게 프로그레스바 등을 이용해 작업의 진행과정을 알려 기다리도록 한다.
• LMK 란 ?
  • Low Memory Killer
  • 안드로이드에서 가용 메모리(available memory)가 부족할 때 프로세스들을 죽이는 동작
  • Linux Kernel의 OOM Killer가 안드로이드의 주요 서비스나 어플리케이션을 죽일 수 있는 문제를 보완하기 위해, 가용 메모리가 설정된 6개의 임계치(minifree) 이하로 떨어지면 해당 그룹 별로 프로세스를 죽이도록 설정한 기능으로 OOM 전에 여유 메모리를 확보하기 위한 안드로이드에서 추가된 모듈
  • LMK의 목적
    • LMK의 목적은 바로 가용 메모리를 확보하는 것이다. 이것이 부족하면, PC나 휴대폰 등과 같은 시스템들의 성능이 크게 떨어집니다. 무지무지 느려지는 거죠. 심하면 앱 하나 띄우는데 몇 초 이상의 시간이 걸릴 수도 있습니다. 이런 문제를 방지하기 위해서 안드로이드는 사용하지 않는 프로세스들을 메모리에서 지워야 합니다. 여러분들이 가지고 계시는 안드로이드 폰들에서 LMK가 바로 이러한 역할을 수행하고 있습니다.
  • LMK 의 Priority
    • LMK 는 우선순위를 가지며 우선순위가 낮은 경우 부터 메모리에서 해제된다. (아래로 갈수록 우선순위가 낮다)
    • foreground process(현재 포그라운드에 올라온 애플리케이션, 현재 동작하고 있는 서비스)
    • visible process(사용자가 화면에서 볼 수 있지만 포그라운드가 아닌 경우 ex. 다이얼로그 에 가려진 onPause 상황 )
    • service process (직접 화면에 보이지는 않지만, 백그라운드에서 동작하는 데이터 업로드 또는 다운로드 경우, 오랫동안 동작한 서비스)
    • cached process (현재 사용하지는 않지만, 메모리에 적재되어 있는 프로그램)
• OOM 란 ?
  • Out Of Memory
  • 안드로이드는 먼저 LMK 로 진행하다가, 더 이상 내릴 프로그램이 없을 때 OOM 순서를 밟는다
  • 프로그램이나 운영체제에서 사용할 메모리를 할당하지 못하는 컴퓨터 동작 상태입니다. 리눅스는 MMU(Memory Management Unit)이란 하드웨어를 이용하여 가상 메모리를 물리 메모리로 변환하여 사용하는데, 가상 메모리로 사용하기 때문에 물리 메모리보다 더 큰 메모리를 사용할 때 OOM이 발생합니다.

3. Android 프로젝트 구성요소

• libs
• 프로젝트에서 사용하는 다양한 라이브러리 소스가 저장되는 공간입니다.
• androidTest
• 앱의 일부 코드를 테스트하기 위한 소스를 저장하는 공간입니다.
• java
• 자바 코드를 저장하는 공간입니다 표준 자바와 동일하게 패키지를 이용한 하위 디렉토리 생성 방식을 사용합니다.
• res
• 리소스(이미지, xml 레이아웃, 메뉴, 값)를 저장하는 공간입니다.
• AndroidManifest.xml
  • 애플리케이션에 대한 필수적인 정보를 안드로이드 플랫폼에 알려준다.
  • 앱에 대한 전체적인 정보를 담고있는 파일입니다. 앱의 구성요소와 실행 권한 정보가 정의되어있습니다.
    • 매니페스트 파일은 앱의 이름, 버전, 구성요소, 권한등 앱의 실행에서 꼭 필요한 정보가 저장되어 있는 파일입니다.
    • xml파일로 프로젝트의 최상위에 존재합니다.
    • 태그 구성으로 가장 위는 manifest태그가 존재하고 패키지명, 버전 등이 기제됩니다.
    • application태그에는 앱 아이콘, 앱 이름등의 정보가 저장됩니다.
    • activity태그에는 액티비티 클래스명과 액티비티 이름을 정의합니다.
    • activity하위에는 intent-filter태그를 이용하여 엑티비티에 대한 인텐트 작업시 필요한 action과 category를 정의합니다.
    • service, receiver, provider 태그에는 서비스,리시버,프로바이더에 대한 내용이 정의되어 있습니다.
    • permission태그에는 앱에서 필요한 권한을 정의합니다.
    • 그밖에 sdk버전을 지칭하는 uses-sdk와 다른 패키지를 등록할 수 있는 uses-library등이 존재합니다
    • 모든 안드로이드 앱은 반드시 AndroidManifest.xml 파일을 자신의 루트 디렉토리에 가지고 있어야함
• project > build.gradle
• 프로그래머가 직접 작성한 그래들 빌드 스크립트 파일입니다.
• gradle > build.gradle
• 앱에 대한 컴파일 버전정보, 의존성 프로젝트에 대한 정의가 되어있는 파일입니다.

4. Android 구성요소

• 안드로이드 4대 컴포넌트(구성요소) 는 무엇인가

• 액티비티(Activity)는 안드로이드에서 화면을 관리하고 사용자의 다양한 이벤트를 처리하는데 사용됩니다.
• 서비스(Service)는 화면에서 보이지 않지만 특정한 기능을 백그라운드에서 처리하는데 사용됩니다.
• 브로드캐스트 리시버(Broadcast receiver)는 안드로이드에서 발생하는 특정 브로트캐스트 메세지를 처리하기 위한 컴포넌트입니다.
• 콘텐츠 제공자(Content provider)는 앱 사이의 데이터의 공유를 위한 인터페이스를 제공하는 컴포넌트입니다.
• 개별적이고 비순차적으로 실행될 수 있으며, 운영체제나 사용자가 언제든지 앱 구성요소를 제거할 수 있습니다. 이러한 이벤트는 직접 제어할 수 없기 때문에 앱 구성요소에 앱 데이터나 상태를 저장해서는 안 되며 앱 구성요소가 서로 종속되면 안 됩니다.

• 액티비티와 프래그먼트가 굳이 나뉘어진 이유는 무엇일까요?

• 액티비티는 독립적으로 활용할 수 있다.
• 프래그먼트는 액티비티에 종속되어 있다.
• 액티비티는 전체화면을 차지하지만 프래그먼트는 전체 화면이 아니여도 되며 디자인에 많은 유연성을 가지고 있다.
• 액티비티는 자동적으로 스택에 넣어지고 프래그먼트는 트랜잭션을 통해서 요청해야 한다.

• 안드로이드 라이프사이클 - fragment, activity, viewmodel 관점 등
• Activity 수명주기 (LifeCycle)?
• Fragment 수명주기(LifeCycle)? - here
• Activity 시스템에 의한 종료 시 데이터를 유지하는 방법?

• Activity가 종료되는 상황은 1)뒤로가기키 눌러, 2)fisnish() 메소드 호출. 3) 시스템에 의한 종료
• 시스템에 의한 종료 : 화면 가로세로 전환 또는 메모리 부족, 홈키를 눌러 화변에 보이지 않은상태로 장시간 경과한때 등이 있음
• onSavedInstanceState(), onRestoreInstanceState() 메소드 사용
• onSaveInstanceState() - 액티비티가 pause 되기 전에 데이터를 저장하는데 사용합니다.
• onRestoreInstanceState() - 액티비티가 파괴되고, 다시 재생성될 때, 액티비티가 가지고 있는 번들로부터 데이터를 회복할수 있다. 또한 onCreate() 와 onRestoreInstanceState() 콜백 메서드는 같은 번들 객체를 전달 받는다. 그래서 보통은 데이터를 회복하는 코드를 onRestoreInstanceState() 에 많이 작성하는 편이며, onCreate 에서 savedInstance를 받아 처리하는 경우에는 처음 실행이 되는지, 재생성되는 것인지 판단하기 위해서, 데이터의 null check 가 필요하다. null 이라면 처음 생성되는 것이고, 아니라면 재생성이다.

• 서비스(Service)란?

• 서비스는 백그라운드에서 실행되는 구성 요소입니다. 서비스는 사용자에게 보이는 화면이 존재하지 않으며, 정해지지 않은 시간 동안 운영됩니다.
• 서비스는 다른 구성 요소들처럼 메인 쓰레드에서 동작합니다. 따라서 CPU를 많이 사용하거나 대기 상태를 필요로 하는 경우 새로운 쓰레드를 이용하여 생성해야합니다.
• 서비스의 객체는 단말에서 오직 1개만 생성되어 관리합니다.

• Service의 3가지 타입?

• Foreground Service : 포그라운드 서비스는 유저에게 알림을 줄 수 있는 명령을 수행한다 예를 들어 우리는 음악을 실행하기 위해서 포그라운드 서비스를 사용할 수 있고 사용자에게 알림을 표시해주어야 한다.
• Background Service : 백그라운드 서비스는 유저에게 직접적으로 알림을 주지 않는 서비스를 수행한다. 안드로이드 API 26 레벨 이상에서는 백그라운드 서비스를 사용하는 것이 금지 되었다. 그래서 이런 작업들에는 WorkManager 를 사용해야 한다.
• Bound service : 바운드 서비스는 bindService() 메소드를 호출함으로써, 어플리케이션 컴포넌트에 바인딩 되는 서비스이다. 바운드 서비스는 요청을 보내거나, 결과를 받는 클라이언트-서버 인터페이스가 제공된다. 또한 다른 어플리케이션 컴포넌트에 바운드 되어 있는 경우에만 실행된다.

• Service 구현 및 실행과정

• 서비스는 Service 클래스를 상속받아 onStartCommand 또는 onBind 메소드를 재정의하여 구현할 수 있습니다.
• 먼저 서비스가 startService 메소드로 실행되는 경우 서비스가 생성될 때 onCreate 메소드가 실행됩니다. 이후 서비스가 실행을 시작할 때 onStartCommand 메소드가 호출되며 서비스의 상태가 실행중으로 변경됩니다. 이후 stopService 메소드가 실행되면 서비스가 종료되며 onDestroy 메소드를 호출하며 서비스의 상태가 종료로 변경됩니다.
• 다음으로 서비스가 bindService 메소드로 실행되는 경우 서비스가 생성될 때 onBind 메소드가 호출됩니다. 다음으로 unbindService 메소드가 호출되어 바인딩이 해제되면 onUnbind 메소드가 호출됩니다. 이후 완전히 종료될 때 onDestroy 메소드가 호출됩니다.

• Service와 Intent Service의 차이는?

• **서비스(Service)**는 안드로이드 서비스를 위한 기초(Base) 클래스이다. 그래서 어떤한 서비스로도 확장되거나, 만들어질 수 있다. 서비스를 직접적으로 상속받은 클래스는 기본적으로 메인 스레드에서 실행되기 때문에 UI를 Block 할 수 있다. 그래서 비교적 간단한 태스크를 수행하거나, 무거운 작업을 하게 될 경우에는 다른 스레드를 만들어 사용해야한다.
• **인텐드 서비스(Intent Service)**는 서비스의 하위 클래스 이다. "인텐트" 라고 불리는 비동기 요청을 처리하는 서비스이다. 클라이언트는 startService() 메소드를 통해 요청을 보낸다. 인텐트 서비스는 필요에 따라 실행되며, 워커 스레드를 사용하여 각각의 인텐트가 처리된다. 작업을 모두 수행하면, 종료한다.

• 브로드캐스트 리시버(Broadcast receiver)란?

• 브로드캐스트는 앱 전체에 걸쳐 그리고 일반 사용자 플로우 외부에서 전하는 메시징
• 앱은 특정 브로드캐스트를 수산하도록 등록할수 있고, 브로드캐스트가 전송되면 등록된 브로드캐스트를 받을 수 있음
• 스마트폰에서 전원 충전, 전원 충전 해제, 비행기 모드 돌입, 애플리케이션 설치 완료, sms 수신, 화면 on, off, 카메라 버튼이 눌렸을 때, 부팅이 끝났을 때 등의 다양한 이벤트들이 브로드캐스트에 해당
• 정적 Broadcast Receiver
  • 앱이 종료가 된 후에도 브로드캐스트를 받으면 해당 방송에 대하여 사전에 세팅했던 명령을 실행하게 됨
  • AndroidManifest.xml에 등록 하여 구현
• 동적 Broadcast Receiver
  • 앱이 실행 중일 때 Receiver를 실행
  • 코드로 구현

• 컨텐츠 프로바이더(Content providers)란
  • 컨텐츠 프로바이더는 하나의 어플리케이션에서 요청시에 다른 어플리케이션으로 데이터를 제공한다.
  • 어플리케이션의 데이터 보안으로 인해 구조화된 데이터 구조를 가지고 있도록 정의되어 있다.
  • 컨텐츠 프로바이더는 기본적으로 다른 프로세스에서 다른 프로세스로 데이터를 제공할 수있는 인터페이스를 가지고 있다. 만약 컨텐츠 프로바이더를 이용하여 데이터 접근을 원한다면, Application Context 안에 있는 ContentResolver 오브젝트를 사용하여 클라이언트(요청하는 쪽)로서 커뮤니케이션한다 (요청 받는 쪽이 서버라고 보면 되겠다
• Content providers를 사용하여 데이터에 접근하는 방식은?
  • 먼저 Access permissions 를 획득했는데 확인해야한다. 그리고 컨텍스트 객체 안에 있는 ContentResolver 객체를 가져온다.
  • ContentResolver 의 query() 함수를 통해 데이터를 끌어온다(Retrieving). query() 함수는 Cursor 를 리턴하기 때문에, 커서를 사용하여 각각의 칼럼을 가져와서 데이터를 사용한다.
• **인텐트(Intent)란?**
  • messaging object(메세지 객체) 이다. 이 객체를 통해 다른 컴포넌트 간에 정보를 주고 받을 수 있다.
    • Intent Types
    1. Explicit Intents (명시적)
    2. -명시적 인텐트는 인텐트에 클래스 객체나 컴포넌트 이름을 지정하여 호출할 대상을 확실히 알 수 있는 경우에 사용한다. (주로 애플리케이션 내부에서 사용)
    3. Implicit Intents (암시적)(안드로이드 시스템이 인텐트를 이용해 요청한 정보를 처리할 수 있는 적절한 컴포넌트를 찾아 사용자에게 그 대상과 처리 결과를 보여준다)
    4. -암시적 인텐트는 호출할 대상이 달라질 수 있는 경우에는 암시적 인텐트를 사용한다.