17. UI 수정 / 악보 좋아요 기능 추가 / 그룹 기능 추가 / 성능 개선

이 앱의 메인 기능인 악보에 대한 CRUD 구현이 모두 끝나서 주변 기능들을 구현하기 시작했다.

 

1. '좋아요', Key 조절 기능 추가

악보 뷰어 페이지에서 악보에 좋아요를 누를 수 있도록 버튼을 만들고,

마이페이지에서는 내가 좋아요 표시한 악보를 모아서 볼 수 있도록 했다.

 

이를 위해서 자동 스크롤 UI 위치를 하단으로 수정했다.

좋아요 버튼을 상단 앱바에 넣고 싶었기 때문이다.

 

그리고 하단에 자동 스크롤 UI만 덩그러니 넣으니 허전해서

마침 구현하려고 했었던 악보 키를 조절하는 버튼도 넣었다.

 

UI가 나름 괜찮아졌다 ㅎㅎ

지금 악보는 내가 미리 좋아요 표시를 해두어서 색이 칠해진 하트 모양이다.

좋아요를 표시하지 않은 악보는 색이 칠해져 있지 않다.

지금 포스팅을 쓰면서 생각해보니 하트 색을 빨간색으로 수정하는 것을 고민해보면 좋을 것 같다.

모든 UI 버튼의 색이 하얀색이라 좋아요 버튼이 강조되어 보이지 않는다.

 

'내 악보' 페이지에서 이렇게 내가 좋아요 표시한 악보를 모아볼 수 있다.

물론 해당하는 악보를 터치하면 악보를 바로 읽을 수 있는 뷰어로 이동한다.

 

현재 좋아요 표시한 악보와 내가 만든 악보는 3개까지 보여주도록 하고 있다.

버튼을 클릭해 더 자세히 볼 수 있도록 버튼은 만들어 두었지만, 아직 버튼의 기능은 구현하지 않았다.

---

그리고 원래는 '악보검색' 페이지의 리스트 아이템과 '내 악보' 페이지의 리스트 아이템 위젯을 따로따로 작성했었다.

그런데 코드를 살펴보니 중복되는 코드가 너무 많아서 중복되는 부분을 통합하여 별도 위젯으로 작성했다.

코드가 매우 짧아지고 보기 좋아졌다 :)

 

그렇게 정리하다보니 나름 체계적(?)으로 구조가 만들어졌다.

 

2. 그룹 기능 추가

이제 슬슬 그룹에 대한 기능도 만들어야겠다고 생각했다.

아직 디자인이 다 된 것은 아니지만, 기본적으로 그룹을 만들고 만든 그룹의 정보를 읽는 기초 UI를 만들었다.

 

그룹 기능은 평소 교회에서 찬양단으로 활동했던 것을 생각하면서 만들었다.

어떻게 기능을 구성해야 찬양단에서 이 앱을 쓴다면 편하게 쓸 수 있을지 고민하면서 기획했다.

 

새로운 그룹을 만들 때는 우선 '이름'과 '공개 여부'를 설정할 수 있도록 했다.

그룹의 경우는 악보와 다르게 확인 버튼을 누르는 순간 그룹이 생성되도록 했다.

(악보는 악보 편집창에서 V 버튼을 눌러 저장을 해야 악보가 생성된다)

 

그룹 상세페이지는 다음과 같이 만들었다.

아직 모든 기능이 구현되지는 않았지만, 우선 멤버 정보를 표시하도록 만들었다.

 

지금 생각하는 기능은, 일정에 따라서 다른 악보를 볼 수 있도록 하는 것이다.

그리고 가능하다면 멤버 별로 권한을 다르게 주어서 그룹장이 멤버를 강퇴하거나 초대하고,

그룹에서 볼 악보를 수정하거나 삭제하는 기능을 수행할 수 있도록 역할도 부여할 계획이다.

 

그룹 기능은 아직 기획단계라 구체적인 디자인과 기능은 완성되지 않았다.

 

3. 성능 개선

지난 포스팅 이후로 사실 이 작업이 지금까지 했던 작업 중 가장 뿌듯한 작업이었다.

기존에는 악보를 읽거나 악보를 수정할 때 각각의 코드셀에 대해 모두 TextField 위젯을 사용했다.

그리고 읽기 모드에서는 readOnly 속성을 사용하도록 했다.

 

이렇게 하니 가뜩이나 stateful 위젯이라 성능이 좋지 않은 TextField 위젯 수십 개를

빌드 할 때마다 계속 그려야해서 성능이 악화되었다.

 

악보를 로딩할 때마다 디버깅 모드 기준으로 3~5초 정도가 소요되었고,

성능 저하가 없는 프로파일 모드로는 시간 소요가 디버깅 모드만큼은 없었지만,

애니메이션이 눈에 띄게 버벅이는 모습을 보였다.

