[안드로이드] 퀴즈 어플 소개 및 DB 설계

Junyoung Park·2021년 12월 27일
2

ToyProject

목록 보기
1/11

# Hello, Kotlin

우리 학교 문과대를 전공으로 삼는 학생은 졸업 요건을 충족시키기 위해 '한자 시험'을 쳐야 한다. 외부 한자 급수가 있다면 상관없지만, 나처럼 영어보다 한자가 더 낯선 학생은 울며 겨자먹기로 학교에서 주관하는 한자 시험을 치러야 한다.

코로나 이전에는 특강으로, 코로나 시기에는 기출 문제를 중심으로 문제를 내기 때문에 막상 공부를 한다면 그렇게 어렵지는 않다. 하지만 학교 측에서 제공하는 기출 문제 답안지는 정말로 친절하지 않기 때문에, 모르는 한자를 일일이 검색하거나 틀린 부분을 알아내 오답노트를 만들어야 한다는 불편함이 있다.

학기 중 한자 시험을 치르려고 오답노트를 만들고 있으니 불편하기 그지 없었다.

유형별로 문제를 내서 어디에서 틀렸는지 자동으로 보여주는 어플이 있으면 좋겠다!

어쩌면 내게는 더 이상 필요하지 않은(한자 시험은 이미 통과했기 때문에) 이 어플에 도전하게 된 이유는 다음과 같다.

1. 어플에 대한 충분한 수요

한 번 '도전'해보는 어플이지만, 나름대로 다른 사람들이 직접 사용 가능한 어플을 구현해보고 싶었다. 사실 과제로 구현한 프로젝트는 대부분 나 혼자만 보고 다시 켜지 않는 게 대부분일텐데, 한자 시험 어플은 지금도 종종 에브리타임 같은 곳에서 족보를 살 정도로 일종의 '틈새 시장', 수요가 있는 분야다. 무료로 다양한 사람들의 피드백을 받을 수 있는 좋은 기회다.

2. Kotlin에 익숙해지는 기회

모바일 어플 개발에 있어서 양대 산맥 중 하나인 안드로이드 네이티브 언어, 코틀린을 접해보고 싶었다. 사실 위 한자 퀴즈를 플라스크와 같은 프레임워크를 사용한 웹을 통해서도 구현할 수 있지만, 그러려면 웹을 계속 열어놔야 한다는 단점이 있었고, 개인적으로도 평상시 생각지도 못한 모바일 언어를 다뤄보고 싶다는 생각이 들었다. 안드로이드와 iOS 가운데 고민했고, 하이브리드 언어를 써볼까, 라는 생각도 들었지만 모바일 프로그래밍 자체가 처음이니 네이티브, 그 중에서 유명한 코틀린을 사용해보고 싶었다.

3. DB 사용을 복습한다.

퀴즈에 사용할 한자 정보를 데이터베이스를 활용해 다루면서, 동시에 유저 점수 등을 저장하는 기능도 구현할 계획이다. 간단한 기능인지라 이번 학기 배운 데이터베이스를 가볍게 복습하는 차원에서라도 좋은 선택이라 생각한다.

Planning


자, 그러면 어디서부터 시작할까? 일단 먼저 코틀린 입문 책(이것이 안드로이드다 with 코틀린), 유튜브, 구글링 등 배우면서 동시에 코드를 짜면서 구현하려 한다. 기본적인 문법과 구조만 파악하고 다른 퀴즈 어플 소스를 훑어보면서 참고할 예정이다. 여력이 충분하다면 Git의 오픈 소스 코드를 잘 활용해 좀 더 깔끔한 레이아웃, 스타일을 주고 싶다.

Mindmap

퀴즈 어플을 만들어 기출/유형별로 채점하고, 틀린 문제를 오답 노트에 추가해 확인할 수 있도록 하자. 점수도 기록해서 합격 정도에 가까운지 눈으로 보이게 하자!

어플에 대한 윤곽은 대략 이랬고, 만들기로 한 친구와 함께 이를 어떻게 구현할지 이야기를 나눠보았다.

흠, 그런데 생각보다 기존의 생각을 수정하는 부분도 적지 않았다. 가령 1). 로그인 유무 2). 유형별 관리 방법 3). 사용 방법 스와이프 형식으로 알리기 등 어플의 근본적인 특징까지 달라지진 않았지만 소소히 다른 부분들이 없지 않았다. 아래는 나누던 이야기를 방향에 상관없이 그려본 마인드맵이다.


Question types

기출 문제 예시는 다음과 같다.

즉, 100문제이지만 동일한 유형이 아니다. 6개 정도의 유형으로 나뉘는 이 기출 문제를 기준에 따라 두 가지로 분류했고, 이를 테이블로 표현했다.
대체적인 테이블의 어트리뷰트와 문제 유형을 연결하자면 다음과 같다.


DB ERD

"ERD가 너무 간단한데?"

DB 수업 때 공부한 것처럼, 스키마 다이어그램을 짜기 전 ERD를 통해 전체적으로 데이터를 어떻게 관리할지 그려보았다. 사실 본 어플의 기능은 매우 간단한지라 문제/정답/기록이면 충분하다! (로컬 환경에서 어플을 사용하는 까닭에 전체 유저를 관리할 필요도 없다) ERD에서 사용하는 엔티티와 릴레이션십은 다음과 같다.

