Boiledegg's Blog

실시간 채팅 구현 1탄 이후 약 2달만에 2탄을 작성하네요. 그동안 제 채팅 구조에는 피바람이 불어서 채팅 구현기를 구상했을 때와 많이 바뀌었는데요.. 2탄에서는 기존 구현 방식과 더불어 변경 이유와 현재 구현 방식을 잘 융합해서 적어보도록 하겠습니다! 이 글의 내용에 대해 미리 스포를 하자면, STOMP 라이브러리인 Krossbow 사용과 Krossbow 사용에서 겪은 문제점과 Krossbow 없이 1탄에서 언급한 OkHttpWebSocket을 활용한 구현을 다룹니다. 이전 글에서 어떤 기능 때문에 꽤 고생을 했다고 했죠? 그 주인공은 바로 STOMP입니다. 웹소켓 사용도 처음 해보는데 STOMP라는 개념이 등장해서 약간 당황했고, API 테스트 프로그램인 POSTMAN으로도 확인하기가 어려워 꽤나 애..

최근에 "납작마켓"이라는 프로젝트에서 웹소켓을 활용한 채팅 기능을 구현했습니다. 이전엔 Retrofit을 활용한 REST 통신만 다뤄봤기에 안해 많이 해멜 것이라고 예상했는데, 예상대로 시행착오도 많았고 완성까지 꽤 오랜 시간이 걸렸습니다.많은 고민과 시간을 투자한 기능이기에, 추후에 다시 웹소켓 기반 기능을 구현하게 되거나 웹소켓의 기능을 확장하는 상황에 대비해, 이 시점에서 생생한 구현 경험을 기록으로 남겨보고자 합니다. 한 번에 다 풀어내기엔 양이 많아서, 여러 편에 걸쳐 차근차근 정리할 예정입니다. 이번 글 1편에서는 본격적인 구현 설명에 앞서, 웹소켓이 어떤 방식으로 동작하며 서버와 클라이언트를 연결해주는지, 그 개념을 먼저 간단히 정리해보았습니다.HTTP와 실시간 통신일반적인 http 프로토콜..

