- 최근 개인 제작 앱을 구글 플레이 스토어에 등록 심사를 요청했는데, ACCESS_FINE_LOCATION 권한에 대한 허가가 필요한 이유를 사용자에게 구체적으로 제공해야 한다고 하여 거절당했다. - 가볍게 Toast로 위치 권한이 필요합니다. 정도로는 납득시킬 수 없고, 적절한 기능 예시와 함께 사용자에게 권한 허가를 요청해야했다. - 먼저 해당 권한에 대한 기능 관련 화면 스크린숏을 3장 정도 수집했다. 그리고 drawable에 추가. - 나는 수평 슬라이드 페이징을 통해 예시 화면을 보여주고자 했다. - 대충 슬라이드 페이징 - 제목 - 설명 - Yes or No 버튼을 수직으로 배치하고자 Column을 최상단에 약간의 padding을 넣어 선언했다.Column( modifier = Modi..
Android
- 서비스의 기존 로직에 UI 로직과 DB 접근, 네트워크 로직을 복잡하게 모두 차지하고 있는 Manager 클래스가 있었다. - 작업 시에 혼동이 오고 유지보수다 어렵다 보니 에러 발생 시 찾기가 쉽지 않았고, 스레드에 대한 문제도 빈번하게 발생하고 있었다. - 어느 정도 간단한 DB 접근은 문제없다 해도 데이터가 많다면 ANR이 발생.. 이를 위해 비동기 처리가 누락된 부분을 탐색했지만 매니저 클래스를 나눠버리는 게 나을 것으로 확인되었다.- 아예 MVVM 패턴을 적용하도록 했다. 내부의 DB 쿼리 작업들이 명시된 ~DAO 클래스들은 내부적으로 AppContext를 사용하고 있는데, 이 의존성을 전부 해결하려면 상당한 시간이 걸려.. 일단은 당장 ANR 문제를 해결하기 위해 Hilt 없이 MVVM 패..
- Polling에 대한 로직을 구성하면서 여러 화면에 한 번에 폴링에 따른 변경 사항을 전파할 수 있는 Event Bus 라이브러리를 사용했다.https://github.com/greenrobot/EventBus GitHub - greenrobot/EventBus: Event bus for Android and Java that simplifies communication between Activities, Fragments, ThreadEvent bus for Android and Java that simplifies communication between Activities, Fragments, Threads, Services, etc. Less code, better quality. - green..
- 폴링은 특정 조건이 충족될 때까지(또는 최신 상태를 얻기 위해) 일정 간격으로 서버나 작업 상태를 반복 조회해 변화가 있으면 처리하는 방식이다. - 서버에서 비동기로 처리 중인 데이터가 있다면 그 처리 상태를 클라이언트에서 주기적으로 확인하는 시스템이 필요했다. - 먼저 object class로 Polling Manager를 선언했다. 그리고 멀티 스레드 상황 처리에 대한 SynchronizedList를 기반으로 대상 데이터 타입을 기반으로 한 리스트를 선언했다.object PollingManager { private val pollingList = Collections.synchronizedList(mutableListOf())- Collections.synchronizedList(...)는 ..
- 사용자가 유연하게 특정 Value를 조정할 수 있는 SeekBar - 몇 가지 커스텀 방법에 대해 정리해 본다. - 다음처럼 단순한 형태의 경우에는 아래처럼 구현되었다.- progress: 초기 설정 값- progressDrawable: SeekBar 트랙 라인에 대한 커스텀 지정- thumb: 가운데 조절 버튼에 대한 커스텀 지정 - 이렇게 완전한 free가 아니라 어느 정도 단계를 지정해 둔 경우에는 다음과 같이 구현할 수 있다. - max="6" → 진행 범위는 0.. 6 (총 7단계)- progress="3" → 초기 위치는 가운데(3)- progressTint: 진행된 영역에 대한 색상- tickMakr: 각 단계의 눈금 표시점에 대해 커스터마이징 - 이후에는 다음과 같이 Listener로 ..
- SOLID 원칙 : 객체 지향 프로그래밍에서 견고하고 유지보수 가능한 개발을 위한 원칙이다. - SRP, OCP, LSP, ISP, DIP 총 5가지가 합쳐져서 SOLID인데, 먼저 SRP부터 살펴보자SRP 단일 책임 원칙 Single Responsibility Principle- 클래스나 모듈은 하나의 책임만 가져야 하며, 오직 하나의 이유로만 변경되어야 한다.- 복잡성을 줄이기 위한 핵심 원칙으로, 클래스가 여러 가지 일을 할 때 발생할 수 있는 변경의 부담을 줄임- 코드의 가독성과 유지보수성을 향상- 변경이 필요할 때, 변경의 영향을 최소화할 수 있음class DataRepository(private val apiService: ApiService) { fun fetchData(): Dat..
- 리드미에 프로젝트 구조를 정리해서 보여줄 때 용이하게 사용되는 트리 구조 - 프로젝트 수준의 build.gradle에 아래 함수를 구성함으로써 안드로이드 스튜디오 터미널에서 간편하게 생성할 수 있다.import java.nio.file.Filesimport java.nio.file.Pathimport java.io.Fileimport java.util.stream.Collectors//import 영역은 반드시 다른 어떤 코드들보다 최상단에 위치할 것tasks.register("printPackageTree") { group = "report" description = "Prints tree under app/src/main/java/com/windrr/jibrro" val ignor..
- 이번에 마켓에 또 앱을 하나 제출하면서, Location 권한에 대한 요청 사유를 제출하라는 경고를 받았다. - 여태 Location 권한을 사용하는 앱을 혼자 제출해 본 적은 없었는데, 경험 삼아 짧게 내용을 정리해 본다.- 앱에서 위치 접근 권한이 사용되는 중요한 기능 몇 가지를 상세하게 설명했다. 영어로 쓰는 게 심사에 좀 더 유연할 것 같아서 영어로 표기했다. - 그리고 유튜브 동영상을 넣으라는데, 내가 기존에 가끔씩 운영하던 유튜브에 '일부 공개'로 업로드하여 직접 기능을 사용하는 영상을 녹화해둔 링크를 제공했다. - 유튜브에서 일부 공개로 지정 시에는 링크를 직접 공유받은 사용자만 영상을 확인 가능한 것으로 알고 있다.
- 카테고리라는 테이블이 존재하고, 하위에 Book이라는 데이터가 리스트로 들어가는 구조가 있다. - 그리고 이 Book 또한 다른 테이블이고, 카테고리의 id를 외래키로 참조한다. - 카테고리의 id가 DB에 저장된 이후 업데이트되는 값이라 사실상 카테고리가 먼저 저장되지 않는 이상, Book 데이터가 저장될 수가 없는 상황이다. - 서비스에서는 매 동기화로 수신받은 카테고리가 DB에 존재할 경우에는 굳이 다시 DB 업데이트 로직을 진입하지 않는다. - 하지만 여기서 문제가... 카테고리는 제대로 저장되었어도 다음 Book 데이터 처리과정에서 사용자가 앱을 강제 종료하거나 어떠한 이유로 예외가 발생하여 동기화 상태가 완료되지 못한다면 카테고리 데이터만 남고, Book 데이터는 아무리 다시 동기화를 해도..
- 클린 아키텍처에서 UseCase는 단일 책임 원칙 하에 앱에서 실행되는 비즈니스 프로세스를 캡슐화하는 역할을 한다. - UseCase를 구성함으로써 ViewModel의 역할을 명확히 할 수 있고, UseCase는 변경을 최소화 한 채 관심사를 분리하고, Activity 뿐만 아니라 View, Widget에서 즉시 사용 가능한 이점도 있다. - 근데 사이드 프로젝트에서 UseCase를 구성하고 관리하다 보니.. UseCase의 역할이 단순히 전달 정도로 밖에 안 되는 부분들이 많았다.class GetDestinationUseCase( private val repo: SettingsRepository) { operator fun invoke(): Flow = repo.getDestination..
