악보에 태그 기능을 달면 더 좋겠다는 아이디어가 생각났다. 블로그 태그 같이 자유롭게 여러개를 다는 기능보다는 작성자가 직접 난이도와 곡 장르를 정해진 태그 중 골라서 매기는 기능이다. 이 기능이 추가되면 사용자들이 좀 더 편하게 악보를 찾을 수 있을 것이다. 난이도와 장르를 구분하지 않고 이렇게 enum 하나에 묶은 뒤, 각 값마다 태그의 배경색과 보여질 내용을 하드코딩했다. 난이도와 장르를 enum 하나에 묶은 이유는 Flutter의 Chip 이라는 기본 위젯을 가볍게 커스터마이징해서 Tag 라는 커스텀 위젯을 만들었는데, 이 Tag 라는 위젯에 TagContent 라는 하나의 enum 을 넘겨서 장르와 레벨을 모두 표현하고 싶었기 때문이다. enum을 구분하면 위젯도 GenreTag, LevelTa..
기본적인 기능은 어느정도 만들어졌다고 생각해서 플레이스토어에 한번 출시해보기로 마음먹었다. 구글 개발자 계정은 전에 만들어두었다. 근데 앱을 등록하는 절차가 정말 복잡했다. 앱 정보 뿐만 아니라, 미국 세금 관련 정보, 국내 결제 정보 같은 것도 입력해야하는데 낯선 부분이 정말 많았다. 앱 아이콘을 간단하게 만드는 방법을 검색해서 피그마로 만들었다. 그래픽 이미지는 어디에 쓰이는 건지 모르겠다. 앱 링크 공유하면 나오는 이미지라는데 해보니까 앱 아이콘으로 나오던데..? 1학년때 디디입 수업을 들으면서 앱 아이콘 디자인 과제를 해본 게 조금 도움이 되었다. 진짜 너무 힘들었던 수업인데 이럴 때 도움이 되네.. 스크린샷을 올려준다. 같은 태블릿 스크린샷인데 10인치에 사이즈가 안맞는다고 안올라가서 당황했다...
말출을 나오면서 컴퓨터를 하나 새로 장만했다. 60만원대 정도로 적당히 샀는데, 게임도 잘 돌아가고 개발 환경도 아주 좋아졌다ㅎㅎ 밖에서 개발하는 김에 오랜만에 입대직전까지 진행했던 이 프로젝트를 이어서 해보려고 했다. 아아... 플러터 SDK 버전이 달라서 그런지 스택오버플로우를 검색해가며 Gradle 파일을 수정해봤는데 뭔가 문제가 있는 듯 하다. 이전에 개발하면서 사용했던 라이브러리 일부도 deprecated 되면서 사용을 권장하지 않게 되었다. 2년동안 방치했더니 그동안 너무 많은 것이 바뀌어버렸다. 이걸 하나하나 수정을 하기에는 힘들어 보이기도 하고, 이 프로젝트를 너무 오랫동안 방치한 탓에 나도 이 프로젝트의 코드 구조를 까먹어 버린 상태라 이왕 이렇게 된 거 다시 구조도 복기할 겸 코드를 새..
지난달까지는 이 프로젝트를 배포할 때 nodemon을 이용해서 배포를 하였다. nodemon으로 배포하고 있을 때는 소스코드를 수정한 결과물을 자동으로 반영해주어서 결과물을 확인하기 좋았기 때문이다. 하지만 단점도 있었다. 매번 프로젝트를 할 때마다 노드몬을 키고 끄는 작업을 반복해야했기 때문이다. 물론 노드몬 자체를 백그라운드로 실행시킬 수도 있겠지만 나중에 노드몬을 끌 때 프로세스 아이디를 읽고 꺼야하는 귀찮음이 있어서 하고 싶지 않았다. 이 작업이 너무 번거롭다고 생각해서 백그라운드에서 배포하는 방법을 알아보았다. 검색을 해보니 nodemon말고도 forever와 pm2 등 선택지가 더 있었다. 그 중에서 나는 forever를 선택했다. 그 이유는 다음과 같았다. forever start 명령어로 ..
원래는 악보를 구성할 때, 페이지 별로 구성하는 것을 생각했었다. verse 페이지 작성하고, chorus 페이지 작성하고, bridge 페이지를 각각 만든다음 '전체' 페이지에는 각 페이지에 작성한 코드를 이리저리 조합해서 만들자! 이게 내 처음 아이디어였는데, 생각보다 '전체' 페이지에서 각 페이지의 코드를 합치는게 복잡했다. 단순히 각 페이지의 코드를 읽어서 붙이는 것이라면 상관없겠지만, (사실 이것도 구현하기가 너무 귀찮았다.) 이왕 각 페이지의 코드를 참조하는거, '전체페이지의 코드'와 '각 페이지의 코드' 를 서로 연동해서 전체 페이지에서 수정한 코드가 각 페이지에서도 수정되고, 각 페이지에서 수정한 코드가 전체에서도 수정되도록 하고 싶었다. 이걸 구현하려면, 결국 모든 코드셀에대해 Globa..
악보에 대해 CRUD 구현을 완료했다. 그리고 백엔드를 오라클 클라우드를 이용한 리눅스 서버에서, BaaS인 파이어베이스로 이전했다. Firebase 로 이전한 배경 악보에 대해 수정과 삭제를 진행하기 위해서는 악보를 작성한 작성자를 구분할 수 있어야 한다. 유저 인증 기능을 손수 구현한다면 내가 생각하기에 DB에 아이디와 비밀번호를 저장해놓고 사용자가 입력하면 입력값을 DB의 데이터와 단순 비교하여 체크하는 방식으로 했을 것이다. 비밀번호의 경우, 데이터를 그대로 저장하는게 아니라 해시를 사용한다고 들었다. 또 여기저기에서 주워들은 이야기로는 토큰이니 세션과 쿠키니 그런 것으로 유저 인증을 한다고 들었는데, "아이디 + 비밀번호 + 해시" 이 3가지 조합외에 기술을 사용하는 이유는 아직 와닿지 않았다...
악보 편집 기능의 핵심 기능을 완성했다. 3일 동안의 커밋 내역이다. 변경사항이 정말 많다. 3일동안 밥먹고 자는 시간 빼고 플러터로 코딩만 했다... (코딩 : 아키텍처 고안 : 디버깅,플러터 공부 = 3 : 2 : 5 정도 인 듯하다.) 1. DB에 코드를 저장하고, 저장한 코드를 불러오는 기능을 구현했다. 딱 '코드'만 저장하는게 아니라 코드를 포함한 줄 건너뜀과 같은 부분도 저장하도록 했다. 2. 코드셀을 보여줄 때, 높이가 높아지면 아래 코드가 키보드와 버튼 UI에 가려지는 문제를 수정했다. 원래 Scaffold() 위젯의 body 속성으로 코드셀을 넣어주고, 커스텀키보드와 버튼UI를 bottom 속성에 넣었었다. 그런데 bottom 속성은 기본적으로 body위에 스택처럼 덮어서 UI를 보여주는..
