Brian's World

Android Development - Application Fundamentals (2/2)

메니페스트 파일(The Manifest File)

참조: http://developer.android.com/guide/components/fundamentals.html

AndroidManifest.xml 파일을 읽음으로 다른 컨포넌트의 존재를 인지할 수 있다. 프로젝트 루트 디렉토리에 이 파일이 존재하며 앱이 사용하는 모든 컨포넌트는 이곳에 선언되어야 한다.

다음과 같은 컨포넌트 왜 다른 것들도 이곳에 선언된다

-  인터넷 접속이나 사용자 연락처 정보 접속같은  앱에 대한 요구 허용

- 앱이 사용하는 API으로 된 앱의 최소 버전 정보

- 카메라, 블루투스 서비스, 멀티 터치 등 앱에의해 사용되거나 요구되는 하드웨어, 소프트웨어 정보

- 구글 맵 라이브러리 같은 링크되어있는 앱에서 사용되는 API 라이브러리

- 기타 정보

컨포넌트 선언 (Declaring components)

- 액티비티: <activity>

- 서비스: <service>

- 브로드케스트 리시버: <receiver>

- 콘텐트 프로바이더: <provider>

액티비티, 서비스, 콘텐트 프로바이더는 메니페이스파일에 선언되어야하지만 브로드케스트 리시버는 이곳에 선언되어도 되고 아니면 코드에 BroadcastReceiver 추상클래스의 객체로 생성된 후 registerReceiver() 메서드로 시스템에 등록될 수 있다.

컨포넌트 선언 능력(Declaring component capabilities)

컨포넌트를 실행을 위해 Intent 객체를 인스턴스화 할때 직접 그 컨포너트를 명시할 수 있다. 그러나 Intent의 진정한 힘은 그 대상 컨포넌트를 숨기는 것이다. intent의 행동에서, 행동의 타입을 간략하게 정의하고 이 행동을 실행할 수 있는 기기의 컨포넌트를 시스템이 찾는것을 허용할 수 있다. intent에의해 명시된 행동을 실행할 수 있는 다수의 컨포넌트가 있다면, 사용자는 이중 하나를 고를 수 있다.

intent에 응하는 컨포넌트를 시스템이 인지할 수 있는 방법은 다른 앱이나 기기의 메니페스트 파일에 주어진 <intent-filter> 태그로 intent를 구별할 수 있다.

예를 들어 하나의 이메일 앱에서 새로운 메일을 작성하는 액티비티는 "send" intent를 응답하기 위해 Intent 필터를 메니페스트에 선언할 수 있다. 앱의 액티비티가 "send" 행동(ACTION_SEND)을 포함한 intent를 만들 수 있다. startActivity() 메소드를 실행시키면서 실행시킬때, 시스템이 이메일 앱의 "send" 액티비티를 찾고 이것을 시작할 수 있다.

나도 이걸 해석하면서 뭔말인지 모르겠어서 intent filter에 대해 검색해보았다. 결론적으로 선언방법으로 명시적/암시적 두가지 방법이 있다. 

1. 명시적 intent는 객체 인스턴스화 할때 타겟 컨포넌트를 인자로 선언하는 방법이고 

2. 암시적 intent는 메니페시트에 필터를 선언하여 intent를 받았을 때 어떤 컨포넌트를 실행할지 결정하는 방법이다.

더욱 자세한 사항은 검색 하시길~ 

앱 요구사항 선언(Declaring application requirements)

안드로이드에 만들어지는 많은 기기들이 존재하고 이 모든 기기가 똑 같은 기능을 제공하지 않는다. 앱이 필요로하는 기능의 결핍을 막기 위해, 메니페스트 파일에 기기와 소프트웨어의 요구사항을 명확하게 명시하는 것이 주용하다. 기기에 따라 대부분의 선언이 정보화 되며 Google Play같은 외부 서비스에서도  기기에서 앱을 찾기 위해 사용자에게 정보를 제공하기 위해 이 정보를 사용한다.

예를들어 만약 앱에서 카메라를 필요로 한다면 메니페스트에 이를 명시해야하고 이 명시를 보고 Google Play에서 이를 실행할 수 없는(Android 2.1 이하 혹은 카메라가 없는 기기)를 선별하여 인스톨이 가능하게 한다.

그러나 앱에서 카메라를 사용한다고 해서 이를 명시하는 것이 필수 요구사항은 아니지만 이에대한 결과에대해 체크해 보야한다.

다음은 중요한 명가지 기기 특성이다.

화면 사이즈와 농도(Screen size and density): <supports-screens>

입력 형태(Input configurations)/하드웨어 키보드 등: <uses-configuration>

기기 특정(Device features): <uses-feature>

플렛폼 버전(Platform Version): <uses-sdk>

다음 번에는 액티비티의 라이프 사이클(Managiing the Activity Lifecycle)에 대해 알아보겠다.

Android Development - Application Fundamentals (1/2)

애플리케이션 컨포넌트 (Application Components)

참조: http://developer.android.com/guide/components/fundamentals.html

오늘은 자바의 기본 컨포넌트들을 정리하겠다. (본 내용은 위의 안드로이드 개발자 싸이트에 내용을 요약한 것이다.)

안드로이드의 기본 구성으로 네가지 어플리케이션 컨포넌트 타입이 있다. 각 타입은 명확히 다른 목적을 가지며 라이프사이클(생성->소멸)을 가진다.

1. Activities: 하나의 액티비티는 사용자 인터페이스에서 하나의 화면을 나타낸다.

