세상의 모든 Software 지식을 정리

Handler 객체가 Post 메소드 안에 Runnable객체를 넣는 의미가 직접적으로 이해 되지 않아 문서를 본 결과. The  post  versions allow you to enqueue Runnable objects to be called by the message queue when they are received 상대방 측에서 메시지 큐로 부터 수신 했을 떄, 해당 Runnable 즉, 쓰레드 안에서 정의된 로직을 호출한다는 것이다.

리소스 접근시 여러가지 방법이 있겠지만 Bitmap testImg = BitmapFactory.decodeResource(res, R.drawable.testRes0); 이런식으로 파일 ID로 리소스를 읽어와 사용하고 있었습니다. 그런데 리소스가 많을 경우  testImg = new Bitmap[10]; for(int i = 0; i < 10; i++)         testImg[i] = BitmapFactory.decodeResource(res, R.drawable.testRes0+i); 이런식으로 ID로 연산을 하여 읽어오다보면 ID가 꼬이는 경우 문제가 발생할 여지가 많더군요. 파일명이 순차적으로 되어 있다고 하더라도 이런식의 접근은 안좋은 방법인것으로 알고 있습니다. 이럴경우 int tmpID; testImg = new Bitmap[10]; for(int i = 0; i < 10; i++) {        tmpID = res.getIdentifier( "testRes"+i, "drawable" , "com.androidpub.android.test");        testImg[i] = BitmapFactory.decodeResource(res, tmpID); } 이런식으로 리소스 파일명으로 ID를 알아와 접근하는 방식을 사용할 수 있습니다. "패키지명 : 타입 / 리소스명", null, null getIdentifier("com.androidpub.android.test:drawable/testRes", null, null); 또는 "리소스명", "타입", "패키지명" getIdentifier("testRes", "drawable", "com.androidpub.android.test"...

*안드로이드 서비스 클래스는 애플리케이션이 백그라운드 작업을 시작시켜 수행할 수 있게 특별히 설계되었다. 작업을 빨리 수행하고 종료하는 브로드캐스트 수신자와 다르게, 서비스는 실행 시간이 길면서 사용자 인터페이스를 필요로하지 않는 작업을 수행하도록 설계되었다. <스타트 서비스> 스타트 서비스는 다른 애플리케이션 컴포넌트(예를들어, 액티비티나 브로드캐스트 수신자)에 의해 론칭된다. 그리고 서비스가 중단되거나 리소스 해제를 위해 안드로이드 런타임 시스템에 의해 소멸될 때까지 백그라운드로 무한정 실행된다. 이 서비스는 자신을 시작시킨 애플리케이션이 더 이상 포그라운드에 있지 않아도 계속 실행된다. 심지어는 실제로 서비스를 시작시킨 컴포넌트가 소멸될 경우에도 계속 실행된다. 기본적으로 이 서비스는 자신이 론칭되었던 애플리케이션 프로세스와 동일한 메인 스레드에서 실행된다. 이것을 로컬서비스 라고 한다. 따라서 CPU를 많이 사용하는 작업들은 그 서비스의 새로운 스레드에서 수행되도록 하는 것이 중요하다. 그리고 별도의 프로세스에서 서비스가 실행되는 것을 원격서비스 라고하며, 이때는 매니페스트 파일에 구성 변경을 해야 한다. 매니페스트 파일의 설정으로 서비스가 특별히 private(론칭된 프로세스 전용)으로 구성되지 않는다면 그 서비스는 같은 안드로이드 장치의 다른 컴포넌트에 의해 시작될 수 있다. 이때는 한 액티비티가 다른 액티비티를 론칭하는 방법과 똑같이 인텐트 매커니즘을 사용하면 된다. 스타트 서비스는 startService()메소드를 호출하여 론칭하며, 시작되는 서비스를 식별하는 인텐트 객체를 인자로 전달한다. 스타트 서비스는 작업을 완료한 후 stopSelf()를 호출하여 자신을 중단시켜야 한다. 또한, stopService()메소드를 호출하면 실행 중인 서비스를 다른 컴포넌트에서 중단시킬 수 있다. 이때는 중단될 서비스아 일치하는 인텐트를 인자로 전달한다. <인텐트 서비스> IntentService클...

** CoordinatorLayout의 뷰 계층 구조에 속한 특정 뷰의 스크롤 액션을 기준으로 앱바의 요소들이 사라지거나 나타나게 하기 위해 CoorinatorLayout을 사용할 수 있다.  예를들어, RecyclerView의 리스트 항목을 스크롤할 때 그렇게 될 수 있다. 그리고 이렇게 하려면 스코롤이 생기는 요소와 그로 인해 연동되는 요소 모두의 속성을 설정해야 한다. 스크롤이 생기는 요소(여기서는 RecyclerView)의 경우에는 android:layout_behavior(또는 app:layout_bahavior)속성을 appbar_scrolling_view_behavior로 설정해야 한다. < android.support.v7.widget.RecyclerView android :id= "@+id/recycler_view" android :layout_width= "match_parent" android :layout_height= "match_parent" app:layout_behavior="@string/appbar_scrolling_view_behavior"/> < android.support.design.widget.AppBarLayout android :layout_width= "match_parent" android :layout_height= "wrap_content" android :theme= "@style/AppTheme.AppBarOverlay" > < android.support.v7.widget.Toolbar android :id= "@+id/toolbar" android :layout_width= "...

<동적상태 vs 영속적상태> 액티비티 생명주기를 관리하는 주 목적은 적시에 액티비티 상태를 저장하거나 복원하기 위함이다. 상태(state)는 액티비티가 현재 보존하고 있는 데이터와 현재 보이는 사용자 인터페이스 데이터( 화면에 나타난 뷰 객체의 데이터) 를 의미한다. 예를들어, 액티비티는 데이터베이스, 콘텐트 제공자, 파일 등에 저장될 필요가 있는 메모리의 데이터를 유지할 수 있다. 그런 상태정보를 영속적상태 라고한다. 화면에 보이는 사용자 인터페이스는 동적상태 라한다.(사용자인터페이스 상태 또는 인스턴스 상태) 예를들어,액티비티 A가 백그라운드에 있다가 포그라운드로 올 수 있다. 따라서 액티비티A가 포그라운드로 돌아오면 자신이 입력했던 텍스트가 그대로 남아있을 것이라 생각한다. 그러나 이 경우 액티비티A의 새로운 인스턴스가 생성되므로, 만일 동적 상태 데이터가 저장되어 복원되지 않았다면 사용자가 이전에 입력한 데이터는 유실된다. *안드로이드에서는 장치의 구성이 변경되면(장치를 세웠다 눕혔다)액티비티의 인스터스를 새로 생성한다는 것에 유의하자. 그러므로 동적상태를 저장하는 주 목적은 포그라운드와 백그라운드 액티비티들간이 매끄러운 전환을 제공하는 것이다. <액티비티의 생명주기 메소드> Activity클래스는 생명주기 메소드를 많이 갖으며, 액티비티의 상태가 변경될 때 이벤터처리기(Event Handler)처럼 동작한다. onCreate(Bundle savedInstanceState): 이 메소드는 액티비티 인스턴스가 최초 생성될 때 호출되며, 대부분의 초기화 작업을 하는데 이상적인 곳이다. 메소드 인자로 동적 상태 정보를 포함할 수 있는 Bundel객체를 인자로 전달한다. 그런 동적상태 정보는 직전에 생성되었다가 소멸된 동일 액티비티으 인스턴스로부터 전달되며, 일반적으로 사용자 인터페이스의 상태와 관련되는 데이터다. onRestart(): 액티비티 런타임 시스템에 의해 이전에 중지되었다...

*안드로이드 시스템에서 메모리를 해제하기 위해 프로세스들을 중단시킨다. 메모리 해제를 위해 어떤 프로세스를 중단시킬지 결정할 때 시스템에서는 현재 실행 중인 모든 프로세스의 우선순위 와 상태 를 모두 고려한다. 그리고 이때 그런 요소들을 결합하여 구글에서 이야기하는 중요도 서열이라는 것을 생성한다. <안드로이드의 프로세스 상태> 1. 포그라운드 프로세스 가장높은 수준의 우선순위이다. 프로세스가 포그라운드 상태가 되려면 다음의 자격조건을 하나 이상 충족해야 한다. 사용자와 현재 상호작용중인 액티비티를 호스팅(포함해서 실행)한다. 사용자와 현재 상호작용 중인 액티비티에 연결된 서비스를 호스팅한다. 중단되면 사용자에게 해를 끼칠 수 있다는 거을 startForeground()메소드를 호출하여 알려준 서비스를 호스팅한다. 자신의 onCreate(), onResume(), onStart()콜백 메소드 중 하나를 실행하는 서비스를 호스팅한다. onReceive()메소드로 현재 실행중인 브로드캐스트 수신자를 호스팅한다. 2. 가시적프로세스 화면으로 볼 수는 있지만 사용자와 상호작용은 하지않는 액티비티를 포함하는 프로세스는 가시적 프로세스로 분류된다. 3. 서비스 프로세스 이미 시작되어 현재 실행 중인 서비스(service)를 포함하는 프로세스이다. 4. 백그라운드 프로세스 사용자가 화면으로 현재 볼 수 없는 하나 이상의 액티비티를 포함하는 프로세스다. 더 높은 우선순위의 프로세스에서 추가 메모리가 필요한 경우, 이 부류의 프로세스는 안드로이드 런타임에의해 중단될 가능성이 크다. 안드로이드는 백그라운드 프로세스내역을 동적ㅇ로 유지 관리하면서 실행 순서에 따라 프로세스를 중단시킨다. 5. 비어있는 프로세스 실행되는 애플리케이션을 포함하지 않으며, 새로 론칭되는 애플리케이션을 호스팅하기 위해 메모리에 남아있다. 문을 연 채로 엔진을 켜 놓고 탑승을 기다리는 버스와 유사하...

*Serializable 과 Parcelable의 차이점 참고: http://aroundck.tistory.com/2477 이 Parcelable의 뜻은 소포 또는 꾸러미란 뜻이다. 이 Parcelable는 Interface로, 이 녀석을 구현한 Class는 Parcel로 쓰여질 수도 있고, Object로 복구될 수도있다. Process간 정보 교환시 포장 압축하여 전달하고, 받으면 포장을 해제하는 것을, Interface로 만든것이라 보면 된다. 이 Parceleabe을 구현한 Class는 CREATOR라는 static field를 "반드시" 가지고 있어야 한다. 이 CREATOR라는 녀석은 Parcelable.Creator interface를 구현한 놈으로, 해당 Parcel이 어떻게 restore되는지 기술하고 있다. 이 Parcelable은 IPC,즉 프로세스간 통신에도 아주 유용하게 쓰인다. 이 녀석을 구현한 class는 IPC시 추가 작업 없이 process사이를 넘어 다닐 수 있따 물론 Serializable보다 빠르다. [Parcel이라는 녀석은 무엇인가?] IPC시 이 꾸러미를 다른 프로세스로 휙 던져주는 방식이다. Parcelable class가 IPC를 위해서 포장, 압축이 된 형태라고 볼 수 있다. Developer를 참조하여 부가 설명을 하자면.... Parcel은 IBinder를 통해 전달 될 수 있는 Data나 Object Reference의 Container입니다. 이 Parcel은 primitive type, primitive array type 또는 Parcelable class들을 가지고 있을 수 있습니다. 이 Parcel은 Serialization과 "맥락"은 비슷하지만 "매커니즘"은 다르다. 이 Parcelable은 IPC에서 high performance를 낼 수 있는 형태로 되어 있다. [만드는 방법] 1. 먼...

*컴포넌트와 컴포넌트간에 데이터 전달을 위해서는 객체직렬화가 필요하다. 객체 직렬화는 Serializable객체를 통해 구현가능하고 추가적으로 Bundle,Parcel, Parcelable객체도 직렬화를 지원한다. 1. Serializable객체 직렬화의 기본 개념은 간단하다. 객체는 메모리에 존재하는 것이다.(new를 통해 객체 생성된 것) 이렇게 메모리에 존재하는 것을 파일 혹은 네트워크를 통해 저장 및 전송할 수 있을까? 객체 자체는 함수와 변수들이 존재한다. 함수와 변수는 메모리의 다른영역에 저장된다.(함수=code영역, 변수=heap영역) 이것을 그대로 파일/네트워크 등으로 전송/저장한다는 것은 쉽지않다. 직렬화는 함수는 신경쓰지 않고 단지 변수를 직렬화시킨다.(byte코드로 순차적으로 나열시킨다.) 왜 그럴까? 함수를 포함한 Class는 데이터가 아니다. 단지 코드일 뿐이다. 그러므로 Class파일만 있으면 참조가 가능하다. (송신측에 xxx.java, 수신측에 xxx.java 코드만 동일하게 존재하면 해결된다.) 그러나 변수는 다르다. 변수는 데이터이므로 코드로 가질 수 없다. 그러므로 직렬화는 이 변수 데이터들을 어떻게 전달하느냐에 관점을 둔다. 아래를 보자. Class 내 함수는 신경쓰지 않고 단지 변수만 직렬화 시킨다. 직렬화 개념은 변수 데이터를 순차적으로 byte코드로 나열하는 것이다. 이렇게 byte코드로 나열되면 이 데이터는 무엇이든 전송이 가능한 것이다. 아래 1번과 같이 객체를 직렬화 하고 2번과 같이 byte코드를 File이든 네트워크든 메모리든 쓸 수 있다. 만일 다시 객체화 시킬때는 4번과 같이 byte코드를 읽고 역직렬화 과정을 거치면 원래 객체를 복원할 수 있는 것이다. 역직렬화 과정에서는 Class코드를 참조하게 된다. 직렬화 방법은 "Serializable"을 상속받으면 자동으로 직렬화 처리되어 객체가 생성된다. 하지만 주의할 ...