[WIL] 2024년 5월 셋째주 (심화 팀프로젝트 시작 및 필수 구현 완료 : Youtube Data API, MVVM, SearchFragment)

 

 

📅 24년 5월 13일 ~ 5월 19일
	월요일	화요일	수요일	목요일	금요일 및 주말
심화 강의 내용 블로그에 정리		■ Retrofit ■ 개발프로세스 ■ 디버깅 ■ 미세먼지앱		□ 미세먼지앱
과제 해설		□ 과제 해설 수강
팀 프로젝트	■ S.A. 작성 ■ Figma    와이어프레임	■ 기본 틀 구현		■ SearchFragment    필수 기능 구현	■ 팀 필수 구현 모두 완료 후 Merge
베이직반 강의			■ 이전 강의 수강    (1/2/3강)	■ 베이직반 9회차    (Retrofit)
Joyce 서적 독학		□ TodoList 제작    (Room)	□ 미세먼지 V1.0	□ 미세먼지 V2.0	□ 미세먼지 V3.0
심화 목표
- KIA 개념 훑기  - Android Developer 읽기  - 개인프로젝트 UI 구현  - 지난 프로젝트 코드 뜯어보기  - 링크 수강  - 캠프 공식 교육이 끝나고 나면, 챌린지/스탠다드 차례로 수강하기  - 정창경 정리

 

 

 

 

---

 

 

1. 안드로이드 심화 강의 내용 정리

 

 

[Android 기초] 15. SharedPreferences

[Android 기초] 16. Room (데이터베이스)

[Android 기초] 17. 사용자 위치 얻기

[Android 기초] 18. 구글 지도앱 제작

[Android 기초] 19. Retrofit (HTTP, API, REST, JSON, GSON)

[Android 기초] 20(끝). 안드로이드 앱 디버깅

 

• 저번주에 수강 후 정리하지 못했던 내용을 정리하고, 복습했다.
• 이제 수강이 끝났고, Android의 기초적인 내용은 전체적으로 많이 훑었기 때문에 앞으로의 포스팅은 개인적으로 공부하는 테마/기술을 낱개의 포스팅으로 정리할 예정이다.

 

https://roadmap.sh/android

 

 

---

 

2. Joyce 안드로이드 서적 독학 및 프로젝트 실습

 

1~9. 이전에 공부했던 내용 : 이전 TIL에 정리

