우여곡절 끝에, 퀴즈 어플을 완성했다. 이전 포스팅 이후 추가한 기능은 리사이클러뷰에 띄운 특정 아이템으 선택 시 화면 및 실제 DB에서 삭제하는 기능이다. 이 외에도 DB에 기록된 점수를 곧바로 액티비티에 연결된 프래그먼트 화면에 곧바로 갱신할 수 있도로 구현했다.

Recyclerview

리사이클러뷰 아이템 레이아웃은 다음과 같다. 이 아이테믈 담은 여러 홀더들이 내가 입력한 데이터 순서대로 기입되어 스크롤 형태(그리드이든, 리니어이든)로 펼쳐진다.

내가 선택한 아이템 삭제 방법은 다음과 같다.

1. 버튼을 통해 어떤 데이터를 담은 홀더가 선택되었는지 알 수 있다.
2. 데이터의 프라이머리 키 정보를 사용해 DB 상에서 실제 아이템을 삭제한다.
3. 어댑터에 준 데이터 상에서 그 데이터를 지운다.
4. 위치 정보를 갱신해야 하므로 notifyItemRemoved 및 notifyItemRangeChanged를 사용한다.

• 전자는 스크롤 상에서 그 아이템을 담은 홀더를 없애주며, 후자는 그 홀더가 사라진 위치 정보를 갱신하기 위해 각자 위치 정보 및 전체 데이터의 길이를 입력받는다.

holder.itemView.question_del.setOnClickListener {
            val test_num = question.test_num
            val number = question.number
            holder.itemView.question_choice1.setBackgroundColor(Color.WHITE)
            holder.itemView.question_choice2.setBackgroundColor(Color.WHITE)
            holder.itemView.question_choice3.setBackgroundColor(Color.WHITE)
            holder.itemView.question_choice4.setBackgroundColor(Color.WHITE)
            Log.d("item view del", "리사이클러뷰 아이템 삭제")
            val db_helper = DBHelper(context as Context)
            db_helper.delete_review(question.type!!, question.test_num!!, question.number!!)
            listData.remove(question)
            notifyItemRemoved(position);
            notifyItemRangeChanged(position, listData.size)
        }

이렇게, 퀴즈 어플을 사용하는 데 필수적인 '문제 풀이', '채점', '오답 노트', '점수' 기능이 모두 완성되었다!

부족한 점

위 기능을 최대한 정성스럽게 구현하고자 노력했지만, 코틀린 초보로서 이상에 비해 부족한 점이 적지 않았다. 다음은 지금 생각해볼 때 "좀 더 다른 식으로 접근했으면 어땠을까?" 라는 생각이 드는 부분이다.

1. DB 설계

처음에 문제 유형별로 다르게 DB를 설계했고 이를 담을 클래스를 만들어 데이터를 저장/반환했는데, 클래스 하나에 담을 정보가 매우 많았기에 더 '나누었다면' DB 구조적으로는 보다 효율적으로 되었을 것 같다. 예를 들어 question2_1, question2_2 상에서 설계한 내 기준으로 좀 편안하게 하기 위한 중복 데이터 정보(type, order 등)를 기록했는데, 외래키 참조에서 보다 minimal한 어트리뷰트만을 사용할 수도 있었으리라 생각한다.

2. 리사이클러뷰

사실 본 어플의 핵심인 '문제 풀이'와 '채점', '오답 노트'를 구현하는 데 모두 사용되는 가장 중요한 부분이다. 어댑터에 전달한 데이터를 동일한 홀더에 담겨 연결되는 리사이클러뷰를 사용한 데에는 잘 한 선택이라 생각한다(중복 아이템이 많고, 리스트뷰보다 효율적이므로).
하지만 삭제 및 갱신(즉 바로 위에서 구현한 기능)을 할 때 생각한 만큼 부드러운 연동이 되지 않아 타협할 수밖에 없었다. 즉 삭제가 이루어진 뒤 '곧바로' 그 자리를 채우는 기능이 깔끔하게 되지 않았는데, 연속적인 데이터 삭제를 할 때 특정 값을 표시해놓은 텍스트 배경 색깔이 뒤섞이는 등 지금까지도 왜 그런지 알 수 없는 에러가 생겼다.
또한 아이템을 펼치는 효과를 주기 위해 그 홀더 내 특정 레이아웃을 VISIBLE로 했는데, 이 '펼침' 기능 역시 매끄러운 자리 배치가 되지 않아서 애초부터 넉넉한 간격을 사용할 수밖에 없었다. 자동으로 매칭이 되는 형식이 모든 휴대폰에서 잘 사용할 수 있을 텐데, 다음에 리사이클러뷰를 사용할 때에는 이 기능을 확실하게 하도록 해야겠다.

3. 레이아웃 디자인

모바일 어플 개발에서 특히 레이아웃의 중요함을 실감했다. 사실상 리니어 레이아웃을 사용한 글자 및 배치에 아직까지 익숙하지 않아서 억지로 이전에 만들어놓은 카드 뷰를 몇 번이고 재사용하는 등 곤혹스러움을 겪어야 했다. 또한 글자 크기가 달라져도 고정값을 유지해야 하는데, match_parent를 사용했을 때 매우 밀려나는 현상으로 인해 margin을 사용하느라 어떤 홀더에서는 이미지 버튼이 좀 가려진 경우까지 일어났다.

깨달은 점

반면 어플을 만들며 배운 점은 다음과 같다.

1. '코틀린'이라는 언어

자바와 완벽하게 혼용 가능한 코틀린의 힘을 느꼈다. 물론 자바로 구현한 소스 자체가 매우 많기 때문에 인터넷을 통해 찾을 수 있는 정보는 한정적이었지만, 앞으로는 보다 더 많아지리라 생각한다. 나는 구현의 용이함을 위해 (지금은 코틀린에서 지양하라고 말하는) extensions를 도입했는데, 다음에는 View-Binding 기능을 더 적극적으로 사용하고 싶다.

2. 모바일 어플

물론 코틀린이라는 언어 자체가 모바일 어플을 개발하는 언어라는 점에서 1번과 비슷하지만, 처음으로 웹이 아니라 모바일 쪽 언어를 사용해보았다. 심지어 자바도 모르는 상황이었기 때문에 오히려 C를 사용하는 맥락을 떠올리면서 코틀린을 사용했는데, 클래스 개념이 흥미롭게 다가왔다(사실 지금까지 애매한 부분도 많지만).
지금 생각해보면 안드로이드만 사용할 수 있는 어플을 만들어 iOS 수요는 놓쳤다는 안타까움도 있지만, 네이티브 언어를 사용해 어플을 개발하는 좋은 경험이 되었다. 이후 리액트 네이티브 또는 스위프트를 통해 iOS에도 제공 가능한 어플을 만들고자 한다(그 어플이 과연 이 퀴즈 어플이 될 지는 아직 모르겠지만).

• 다음은 어플 사용 영상이다.