Retrofit 통신 과정에서 Exception을 구분하여 에러 이유에 따른 예외처리를 구분하였다.
IOException ( 네트워크 통신 문제 )
HttpException ( 통신 결과 응답 코드 오류 -> 404 Not Found , 500 Internal Server Error 등...)
등을 구분하여 표현할 수 있었으나, HttpException의 경우는 따로 구분하지 않았다.
우선 필요한 응답유형을 구분한다. 현재 예시로 든 코드는 로그인 / 닉네임 변경 등의 결과를 반환하는 코드로 모두 성공 / 실패만 반환하면 되기 때문에 모든 응답에서 필요로 하는 success, code를 포함하여 부가적인 message만 받아오도록 SuccessResponseDomain을 지정해줬다.
이후 repository 단에서 서버와의 응답 결과를 받아와 Error 유형에 따라 SuccessResponseDomain에 코드를 담아 ViewModel 의 LiveData로 넘긴다.
ViewModel단에서는 단순히 UI단에서 요청한 도메인의 타입에 따라 repository 단에서 역할을 수행하고, 반환 결과를 response 라이브 데이터에 담기만 하면 된다.
response livedata의 observer 의 일부 코드
이후 UI단인 Activity에서는 livedata에 observer를 정의, 등록하여 response 타입을 통해 요청 유형을 구분하고, success / code를 구분하여 UI 단에서 적절한 처리를 할 수 있다.
해당 코드는 편의를 위해 하드코딩하였다.
추가적으로 패스워드 전송 시에는 패스워드가 통신에서 평문으로 전송되는 것을 지양해야 하기에 sha256을 적용하여 해쉬된 값을 전송할 수 있도록 구현하였다.
근데 다른 Repository에서 같은 형식의 데이터 모델을 적용시켜보려고 하자 문제가 생겼다.
각각의 UseCase별로 Repository를 생성하였는데 각 UseCase에서 필요로 하는 데이터 모델은 다른데 Service단에서 제공하는 데이터 모델은 바뀌지 않는다는 점이다.
즉, Service단에서 특정 유저 정보를 가져오는 데이터의 반환값을 LoginRequestDTO로 가져오게 되면 다른 Repository에서는 그 데이터의 사용이 힘들다는 점이다. Domain 계층의 필요성을 직접 깨달을 수 있었다.
해결 방안
Service단에서 제공하는 각각의 트랜잭션에 대한 반환값과 요구값을 DTO로 정해두고, Domain단에서는 각 UseCase별로 필요한 데이터 형식을 수립해놓을 것이다. Repository(Data단) 에서 Service에 접근할 때 (DTO -> Domain) 으로 형식을 반환하여 ViewModel / Fragment (UI단)으로 넘기면 해당 Domain 형식을 가지고 Ui에 결과값을 반환하는 것이다.
이전 방식은 ViewModel 단에서 추가적인 디캡슐화/캡슐화를 진행하여 로직을 구분할 수 있을 것이라 생각했는데
결국 service 단에서 해당 로직을 구분하면 될 것으로 판단되어 굳이 viewModel 단에 추가적인 데이터모델을 수립할 필요는 없을 것 같다.
예를 들어 포스트, 댓글, 유저의 id값을 통해 삭제를 진행할 수 있는 api가 각각 따로 존재한다면
DomainModel에는 enum값을 포스트 / 댓글 / 유저를 구분하여 repository로 넘겨주면
repository단에서 각각을 구분하여 service에 요청할 수 있을 것이다.
가장 중요한 것은 각각의 UseCase별로 필요한 요청을 명확히 구분하는 것이라 생각된다.
파이어베이스 위주가 아닌 제대로된 백엔드와의 협업은 처음이라 기본적인 서버 통신 과정에 대해서도 많은 어려움이 있었는데, 특히 단순히 UI를 표시하기 위해 필요했던 데이터들과 서버에 통신을 위한 모델을 어떻게 연결해야할지에 많은 어려움이 있었다.
기존에 진행하였던 부분에서는 서버와의 통신을 배제한 상태에서 진행하다보니 UseCase별 필요한 요청과 응답 부분을 생각하지 않고 진행했던 것이 현재 시점에서 많은 수정을 필요로 하는 어려움을 가져다 준 게 아닐까 되돌아본다.
api가 다 나와있는 시점에서 개발에 들어갔다면 api별로 dto형식을 지정해 변환과정을 거칠 필요가 없이 바로 Repository단에서 필요한 데이터만 올려 보내면 될 일이지만, 명확한 반환값이 정해지지 않은 현재 시점에서 개발 일정에 맞추기 위해 다른 부분들을 마무리 해야하는 점이 많은 어려움이 있었다.
아직 진행되지 않은 부분을 완료되었다고 가정한 interface를 사용하여 이후 개발이 완료된 후에는 해당 부분만 채워두면 동작이 되도록 진행하려고 많이 노력하였고, 해당 과정에서 많은 배움을 얻을 수 있었다.
현재 프로젝트를 진행하면서 PM 역할의 중요성과 필요성을 몸소 느끼고 있다. 개발 일정을 관리하는 데 있어서 프로젝트 범위가 커지다 보니 전체 일정의 진행도를 파악하기가 너무 힘들었고,설계 과정이 부족했던 탓인지 개발 도중 누락된 개발사항이 계속해서 발견되고 있따.
프로젝트를 열심히 해도 영 진행되지 않는 모습에 답답하기도 하고 스트레스를 많이 받았지만, 최대한 Git Issue를 통해 각 프래그먼트 별로 필요한 부분을 적고 진행도를 체크함으로써 일정 관리 문제를 해결하기 위해 노력하고 있다.
Fragment에서는 각각의 요청 (로그인 / 회원가입 / 아이디 찾기 / 비밀번호 찾기)에 대해 각각의 DTO 를 사용하여
다음과 같이 ViewModel에 UserRequest 클래스로 요청한다.
loginViewModel.request(
UserRequest.Login(
LoginRequestDTO(
email = binding.username.text.toString(),
password = binding.password.text.toString()
)
)
)
/**
/* 현재 코드는 각 상황별로 직접 UserRequest(UserRequestDTO())로 요청하도록 되어있지만
/* 서버에 요청하는 코드를 UserRequestDTO 형식을 받는 함수로 따로 만들어
/* 해당 함수에서 UserRequestDTO의 형식을 구분하여 UserResponse에 담아 viewModel에 요청하는 역할을 수행하도록 하여
/* 요청하는 부분에서는 단순히 해당 코드를 각각의 DTO에 담아서 요청할 수 있도록 만든다면 가독성측면과 직관성을 보완 할 수 있을 것 같다.
**/
형식을 통해 ViewModel에게 데이터를 요청하고
classLoginActivity{
overridefunonCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
loginViewModel.response.observe(this, ::responseObserver )
}
privatefunresponseObserver(response : UserResponse){
if( loading.isShowing )
loading.dismissWithAnimation()
when(response){
is UserResponse.Login ->{
val dto = response.dto
if(dto.success){
//로그인 성공 시 결과값 표시
}
}
is UserResponse.FindIdPw ->{
val dto = response.dto
if(dto.success) {
//아이디&비밀번호 찾기 성공 시 결과값 표시
}
}
is UserResponse.Register ->{
val dto = response.dto
if(dto.success) {
//회원가입 성공 시 결과값 표시
}
}
}
}
}
ViewModel에서는 reqeust함수로 들어오는 UserRequest의 타입에 따른 요청을
repository에 UserRequestDTO 형식을 사용하여 전송한다.
UserRequestDTO형식을 사용하기 때문에 dto = requestType.dto로 미리 정의하여
_resposne.value = repository.해당함수(dto)와 같이 코드를 통일성있고 간결하게 작성할 수 있었다.
결국 핵심은 바뀌는 리스트를 넘겨주는 것이 나타내고 싶은 상태가 고정된 리스트 (toList로 새 리스트에 복사)로 전달하는 것이 핵심이다.
submitList(itemList.toList())
추가적으로 LiveData를 다루는 데 있어
단순 _capturedImages.value!!.add(image)와 같이 MutableLiveData의 value인 ArrayList에 add/remove를 통해 수정/삭제하여 옵저버 패턴이 반응하기를 기대했었는데 value 자체가 바뀐 것이 아니라 반응하지 않는 것을 확인했다.
를 사용할 시 root의 LayoutParams가 제공되기에 앞선 예제2 코드와 같이 짤 필요는 없다.
추가적으로, attachRoot의 경우 true를 하면 inflate와 동시에 parent의 계층 구조에 속하게 되므로, viewholder에는 적합하지 않다. ( 해당 링크의 예시 코드를 보면 inflate 후 addView를 하여 뷰를 추가하는 것이 확인가능하며, attachRoot = ture인 경우 addView가 필요없음을 확인가능하다. )
