총무앱 - 이기적인 총무 런칭 그리고 업데이트

예상보다 힘들었던 디자인 작업도 끝나고 이제 드디어 런칭까지 했다! 하아 그런데 생각보다 런칭이 이렇게 오래 걸릴 줄이야... 

https://play.google.com/store/apps/details?id=com.cholab.kwony.jochongmu

애플리케이션을 출시하는 일은 가게 차리하는 것과 비슷했다. 개발하는 일 뿐만 아니라 가게를 꽃단장 하는 것처럼 사용자들이 스토어에 애플리케이션을 다운받으러 들어 올 때 홍보할 그래픽 이미지 및 문구도 필요했고 음식점이 식약청에 검사 받는 것처럼 내 애플리케이션도 유해한 요소가 있는지 없는지 간단한 설문 조사를 통해 검사받았다(3세 이상 이용 가능한 애플리케이션이 됐다)

막상 출시하고 친구들에게 공유를 했는데... 아 생각보다 허접한 느낌이다. 마치 많이 공부 한 것 같은데 시험장에 들어오면 머리가 빈 것 같은 느낌이랄까. 남들이 과연 이걸 쓰고 편안 할 지 모르겠고... 최대한 심플하게 만들겠다고 했는데 반드시 필요한 기능까지 뺀 것은 아닌가 생각했다.

성실하게 피드백 해준 친구 한명 덕에 고칠 부분들을 많이 찾아냈다. 모임을 관리하는 사람의 입장에선 참여한 멤버를 관리 할 수 있는 기능이 반드시 필요하다고 했다. 쉽게 모임 멤버수만 갖고 계산하면 참여한 멤버수를 기억하기가 쉽지 않다고 한다. 다른 애플리케이션도 결제 목록별로 참여자 정보를 모두 관리하고 있었다. 맞는 말인 것 같아서 바로 수용했다. 대리결제자 탭을 참여 멤버 탭으로 변경하고 각 결제 내역 별로 참여한 멤버들을 관리 하도록 했다. 물론 친구의 표현처럼 건물을 3센치 옮기는 일이긴 하지만. 건물이 더 커지기 전에 빨리 옮겨야겠다.

그리고 반올림 기능보단 올림 기능이 좋다고 했다. 반올림하면 손해보는 경우가 생기니 염치 없으려면 제대로 하는게 좋다고(ㅋㅋ) 적극 수용했다.

결제 내역별 참여자 정보는 Relation table을 만들어서 결제내역별로 참여자 정보를 관리 할 수 있도록 했다. 테이블 구성은 아래와 같다.

먼저 party ID로 한 번 거르고 그 다음에는 결제 내역 X 참여자 정보로 관리하는 방식이다. DB숙제에서도 안 썼던 Relation Table을 여기서 쓸 줄이야. Relation Table은 하나의 객체가 다른 여러 객체와 연결이 필요한 경우 데이터 수를 최소화 하면서 관리 할 수 있는 방법이다. 매번 table을 찾아다녀야 하는 cost가 있지만 그래도 공간을 많이 차지하지 않고 관리가 용이하다는 점에서 좋은 방법이다.