이번에 프로젝트의 전반적인 구조를 클린 아키텍처로 구현해보는 것을 하나의 과제로 삼고 진행해보려 노력했다. 아무래도 구조 자체가 추상화가 많이 되어있다보니, 구조의 의도를 이해하는데에 시간과 노력이 꽤나 들어갔던 것 같다. 아키텍처를 잘 써보고 싶어서 요런 고민도 했었고 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..
MVC Model, View, Controller로 구성된 뷰 아키텍처. 컨트롤러가 많은 것들을 담당하는 형태이다. 모델(Entity, DB)의 데이터를 가져오고 업데이트 모델 값 변화가 일어난 경우, 새로 뷰 그려주기 MVC의 단점 컨트롤러가 담당하는게 너무 많다. 컨트롤러가 모델에 대한 컨트롤과 뷰에 대한 컨트롤을 모두 담당하고 있기 때문에, 모델에 변화가 생기면 뷰 까지 영향이 미쳐, 뷰의 수정이 필요함. → 유지보수가 어려움. 모델의 설계를 아무리 잘 해도, 개발을 지속하면서 모델을 수정하는 일은 불가피하므로 유지보수의 측면에서 영향을 받을 수 밖에 없다. MVVM Model, View, ViewModel 로 구성된 뷰 아키텍처. MVC 아키텍처의 단점들을 보완하고자 제시되었다. 모델과 뷰 사이에..