예를들어 Email 앱의 경우 아마도 새로운 메일 리스트를 보인다거나 메일 작성화면 메일을 읽는 화면등이 각각의 액티비티가 될 수 있다. 하지만 이런 각각의 앱티비티가 하나의 앱을 이루지만 각각은 독립적이다. 이렇게 어떤 앱이 다른 앱의  액티비티를 실행시킬수 도 있다.(다른 앱이 이를 허용하는 경우). 이 예는 카메라 앱에서 Email 앱으로 데이터를 정송하는 경우등을 들 수 있다.

액티비티는 Activity 크래스로부터 상속된 하위 클래스이다.

참조: http://developer.android.com/guide/components/activities.html

2. Services: 서비스는 백그라운드에서 동작하며 독작을 운영하거나 프로세스를 삭제하는 작업을 한다.

이 서비스는 사용자 인터페이스에 보이지 않는다. 예를 들어 사용자가 다른 앱으로 작업하는 동안 백그라운드에서 음악을 실행시킨다거나 사용자 화면 없이 네트웩을 통해 데이터를 주고 받을 수 있다. 다른 컨포넌트를 통해(액티비티 같은) 서비스를 실행시키거나 멈추는 서비스와의 상호작용을 할 수 있다.

서비스는 Service 추상 크래스로부터 상속된 하위 클래스이다.

참조: http://developer.android.com/guide/components/services.html

3. Content providers: 콘텐트 프로바이더는 애플리케이션 데이터를 공유한다.

아마 너는 파일 시스템을 통해 데이터를 SQLite  데이터 베이스라던지, 웹, 그 밖에 너가 접속할 수 있는 데이터 스토리지에 저장할 수 있을 것이다. 콜텐드 프로바이더를 통해 다른 앱들이 이런 데이터에 쿼리하거나 수정할 수 있다.(물론 콘텐트 프로바이더가 이를 허락하는 경우) 하나의 예로 컨턴트 프로바이더는 사용자의 연락처 정보를 제공할 수 있다. 이렇게 적당한 허용하에 어떠한 앱도 각 개인의 관한 정보를 읽거나 쓰는 쿼리를 컨턴트 프로바이더를 사용함으로써 이용할 수 있다.

컨텐트 프로바이더는 또한 공유되지 않는 개인 자원의 읽기 쓰기에 도 용이하다.

컴텐트 프로바이더는 ContentProvider 추상 클래스로부터 상속된 하위 클래스이다.

참조: http://developer.android.com/guide/topics/providers/content-providers.html

4. Broadcast receivers: 브로드케스트 리씨버는 시스템 전반의 브로드케스트 알림을 알린다.

많은 브로드케스트는 메인 시스템으로부터 시작된다. 예를들어 브로드케스트 알람은 화면 꺼짐, 베터리 낮음, 화면 쳅처같은 것이 될 수 있다. 앱 또한 브로디케스팅을 할 수 있는데 예를 들어 어떤 데이터가 다운로드되어 다른 앱들이 이를 사용할 수 있을때 이를 이용한다.

브로드케스트 리시버는 BroadcastReceiver 추상 클래스로부터 상속된 하위 클래스이며 각각의 브로드케스트는 Intent 객체로 전달 된다.

컨포넌트의 실행 (Activating Components)

컨포넌트 중 세가지(Activates, Services, Broadcast Receivers)의 경우 비동기적으로 Intent 객체에 의해 동작된다. Intent 객체는 실행 중 서로 다른 컨포넌트들을 묶는 역할을 한다.(쉽게 메신저 역할로 다른 컨포넌트들에게 요청할 수 있다.)

Intent 클래스의 객체는 특정 컨포넌트나 특정 타입의 컨포넌트를 실행시킬 메시지를 정의할 수 있다.

1. 액티비티와 서비스를 위해 화면을 보이거나 무언가를 전달하는 행동을 정의할 수 있다. 예를들어 intent가 웹페이지를 오픈하거나 이미지를 보이는 질의를 전달할 수 있다. 이경우 받은 액티비티가 이를 실행하고 또 결과로 intent를 반환할 수 있다. (예를들어 당신이 개인 연락처를 받고자할 때, 선택된 연락처의 URI정보를 intent를 통해 반환 받을 수 있다.)

Activity: startActivity(), startActivityForResult() 메서드에 intent 인자를 넘김으로 실행(새로운 할것리를 전달)

Service: startService(), bindService() 메서드에 intent 인자를 넘김으로 실행(새로운명령을 실행시키거나 계속 진행)

2. 브로트케스트 리씨버의 경우 intent가 브로드케스트 알림 정보를 정의 할 수 있다.

Broadcast Receiver:  Intent 클래스의 메소드 sendBroadcast(), sendOrderedBroadcast(), sendStickyBroadcast().

3. 마지막으로 컨텐트 프로바이더는 intent에 의해 실행되지 않는다. 이는 ContentResolver(추상클래스)로 부터 요청받았을 때 실행되어 진다. 컨텐트 리졸버는 모든 컨텐트 프로바이터의 트렌젝션을 핸들링한다.  제공자와 트렌젝션하는 컨텐트는 이를 필요로하지 않고 대신에 ContentResolver 객체의 메서드르 호출한다. 이것이 컨텐트 프로바이터와 컨텐트 요구 정보를 추상화하는 개층이 된다.(보안을 위한)

Content Providers: ContentResolver 클래스의 query() 사용.

다음 번에는 Manifest File에 대하여 알아보겠다.