레드의 노트

너무나도 객체지향스러운 방식인 오버로딩을 다트 언어에서는 사용할 수가 없었다. 나는 코드를 가독성 넘치면서 깔끔하게 작성하는데에 있어서 오버라이딩, 오버로딩만큼이나 유용한 도구가 없다고 생각했는데, 요런게 제공이 잘 되지 않다보니 좀 불편함을 느끼게 되는 것 같다. ㅤ 아래가 내가 희망하던 코드의 방식이고 // 내가 짜고싶은 코드 List getEntityList({ DateTime bySelectedDate, }) { ... } List getEntityList({ String bySelectedUserId, }) { ... } // -> 이걸 사용하는 시점에는 list = getEntityList(bySelectedDate: DateTime); list = getEntityList(bySelected..

Data Layer 쪽의 리펙토링을 진행하면서, 내가 데이터 계층의 Repository Impl 클래스를 파이어베이스에 의존적이게 코드를 작성하고 있다는 걸 깨달았다. 클린 아키텍처의 의의를 ‘쉽게 갈아끼울 수 있는 백엔드와 프론트엔드’ 라고 생각하고 적용하려고 노력하고 있기 때문에, 범용 클래스를 무조건 “특정 서비스에 의존적이지 않은 형태”로 작성해야 한다고 생각한다. 이에 요걸 분리하기 위해서 여러가지 고민을 했고, 이걸 글로 남겨두려고 한다! ㅤ 현재 계층 구조와 설계한 사용 모델들을 간략하게 써보면 아래와 같다. Presentation Layer에서는 뷰 계층의 model을 사용한다. Domain Layer에서는 Entity를 사용한다. Data Layer에서는 데이터 계층의 model을 사용한..

파이어베이스에서 데이터를 받아올 때 시간과 날짜를 나타내는 자료형이 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 컴파일러를 사용하면 실행 중에 바뀐 코드..