FPS를 측정해보니 11~13 프레임정도로 처참한 성능을 보여주었다...

 

그래서 다음과 같은 단계로 성능을 개선했다.

 

1. SingleChildScrollView + Column 위젯 조합을 ListView 위젯으로 수정

전자의 조합은 컬럼 내의 모든 위젯을 그려놓고 스크롤을 부여하는 반면,

리스트뷰는 현재 화면에 보이는 위젯들만 그려놓고, 스크롤을 내리면 해당 위젯을 그때서야 그린다.

당연히 초기 로딩시간에 차이가 생길 수 밖에 없었다.

 

이렇게만 수정해도 꽤 초기 악보 로딩 시간이 꽤 줄어듦을 경험할 수 있었지만,

여전히 스크롤을 내릴 때마다 버벅임이 심했고, 여전히 초기 로딩 속도도 눈에 띄는 속도로 느렸다.

 

2. 읽기 모드에서 TextField 위젯 대신 Text 위젯을 사용하도록 수정

생각해보니 읽기모드에서는 악보를 수정하는게 아닌이상 stateful 위젯을 사용할 필요가 없었다.

그래서 Text위젯을 사용하도록 수정했다.

 

결과는 대성공... 읽기 모드에서 엄청난 속도향상을 느낄 수 있었다.

디버깅모드에서도 시간 지연이 거의 사라졌고, 프로파일 모드에서는 시간 지연을 느낄 수 없었다.

FPS를 측정해보니 30 프레임이 나왔다.

 

하지만 여전히 악보 수정모드에서는 TextField 위젯을 수십개 불러오다보니 로딩이 느렸다.

 

3. 악보 수정 모드에서 '현재 편집 중이 아닌 위젯'에 대해 Text 위젯을 사용하도록 수정

그래서 이 문제를 해결하기 위해 고민을 시작했는데, 답이 생각보다 쉽게 나왔다.

악보 수정모드에서 셀을 선택할 때마다 선택한 셀을 시각적으로 알 수 있게 다시 빌드해주고 있었는데,

어차피 다시 빌드할거라면, 선택한 셀에 한해서 TextField 위젯을 사용하도록 빌드하고,

그 밖의 셀에 대해서는 Text 위젯을 사용하도록 해두면 성능이 나아질 것이라고 예상했다.

 

역시 결과는 대성공이었다. 악보 수정모드에서도 성능향상이 크게 이뤄졌다.

프로파일 모드에서도 악보 수정에 큰 버벅임 없이 자연스러운 화면전환과 악보 로딩을 느낄 수 있었다.

---

이렇게 오늘까지의 작업을 통해 앱에 기능을 추가하고, 성능을 개선하고, 코드 구조를 수정했다.

안드로이드 앱 자체를 처음 만들어보고 있는데, 만들다보니 점점 익숙해지는게 느껴진다.

예전에는 기능하나를 추가하는데 1주일이 걸렸다면, 이젠 1시간이면 추가할 수 있게 된 것 같다.

(플러터라는 프레임워크가 쉬운 것도 한몫 해주고 있다 ㅎㅎ)

 

그리고 실제 기능이 없어서 포스팅에 자세히 적지는 않았지만,

원래는 카카오 로그인도 구현하려고 했었다.

 

카카오 단독 로그인은 구현에 성공했는데,

그렇게 하니 파이어 베이스를 사용하는 인증과 코드가 서로 꼬여서 문제가 생겼다.

그래서 파이어베이스에 카카오로그인을 통합하려고 했다.

사실 이거 때문에 거진 3~4일을 쓴거 같다 ㅋㅋㅋㅋ

 

결과적으로 플러터 프레임워크 내 라이브러리 문제로 추정되는 부분 때문에, 구현은 실패했다.

엑세스 토큰까지 잘 받아왔는데!! 파이어베이스에도 잘 넘겼는데!

마지막 단계에서 node 서버와 카카오 서버의 http 통신이 안됐다...

flutter 깃허브 이슈로도 있던데, 2019년에 발생한 이슈가 아직까지 존재하는 듯하다..

 

하지만 덕분에 OAuth 2.0 에 대한 공부도 해봤고,

별도 인증서버를 둬야해서 오라클 클라우드에 node.js 서버도 만들어봤는데

(사실 node.js 서버 만드는 데에만 이틀을 썼다..ㅋㅋ)

node.js도 파이썬의 flask와 느낌이 비슷해서 신기했다.

백엔드는 구조가 다 비슷비슷 한 것 같기도...

 

이왕 서버 만든김에 node.js 공부도 해볼까 했는데,

이 공부는 군대에 가서도 할 수 있을 것 같다고 느껴서 (제발.. 할 수 있기를..)

우선 군대에서 하기 힘든 앱개발에 집중하기로 했다.