미리보기

1. "Ddaraogae"는 반려견 산책을 기록하고, 도와주며 견주에게는 편의성과 재미를 제공하는 앱 입니다. [참여 인원 : 5명] -> 따라오개

2. 플레이스토어에 런칭.

3. Naver Map SDK, 홈 화면 '몇 시간 전' 담당.

4. Naver Map SDK 선정 이유

   • [대표 3사]

     • 지도하면 구글, 네이버, 카카오 중에 선택해야 합니다.

     • 구글은 관련 레퍼런스가 많은 것이 장점이지만 영어로 되어있고, 한국은 휴전국으로, 서비스 차원에서 제한이 있는 것으로 알아 국내 플랫폼을 이용하고자 했습니다.

   • [유저 친화적]

     • 이전에 지도 API 경험을 토대로 네이버가 조금 더 폭 넓은 가이드와 레퍼런스를 제공한다고 생각해서 채택 하게 되었으며, 실제로 카카오를 쓰면서 불편함을 느껴 네이버로 넘어온 사례를 보았습니다.

5. '몇 시간 전'을 담당하게 된 이유

   • [신입에게는 어려운 개념 MVP, 애자일]

     • 신입 개발자에겐 MVP도 버거운 탓인지 '몇 시간전'과 같은 디자인 아이디어는 묵살되곤 했습니다.

     • MVP 개발이 마무리 된 후, 새로운 마일스톤 수립 중 재언급을 통해 담당 파트는 아니었지만 해당 기능을 담당하게 되었습니다.

   • [상상을 현실화 해보기]

     • 홈 화면에서 반려견 id마다 마지막 산책 시간을 '몇 시간 전'을 시각적으로 제공해야 효과적인 산책에 도움이 된다고 생각하여서 강하게 어필했던 기억이 납니다.

6. Custom UI Visible시, 버튼을 가리는 문제

   • [개발 가능 여부로 인한 디자인 논의]

     • 시작하기 버튼을 누르면 커스텀 Ui가 Visible되면서 버튼을 가리는 문제가 있었습니다.

     • 네이버의 Location Button은 위치 조정은 불가하고 활성화 여부만 지원하는데, 커스텀 Ui의 디자인을 바꾸자니 보여줘야 하는 정보의 가시성이 떨어져서 팀원들 간의 논의 끝에 Location Button을 커스텀 하기로 하였습니다.

   • [공식 문서의 중요성]

     • 후에 커스텀 버튼과 ZoomControlView(네이버의 Location Button)의 위치가 통일감이 없다는 디자인 피드백으로 인해 ZoomControlView 객체에 접근하여 위치를 조정하려 했으나 접근이 불가하여 어려운 상황에 처해 있었습니다.

     • 그런데, 문서에서 setContentPadding이라는 것을 발견하게 되었고, 지도 위의 content의 bottom에 padding 값을 주면서 로고와 버튼이 이전과 상대적으로 위로 위치하게 되어 Custom Ui가 Visible 되어도 잘 보여지게 해결했습니다. 이를 통해 공식 문서의 중요성을 다시금 느꼈습니다.

7. 지도 객체 초기화 이전에 이벤트 발생시, 앱이 터지는 문제

   • 맵 초기화 전 현재 위치 버튼 누르면 죽는 문제가 있었습니다.

     • if(::naverMap.isInitialized && ::cameraPosition.isInitialized)로 조건에 부합할때만 동작하게 문제를 해결함으로써 유저 플로우와 초기화의 중요성을 더 깨닫게 되는 시간 이였습니다.

1. "Dopaminemoa"는 Youtube API 데이터를 받아 데이터를 제공해주며 짧은 영상(쇼츠)을 골라 보여줄 수 있는 플랫폼입니다. [참여 인원 : 4명] -> 도파민모아

2. MyVideoFragment를 담당하여 좋아요 데이터를 RecyclerView에 보여주는 역할을 담당 했습니다.

   • 실시간으로 반영이 되는 것이 아닌, 재실행 되었을때만 반영이 되는 문제

     • DetailFragment에서 좋아요 처리를 하고, MyVideoFragment에서는 실시간으로 데이터가 반영 되어야 합니다.

     • 실시간으로 데이터를 보여주는 역할은 ViewModel이지만, 이 과정은 FragmentResultListener와 협력하여 이루어집니다. FragmentResultListener는 이벤트 전달의 역할을, ViewModel은 데이터 처리와 UI 업데이트의 역할을 수행합니다.

3. Clean Architecture에 한 걸음

   • [애매하더라도 의논과 질문은 필수]

     • 기존에 DetailFragment를 담당하는 분과 의논이 되지 않은 상태에서 작업을 진행했기 때문에 자체적으로 Utils 객체에 SharedPreference를 정의하고 좋아요 데이터를 ViewModel에 가져오고자 했었습니다.

     • 후에 문제점을 깨닫고, 만들었던 코드들을 폐기하며 팀원분께서 만들어주신 Repository Patteren을 활용하여 해당 프래그먼트에 필요한 정보들만 ViewModel에 가져와 빠르게 문제를 해결하였습니다.

   • [의존성 역전 원칙]

     • 처음으로 Repository Patter을 다루면서 Clean Architecture의 핵심 원칙 중 하나인 '의존성 역전 원칙'을 배우게 되는 시간이였으며, 데이터 접근 계층을 추상화하여 도메인 계층이 데이터 소스에 직접 의존하지 않도록 함으로써 코드의 유지보수성과 테스트 용이성을 크게 향상 시킨다는 점을 배웠습니다.

비전공자에게 코딩, 그리고 iOS 라는 벽은 너무나도 높게 느껴졌습니다. 고민하던 중에 직접 커뮤니티를 개설하게 되었고 좋은 기회로 23년도에는 총 3회의 Meet-Up을 개최하였으며, 자체 사이드 프로젝트와 모각코를 진행 해오면서 개발 문화를 알아가고, 네트워킹을 통해 새로운 기술과 개발 트렌드를 알아가는 유의미한 시간들이였습니다. 이를 통해 Git을 이용한 협업, api 적용, 종속성 관리자(ex. CocoaPods)등을 배우게 되면서 Android 입문에 큰 어려움이 없었습니다.