Question1

  • 매우 간단한 유형(총 5가지)을 한꺼번에 관리하는 테이블이다. 따라서 문제와 정답, 보기를 한꺼번에 저장한다.

Question2(1, 2, 3)

  • 다소 복잡한 유형으로, 큰 지문 박스를 공통적으로 다루는 문제 4~6개가 들어간다. 따라서 지문 박스는 이미지화하여 담아두고, 하위 문제가 이를 가리키고, 문제에 해당하는 보기 정보를 담은 테이블로 분리했다.

Review

  • 사용자가 문제를 풀었을 때 택한 답안이 문제가 함께 제공한 정답과 일치하지 않을 때 자동으로 Review, 즉 오답 노트에 추가된다. 이때 시험 회차와 문제 번호만 안다면 내 오답과 함께 SELECT할 수 있는 최소한의 정보만 테이블에 저장한다. 이때 'date' 어트리뷰트를 통해 같은 문제, 같은 오답으로 틀린 경우도 구분할 수 있도록 구현했다.

DB Schema Diagram

ERD와 뭔가 다르다?!

사실 ERD와 스키마 다이어그램이 다소 다른 게 일반적이지만, 스키마 다이어그램에서 Review 테이블을 두 개 사용할 줄은 ERD를 그릴 때 생각조차 못하고 있었다. 그런데 생각해보니, 문제 유형이 다른 테이블을 두 개 만들었으므로 외래키로 참조할 때 하나만 지정해야 했다!

결국 Review 테이블을 한 개 더 추가해서 오답노트를 열 때 합치자는 생각이 떠올랐다. 이 밖에도 Review2(즉 지문 박스가 있는 문제의 기록을 위한 테이블)가 referencing하는 테이블이 소소하게 Question2_2에서 Question2_3으로 관리를 위해 바뀌기도 했다.

Question1

  • ERD에서의 역할과 달라지지 않았다.

Question2(1, 2, 3)

*사실 3 → 2 → 1 순으로 상속한다고 봐도 되는데, 데이터 조작의 편의를 위해 중복값을 남겨두었다(시험 회차 및 유형 번호, 순서 등).

Review(1, 2)

*1번째 기록이 Question1을, 2번째 기록이 Question2만을 관리한다.

Plus

*유저가 임의로 정할 닉네임은 데이터베이스가 아니라 shared preference를 통해 저장하기로 했다. 어플을 처음 켜거나 Review를 확인하는 창에서 수정 가능하도록 구현하자. 또한 기출 별 점수를 확인하는 score 기능은 따로 데이터베이스 테이블을 통해서보다는 shared preference를 통해 구현한다(구현 도중 변경 가능).


Algorithm Flow

위 알고리즘 플로우 차트를 풀어 쓰자면 다음과 같다.

문제 풀기

유형별 문제 풀기

  1. 유형별 선택 (총 6개 유형, Question1 → 유형1~5, type 어트리뷰트를 통해 구별 가능, Question2 → 유형6, type 어트리뷰트를 통해 구별 가능)
  2. 랜덤으로 유형별 10문제 선정, 문제를 푼다(답안을 제출할 때에만 채점 가능). + 문제를 풀면서 헷갈리거나 어려운 문제는 오답 노트로 곧바로 옮길 수 있다.
  3. 정답과 비교, 즉 채점을 통해 틀린 문제를 오답 노트로 옮긴다.

기출 문제 풀기

  1. 기출 회차 선택 (총 5개 존재, 각 기출 문제 당 100문제)
  2. 정해진 순서대로 문제를 푼다. + 문제를 풀면서 헷갈리거나 어려운 문제는 오답 노트로 곧바로 옮길 수 있다.
  3. 정답과 비교, 즉 채점을 통해 틀린 문제를 오답 노트로 옮긴다.

리뷰

오답 노트

  1. 틀린 문제(자동으로 로드) 및 선택 문제(임의로 로드)를 확인할 수 있다.

점수 확인

  1. 기출별 점수를 기출 회차별로 확인할 수 있다.
  2. 평균을 통해 한자 시험에 충분히 합격 가능한지 여부를 확인한다.

기타

닉네임 변경

  1. 어플 초기 구동 시 닉네임을 입력할 수 있는 화면이 있다(입력 이후 다시 뜨지 않도록 설정).
  2. 리뷰 칸의 닉네임을 클릭해 닉네임을 수정할 수 있다.

사용법 확인

  1. 어플 초기 구동 시 닉네임 입력 이후 기본적인 어플 사용 방법을 스와이프로 넘기며 확인할 수 있도록 한다.
  2. 체크박스를 통해 다시 뜨지 않도록 한다(디폴트는 체크 박스 해제).

Layouts

마지막으로 어플 레이아웃 설계도를 그려보자. 대략 6~7 종류 정도면 충분할 것 같다.


이렇게 대체적인 설계가 끝났다! 아마 언어에만 익숙해지면 금세 어플을 구현할 수 있으리라 생각한다. 어느 정도 경과가 지나면 다시 만나요!

profile
JUST DO IT

0개의 댓글

관련 채용 정보