Android with Kotlin

Activity 는 유저가 할 수 있는 한가지의 집중된 것을 의미한다.전형적인 Activity는 UI 요소가 어떻게 스크린에 나타날지 정의한 layout 과 관계를 갖는다.Kotlin 프로젝트임에도 app/java 디렉터리 안에 main 이 있는 이유는, 이 규약을

이 단원에서는 스스로 공부하는 방법을 배운다. 안드로이드 템플릿을 골라서 코드를 분석하기Empty template 에서 file -> new -> activity -> gallery 에서 특정 액티비티 추가하면서 공부하기구글의 샘플 코드 분석하기 Android · Gi

ScrollView 가 가능한 App 을 만들건데, Design Tool 을 이용해서 만들거다. Android Kotlin Fundamentals: LinearLayout using the Layout Editor(https://developer.androi

효율적인 레이아웃 설계를 위하여 : 성능 및 뷰 계층 구조  |  Android 개발자  |  Android Developers간단한 레이아웃을 구성하려면 linearLayout 을 쓰는게 좋지만, 복잡한 레이아웃에 linearLayout 를 중첩해서 사용하는건 성능

이상 살펴본 터치 이벤트, 키 이벤트와는 별개로 각 View 들은 고유의 이벤트를 가지고 있다.뷰 이벤트 처리는 이벤트 소스, 이벤트 핸들러로 역할이 나뉘며 둘을 리스너 로 연결해야 이벤트를 처리할 수 있다. 이벤트 소스 : 이벤트가 발생한 객체이벤트 핸들러 : 이벤트

res/drawable 에서 new -> Drawable Resource File그리고 원하는 이름으로 파일을 작성 아래의 예시 파일 이름은 round_button 으로 생성함.요런게 생긴다.이걸 layout 에 적용할 수 있는데, background 에 적용하면이런

키가 의미하는 것은 카카오톡에서 메시지를 보낼때 나타나는 키보드(소프트 키보드)를 의미하는 것이 아니다. 키 이벤트는 안드로이드 기기에 있는 하드웨어 키보드에서 발생하는 이벤트를 말한다.하드웨어 키보드는 전원버튼, 볼륨 조절 버튼, 하단 네비게이션 바의 버튼을 말한다.

터치 이벤트 자체를 처리하는 것은 게임이나 그림판과 같은 앱에서는 많이 쓰이지만 서버와 통신을 주고받는 앱에서는 view 에 정의되어 있는 이벤트를 더 자주 사용한다.앱의 화면에서 발생하는 사용자 이벤트는 터치이다. 앱은 사용자가 터치를 했는지, 스와이프를 했는지 인식

Linear layout 을 이용하면 view 계층 구조를 이용해서 화면을 구성할 수 있다. 이러한 방법을 컴포지트 패턴 또는 문서 객체 모델이라고 부른다. 이런 화면 구성 방법은 웹 레이아웃에서 흔한 방법이다.layout 에서 중점적으로 살펴볼 사항은android:l

res 디렉터리 하위에 위치한 리소스는 정적인 자원을 의미한다.프로젝트를 새로 만들거나, 모듈을 새로 만들면 res 하위에 drawable, layout, mipmap, values 라는 디렉터리가 생긴다. 기본으로 4개의 디렉터리가 생기지만 더 많은 디렉터리가 있다.

리소스 조건은 어떤 리로스를 특정 환경에서만 적용하도록 설정하는 것을 말한다. mdpi(medium dots per inch) 용으로 48x48(px) 이미지를 준비했다고 해보자, 그런데 이 이미지를 똑같이 hdpi(high dots per inch) 에도 적용하면 이

API 레벨 호환성 문제는 gradle 에 minSdkVersion, targetSdkVersion 을 설정한다고 해결되는게 아니다. 사용하는 클래스, 함수들까지 고려해야한다.안드로이드 문서 보면 makeText()(https://developer.andro

안드로이드 디바이스는 다양한 크기로 출시된다. 그러므로 안드로이드 앱 개발자는 다양한 기기와 호한되는 화면을 만드는 것이 중요한 과제이다. 이러한 디바이스 크기에 따른 호환성은 안드로이드 시스템 자체에서 도와주는 부분이 있고, 개발자가 직접 코드에서 해결해야 하는 부분

퍼미션은 앱의 특정 기능에 부여하는 접근 권한을 말한다. 내가 개발하는 앱이 다른 앱이나 안드로이드 시스템에서 보호하는 특정 기능을 이용할 때 퍼미션 사용을 설정해야한다. 마찬가지로 내가 만든 기능을 다른 앱에서 사용할 수 없도록 보호하고 권한을 얻은 앱에서만 허용하고

다이얼로그란 사용자와 상호 작용하는 대화상자이다. 대표적으로 사용되는 다이얼로그로는 토스트가 있고, 날짜 또는 시간 입력, 알림 창 등이 있다. 그 외에 다양한 다이얼로그가 있으며, 개발자가 직접 구성하는 커스텀 다이얼로그도 있다. 두번째 매개변수가 메시지이며, 세번째

안드로이드에서 다이얼로그의 기본은 AlertDialog 이다. 알림창은 단순히 메시지만 출력할 수도 있고 다양한 화면을 출력할 수도 있다. 이전에 살펴본 데이트 피커, 타임 피커 모두 AlertDialog 의 하위 클래스이다. 알림창은 크게 제목, 내용, 버튼 영역 이

사용자에게 짧은 소리로 특정한 상황을 알릴 때가 있다. 대표적으로 카카오톡 메시지가 있을텐데, 이를 알림음이라고 한다. 알림음은 자체 녹음한 음원을 쓸 수도 있지만 안드로이드 시스템에 등록된 소리를 이용할 수도 있다. 안드로이드 시스템은 알림(notification),

앱의 상태바(베터리, 네트워크, 시간)에 앱의 정보를 출력하는 걸을 알림(notification) 이라고 한다. 원래 상태바는 안드로이드 시스템이 관리하는 곳으로 앱이 직접 제어할 수 없다. 그러므로 앱은 시스템에 의뢰하는 (시스템 콜 같은건가?) 형태로 알림을 띄우게

알림은 사용자에게 앱의 상태를 간단하게 알려주는 기능을 하는데, 사용자가 더 많은 정보를 요구할 수 있다. 그래서 대부분 앱은 사용자가 알림을 터치했을 때 앱의 액티비티 화면을 실행한다. 그런데 이렇게 하려면 알림의 터치 이벤트를 구현해야 한다. 알림은 안드로이드 시스

알림에 보이는 정보는 기본으로 문자열이지만 그 밖에 여러 가지 스타일을 제공한다. 이 스타일을 이용하면 문자열 이외에 다양한 콘텐츠로 알림을 구성할 수 있다.

플랫폼에서 제공하는 API만으로 앱의 화면을 구성할 수 이씨잠ㄴ, 버전 호환성 때문에 개발을 어렵게 만든다. 또한 사용자 요구가 늘어남에 따라 앱이 복잡해지다보니 좀 더 다양한 뷰가 필요하기도 하다. 구글에서는 이러한 요구에 따라 플랫폼 API 외에 라이브러리를 따로

액티비티의 구성 요소인'액션바(ActionBar)'는 화면 위쪽에 타이틀 문자열이 출력되는 영역을 의미한다. 이 액션바 부분을 제외한 영역을 '콘텐츠'라고 부른다. 즉, 액티비티가 출력되는 전체 창은 액션바 영역과 콘텐츠 영역으로 구분된다.액션바는 타이틀, 네이게이션

툴바(ToolBar) 를 사용하는 목적은 액션바와 같다. 그런데 액션바는 액티비티 창이 자동으로 출력하는 액티비티의 구성요소지만, 툴바는 개발자가 직접 제어하는 뷰라는 데 차이점이 있다. 툴바를 쓴다는 것은 액션 바를 쓰지 않겠다는 것이고, 하나의 액티비티 전체가 콘텐

androidx 에서 제공하는 라이브러리가운데

일반적으로 앱을 사용하다 보면 여러 가지 항목을 나열하는 목록 화면이 많다는 것을 알 수 있다. 리사이클러 뷰는 이러한 목록 화면을 만들 때 사용한다. 리사이클러 뷰는 목록을 만드는데, RecyclerView 클래스만으로 화면에 아무것도 출력되지 않는다. 그러므로 다음

레이아웃 매니저는 어댑터로 만든 항목을 리사이클러 뷰에 배치한다. 레이아웃 매니저는 RecycelrView.LayoutManager 를 상속받은 클래스로, 라이브러리에서 다음의 기능을 제공한다. LinearLayoutManager: 항목을 가로나 세로 방향으로 배치한다

뷰 페이저는 스와이프 이벤트로 화면을 전환할 때 사용한다. 플레이 스토어 앱을 보면 사용자가 손가락을 이용해 화면을 양옆으로 밀어 이전이나 다음 화면을 볼 수 있다. 이러한 기능이 뷰 페이저이다.뷰 페이저는 플랫폼 API에서 제공하지 않기 때문에 androidx 라이브

드로어 레이아웃(DrawerLayout)은 액티비티 화면에 보이지 않던 내용이 왼쪽이나 오른쪽에서 손가락의 움직임에 따라 밀려 나오는 기능을 한다. 마치 서랍같다고 해서 drawer 라고 한다. 마찬가지로 드로어 레이아웃 역시 플레이 스토어에 적용되어 있다.드로어 레이

androidx 라이브러리에 대해 다뤘던 툴바, 프레그먼트, 뷰페이저

구글의 material 디자인 은 모바일과 데스크톱, 그리고 그 밖에 다양한 장치를 아우르는 일관된 애플리케이션 디자인 지침이다. 이러한 지침에 맞게 앱을 개발하려면 다양한 뷰가 필요한데, 구글은 이를 지원하려고 머티리얼 라이브러리를 제공한다. 이러한 라이브러리를 이용

탭 레이아웃은 탭(tab)으로 구분하는 화면에서 탭 버튼을 배치하는 레이아웃이다. 탭 화면에는 탭 버튼을 선택했을 때 나와야 하는 내용이 있다. 탭 레이아웃은 이 중 탭 버튼을 다양하게 표시하고자 사용하는 뷰이다. 역시 플레이스토어 상단과 하단의 탭이 탭 레이아웃을 이

지난 포스팅에서는 androidx 라이브러리의 드로어 레이아웃을 봤었다. 그때는 단순히 드로어 레이아웃에 TextView 만 넣었는데, 일반적으로 드로어에는 네비게이션 뷰를 넣는다. 드로어가 네비게이션 뷰를 갖도록 하였고, 헤더로는 res/layout 의 navigat

확장된 플로팅 액션 버튼은 화면에 떠 있는 듯한 버튼을 제공하는 뷰이다. 머티리얼 라이브러리가 처음 나왔을때 플로팅 액션 버튼을 제공했지만, 지금은 문자열까지 출력할 수 있는 확장된 플로팅 액션 버튼도 제공한다. 그리고 코드에서 문자열까지 나오게 확장하거나 아이콘만 나

앱바, 코디네이터, 탭 레이아웃

안드로이드 앱은 4개의 컴포넌트(액티비티, 브로드캐스트 리시버, 서비스, 콘텐츠 프로바이더)를 이용하여 개발하는데, 이때 핵심 클래스가 Intent 이다. 인텐트는 '컴포넌트를 실행하려고 시스템에 전달하는 메시지' 라고 정의할 수 있으며, 기능을 수행하는 함수를 제공하

액티비티는 화면을 구성하는 컴포넌트이다. 따라서 한 액티비티에서 인텐트로 다른 액티비티를 실행하면 화면이 전환된다. 이때 고려할 사항이 있다. 어떤 액티비티가 다른 액티비티를 실행해 화면이 전환되었을 때 의도에 따라 화면을 되돌리거라 되돌리지 않을 수도 있다. 이런 상

일반적으로 액티비티가 종료되면 객체가 소멸하므로 액티비티의 데이터는 모두 사라진다. 그리고 다시 액티비티를 실행하면 초기 상태로 나온다. 그런데 액티비티가 종료될 때 유지해야 할 데이터를 저장했다가 다시 실행할 때 복원할 수 있을까?액티비티가 종료되는 상황으로는 코드에

시스템에서 제공하는 키보드(소프트 키보드)는 액티비티 화면에서 사용자가 글을 입력할 수 있는 뷰가 포커스를 가지는 순간 자동으로 올라온다. 그리고 사용자가 뒤로가기 버튼을 누르면 뷰가 자동으로 사라진다.그런데 때로는 코드에서 특정한 순간에 키보드를 올리거나 내려야 할

태스크 관리란 액티비티를 어떻게 생성하고 관리하는지를 제어하는 일을 의미한다. 시스템에는 액티비티의 태스크를 유지하는 기본 규칙이 있으며 일반적으로는 이 기본 규칙을 그대로 이용하므로 개발자가 태스크를 제어할 일은 많지 않다. 그런데 특정한 상황에서 개발자가 액티비티의

ANR 은 activity not response 의 약자로, 액티비티가 응답하지 않으는 오류 상황을 의미한다. 액티비티를 작성할 때 ANR 을 고려하지 않으면 앱이 수시로 종료될 수 있다. 액티비티로 구성한 앱 화면은 사용자 이벤트에 빠르게 반응해야 한다. 그런데 액

브로드캐스트 리시버는 안드로이드 시스템에서 생명주기를 관리하는 컴포넌트 클래스 4개 가운데 하나이다. 브로드캐스트 리시버는 액티비티와 달리 앱의 핵심 로직을 담당하지 않는다. 그리고 브로드캐스트 리시버를 작성하는데 도움을 주는 별도의 API도 별로 없다. 그런데도 동작

서비스 컴포넌트는 백그라운드 작업을 목적으로 하는 컴포넌트이다.

바인드 서비스 바인드된 서비스란 클라이언트-서버 인터페이스 안의 서버 역할을 맡은 컴포넌트(서비스)를 말한다. 이를 사용하면 컴포넌트(Activity 등)를 서비스에 바인딩하고, 요청을 보내고, 응답을 수신하며, 프로세스 간 통신(IPC)을 실행할 수 있다. 일반적으로

안드로이드 앱은 4개의 주요 컴포넌트로 구성된다. 그런데 액티비티를 제외한 나머지 컴포넌트는 화면을 구현하는 용도가 아니라 백그라운드에서 작업을 처리할 목적으로 사용한다. 예전에는 사용자가 앱을 실행해 화면이 출력된 적이 없는 상황에서도 서비스나 브로드캐스트 리시버로

앱이 백그라운드 상황일때 서비스를 이용하는 것은 제약을 받지만, 잡 스케줄러를 이용하면 이를 보완할 수 있다. 안드로이드 버전 8부터 서비스 백그라운드 제약이 생기면서 잡 스커줄러의 역할이 더욱 중요해졌다. 잡 스케줄러를 이용한다고 해서 모든 상황의 백그라운드 처리를

MP3 음원을 재생하는 서비스를 가진 앱 모듈을 만들고, 다른 모듈에서 해당 앱의 서비스를 호출해서 사용하도록 만들어보자. AIDL 과 메시지를 모두 이용해보자.우선 음원을 재생하는 기능을 가진 outer 모듈을 만들자. MyAidlInterface.adil 파일을

앱의 데이터는 그 앱의 구성 요소에서 이용할 때는 문제가 없지만 외부 앱에서는 보안상의 이유로 접근하지 못한다. 그렇지만 앱을 만들다보면 공유해야하는 데이터도 있기 마련이다. 대표적인게 휴대폰에 저장된 주소록 데이터이고, 카메라로 촬영한 사진등이 있다. 이런 앱 사이에

카메라 앱을 실행해 사진을 촬영하고 사진 데이터를 가져오는 방법을 알아보자. 카메라 앱을 연동하여 사진을 촬영하고 그 결과를 돌려받는 방법은 2가지가 있다. 사진 데이터를 가져오는 방법 사진 파일을 공유하는 방법 사진 데이터를 가져오는 방법은 카메라 앱으로 사진을 촬영한 후 파일로 저장하지 않고 데이터만 넘겨주는 방식이다. 이 방식은 사진을 파일로 저장...

대부분의 앱이 데이터를 만들고 저장하고 다양한 방법으로 가공하여 서비스 한다. 이때 앱의 데이터는 대부분 외부 서버에 저장해 놓고 통신으로 주고받지만 휴대용 기기의 특성상 네트워크가 불안정한 상황도 고려해야 하므로 기기에 저장하는 방법도 알아야 한다. 데이터베이스에

대부분 앱은 네트워크 통신을 이용해 서버에서 데이터를 가져와 화면에 출력하거나 앱에서 발생한 데이터를 서버에 넘겨서 저장한다. 때문에 HTTP 통신 방법과 기기의 각종 네트워크 정보를 확인하는 방법을 알아야한다. 네트워크 접속 정보를 파악할 때는 Connectivity

앱에서 네트워크 통신을 구현하려면 퍼미션을 설정해야한다. 안드로이드 앱은 네트워크 통신을 할때 기본으로 HTTPS 보안 프로토콜을 사용한다. 만약 일반 HTTPS 프로토콜로 통신하려면 특정 도메인만 허용하도록 선언해 줘야 한다. res/xml 폴더에 임의의 이름으로 X

2015년 스퀘어에서 만든 HTTP 통신을 간편하게 만들어 주는 라이브러리이다. Retrofit은 네트워크 통신 정보만 주면 그대로 네트워크 프로그매잉을 대신 구현해 준다. 통신에 필요한 인터페이스를 만들고 코드를 구현하지 않은 상태에서 Retrofit에게 인터페이스

Context : application environment 의 전역 정보에 대한 접근 권한을 준다.ContextWrapper : proxy implementation for the ContextContextThemeWrapper : 요런것도 있더라Activity :

네비게이션을 체계적으로 이용해보자

네비게이션 컴포넌트의 추가 기능인 Safe Args 를 이용하는것이 좋다. Type Safe 하게 데이터를 전달할 수 있게 도와주기 때문에 의도치 않은 실수를 줄일 수 있다.

안드로이드 앱에서 여러 뷰를 이동하면 안드로이드 시스템은 사용자가 이동한 화면을 백스택에 쌓아둔다. 백스택은 유저가 방문한 화면에 대한 로그이다. 네비게이션의 destination 을 이동할때마다 안드로이드 시스템은 이 destination 을 백스택 최상단에 쌓아둔다

유저가 버튼을 눌러서 이동하는 선형적인 네비게이션 구조에서는 필요없겠지만, 일반적인 경우 네비게이션 UI에 네비게이션 그래프를 결합해서 사용한다.바텀 네비게이션 바를 만든 상황을 가정하자. home, post, setting 세가지 화면을 바텀 네비게이션에서 클릭된 아

findViewByiD<View>(id: Int) 함수는 root 뷰에서부터 순차적으로 탐색해가면서 id 에 해당하는 뷰를 찾는다. 그 때문에 뷰가 많아지면 앱의 성능이 저하될 수 밖에 없다. 또한 type safe 하지 않아서 런타임 에러를 유발할 수 있다.그에

액티비티는 onCreate 시점에 device configuration 을 참조한다. 만약 device configuration 이 변경되면 onCreate 를 다시 호출하고 이러한 이유로 다른 조치가 없다면 핸드폰을 가로 모드로 하면 view 가 초기화 된다. 이때

만약 뷰 모델의 데이터가 변경되면 UI 컨트롤러(액티비티 혹은 프레그먼트)가 그에 맞춰서 스크린에 출력되는 데이터를 바꿔줘야 한다면, 라이브 데이터가 도와줄 수 있다.

뷰 모델과 라이브 데이터를 적용하여 각 코드영역의 관심사의 분리를 만들어냈다. 그럼에도 불구하고 view 가 프레그먼트에서 코드의 복잡성은 증가하게 된다. 만약 뷰가 스스로 정보를 업데이트 하도록 만들면 어떨까? 프레그먼트의 코드가 훨씬 단순해질 것이다. 이러한 방식을

SQLite 를 사용해서 데이터를 저장한다는 사실은 알았다. 이러한 SQLite 를 위한 라이브러리가 Room 이다. Room 은 SQLite 위에서 작동하며, SQLite 의 장점을 이용하는 동시에 코드를 더욱 간결하게 사용할 수 있게된다. 이러한 Room 을 이용하

리사이클러 뷰에 데이터셋이 추가되어서 notifyDataSetChanged() 를 사용하는 경우가 흔하다. 하지만 리사이클러뷰를 업데이트하는 함수가 이것뿐만 있는게 아니고, 이 함수를 남발할 경우 성능에 악영향을 줄 수 있다. 전체 list 를 다시 그린다. 리스트의

깃헙 마스터브랜치에 있는 코드 리사이클러뷰에 네비게이션을 적용해보자.

https://medium.com/@kimdohun0104/%EB%AA%A8%EB%86%80%EB%A6%AC%ED%8B%B1%EC%97%90%EC%84%9C-%EB%A9%80%ED%8B%B0-%EB%AA%A8%EB%93%88%EB%A1%9C-%ED%83%88%

compose 를 배워보고싶은데 왜 배워야하는지 먼저 알아보자.

Compose 에서는 상태를 어떻게 관리할까?

Stateless 한 composable 을 알아보자

compose 에서 복잡한 state 와 logic 은 어떻게 관리할까?