레드의 노트

파이어베이스에서 데이터를 받아올 때 시간과 날짜를 나타내는 자료형이 Timestamp였고, 플러터에서는 Datetime을 사용하고 있었다. 나는 Timestamp가 flutter(dart)의 내부 클래스이고, datetime과 timestamp가 같은 타입이라고 생각했는데, Timestamp는 Firestore 프레임워크에 포함된 타입이며 datetime으로 사용하기 위해서는 명시적으로 형변환 과정을 거쳐야 하는 것을 확인했다. ㅤ 검색해서 찾다보니 누군가는 Timestamp가 더 세밀한 초 (millisecond)를 표현할 수 있는 자료형이라고 했는데, 파이어베이스에서는 초 단위까지만 입력이 가능하고, DateTime 클래스의 프로퍼티에 microsecond 단위의 데이터를 넣을 수 있는 것으로 보아서..

열심히 프로젝트 구조를 클린 아키텍처 구조로 개선하고 있다. 내가 싼 똥이 점점 정리되는 중이라고 느껴진다. 뭔가 다시 작업을 시작하면 더 깔끔하고 편리하게 작업을 진행할 수 있을 것 같은 느낌이랄까…? ㅋㅋㅋㅋ ㅤ 그래도 나름의 고민을 거듭하면서 구조를 개선해나가고 있는 중이다. 이번 차례에는 Data Layer에 대한 대공사를 진행하고 있는데, repository - repository impl - datasource 의 관계를 어떻게 구성하는게 적절한 지에 대해 고민을 열심히 하고 있다. ㅤ (대충 뭔가 호작질중) ㅤ 그렇게 설계한 2번째 구조는 아래와 같다. ㅤ 먼저 repository와 repository impl은 1대1 관계로 작성해주었다. 각 repository는 interface로서 구현..

ㅤ 클린 아키텍처를 적용하기 위해 기존의 프로젝트를 리팩토링 하고있다. ㅤ 기존에는 각 기능(뷰) 별로 폴더 내에 presentation, domain, data 세 가지 layer를 모두 배치하고, 각 계층 내에 필요한 폴더를 따로 만들어서 관리하고 있었는데, 여러 기능에서 공유되어야 하는 usecase가 하나의 기능 폴더에 귀속되어 있어 다른 기능쪽에서 끌어서 사용해도 되나? 라는 걱정이 많이 되었었는데, 요런 부분들을 타파하기 위해 완전 구조 개선을 시도하고 있다. ㅤ 개선을 시도한 내용은 아래와 같다. 모든 폴더에 따로 놓여있는 모델 → Entity로 이름을 바꿔 한 폴더에서 관리하기 동일한 개념이지만 여러 개로 구현되어있는 모델은 하나로 정리하기 여기저기 흩어진 usecase를 한 폴더에서 관리..

이번에 프로젝트의 전반적인 구조를 클린 아키텍처로 구현해보는 것을 하나의 과제로 삼고 진행해보려 노력했다. 아무래도 구조 자체가 추상화가 많이 되어있다보니, 구조의 의도를 이해하는데에 시간과 노력이 꽤나 들어갔던 것 같다. 아키텍처를 잘 써보고 싶어서 요런 고민도 했었고 Riverpod을 통해 클린 아키텍처를 적절히 구현하려고 요런 고민도 했었다. ㅤ 그리고 실제로 계층 구조를 나누고 그 위에 코드로 기능들을 구현을 하면서 여러가지 장단점이 눈에 들어왔다. 물론 내가 처음에 구조를 잘못 나눠 불편한 점도 많이 있었지만, 어떻게 해야 좀 더 의도에 적합하게 코드를 작성할 수 있을 지도 눈에 들어오기 시작했다. 그 경험들을 잊기전에 짧게 기록으로 남겨두려 한다. ㅤ 단점부터 시작하자 러닝코스트가 너무 높다!..

별 거 아닌 것 같은데, 요걸 구현하면서 4시간 정도 삽질을 했다. 후… 그래서 누군가 찾아보지 않을까 싶어서 기록을 남겨둔다! 아래 이미지처럼 나타나지는 위젯을 만들고싶었다. 이걸 분석해봤을 때, 요구조건은 아래와 같다. Row의 Children에 들어가서 Cell로 작동해야 한다. Row의 자식으로, 한 줄 전체를 사용한다. 말풍선의 가장 오른쪽에는 이미지가 들어간다. 텍스트의 길이에 따라 말풍선의 길이가 달라진다. ← 이게 진짜 열받음 요걸 구현하기 위해서 Row 내에 Cell로 (1번 조건) Expanded가 들어가고 (전체 한 줄을 사용하기 위해 - 2번 조건 ), Expanded 내에 다시 Row를 넣고 (이미지와 텍스트를 배치하기 위해 - 3번 조건), 텍스트에 Expanded로 적당히 Fi..

