📖 오늘의 학습계기 메소드 안에 메소드를 작성하는 문법은 요즘 대부분의 언어에서 지원하는 문법이다. 하지만 일반적으로 이를 사용하지 않아도 대부분의 기능들은 충분히 구현이 가능하며, 이를 잘못 사용했다가 가독성만 안좋아지고 소통이 안 될 가능성이 있어서 그동안에는 잘 사용하지 않았다. 그러던 도중 이를 유용하게 사용할 상황을 마주했다. 유용하게 사용할 수 있는 상황 작업이 끝난 뒤, 작업에 사용된 오브젝트의 id와 state를 다른 컴포넌트들과 동기화를 시켜야하는 상황이 있었다. 모든 컴포넌트들이 listen하고 있다가 알아서 바뀌면 좋겠지만, listen을 설정해주는 작업을 해주는게 더 크기에 순회로 비교하며 값을 바꿔주기로 했다.  내가 바꿔줘야하는 데이터 리스트는 총 4개, 모두 같은 타입이다. ..

📖 오늘의 학습  현재 프로젝트는 클린 아키텍쳐로 진행이 되고 있다. 클린 아키텍쳐에서 원하는 모든 것을 따르진 않지만, 전체적인 틀은 지키려고 한다. ▼ 현재 구조는 대략 이렇다. entities(request dto, response dto) -> api repository -> usecase -> controller -> presenter 모델을 먼저 선언하고 레포지토리에서 이를 사용하여 API를 호출하는 메소드를 정의한다. 그리고 이를 usecase화 시켜 컨트롤러에 뿌리고, 컨트롤러는 이를 사용하여 데이터를 받아온 다음 프레젠터로 전달한다. 굉장히 이상적인 구조로 프로젝트가 설계되어있는데, 여기에 몇가지 문제점이 존재했다. 바로 response, request dto의 통일성 문제와 useca..

📖 오늘의 학습JSON의 배열 원소로 null이 온다면 JSON 파싱을 할 때, 일반적으로 리스트에 `null`값이 들어올거라고 생각을 안한다. 애초에 `null`이라는 값이 없다는 것인데, 없으면 안보내면 되는걸 굳이 보낼 이유가 없다. 그렇기에 대부분 배열 자체가 `null`로 오는 것을 체크하지, 배열 내부의 원소가 `null` 인걸 체크하지 않는다. 일반적인 경우 연산 낭비이기 때문이다.  그런데 `null`이 배열 원소로 온다면? '뭐 `null`이니까 적당히 공백 데이터로 파싱한 뒤 넘어가지겠지' 라고 생각했었는데, 아예 예외를 날려버렸다. 그 이유는 형변환 에러. `null`을 `String`이나 `int`, 혹은 내가 정의한 타입으로 변환할 수 없기에 생기는 예외다. `null`은 그 어..

📖 오늘의 학습제목에는 괴랄한이라고 적어놨지만, 사실 그렇게 괴랄한 구조는 아니다. 하지만 보통은 예상하기 어려운 구조로 전달을 받았다. 일반적으로 생각하고 그리고 바라는 JSON 구조는 약간 이런 식이다.{ "key" : value} 그러나 이번에 내가 받은 구조는 이런 식이었다.[ "string", "string", "string"]  이런식으로 들어오지 않는다고 암묵적인 약속을 받고, 전체적인 시스템을 짜놓고 개발을 하고 있었는데 이렇게 약속과 다른 형태로 넘어오니 조금 당황스러웠다. 이래서 백엔드랑 소통을 잘해야한다고 하는거구나를 정말 뼈저리게 느꼈다. (근데 저번에 이렇게 주지 말라고 했는데 계속 이렇게 주면 내가 뭘 할 수 있는게 없다...)  원래 시스템에서는 json을 `Map`으..