[Android TIL] 240415 (Joyce 서적 공부, 스탠다드반 4주차 과제 UI 구현, 베이직 및 스탠다드반 3·4주차

[WIL] 2024년 5월 둘째주 (심화 강의 수강, 개인 과제 구현중, 스톱워치, 뮤직플레이어, QR리더기)

 

10. Todo List 프로젝트 제작

• Room, RecyclerView를 복습하기 위함

 

 

---

 

3. 팀프로젝트 : Youtube Data API - SearchFragment, MVVM 등 필수 완료

 

맡은 부분 안에서의 필수 구현을 모두 완료했다.

 

1. Youtube Data API를 이용하여 검색 결과 출력

Search  |  YouTube Data API  |  Google for Developers

• 우선, 해당 API를 통해 검색 결과를 반환하는 검색 화면을 만들 것이다.
• 주의해야 할 점은 'Search' 엔드포인트에서 반환을 요청하는 비용이 생각 이상으로 비싸다는 것이다.
  일반적인 댓글, 재생목록, 채널명 출력은 1의 비용을 사용하지만, 검색은 한 번의 요청마다 무려 100을 사용한다.
  무료 버전의 경우 하루 10,000의 할당량을 채우면 다음날 오후 4시까지 HTTP 403 오류가 뜬다. 
• 아직 팀프로젝트 발표가 끝난 것이 아니므로, 자세한 코드(특히 네트워크)는 차후에 정리하겠다.

 

💡 고민점: 어떤 방법으로 검색을 요청할 것인가?

    private fun setupSearch() {

                // (1) 검색어가 갱신될 때마다 자동 검색
        binding.etSearch.addTextChangedListener { editable ->
            val query = editable.toString()
            if (query.isNotEmpty()) {
                viewModel.searchVideos(query)
            }
        }

        // (2) 검색 버튼없이 키보드의 엔터로 작동 (imeOptions="actionSearch", inputType="text" 로 설정 후 구현)
        binding.etSearch.setOnEditorActionListener { v, actionId, event ->
            if (actionId == EditorInfo.IME_ACTION_SEARCH ||
                event?.action == KeyEvent.ACTION_DOWN && event.keyCode == KeyEvent.KEYCODE_ENTER
            ) {
                val query = binding.etSearch.text.toString()
                if (query.isNotEmpty()) {
                    viewModel.searchVideos(query)
                } else {
                    Toast.makeText(requireContext(), "검색어를 입력해주세요.", Toast.LENGTH_SHORT).show()
                }
                true
            } else false
        }

        // (3) 검색 버튼(btnSearch)을 추가한다면 아래 코드 사용 가능
        binding.btnSearch.setOnClickListener {
            val query = binding.etSearch.text.toString()
            if (query.isNotEmpty()){
                viewModel.searchVideos(query)
            } else {
                Toast.makeText(requireContext(), "검색어를 입력해주세요", Toast.LENGTH_SHORT).show()
            }
        }

    }

• 기능을 다 구현해놓고, 검색 방법에 대한 고민이 있었다. 아래와 같은 종류가 있다고 생각했다.
  (1) (검색 버튼X) 텍스트가 입력되고 약간의 텀이 있을 때마다 자동으로 검색
  (2) (검색 버튼X) 텍스트를 원하는 만큼 다 입력하고, 엔터를 입력했을 때만 검색
  (3) (검색 버튼O) 검색 버튼을 구현해두고 그 버튼을 눌렀을 때만 검색
• 처음엔 (1)이 괜찮다고 생각했으나, 검색을 너무 자주 갱신해서 API 할당량을 초과하는 문제가 있었다.
• 검색 버튼을 따로 만들어두는게 심미적으로 별로라서 2번 코드만 남겨두었다.

 

 

• 위와 같이 SearchFragment.kt가 완성되었다.
  주어진 검색어에 따라서 Youtube Data API의 search 엔드포인트를 이용해 검색 결과가 출력된다.
• MVVM으로 바꾸기 이전까지의 구조는 아래와 같다.
  
  

  model   ㄴ database     ㄴ ...   ㄴ SearchData.kt presentation   ㄴ activity   ㄴ adapter     ㄴ RVSearchAdapter.kt   ㄴ fragment     ㄴ SearchFragment.kt network   ㄴ ChannelsInterface.kt   ㄴ NetworkClient.kt   ㄴ SearchInterface.kt

  위에서 말했듯 자세한 코드는 나중에 정리할 것이다.

 

 

 

 

2. MVC -> MVVM으로 변경

이제 프로젝트 기획 초기에 생각했던 MVVM 패턴으로 코드를 변경하였다. 팀원분의 설명으로 기본적인 구조를 이해하고 나니, MVC 구조를 MVVM 구조로 변경하는 작업은 단계별로 수행하면 크게 어렵지 않다고 느꼈다.
MVVM 구조는 데이터와 UI를 분리해 유지보수성과 테스트 용이성을 높이며, 이번 프로젝트의 경우 LiveData와 ViewModel을 사용하여 데이터 바인딩을 처리할 수 있다.

(1) SearchViewModel : LiveData를 통해 데이터를 Fragment에 전달, 데이터 로딩 및 비즈니스 로직 처리
(2) SearchFragment : UI로직을 처리하고, ViewModel의 데이터를 관찰하여 UI 업데이트
(3) RVSearchAdapter : 검색 결과를 리사이클러뷰로 보여줌

 

 

1. SearchFragment.kt 변경

• UI와 직접적으로 상호작용하는 코드는 SearchFragment에 두고,
  데이터 처리와 비즈니스 로직은 뷰모델(SearchViewModel.kt)로 옮긴다.
• LiveData를 통해 데이터 변경을 감지하고 UI를 업데이트 한다.

 

class SearchFragment : Fragment() {
	..
    // 뷰모델 생성
    private val viewModel by viewModels<SearchViewModel> {
        SearchVideoViewModelFactory()
    }
    ..

• SearchFragment 상단에 위와 같이 뷰모델을 셋팅해둔다.

 

    private fun searchVideos(query: String) {
        lifecycleScope.launch {
            try {
                val searchItems = getSearchResults(query)
                searchAdapter.setItems(searchItems)
            } catch (e: Exception) {
                handleException(e) // 다양한 케이스의 예외처리를 위해 만듦
            }
        }
    }

    private suspend fun getSearchResults(query: String): List<SearchItems> {
        return withContext(Dispatchers.IO) {
            try {
                val response = NetworkClient.youtubeApiSearch.getSearchList(
                    key = NetworkClient.AUTH_KEY,
                    part = "snippet",
                    safeSearch = "strict",
                    type = "video",
                    maxResults = 1, // 데이터 아끼기 위해 일단 3개
                    query = query,
                    videoCategoryId = "15" // Pets & Animals
                )
                response.items
            } catch (e: Exception) {
                e.printStackTrace()
                emptyList()
            }
        }
    }
    
     private fun handleException(exception: Exception) {
        val errorMessage = when (exception) {
            is IOException -> "IO Exception 오류가 발생하였습니다."
            is HttpException -> {
                when (exception.code()) {
                    400 -> "Bad Request 오류 발생"
                    401 -> "Unauthorized 오류 발생"
                    404 -> "not found 오류 발생"
                    else -> "알 수 없는 오류가 발생하였습니다."
                }
            }

            else -> "알 수 없는 오류가 발생하였습니다."
        }
        Toast.makeText(requireContext(), errorMessage, Toast.LENGTH_SHORT).show()
    }

• 기존에 SearchFragment에서 사용했던 함수 중 위의 부분들은 모두 삭제한다.
• searchVideos : 해당 기능을 ViewModel로 이동하면, ViewModel에서 데이터를 로드하고 LiveData 를 통해 UI에 전달
• getSearchResults : 해당 기능을 ViewModel로 이동하면, ViewModel에서 네트워크 요청을 처리한다.
• handleException : 해당 기능을 ViewModel로 이동

 

override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)

		...
        setupObservers()
		...
    }
    
        private fun setupObservers() {
        viewModel.getSearchData.observe(viewLifecycleOwner) { searchItems ->
            searchAdapter.setItems(searchItems)
        }
        viewModel.errorMessage.observe(viewLifecycleOwner) { message ->
            Toast.makeText(requireContext(), message, Toast.LENGTH_SHORT).show()
        }
    }