코드와 모델을 밀접하게 연관시키는 것은 코드에 의미를 부여하고 모델을 적절하게 한다.- 에릭 에반스 객체지향 설계는 세 가지 관점으로 바라볼 수 있다. 이 세 가지 관점들을 통해 클래스를 어떻게 설계해야 하는지 힌트를 얻을 수 있다.개념 관점 (Conceptual Perspective)도메인 안에 존재하는 개념과 개념들 사이의 관계를 표현한다.사용자가 도메인을 바라보는 관점을 반영한다.실제 도메인의 규칙과 제약을 최대한 유사하게 반영하는 것이 핵심이다.명세 관점 (Specification Perspective)개발자의 관점으로, 객체가 협력을 위해 ‘무엇’을 할 수 있는가에 집중한다.인터페이스와 구현을 분리하고, 인터페이스를 설계하여 객체의 책임을 명확하게 설정한다.구현 관점 (Implementation..

유일하게 변하지 않는 것은 모든 것이 변한다는 사실뿐이다.- 헤라클레이토스 이번 장은 소프트웨어를 구조 중심으로 설계해야 한다는 점을 강조한다. 구조를 중심으로 설계하면범용적이고,재사용성이 높으며,변경에 안정적인 모델을 만들 수 있다.위와 같은 특징이 중요한 이유는 사람들의 요구사항이 계속 변하기 때문이다.구조가 아닌 기능에 집중하여 설계하는 순간 위 장점들을 모두 잃게 된다. 기능 중심과 구조 중심의 설계를 길을 찾는 경우에 빗대어 설명해보자면,기능 중심: A에서 B로 가기 위한 경로를 방향을 비롯하여 랜드마크들을 사용하여 상세하게 설명한다.구조 중심: 지도 상에서 A에서 B로 연결된 경로를 따라 이동한다.경로를 설명하는 경우, A와 B 사이에 경로만 포함하기 때문에 재사용이 제한된다.이와 반대로, 구..

의도는 “메시징”이다. 휼륭하고 성장 가능한 시스템을 만들기 위한 핵심은 모듈 내부의 속성과 행동이 어떤가보다는 모듈이 어떻게 소통하는가에 달려있다.- 엘런 케이 📌 자율적인 책임설계의 품질을 좌우하는 책임객체지향 공동체를 구성하는 기본 단위는 ‘자율적’인 객체다.자율적인 객체란 스스로 정한 원칙에 따라 판단하고 스스로의 의지를 기반으로 행동하는 객체다.자율성: 자기 스스로의 원칙에 따라 어떤 일을 하거나 자신을 통제해서 절제하는 성질이나 특성타율성: 자신의 의지와 관계없이 정해진 규율이나 원칙에 따라서만 움직이는 성질객체가 어떤 행동을 하기 위해서는 다른 객체로부터 요청을 수신해야 하고,수신한 요청을 처리하기 위해 수행하는 행동을 책임이라고 한다.적절한 책임을 객체에 할당하여 자율적인 객체를 만들고,..

https://getstream.io/blog/jetpack-compose-stability/해당 포스트를 내 마음대로 정리한 글이다. 더 자세한 내용을 알고 싶다면 이 포스트를 읽어보자! 여러 안드로이드 프로젝트의 코드를 들여다보면서 @Stable, @Immutable과 같은 어노테이션을 많이 마주치곤 했다.하지만 그 둘의 차이점과 동작 방식을 몰라 코드를 온전히 이해할 수 없었다. 그러다 최근에 진행 중인 프로젝트에서 팀원이 안정성 어노테이션을 사용하는 것을 보았고, 이제는 제대로 짚고 넘어가야겠다 싶어 안정성과 어노테이션에 대해 알아보았다. 이 글에선 안정성 어노테이션만을 다루고자 했지만, 온전히 이해하기 위해선 Compose 안정성에 대한 이해가 바탕에 있어야 하기에 때문에 안정성에 관한 설명도 ..

우리 모두를 합친 것보다 더 현명한 사람은 없다. - 켄 블랜차드 이번 장은 1982년에 독일의 베르너 귀스 교수가 실시한 “최후통첩 게임” 실험에 대한 이야기로 시작한다. 이 실험에서는 참가자를 ‘제안자’와 ‘응답자’ 무리로 나눈다. 제안자에게는 일정한 금액이 주어지며, 제안자는 받은 금액의 일부를 응답자에게 나눠줘야 한다. 이 때 제안자가 응답자에게 제시하는 금액의 비율은 직접 정하면 되는 것이다.응답자는 제안자의 제안을 수용하거나 거부할 수 있다. 만약 응답자가 제안을 승낙하면 제안자와 응답자 모두 제시한 비율에 따라 금액을 나누어 가질 수 있다. 하지만 응답자가 제안을 거부하게 되면 둘 다 한 푼도 건질 수 없게 된다.이 게임의 룰만 들었을 땐 제안자는 최소 금액을 응답자에게 제안하는 이기심을 보..

[Medium] Jetpack Compose - When shoul I use derivedStateOf?해당 포스트를 내 마음대로 해석한 글이다.derivedStateOf란?derivedStateOf를 사용하면 계산에 사용된 상태 중 하나가 변경될 때마다 계산을 실행한다.하지만 계산된 값이 기존 값과 동일한 경우 컴포즈 상태 스냅샷 시스템에서 상태 변경으로 간주하지 않아 리컴포지션 이벤트를 발생시키지 않는다고 한다. derivedStateOf는 상태값이 UI보다 더 자주 업데이트돼야 하는 경우에 사용해야 한다. 왜냐하면 입력이 바뀌어 derivedStateOf가 다시 계산되더라도, 결과가 같으면 리컴포지션이 일어나지 않기 때문이다. 예시를 하나 보자. 아이디를 입력하는 TextField와 아이디가 유효..

CompositionLocal이란?Composable 트리의 최상단에서 상태를 관리하기 위해 소개된 개념 상태 호이스팅 (State Hoisting)컴포저블 함수는 트리 구조로 조직된다. 먼저 등장하는 컴포저블이 상위, 그 다음이 하위가 된다.상태를 트리의 가능한 가장 상위 노드에 선언하여 관리하는 것이 상태 호이스팅이며, 컴포즈에서 권장되는 패턴이다.특정 상태가 여러 컴포넌트에서 필요한 경우, 그 모든 컴포넌트들의 접점이 되는 상위 컴포넌트에서 관리함으로써 재사용성을 높임여러 컴포넌트들이 하나의 상태를 참조함으로써, UI의 일관성을 유지할 수 있음상태 변경 로직을 한 곳에 집중시킬 수 있음. 이를 통해 가독성을 향상시키고, 상태 변경에 따른 부수 효과(Side-Effects)도 관리하기 쉬워짐하위 컴포..

멀티모듈 환경에서 빌드로직을 구현하고 적용하던 중 맞닥뜨린 오류다. Compose와 Kotlin에 관련된 플러그인을 마련한 후 Application 모듈에 해당 플러그인들을 적용하려는 순간 다음과 같은 오류가 발생했다. //오류 중 일부 발췌Caused by: org.gradle.api.internal.plugins.PluginApplicationException: Failed to apply plugin class 'com.boiled.calendar.buildlogic.primitive.ComposePlugin'...Caused by: org.gradle.api.UnknownDomainObjectException: Extension of type 'LibraryExtension' does not ex..