LOCKA 프로젝트 3,4주차 개발일기

2주차 일기는 https://oflofty.tistory.com/8

LOCKA 프로젝트 2주차 일기

사실 1주에 1개씩 꾸준히 일기를 쓰려고 했는데 제출기한이 되가니까 너무 정신이 없어서 못쓰고 있다가 프로젝트가 마무리되가는 시점인 오늘 3~5주차 일기를 몰아쓰려고 한다. 2주차 일기까지가 D-day 계산기와 월급 합 계산을 삽을 막 뜨던 시점이었던 거 같은데 지금 생각해보니 마감이 상당히 더뎠다고 생각된다.

어려웠단 이슈가 몇개 있었는데 그 중에서 가장 어려웠던 점은  마지막주인 10월 5주차가 훈련주간이라서 그냥 일과를 소화하기에도 너무 정신없던 와중에 마감까지 해야했던 점이다. 거기다가 저번 일기에서 말한 것처럼 탄약고근무도 미친듯이 들어가느라고 피로누적 문제도 꽤나 심각했던 거 같다. 개발기간 동안은 피로나 압박감같은 것들이 시험기간하고 비슷비슷했던 거 같다.

 

이런저런 환경에 대한 푸념이 좀 길었는데 본론으로 들어가서

전체적인 개발 문서는 github README에 서술했으니 관심있으신 분들은  https://github.com/vesselofgod/APP_LOCKA_DreamY

vesselofgod/APP_LOCKA_DreamY

사실 뭐 여기에 기능설명도 좀 쓸까 했는데 어차피 여기 쓰는 글들은 개발하고 나서 느낀 점들이니까 내가 개발한 앱에 대한 어필은 하지 않을 거 같다. 그래서 잘 만들었냐? 라고 하면 일단 최선을 다 했고, 기획했던 기능들을 모두 구현하는 데에 성공했다고 생각한다. 만족스럽다.  그리고 막상 쓰려니까 하고 싶은 말이 너무 많은 거 같아서 이 글에서는 구현하면서 있었던 개발상의 issue에 대해서 말해보려고 하고 LOCKA 프로젝트 개발을 마치고 느낀 점들은 아래 글에 써보려고 한다. 사실 이게 이번 개발하면서 머리속에 가장 많이 남는 것들이니까 꼭 봐주셨으면 한다 :)

https://oflofty.tistory.com/11

LOCKA 프로젝트를 마치며...

 

Trello를 이용해서 프로젝트 issue, 일정관리를 했다.

가장 먼저 다뤄볼 이슈는 Permission에 따른 첫화면 변경이다.

무슨 말이냐 하면...

우리가 앱을 사용할 때 몇몇 앱들은 앱이 작동하기 위해서 권한을 받아와야 한다. 그런데 매번 이런 권한페이지가 앱을 킬때마다 뜬다고 한다면 앱을 사용하는 데 있어서 무척이나 번거로울 것이기에 첫 화면은 이 앱에 필요한 권한을 허용했는지 아닌지에 대해서 확인한 후, 권한이 허용되어 있다면 더이상 권한을 요구하는 화면을 띄우지 않도록 설정하였다.

그런데 이 이슈를 접하면서 힘들었던 점은 내가 억지로 구글링해서 '아 이런 기능이 있으니 쓰면 해결되겠지?'를 너무 쉽게 생각했다는 점이다. switch navigation이라는 react에서 화면전환을 도와주는 기능을 사용해서 하려고 했는데 이게 initRoute라는 변수를 통해서 첫 화면을 제어해주면 된다고 생각했는데 이상하게시리 너무 안돌아가는거였다... 이것저것 건드려보면서 해결하려고 했는데 자바스크립트의 비동기 처리 패턴을 이해하지 못한 상태에서 그냥 무작위로 asyncdata를 이용해서 스파게티 코드를 짜고 있었던 것이다. 그나마도 돌아갔냐고 하면 돌아가지도 않는 상태로 백색화면만 뜨고 디버깅도 불가능한 환경이라서 아무것도 못하는 상태로 2일정도 날렸다. 

 