• 옵저빙을 위한 함수를 만들어준다. 위의 searchVideos와 같은 함수가 필요하지 않은 이유다.

 

• searchVideos 로직이 프래그먼트에서 삭제되고 뷰모델로 옮겨갔으므로, 위와 같이 코드들을 적절히 수정해준다.

 

 

 

2. SearchViewModel.kt 변경

• 비즈니스 로직과 네트워크 요청을 ViewModel에 넣어 관리한다.
• 역시 LiveData를 사용하여 데이터와 UI간의 상호작용을 처리한다.

 

package com.limheejin.kidstopia.viewmodel

import ...

class SearchViewModel(private val repository: Repository): ViewModel() {
    private val _getSearchData: MutableLiveData<MutableList<SearchItems>> = MutableLiveData()
    val getSearchData: LiveData<MutableList<SearchItems>> get() =_getSearchData
    fun getSearchData(query: String) = viewModelScope.launch {
        _getSearchData.value = repository.getSearchVideoList(query).items
    }
}


class SearchVideoViewModelFactory : ViewModelProvider.Factory {
    private val repository = RepositoryImpl(NetworkClient.youtubeApiSearch)
    override fun <T : ViewModel> create(
        modelClass: Class<T>,
        extras: CreationExtras
    ): T {

        return SearchViewModel(
            repository
        ) as T
    }
}

• 팀원분이 공유해주셨던 뷰모델의 기본 틀은 위와 같다. 
  내가 필요한 SearchItems를 LiveData로 설정하고 받아올 수 있다.
• 뷰모델 팩토리가 필요하다. 왜 뷰모델 팩토리가 필요한지는 링크(클릭)에 나와있다.
  이렇게 만들어진 팩토리는 내가 불러오고자 하는 Activity/Fragment에서 초기 셋팅에 이용된다.

 

class SearchViewModel(private val repository: Repository) : ViewModel() {
    private val _getSearchData: MutableLiveData<MutableList<SearchItems>> = MutableLiveData()
    val getSearchData: LiveData<MutableList<SearchItems>> get() = _getSearchData

    private val _errorMessage: MutableLiveData<String> = MutableLiveData()
    val errorMessage: LiveData<String> get() = _errorMessage

    fun searchVideos(query: String) {
        viewModelScope.launch {
            try {
                val searchItems = withContext(Dispatchers.IO){
                    repository.getSearchVideoList(query).items
                }
                _getSearchData.value = searchItems
            } catch (e: Exception) {
                handleException(e)
            }
        }
    }
    
    private fun handleException(exception: Exception) {
        val errorMessage = when (exception) {
            is IOException -> "IO Exception 오류가 발생하였습니다."
            is HttpException -> {
                when (exception.code()) {
                    400 -> "Bad Request 오류 발생"
                    401 -> "Unauthorized 오류 발생"
                    404 -> "not found 오류 발생"
                    else -> "알 수 없는 오류가 발생하였습니다."
                }
            }

            else -> "알 수 없는 오류가 발생하였습니다."
        }
        _errorMessage.value = errorMessage
    }
    