https://www.youtube.com/watch?v=tGeYQlrbdGk&t=4s 위 에프터이펙트 강의 영상에서 봤던 것 처럼, 이모지가 불꽃놀이처럼 주변으로 팡팡 터지면서 공중으로 날아가는 효과를 만들고 싶었다. 그런데, 도저히 이거랑 관련된 소스코드를 찾을 수 없었어서, 직접 애니메이션을 한 번 구현해보기로 했다. 후! ㅤ ㅤ 작업에 본격적으로 들어가기 전에, 에프터이펙트에서 해당 효과를 나타내기 위해 어떤 작업들을 처리하는지 살펴봤다. emitter → 주변으로 이모지를 퍼트리는 효과 wind → 바람에 날아가듯이 공중으로 날려보내는 효과 scale → 이모지가 작아졌다 커졌다 하기 rotate → 이모지가 날아가는 동안 빙빙 회전하기 replace emoji → 날아가는 동안 이모지의 종류가..

ㅤ https://www.youtube.com/watch?v=tGeYQlrbdGk&t=4s 위 영상에 나오는 것 처럼, 이모지가 팡팡 터지면서 불꽃놀이 효과가 나는 이펙트가 필요해서, 요런걸 찾고 싶었다. 그런데 왠걸,, 생각보다 저런 이펙트를 플러터로 구현해놓은 코드를 찾는 것이 쉽지 않았다. 구글링과 깃허브 레포지토리까지 열심히 뒤져봤지만, Confetti 라는 효과 말고는 크게 의미 있는 코드를 발견할 수 없었다. (진짜 눈물 줄줄 😭😭😭 괜히 플러터의 단점이 “커뮤니티가 작다”인게 아니였다… ) ㅤ 열심히 고민해봤는데, 이왕 프로젝트를 하는거 여기에서 이펙트, 애니메이션에 대한 이해와 구현하는 능력을 어느정도 공부하면서 정리를 해두면 나중에 앱 개발을 할 때 이펙트에 대한 역량을 충분히 기를 수 ..

플러터의 다트 언어를 공부하면서, 다트는 JIT와 AOT를 둘 다 지원하는 언어이기에 효율적이라는 내용이 나왔다. 둘이 충돌하는 내용이 아닌가?? 라는 의구심이 들어서 찾아보았다. ㅤ JIT - Just In Time JIT 컴파일러는 프로그램 소스코드를 네이티브 기계어로 프로그램의 실행 직전에 (런타임에) 컴파일을 수행한다. 다음에 실행될 명령어를 예측하고 코드를 실행 직전에 컴파일 하는 방식으로 작동한다. 일반적으로 [빌드 > 중간 언어로 전달 > 런타임에 중간 언어를 기계어로 변환] 의 매커니즘으로 프로그램을 실행한다. 장점 환경에 맞게 실시간으로 기계어로 변환할 수 있어, 효율적인 실행을 할 수 있다. 배포되는 프로그램 파일의 사이즈가 비교적 작다. JIT 컴파일러를 사용하면 실행 중에 바뀐 코드..

“나, 클린 아키텍처를 완벽히 이해했어!” 라는 말을 여기저기에 하고 다녔는데, 다들 막 이것 저것 태클을 걸고싶어서 “그 부분은 좀 있다가 한 번 이야기해보죠” 라는 말을 자주 많이 들었다. ㅋㅋㅋㅋ 아무래도 클린 아키텍처 자체가 넓은 방법론 중 하나이기도 하고 한 번씩은 적용하기를 시도해보니까, 다들 해석하는 방법도 다양하고, 적용하는 데에 있어서 거친 고난과 역경을 겪으며 각자가 스스로 깨달은 바가 많아서 그런게 아닌가 싶다. 개념적으로 클린 아키텍처를 통해서 하고싶은게 뭔지는 다 캐치를 했는데, 이걸 코드로 작성하려고 하니 또 다른 난관에 부딪히고 있다. 플러터에서 상태관리를 위해 사용하는 Riverpod 프레임워크에 생각보다 제약이 많았고, 이걸 활용해서 내가 만들고자 하는 클린 아키텍처 스러운..

플러터로 개발을 진행하면서, MVVM 구조로 뷰 로직을 작성하기 위해 state 관리를 하기 위해 플러터의 상태 관리 도구들을 찾아보았고, 그 중에서 Riverpod 이라는 프레임워크를 사용하기로 하였다. 처음에는 너무나도 이해가 안되고 SwiftUI 가 그리웠지만, 한 3일 정도 Riverpod으로 고생을 좀 하다보니 어느정도 감이 잡힌 것 같다. Riverpod를 공부하면서 유튜브에서 이것저것 강의영상을 찾아봤었는데, 개인적으로는 아래 영상이 제일 이해가 잘됐다. 이전 영상들을 보고 나서 요걸 봐서 이해가 된 걸 수도 있겠지만, Riverpod의 여러가지 Provider를 한 번에 쭉 소개해주면서 비교해서 그런지, 이전에 봤지만 헷갈리던 내용들까지 쫙 정리가 되었다. 추천추천! bookmark Riv..