📖 오늘의 학습이번엔 구글 지도를 연동해 주변 정보를 가져오는 기능을 만들어봤다. 지도 API는 몇 번 써보긴 했는데, 사용자가 지도를 움직일 때 마다 근처의 장소 정보들을 패칭해 오는 것은 처음 해보는 터라 걱정이 좀 있었다. 그러나 패키지를 사용하니 별 거 아니게 되었다... 우선 전체 코드는 아래와 같다. notifier(컨트롤러)에 대부분의 로직이 담겨있어서 대략적인 기능만 알 수 있다. ▼더보기GoogleMap( initialCameraPosition: const CameraPosition( target: LatLng(37.56, 127.0001), // 초기 위치 (서울 중심 좌표) zoom: 16.0, ), ..

📖 오늘의 학습개발을 하던 도중, Html을 렌더링을 해야하는 상황이 생겼다. 이 부분은 flutter_widget_from_html이라는 패키지를 이용해서 큰 힘을 들이지 않고 구현을 했으나, 문제가 하나 있었다. 바로 CustomScrollView의 Lazy Loading이다. Lazy Loading은 화면에 보이는 영역에 가까운 위젯만 동적으로 생성하고, 화면에서 벗어난 위젯은 자동으로 폐기시킨다. 문제는 html 패키지가 html을 파싱 하고 태그에 맞게 위젯으로 변환하여 보여주는데, 거기에 있는 사진들도 새롭게 렌더링을 한다는 것이다. 사진이 몇 개나 있을 지, 그리고 사진 크기가 어떻게 될 지는 해당 패키지 입장에서 전혀 모르기 때문에, 높이는 전부 렌더링 한 뒤에 정확한 값을 갖게 된다. ..

📖 오늘의 학습 오늘은 RestAPI 명명법에 대해 생각을 해봤다. 회사에서 백엔드 팀과 논의하는 과정에서 RestAPI URL은 어떻게 할 지가 안건으로 나왔다. 사실 그동안에는 프론트엔드 입장에서 RestAPI 명세는 헷갈리지만 않으면 되는 문제라고 생각을 했었는데, 오늘 다시 생각해보니 그러면 어떻게 해야 안 헷갈리게 할 수 있을까 하는 생각이 들었다.  뭐든 그렇겠지만 각자의 입장에서 편한 부분이 존재한다. 백엔드는 백엔드의 관점에서 편한 부분이 있고, 프론트엔드는 프론트엔드의 관점에서 편한 부분이 존재한다. 너무 한쪽이 편한대로만 하는 것도 문제인데, 그것보다 더 큰 문제는 서로서로 괜찮다고 상대의 요구만 들어주는 것이다. 일종의 배려라고 할 수 있지만, 이게 반복된다는 것은 주관이 없다는 것..

📖 오늘의 학습지금까지의 개발: View 레벨의 상태관리 지금까지의 Flutter 개발을 할 때에는 View 단위로 개발을 하곤 했었다. 상태관리를 View 레벨로 정의를 하여, 내부의 위젯들에 변화가 생기면 전체를 리로드 하는 방식으로 개발을 했다. 이게 권장 사항은 전혀 아니지만, 나름의 장점이 존재한다. View 레벨 상태관리의 장점 View 레벨로 상태관리를 할 때의 장점은 개발이 굉장히 빠르고 간편해진다는 것이다. 그도 그럴 것이, 위젯 각각이 상태를 가지는 것이 아니라 페이지 하나가 상태를 가지고 그 상태를 해당 페이지 내에서 공유를 하는 방식이기 때문이다. 중앙 집중 방식이기에 이해도 쉽고 코드 짜는 것도 간편해진다. 일종의 MVC 패턴의 성격을 보인다. View 레벨 상태관리의 단점 그러..

📖 오늘의 학습  국제화나 다크모드, 라이트모드 적용은 프로젝트가 시작할 당시 모두 세팅을 해두어서 이제부터는 피쳐 개발을 진행하면 된다. 그래서 오늘은 간단하게 회원가입 페이지를 마무리했다.  회원가입 페이지의 마지막에 있는 이 체크 이미지에 대한 명세에는 애니메이션이 없었다. 그런데 그냥 이렇게만 있으면 상당히 밋밋하기도 하고 디자이너도 여기에 큰 의도를 담지 않았기에 내 마음대로 애니메이션을 넣기로 했다. ▼  가운데의 이미지는 그대로 두고 주변을 도는 점들이 확 퍼지면서 주위를 천천히 돌게 했으면 하는게 내가 원하는 애니메이션이다. Flutter에는 두 가지 종류의 애니메이션이 있는데 하나는 암묵적, 다른 하나는 명시적이다. 지금 이 애니메이션 같은 경우에는 움직임의 경로에 따른 움직임이 나타나..

🚀 오늘의 문제풀이 글은 여기에 있습니다. ▼ 백준 11722번 가장 긴 감소하는 부분수열 - C++문제수열 A가 주어졌을 때, 가장 긴 감소하는 부분 수열을 구하는 프로그램을 작성하시오.예를 들어, 수열 A = {10, 30, 10, 20, 20, 10} 인 경우에 가장 긴 감소하는 부분 수열은 A = {10, 30, 10, 20, 20,noguen.com  📖 오늘의 학습오랜만에 DP문제들을 다시 풀려고 하니 헷갈려서 조금 난감했다...예전에 풀었던 가장 긴 증가하는 부분 수열이랑 다를게 없는 문제인데 너무 옛날에 풀어서 기억을 되찾느라 조금 걸렸다.심지어 접근도 잘못해서 더 고생했다...  🤔 오늘의 회고약간 의미없는 데에 시간을 많이 낭비한 느낌이 들어 이제는 PS TIL말고 개발 TIL을 ..