android

[Android] URI, URL

URI URI는 특정 리소스를 식별하는 통합 자원 식별자(Uniform Resource Identifier). 웹 기술에서 사용하는 논리적 또는 물리적 리소스를 식별하는 고유한 문자열 시퀀스. URL URL은 흔히 웹 주소라고도 하며, 컴퓨터 네트워크 상에서 리소스가 어디 있는지 알려주기 위한 규약. URI의 서브셋이다. 요약하면 URI는 식별하기 위함이고, URL은 위치 정보이다.

[Android] Vector 이미지

Android 스튜디오에서 SVG(Scalable Vector Graphic) 파일을 Vector 리소스로 사용할 수 있도록 Vector Asset Studio 도구를 제공한다. Vector 이미지를 사용하면서 얻는 이점은 여러 해상도에 대응할 필요 없이 하나의 이미지로 화질 손실 없이 다른 화면 밀도에 맞게 크기를 조정할 수 있기 때문에 리소스로 관리로 인한 앱의 크기를 줄일 수 있다. 하지만 Android 4.4(API 20) 이하의 기기에서는 Vector 리소스 사용을 지원하지 않기 때문에 하위 호환에서 문제가 생길 여지가 있다. Vector를 사용하는 것은 단순한 아이콘 표현에 적합하다. 왜냐하면 다른 리소스 표현 방식보다 처음 이미지를 로드할때 CPU 사이클이 더 소모되기 때문에 최대 200 X..

[Android] left, top, right, bottom

Canvas를 통해 bitamp을 다루는 작업을 하다가 Rect 클래스를 사용하게 되었는데 left, top, right, bottom의 개념에 대해 혼동하는 부분이 있어 정리해보게 되었다. 이 개념은 View에 대한 좌표 혹은 크기를 정의할 때 사용되는데 각자 어떻게 정의되는지 그림을 그려봤다. Canvas 좌표계에선 [0,0] 부터 시작하는 특징이 있고, 각각 값의 의미는 아래와 같다. left : view 시작점의 x 좌표 top : view 시작점의 y 좌표 right : view 종료점의 x 좌표 bottom : view 종료점의 y 좌표

[Android] two-way binding 형식 지정하기

EditText에 데이터 바인딩을 적용하면서 입력되는 문자를 특정 형식으로 바로 변환해주고 싶었다. 해서 Converter라는 Object 클래스를 만들고 아래와 같은 함수를 만들었다. object Converter{ @JvmStatic fun stringWithFormat( value: String? ): String { return value?.moneyFormat() ?: "" } } 위 함수를 EditText의 속성에 databinding으로 적용해 보았다. 실행 결과는 에러이고 그 이유는 아래와 같다. The expression 'yourpackage.util.Converter.stringWithFormat(vmAmountGetValue)' cannot be inverted, so it cann..

[Kotlin] CoroutineBuilder

코루틴은 일시 중단이 가능한 작업 객체로 동시성을 지원하는 관점에선 스레드와 유사한점이 많다. 하지만 코루틴은 분명 스레드에서 동작하지만 그 어떤 스레드에 종속되진 않는다. 하나의 코루틴 작업을 스레드 이곳저곳을 돌아다니며 실행시킬 수 있기 때문이다. 이러한 코루틴을 만드는 방법은 CoroutineBuilder를 활용하는 것이다. CoroutineBuilder는 말그대로 코루틴을 만드는 코루틴 객체 생성자이다. CoroutineBuilder는 launch, async 이렇게 두 개로 볼 수 있다. launch, async를 알아보기에 앞서 Dispatchers에 대해 잠깐 알고 넘어가자. Dispatchers는 코루틴의 실행을 관리해주는 CoroutineContext로 스레드에 코루틴의 실행을 분배하거나..

[Android] Android Architecture Components(AAC)

구글에서 권장하는 아키텍처의 원칙은 '관심사 분리'와 '데이터 모델에서 UI 도출'이다. Activity나 Fragment와 같은 UI 기반의 클래스는 UI 및 운영체제 상호작용을 처리하는 로직만 포함되어야 한다. 위와 같은 클래스들은 최대한 가벼운 상태로 유지하여 수명 주기와 관련된 문제들을 피하고 테스트가 쉽도록 고려되어야 한다. 또한 OS가 언제든지 사용자에 의해 메모리 부족과 같은 시스템적인 조건으로 UI클래스들을 제거할 수 있기 때문에 로직의 성격에 따라 분리하여 UI클래스에 대한 의존성을 최소화하는 것이 좋다. 또한 UI는 데이터를 처리하는 모델에 의해 도출되어야 한다. 모델은 네트워크에 문제가 있거나 OS가 리소스를 확보하기 위해 앱을 제거해도 사용자의 데이터 또는 앱의 동작은 문제없이 지속..