[Android/오르다] 오르다 다이어리 레거시 리팩토링 01 - 현재 코드 분석

📌 오르다 다이어리 레거시 리팩토링 01 - 현재 코드 분석

https://yujinius45.tistory.com/154

[Android/오르다 다이어리] 오르다 다이어리 리팩토링 - 계획 수립

 

▲ 이전 글에서는 오르다 다이어리의 리팩토링 계획을 정리했다. 이번 글에서는 현재 코드가 어떤 문제를 가지고 있으며, 이를 개선하기 위해 어떤 방향으로 리팩토링할 것인지 분석한 내용을 정리한다.

---

📌 오르다 다이어리 v1.0.0 주요 기능

대략적으로 위와 같이 4가지의 기능이 존재한다.

오르다 다이어리는 일정 관리, 일기 작성, 알람, 지도 메모 기능을 제공하는 다기능 다이어리 앱이다. 사용자가 일상 기록을 보다 편리하게 관리할 수 있도록 설계되었다.

🗓️ 일정 관리 (To-Do List)

• 캘린더에서 일정 확인 및 관리
• 사용자가 입력한 일정 목록을 내장 DB(SQLite)에 저장
• 일정 추가/수정/삭제 기능 제공
• RecyclerView를 활용한 일정 목록 UI 구성

📖 일기장 기능 (Diary)

• 사진 추가: 카메라 촬영 또는 갤러리에서 이미지 첨부
• 음성(STT) 지원: 음성 입력으로 빠르게 일기 작성 가능
• 텍스트 입력: 키보드 타이핑을 통한 일기 작성 지원
• 내장 DB(SQLite) 저장: 영구적으로 데이터 저장 가능

⏰ 알람 기능 (Alarm)

• 지정한 시간에 알람 설정 가능
• 플래시 & 사운드 알람: 알람이 울릴 때 플래시와 음악이 함께 재생
• 가속도 센서를 활용한 알람 해제
  • 단순한 버튼 클릭이 아닌 핸드폰을 일정 강도로 흔들어야 알람이 해제됨 (가속도 센서 활용)

🗺️ 지도 기반 메모 기능 (Map Memo)

• 지도(Google Maps)를 활용한 특정 위치에 메모 추가 가능

💾 내장 DB(SQLite) 기반 데이터 저장

• 일정, 일기, 알람, 지도 메모 등 모든 데이터를 영구 저장
• SQLiteOpenHelper를 활용하여 데이터 관리
• 앱을 종료해도 데이터 유지

---

🔍 현재 코드의 특징 및 분석

📅 프로젝트 이야기

오르다 다이어리는 3년 전 개발된 Java & XML 기반의 레거시 코드로, 현재의 Android 개발 트렌드와는 다소 거리가 있는 구조를 가진다.

당시에는 Android Jetpack이나 AAC(Android Architecture Components)와 같은 최신 기술을 적용하지 않고, Activity 중심의 화면 전환과 SQLite 직접 접근 방식을 사용했다.

 

💡 현재 코드에서 발견된 주요 사항

1️⃣ AAC 미적용 (Jetpack Architecture 미사용)

• 현재 프로젝트는 AAC(Android Architecture Components)를 전혀 활용하지 않고 있다.
• ViewModel, LiveData, RoomDB 등의 개념이 적용되지 않았으며, Activity에서 직접 데이터베이스에 접근하거나 UI 상태를 관리하고 있다.
• 현재의 안드로이드 개발 방식에서는 AAC를 활용한 구조적 개선이 필수적이다.

2️⃣ 모든 화면이 Activity 기반으로 구현됨

• 현재 모든 주요 기능이 Activity 단위로 구현되어 있다.
• 화면 이동 시 Intent를 통해 데이터를 주고받으며, 각 Activity가 독립적으로 동작하도록 설계되었지만, 그로 인해 화면 간 상태 유지가 어렵다.
• 예를 들어, 일정 관리 화면에서 일기 작성 화면으로 이동하려면 뒤로 가기를 눌러 홈 화면을 거쳐야 하는 불편함이 있다.
• 해결 방향:
  • Fragment를 활용하여 화면을 전환하고, Navigation Component를 적용하여 보다 자연스러운 화면 이동을 구현한다.

3️⃣ UI 상태 관리 문제 (Configuration Change 미대응)

• 화면 회전(Configuration Change) 시 일부 화면의 UI 상태가 유지되지 않는다.
• 확인된 문제점:
  • 일정 화면(캘린더)에서 화면을 회전하면, 선택한 날짜가 초기화된다.
  • 지도 화면에서는 회전 시 저장된 메모가 사라진다.
  • 일기 작성 화면은 회전하면 입력 중이던 내용이 손실된다.
  • 반면, 일기 목록 화면에서는 데이터가 유지된다.
• 원인:
  • 상태 저장 로직이 대부분 적용되지 않았다.
  • Activity 간 이동이 Intent를 통한 데이터 전달 방식이므로, 화면이 재생성되면서 데이터가 유지되지 않는다.
• 해결 방향:
  • ViewModel과 LiveData를 적용하여 UI 상태를 유지하고, 회전 시에도 데이터가 보존되도록 개선한다.

4️⃣ SQLite 직접 접근 방식 사용 (RoomDB 미적용)

• 현재 프로젝트는 SQLiteOpenHelper를 활용하여 SQL 쿼리를 직접 작성하여 데이터베이스를 관리한다.
• 문제점:
  • SQL 쿼리가 직접 코드에 포함되어 있어 가독성이 낮고, 유지보수가 어렵다.
  • 데이터 접근 로직이 UI 코드와 섞여 있어 관심사 분리가 되지 않은 구조이다.
• 해결 방향:
  • RoomDB를 적용하여 ORM(Object Relational Mapping) 방식으로 변경한다.
  • DAO(Data Access Object) 패턴을 적용하여 데이터 관리 로직을 분리하고, Repository 패턴을 도입한다.

5️⃣ ViewModel 및 MVVM 미적용

• 현재 Activity에서 UI 로직과 데이터 로직이 섞여 있다.
• ViewModel을 활용하여 UI 데이터를 관리하지 않으며, Activity가 종료되면 데이터가 모두 사라지는 구조이다.
• 해결 방향:
  • ViewModel을 활용하여 UI 데이터를 관리하고, LiveData를 통해 UI와 데이터의 의존성을 낮춘다.
  • MVVM 아키텍처를 적용하여 유지보수성을 높인다.

---

🎯 리팩토링 방향 정리

문제점	현재 방식	개선 방법
AAC 미적용	Jetpack 미사용	AAC(ViewModel, LiveData, RoomDB) 적용
Activity 기반 구조	모든 화면을 Activity로 관리	Fragment + Navigation Component 적용
UI 상태 미유지	DB에서 데이터를 불러와 바로 표시	ViewModel, LiveData 활용하여 상태 유지
DB 직접 접근	SQLiteOpenHelper 사용	RoomDB + DAO 패턴 적용
비효율적인 UI 로직	Activity 내 UI 및 데이터 로직 혼재	MVVM 패턴 적용하여 관심사 분리

---

✅ 다음 목표: UI 상태 관리 개선

이제 첫 번째 리팩토링 작업으로 UI 상태 관리를 개선하는 작업을 진행할 예정이다.

• 화면 회전 및 Activity 재생성 시 데이터가 유지되도록 ViewModel과 LiveData를 적용한다.
• 기존의 Intent 기반 화면 전환 구조를 Fragment로 변경하고, Navigation Component를 적용한다.

다음 글에서는 UI 상태 유지 문제를 해결하기 위한 접근법과 구현 방안을 다룰 예정이다. 🚀