이 이슈를 해결한 것은 '첫 화면이 뜨고 나서 그려지기 전에 권한 설정여부를 확인해서 화면을 표시하면 되겠다' 라는 아이디어였다. 사실 보통은 다들 switch navigation을 쓰겠지만 이걸 확실하게 이해하고 코드짜기엔 개발시간이 너무 모자라서 ReactNative의 LifeCycle을 이용해서 해결할 수 있었다. 

 

출저 : https://medium.com/@jang.wangsu/rn-react-native-생명주기-는-d744d59e275

 

간단하게 constructor에서 state를 확인하는 함수를 돌린 후에 만약 권한이 허용되어있지 않다고 하면 Permission 화면으로 이동하게끔 설정하였다. 마감을 얼마 두지 않고 갑작스럽게 오류가 발생해서 놀랐지만 이슈를 해결했으니 참 다행이다 싶었다.

 

가장 당황했던 이슈라고 하면 마감 하루전날에 항상 아팠던 팔목때문에 물리치료를 받으러 외진을 갔는데 항상 외진을 가면 비상연락용으로 휴대폰을 불출해서 가져간다.그런데 여기서 마감 하루 전날에 앱을 켜보니까 잠금시간이 완전히 틀린 상태로 출력되어있어서 당황스러웠다. 솔직히 큰 이슈는 아니였고 부등호 하나 바꿔서 다시 잡은 이슈긴 하지만 개발이 끝난 줄 알았는데도 테스트를 해보니 특정 경우에서 안돌아가는 경우를 꼭 따져보는 습관이 부족했던 것 같다. 근데 뭐 당황했을 뿐이지 해결은 금방 끝나서 상관없지 않았나 싶다.

 

추후에 포스팅할 이슈들 ...

 

그리고 이번에 개발을 하면서 시간이 급해 몇몇 구현은 약간 회피하는 식으로 개발을 했는데 대표적으로 InputText 화면깨짐 처리를 하지 않고 피했다. 원래 기본적으로 아래 보이는 잠금해제코드 입력화면과 같이 텍스트를 입력할 수 있는 박스를 이용해서 월급계산기 쪽에서도 적금액을 입력하려고 했었다.

 

화면 해제 상황에서 사용되는 InputText

 

그런데 문제가 생긴다. InputText 박스를 터치하는 순간 키보드가 올라오는데 키보드가 올라오면서 화면비율이 완전히 깨져버리는 것이다. 해제화면같은 경우에는 화면에 들어가는 버튼들이나 요소들이 적으므로 화면이 깨지지 않고 잘 돌아갔던 거에 비해 월급계산화면은 이것저것 버튼이 많아서 화면이 완전히 깨져버렸다. 구글링을 해보니 KeyboardAvoidingView 태그를 이용해서 해결하라고 했는데 당연히 이것만 써서는 해결이 안됐다. KeyboardAvoidingView는 키보드가 올라올 때 화면들을 축소된 화면에 맞춰서 재배치하는 역할을 하는데 문제는 너무 많은 버튼들이 배치되어있어 버튼들이 겹치는식으로 엉망이 되버렸다. 

 

이걸 어찌어찌 해결하는 방법은 버튼을 줄이던가 아니면 화면 비율을 일일히 조정하던가 했어야했는데 마감이 얼마 남지 않은 시점에서 코드 한 줄 바꾼 걸 테스트하는데만 5분 이상 걸리는 환경에서 비율을 직접 다 조정한다? 시간이 충분하다면은  해결이 가능하겠지만 마감이 얼마 남지 않은 관계로 결국은 포기하고 맘 편하게 text dialog를 통해서 입력을 받게끔 변경하였다.

 

 

추후 추가될 내용들

branch 꼬이는 문제

앱 삭제방지

select picker