안드로이드

스터디에서 간단한 앱을 제작 중이고, 구글 로그인 기능을 구현하려고 해보았다. 관련 유튜브 영상에서 파이어베이스에 앱을 등록하는 방법, 이미지url 로딩에 도움이 되는 오픈소스를 참고했다. 파이어베이스 제품을 사용하기 위해 구성파일과 SDK를 추가하고, 파이어베이스 '

1.서론 현재 학부생니까 다양한 분야를 접해보고 있다. 그 일환으로 안드로이드 스터디를 하다보니 깨닫게 된 점: 안드로이드는 참 다양한 방법으로 레이아웃을 보여주지 않을 때가 있다. 그래서 디버깅 로그를 봤는데 몇 백줄은 되는 것 같았다. 그 많은 정보들 가운데 딱 보

Clean Architecture 권장 앱 아키텍처 안드로이드 문서에 따르면 권장 앱 아키텍처는 다음과 같다. 도메인 레이어가 선택인 이유는 있을 경우, 결합도를 낮추고 관심사를 분리할 수 있지만, 그만큼 보일러 플레이트가 증가하기 때문이라고 생각한다. UI Lay

홈 UI를 만들고 있다. 검색바를 클릭하면 기준에 맞는 콘텐츠를 찾게 만들 필터를 뙇! 보여줘야 한다. 밑으로 스르륵 smooth하게 애니메이션도 넣고 싶지만! 일단은 기초부터 만들어보았다. Frament1 속의 검색바를 클릭하면 검색필터를 하위프레그먼트로 보여주려고

1.서론 로그인 인증이나 아이디&닉네임 중복확인에 실패했음을 시각적으로 알려주기 위한 기능을 만드려고 한다. ViewModel에서 로그인이나 중복확인에 실패 처리를 할 때, 실패의 결과로 UI에서 사용자에게 알림을 줘야 한다는 뜻이다. 2.본론 1.먼저 생각해 본

1.서론 서버에 로그인 요청을 보내면 응답으로 아래처럼 토큰 정보들을 반환할 예정이다. 참고자료 https://developer.android.com/training/data-storage/shared-preferences?hl=ko

참고자료 https://yozm.wishket.com/magazine/detail/912/

평소 인텔리제이보다는 안드로이드 스튜디오를 많이 이용해서 인텔리제이는 설정이 굉장히 raw한 상태이다. 이제 kotlin style guide을 따르지 않으면 포매팅 이슈를 보고하도록

compose도 기본을 알고 사용해야 효율적인 앱을 만들 수 있다!compose를 사용해 프로젝트를 진행한 적은 있다. 하지만 아래와 같이 compose 라이브러리의 하위 개념들에 대해서는 잘 모르고 있었다. 화면을 이루는 컴포넌트의foundation, ui, layo

좋은 앱을 만드려면 화면 렌더링을 이해하고, 메모리 자원을 효율적으로 사용해야 한다. 자원을 효율적으로 사용하려면 낭비되는 것을 막아야 한다! 그래서 대표적인 메모리 누수를 일으킬 수 있는 사례들을 정리해보려고 한다.아래 코드의 문제점은 내부 클래스가 외부 클래스에 대

fastlane으로 구글 플레이 콘솔의 내부테스트로 앱을 배포하려는데 사이닝 키가 다르다는 메세지를 받았다. 이를 확인하기 위해 위의 명령어로 현재 프로젝트의 사이닝 키 정보를 출력해보았다.확인해보니 내가 준 인증서 SHA1키와 줘야하는 인증서 키 내역이 달랐다. 구글

Android xml+RecyclerView로 고통받던 건 옛날이야기로 느껴질 정도로 편리해진 LazyColumn+Paging 방법이 있다. gradle 추가 1.0.0은 이 포스팅에서 이용하고자하는 collectAsLazyPagingItems이 없으므로 아래의 버전으

계정 선택 인텐트 화면까지는 뜨는데 여기서 계정을 선택하면 더 데이터를 얻을 수가 없고 닫힌다googleAuthLauncher부분에서 resultCode가 RESULT_CANCELED로 나오는 게 문제이다.관련 공식문서??설정 오류가 나면 이렇다고 한다…코드는 문제없는

Background concurrent copying GC freed 101442(4MB) AllocSpace objects, 4(96KB) LOS objects, 50% free, 7MB/15MB, paused 225us total 113.089ms위와 같은 로그를

앱을 사용하면서 사용자는 다양한 요청을 하게 된다. 서버의 문제이거나, 사용자 권한 문제로 사용자가 예상하지 못한 결과를 보여주어야 하는 경우가 생긴다. 이런 경우에 대처하는 것이 에러핸들링이다. 에러핸들링을 하지 않으면 그냥 빈 화면, 최악의 경우 앱이 튕겨버리기 때

OkHTTP3 에러 - IllegalStateException:close 구글 사전 출시 보고서에서 보고된 에러 중의 하나로, api 응답으로 200이 아닌 401을 받았을 때 발생하는 것으로 보였다. 하지만 401발생 -> 해당 에러 발생은 아니고, 에러가 오면 로

다운로드 용량 26.7MB 짜리 앱이 빌드는 12분 가량 된다는 게 가장 큰 문제이다.로컬 빌드는 3분 47초 걸리는데 CI가 3배나 걸리면 CI빌드를 도입한 보람이 없다고 생각했다. 그래서 CI빌드 속도 개선을 시작했다!아직 빌드를 위한 전처리와 빌드 밖에 없는 기본

서버에서 받은 응답을 모바일 화면에서 계속 사용해야 하는 상황이라면 서버에 그 정보를 저장하고 요청해서 사용하는 게 일반적이다.하지만 서버에 저장할 가치가 없을 경우 모바일에서 로컬에 저장하고 꺼내 사용하는 것이 더 적합하다고 생각해서 RoomDB를 사용해보고 간단한

안드로이드 Viewmodel에 단위테스트를 적용해보는 중인데 마침 안드로이드 코드랩에서 튜토리얼을 제공하길래 따라해보며 정리해보았다.깃허브 오픈소스 프로젝트를 바탕으로 예시 코드를 보며 Viewmodel에 대한 단위테스트 시나리오 예제들은 어떤 식인지 참고하기 좋았다.

ㅇㅇ

테스트를 실행했는데 아래와 같은 에러를 계속 보게 되었다.클래스를 못찾는 거니까 IDE 캐시를 지워보거나, 재시작을 해보거나, 클래스가 생각밖의 위치에 있지는 않은지 확인해보아야 한다. 이 스택오버플로우의 답변 하나가 힌트를 알려주었다.이 답변을 보고 직접 문제가 된

ComposeNotIdleException 아래와 같이 UI테스트를 하던 중 스레드 딜레이를 쓰지 않았음에도 테스트가 27초까지 종료되지 않았고, 결과 화면에는 ComposeNotIdleException: Idling resource timed out: possibl