오늘도 디벅잉 오늘도 디벅잉

🧭 네이게이션 스타일 안드로이드는 일반적으로 '메뉴, 홈버튼, 뒤로가기' 묶음을 가지는 네비게이션 스타일을 가집니다. 하지만 iOS 처럼 스와이프 제스쳐로 설정을 변경할 수 있습니다. 플러터에서 해당 설정을 확인하는 방법 그렇다면 사용자가 버튼 형태의 스타일을 사용하는지 스와이프 제스쳐를 사용하는지 확인할 수 있을까요? 디바이스의 높이를 계산하면 사용자가 어떤 스타일을 사용하고 있는지 파악할 수 있습니다. 디바이스의 실제 높이에서 화면에 사용하는 높이를 빼고 나면 남는 부분이 안드로이드 네비게이션의 높이일 것입니다. 디바이스 실제 높이 디바이스의 실제 높이를 확인하려면 device_info_plus라는 라이브러리가 필요합니다. 해당 라이브러리를 통해 다음과 같이 디바이스 높이를 알 수 있습니다. fina..

🧭 in_app_update 안드로이드 강제업데이트를 위해 인앱업데이트를 지원하는 in_app_update 라이브러리를 사용해 보았습니다. 업데이트 옵션으로 강제업데이트, 선택업데이트가 있습니다. 강제업데이트 시에는 업데이트 후 앱이 자동으로 재실행되어야 하지만 재실행 없이 종료만 되었습니다. singleTop vs singleTask AndroidManifest.xml 파일을 보면 아래로 다음과 같은 옵션이 있습니다. android:launchMode="singleTop" 해당 옵션을 singleTop에서 singleTask로 변경해주면 강제업데이트 후 앱이 재실행됩니다. android:launchMode="singleTask" singleTop과 singleTask의 차이점은 아래 두번째 링크를 참고..

🧭 iOS 빌드 속도는 안드로이드에 비해 다소 느린 감이 있습니다. 특히, 파이어베이스를 연동하면서 속도가 저하되는데 precomplied SDK를 활용하면 이를 개선할 수 있습니다. root > ios > Podfile 파일에 파이어베이스 버전명을 포함하여 다음과 같은 코드를 추가합니다. pod 'FirebaseFirestore', :git => 'https://github.com/invertase/firestore-ios-sdk-frameworks.git', :tag => '10.0.0' 아래는 위 코드를 반영한 모습입니다. 참고한 사이트에서는 성능을 67% 까지 감소시켰다고 나와 있습니다. 제가 측정한 빌드 시간은 70여초에서 60여초로 크게 체감되는 정도는 아니었습니다. 📌 https://www...

🧭 변수의 타입을 왜 확인해야 하는가? 모든 변수를 정적 타입으로 선언했다면 타입을 확인할 필요가 없을 것입니다. 오래된 프로젝트를 업그레이드 한다든지 하는 경우 dynamic 타입의 변수를 마주할 수 있고 타입을 확인하고 싶은 경우가 있을 수 있습니다. 플러터의 모든 변수들의 조상격인 Object 타입에는 runtimeType이라는 프로퍼티가 있습니다. 어떤 변수든 runtimeType 프로퍼티를 불러와서 출력하면 타입을 확인할 수 있습니다. dynamic variable; print(variable.runtimeType); // dynamic 📌 https://www.kindacode.com/article/how-to-check-type-of-a-variable-in-flutter/ How to ch..

🧭 디자인 아이콘 사이즈 기준 20dp, 24dp, 40dp, 48dp를 권장하고 있습니다. 아이콘 터치 영역은 이에 더해 상하좌우 10dp의 영역을 포함하는 것이 좋습니다. (아이콘 사이즈가 24dp by 24dp일 경우, 터치 인식 영역은 48dp by 48dp) https://m3.material.io/styles/icons/applying-icons Material Design Icons can be used to represent common actions. Material Symbols are a set of variable icon fonts created at seven weights across three different styles. m3.material.io 플러터 primary 속..

🕹️ 개발자로 새로운 커리어를 시작하고 첫 프로젝트를 종료하였습니다. (그전까지 UI, 네트워크 통신 구현, Clean Architecture 등 조각조각의 개념들을 익혔습니다.) 완료가 아닌 종료라고 표현한 것은 정규 출시되는 프로젝트가 아닌 토이였기 때문입니다. 같은 시기에 입사한 동료 분과 같이 플러터 개발을 담당했습니다. 우리 프로젝트에 적합한 프로젝트 구조를 결정하지 못한 채로 프로젝트를 시작하는 바람에 진행하면 할수록 서로의 코드가 각자의 길로 빠져버리고 말았습니다. 부트캠프에서 실전 프로젝트 진행시 NestJS를 선택했던 주목적이 프로젝트 구조를 통일성 있게 가져가서 협업을 효율적으로 하는 것이었는데, 실제 상황과 맞닥뜨리니 그런 생각이 더 와닿게 되었습니다. 한편 일정 초반부에는 코드의 짜..