    class SearchVideoViewModelFactory : ViewModelProvider.Factory {
    private val repository = RepositoryImpl(NetworkClient.youtubeApiSearch)
    override fun <T : ViewModel> create(
        modelClass: Class<T>,
        extras: CreationExtras
    ): T {

        return SearchViewModel(
            repository
        ) as T
    }
}

 

• 이제 기본 틀에서 코드를 내 상황에 맞게 적절히 수정한다.
• 에러 메시지 표시를 위해 위의 _getSearchData 구조와 맞게 _errorMessage를 생성해주었다.
• 아까 Fragment에 구현해놨었던 searchVideos 와 handleException을 뷰모델에 옮겨준다.
• 뷰모델 팩토리에서는 기존 틀에서 크게 수정할 것이 없었다.

 

3. RVSearchAdapter 변경

package com.limheejin.kidstopia.presentation.adapter

import ...

class RVSearchAdapter(
    private val onItemClick: (SearchItems) -> Unit,
    private val onLongClick: (Int) -> Boolean
) : RecyclerView.Adapter<RVSearchAdapter.MyViewHolder>(){

    private var items: List<SearchItems> = listOf()

    fun setItems(items: List<SearchItems>) {
        this.items = items
        notifyDataSetChanged()
    }

... 생략 ...

        fun bind(data: SearchItems) {
            with(binding) {
                searchitemTitle.text = data.snippet.title
                searchitemContext.text = data.snippet.description
                Glide.with(itemView.context)
                    .load(data.snippet.thumbnails.medium.url)
                    .into(searchitemThumbnail)
            }
        }
    }
}

• 리사이클러뷰 어댑터에서는 크게 변경할 점이 없지만, 사용하는 아이템이 SearchItems인 점에 유의한다.
• 밑에 데이터를 바인드 하는 부분이 프래그먼트나 뷰모델에 있어야 하는 게 아닌가 생각이 들었는데, 검색 결과 일반적으로 저렇게 리사이클러뷰 어댑터에서 데이터 바인딩을 처리하는 게 맞다고 한다.
  (1) 책임 분리 : 어댑터는 데이터와 UI 요소의 바인딩을 책임지며, 뷰모델은 데이터 로직과 UI 로직을 분리
  (2) 유지보수성 : 뷰홀더 클래스 내에서 뷰 바인딩을 처리하면, UI 관련 코드가 집중되어 있어 유지보수 쉬움
  (3) 성능 최적화 : 뷰홀더 패턴을 사용하여 뷰를 재사용하므로 성능 최적화
• Fragment나 ViewModel에서는 데이터를 준비하고 어댑터에 전달, 어댑터는 그 데이터를 UI에 바인딩

 

 

 

 

 

3. MainActivity에 설정된 Navigation 각 아이콘 클릭 시 Fragment 살리기

// 기존 코드
when (item.itemId){
	R.id.mnu_home -> {
		supportFragmentManager.beginTransaction().replace(R.id.fl, HomeFragment()).commitAllowingStateLoss()
		return true
}

// 수정 코드

override fun onNavigationItemSelected(item: MenuItem): Boolean {
        val fragmentTransaction = supportFragmentManager.beginTransaction()

        supportFragmentManager.fragments.forEach { fragment ->
            if (fragment.isVisible) {
                fragmentTransaction.hide(fragment)
            }
        }

        when (item.itemId) {
            R.id.mnu_home -> {
                val homeFragment =
                    supportFragmentManager.findFragmentByTag("HOME") ?: HomeFragment().apply {
                        fragmentTransaction.add(R.id.fl, this, "HOME")
                    }
                fragmentTransaction.show(homeFragment)
            }

            R.id.mnu_search -> {
                val searchFragment =
                    supportFragmentManager.findFragmentByTag("SEARCH") ?: SearchFragment().apply {
                        fragmentTransaction.add(R.id.fl, this, "SEARCH")
                    }
                fragmentTransaction.show(searchFragment)
            }

            R.id.mnu_user -> {
                val myVideoFragment = supportFragmentManager.findFragmentByTag("MY_VIDEO")
                    ?: MyVideoFragment().apply {
                        fragmentTransaction.add(R.id.fl, this, "MY_VIDEO")
                    }
                fragmentTransaction.show(myVideoFragment)
            }
        }
        fragmentTransaction.commitAllowingStateLoss()
        return true
    }

• 기존에 단순히 replace로 Fragment를 죽이며 옮겼던 방식을, 모두 show(), hide()의 방식으로 변경하였다.
• 프래그먼트를 옮겨다녀도 검색 결과와 위치가 살아있게 되었다.

 

 

 

 

 

---

 

 

💭 Retrospect

이제껏 진행된 팀프로젝트 중에서 다른 요소는 다 차치하고, 기능 구현과 코드를 짜는 영역에선 제일 열심히 하고 있는 것 같다. 이번 기능을 구현하면서 제일 많이 배우고 있고, 헷갈렸던 이론과 구조들(MVVM, 네트워크, API, Fragment 간의 데이터 전달 등)을 이번 주 내내 계속 복습하니 자연스레 이해가 되고 있다. 재밌고 좋다. 다른 팀원분을 도와줄 수 있는 데서 기쁨을 느낀다.

​