[부스트코스ACE 2기] 2주차 프로젝트 후기

1주일은 생각보다 (많이) 빨랐습니다..... ㅎㅎ..!

두번째 프로젝트는 화면 전환(+ 데이터 전달) 기능을 구현하는 것 이었어요!

프로젝트 미션 자체는 화면 전환 기능만 구현 하면 되는 것 이였지만, 1기 활동을 하면서 이미 코드리뷰를 받은 친구들이 말하기를.. Pass 는 주지만, 평가란에 데이터 전달 기능도 구현하라고 남겨 주셨다고 하더라구요...!

그래서 어쩌피 많은 기능이 아니니, 일찍 해놓는게 나을 것 같다는 생각에 데이터 전달 기능까지 함께 구현을 하게 되었습니다!

기능 구현

이전에 구현 했던 것 처럼 DataBinding library를 이용하여 구현하였고, 

현재 View Model 과 LiveData까지 적용하여 MVVM패턴으로 구현하기 위해 열심히 공부 중에 있어요..!

 (ง •̀_•́)ง 

코드 리뷰

---------------------------------------------------------------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------------------------------------------------------------------------

작성하기 > 영화상세화면 까지는 한줄평에 대한 처리를 해 놓았는데,

모두보기에서 작성하는 경우, 모두보기 > 작성하기 > 모두보기 까지만 처리를 해 놓고, 상세화면에는 내용이 반영되지 않았었어요T_T

그래서 저렇게 한줄 평을 남겨주신 것 같은데.. 🤔바로 적용해서 모든 뷰에서 같은 데이터를 볼 수 있도록 수정 해 놓았답니닷!

1. Main 페이지의 ListView

리스트 뷰는 일반적으로 데이터가 위에서 아래로 쌓이게 되어있었습니다.

그렇기 때문에, 새롭게 리뷰를 추가 해도 영화 상세 화면에 고정 해 놓은 크기는 상단의 2-3개 () 만 보여주고 새롭게 들어가는 데이터를 보여주지 못해서 어떻게 해결 해 볼까 하다가 생각한 해결책은 세가지 정도가 있었어요.

1) 스크롤을 무조건 하단으로 스크롤 바를 고정시켜   stackFromBottom 리스트 보여주기

2) 데이터가 무조건 위에 쌓이도록 adapter 수정하기 

3) 스크롤 없이 리스트 전체를 보여주는 커스텀 뷰 만들기 

    @Override

    public void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {

        int expandSpec = MeasureSpec.makeMeasureSpec(Integer.MAX_VALUE >> 2,

                MeasureSpec.AT_MOST);

        super.onMeasure(widthMeasureSpec, expandSpec);

    }

처음에는 (1)번 방법으로 구현 해 보았지만, 스크롤이 계속 아래로 내려가 있는 것이 뭔가 어색한 느낌이 없지 않아 있어서 일부러 (3)번 방법으로 구현 해 보았어요. 그런데 리스트를 2-3개만 보이게 하도록 수정하라는 리뷰를 받았고 이전코드로 다시 되돌려 놓았습니다..

2. fill-parents 속성

xml파일을 짤 때, width 또는 height 속성에서 fill_parents 값을 많이 사용했었습니다. 그런데 이게 사용하려고 할 때 마다, 밑줄이 그어져 있어서 사용해도 되는지에 대한 의문이 있어서.. 코드리뷰를 받을 때, 추가 질문사항에 기록을 남겨놓았습니다. 

그랬더니, 아래와 같은 리뷰를 남겨주셨어요! 앞으로는 의도적으로 사용하지 않도록 노력해야겠어요!

fill_parent는 API 8부터 deprecated 되었으니 match_parent를 사용하시기 바랍니다.

3. 임시 데이터 처리

sampleData를 각각의 화면에서 따로 처리하는 방법이 아닌, 'review data arraylist에 담아서 넘기는 방식으로 구현하는것이 좋습니다.'  라며 새로운 방법을 제안 해 주셨어요. 덕분에 이제는 모든 뷰에서 동일한 데이터를 보여줄 수 있게 되었습니다!

4. 

항상 초반에 기능 구현을 할 때, 나중에 서버 연동이 적용되었을 때 수정하기 쉬운 방식으로 미리 코딩을 해 놓았었어요. 나중에 서버 연동을 해야 할 때, 그때 가서 구현했던 기능을 다시 걷어내고 다시 구현하는게 귀찮았기에, 그 때를 생각해서 '대충 어떤 식으로 구현하면 되겠구나'하고 기능을 구현하곤 했었고,

이게 올바른 방법이라고 생각했었어요T_T... 그러나 개발 중에는 미래에 프로젝트가 어떻게 될지 모르니 현재의 프로젝트에 맞춰 기능 구현을 해야 한다고 말씀 해 주셨고, 제 태도에 대해 한번 더 생각 할 수 있는 기회가 되었답니다..ㅠ!

•    이후 네트워킹 챕터에서부터는 서버로부터 받아온 데이터로 set하게 되므로, 생각하신 방법이 맞습니다.
  하지만, 그 방식은 프로젝트5에서의 얘기이고, 현재 프로젝트3에서는 서버연동이 없으므로 하드코딩해야하고,
  하드코딩방식은 좋지 않기 때문에 strings.xml에서 정의하라는 얘기가 나오는것입니다.
  작성자께서 혼란스러운 부분은 이후 챕터에서 어떻게 진행될지 알기 때문에 그러는것입니다. 
  미래에 어떻게될지 모르기때문에 스트링테이블을 관리하는것이고, 개발중에는 수도없이 바뀌기 때문에
  현재의 프로젝트에 맞추어서 정의하는것이 맞는것입니다.

느낀점

이전에 프로젝트 진행을 할 때도, 통신 response를 받는 과정에서 키값을 잘못 전달해서, 프로젝트 마지막날에 하루종일 에러를 해결하느냐 엄청난 시간낭비를 한 적이 있었는데, 그때의 기억이 떠올랐어요^^,,,ㅠ 항상 같은 실수를 반복하는 것 같아요... 한번 더 '꼼꼼 해 지자'하고 다짐하게 되었던 것 같아요...!

프로젝트 제출도 이제까지는 항상 월-화 요일에 제출하곤 했었는데 앞으로는 주말 안에 완성하고 제출하도록 해야겠어요!