nueijeel

안드로이드 스튜디오 시뮬레이터에서는 카카오 로그인이 정상적으로 작동하는데기기에서 배포된 앱을 실행했을 때 카카오 로그인이 안되는 현상이 발생했다. 발생한 오류 로그카카오계정으로 로그인 실패System.err W  AuthError(statusCode=401, reason=Misconfigured, response=AuthErrorResponse(error=misconfigured, errorDescription=invalid android_key_hash or ios_bundle_id or web_site_url))  개발 과정에서 카카오 개발자 콘솔 안드로이드 플랫폼 설정에 이미 디버그용 키 해시를 등록해놓은 상태였기 때문에 무엇이 문제인지 감도 안 잡혔다...구글링을 해보니 릴리즈 키 해시를 등록해야..

프로젝트에서 FCM(Firebase Cloud Messaging)을 이용한 푸시 알림을 구현해야 했는데앱이 Background 상태일 때 푸시가 뜨지 않고 작업 표시줄에만 알림이 표시되는 현상이 발생했다. fcm이 알림을 처리하는 방식과 관련이 있기 때문에 이걸 이용해서 해결해보려고 한다.  앱 상태에 따른 수신 메시지 핸들링 Firebase 공식 문서에 따르면FCM은 FirebaseMessagingService 클래스의 onMessageReceived() 함수를 통해 메시지를 수신한다. 보통의 경우 onMessageReceived() 콜백 함수가 작동해 알림을 표시하도록 하면 되지만 두 가지 예외 케이스가 있다.     1. 앱이 Background 상태일때 Notification 메시지만 수신되는 경..

그동안 단일 액티비티 기반의 프로젝트에서 프래그먼트 간 데이터 공유를 위해 Bundle 객체를 주로 사용해왔다.다양한 타입의 값들을 bundle에 담아 전달할 수 있는데 그 중 사용자 정의 클래스 객체를 전달하기 위해서는 직렬화하는 과정이 필요했다. 지금까지는 java의 serializable 인터페이스를 구현해 직렬화했었는데,안드로이드 환경에서 serializable은 성능적 측면에서 문제가 있을 수 있다는 점을 알게되어 더 나은 방안을 찾아보고 포스팅하게 되었다.   직렬화직렬화(Serializable)는 메모리에 있는 데이터를 디스크에 저장하거나 네트워크 통신을 통해 전달하기 위해 byte stream 형태로 변환하는 것이다. (역직렬화는 반대 개념)    그렇다면 직렬화가 필요한 경우는 언제일까?..

세모반 AOS는 3명이 담당하고 있어서 각자 맡은 부분을 따로 구현하고 별다른 코드리뷰는 진행하지 않고 있다.  그래서인지 api 호출에 필요한 레트로핏 인스턴스 생성 코드도 화면별로 다 따로 만들어져있어서많은 코드가 중복되기도 하고,개발 서버와 운영 서버 도메인을 바꿔가며 테스트할 때 baseURL에 들어가는 값을 바꿔줘야하는 번거로움도 있었다.    이런 점을 해결하기 위해 Retrofit Client 클래스를 한 파일만 두고 공통으로 사용할 수 있도록 합쳐보았다.   우선 저 과정을 공통적으로 수행하게 하기 위해레트로핏 클라이언트 생성 시 매번 다르게 입력되는 api 인터페이스 클래스 타입을 제네릭을 사용해 일반화시켜야 했다.   제네릭(Generic)이란?제네릭은 클래스나 메서드, 프로퍼티를 정의..

서론 지난번 포스팅에서안드로이드에서 서버에 PreSigned URL을 요청해 AWS S3에 이미지를 직접 업로드 하는 과정을 정리해보았다.  [Android] 안드로이드에서 PreSigned URL을 이용해 AWS S3에 이미지 업로드 하기 (1)세모반 프로젝트 배포 후 백엔드 개발자분께서 이미지 처리 로직 변경을 제안해주셔서 새로 구현한 방식에 대해 포스팅하려고 한다. 기존 이미지 처리 로직 기존에는 클라이언트에서 Post api를nueijeel.tistory.com  이후 post 및 patch, put api를 백엔드쪽에서 수정해주시면서 (api request body에 파일 대신 저장된 이미지 경로를 전달)안드로이드에서도 api가 구현된 부분을 수정하여 이미지 업로드 후 서버 통신으로 데이터를 전..

세모반 프로젝트 배포 후 백엔드 개발자분께서 이미지 처리 로직 변경을 제안해주셔서 새로 구현한 방식에 대해 포스팅하려고 한다.  기존 이미지 처리 로직기존에는클라이언트에서 Post api를 호출해 서버로 데이터를 전송하면 서버는 수신한 데이터를 처리해 aws에 직접 이미지를 업로드하는 로직이었다.(데이터 전송 형태는 multipart/form-data 형식으로 전달)  하지만 이 방식은 클라이언트가 서버에 api 통신을 요청하는 횟수가 많아질수록 서버 부하가 발생한다는 단점이 있다.  아직까지 세모반은 사용자가 많지 않은 상태라 위 방식으로 처리를 해도 큰 문제가 없지만,  애초에 앱 개발을 시작할 때 지속적으로 서비스하는 앱을 만드는 게 목적이었기 때문에추후에 사용자가 많아져 서버 통신량도 증가할 경우..

📍 문제 준규가 사는 나라는 우리가 사용하는 연도와 다른 방식을 이용한다. 준규가 사는 나라에서는 수 3개를 이용해서 연도를 나타낸다. 각각의 수는 지구, 태양, 그리고 달을 나타낸다. 지구를 나타내는 수를 E, 태양을 나타내는 수를 S, 달을 나타내는 수를 M이라고 했을 때, 이 세 수는 서로 다른 범위를 가진다. (1 ≤ E ≤ 15, 1 ≤ S ≤ 28, 1 ≤ M ≤ 19) 우리가 알고있는 1년은 준규가 살고있는 나라에서는 1 1 1로 나타낼 수 있다. 1년이 지날 때마다, 세 수는 모두 1씩 증가한다. 만약, 어떤 수가 범위를 넘어가는 경우에는 1이 된다. 예를 들어, 15년은 15 15 15로 나타낼 수 있다. 하지만, 1년이 지나서 16년이 되면 16 16 16이 아니라 1 16 16이 된다..