[2주차/필수과제] Single Activity Architecture를 적용하며 느낀점을 나눠주세요.

[jihyunniiii]

🎤 토론 과제 - Single Activity Architecture를 적용하며 느낀점을 나눠주세요.

여러 개의 Activity를 이용하여 앱을 구현했을 때와 Single Activity Architecture를 적용하며 앱을 구현했을 때의 장단점이 무엇이라고 생각하는지 말씀해주세요. 또, 각 방법을 통해 앱을 구현하며 어떤 것들이 어려웠고 어떻게 해결했는지 여러분들의 경험을 들려주세요!

[boiledEgg-s]

여러 개의 Activity를 사용한 경우, 화면마다 책임분리가 명확해진다고 생각합니다.
또한 Intent를 통해 화면 전환 및 화면 간 데이터 전달이 가능합니다.
하지만 Activity는 메모리를 많이 차지하기 때문에 너무 많이 사용하면 앱이 무거워진다는 단점이 존재합니다.

이러한 문제를 해결하기 위해 Single Activity Architecture가 등장하였습니다.
하나의 Activity 위에 프래그먼트 혹은 컴포저블을 쌓아 앱을 만드는 방식으로, 액티비티를 하나만 사용하기 때문에 메모리가 적게 사용됩니다. 이로 인해 앱의 속도도 향상됩니다.

하지만 SAA에선 navigation을 통해 화면 간 전환을 구현해야 하기 때문에 난이도가 기존 방법보다 높다는 단점이 존재합니다.

저는 하나의 액티비티 위에 Jetpack Navigation를 사용하여 화면 전환 및 데이터 전달을 구현해봤는데, 구현하면서 어려웠던 것은 바로 “스택관리”입니다.
navigation의 스택관리, 전환 애니메이션과 같은 설정은 NavOption이라는 클래스로 구현합니다. 이 클래스는 화면 전환 시 액션을 부여하는 클래스라고 하네요.

예를 들어 로그아웃을 거쳐 로그인 화면으로 이동한 경우, 뒤로 가기를 누르면 앱이 바로 꺼져야 합니다. 이 문제는 NavOptions의 popUpTo 함수와 inclusive 속성을 통해 해결했습니다.

navOptions {
      popUpTo(0) { inclusive = true }
}

또 다른 예로, 바텀바를 사용한 화면 전환의 경우, 어느 화면 버튼을 누르든 백버튼을 클릭하면 홈화면으로 돌아오고 홈화면에서 다시 백버튼을 누르면 앱이 종료되도록 하고 싶었습니다. 이러한 기능을 구현하기 위해 NavOptions의 popUpTo(Home)과 launchSingleTop 속성을 사용하였습니다.

navOptions {
      popUpTo(Home)
      launchSingleTop = true
}

[gitsuhyun]

여러 개의 Activity를 이용하여 앱 구현
장점 : 각 화면이 Activity로 분리되어 있어 독립적이고 역할이 명확하게 구분됩니다.
단점 : 앱이 무거워집니다. 태블릿 PC와 같이 다양한 크기를 가진 디바이스의 UI를 표현하는 것이 어렵습니다.

Single Activity Architecture 적용
장점 : 여러 개의 Activity를 이용했을 때보다 앱이 가벼워집니다. Jetpack Navigation 사용을 통해 화면 전환 기능을 쉽게 사용할 수 있습니다.
단점 : SAA 구조를 처음 접해보는 사람에게는 러닝 커브가 높을 수도 있습니다.

나의 경험

• 여러 개의 Activity 이용
  여러 개의 Activity와 Fragment를 섞어서 사용해 본 경험이 있습니다. 이 때, 화면을 전환할 때 Activity -> Fragment / Fragment -> Activity 등 각각의 경우 데이터를 어떻게 전달하는지 매번 찾아봐야 했기 때문에 불편함을 느꼈습니다. 따라서 이후에는 Activity 사용을 줄이고 Fragment로 최대한 뷰를 구성하여 AAC viewmodel을 적용하여 데이터 전달을 좀 더 편하게 하고자 하였습니다.
• SAA 적용
  이번 과제를 통해 SAA 구조를 적용하며 어려웠던 점은 composable의 route 관리입니다. Activity로 구현한 화면을 컴포저블 함수로 리팩토링 한 뒤 빌드 하였더니 해당 화면이 띄워질 때마다 오류가 발생하였습니다. 알고보니 composable 함수에 전달한 route에 오타가 있어서 생긴 문제였습니다. 이에 좀 더 효율적인 화면 관리를 위해 sealed class Routes를 생성해 화면의 route를 관리해주었습니다.

sealed class Routes (val screen: String){
    object SignUp: Routes("signup")
    object Login: Routes("login")
    object Home: Routes("home")
    object Search: Routes("search")
    object My: Routes("my")
}

[ThirFir]

여러 개의 Activity를 사용할 경우, 각 화면의 역할 분리가 용이해지고 앱 구조가 간단해집니다. 새 화면이 추가될 경우 기존의 화면은 크게 신경쓰지 않고 새 액티비티에 대해서만 작성하면 되므로, 확장이 쉬워진다는 장점이 있습니다.
하지만 액티비티는 메모리를 많이 소모하므로, 그 수가 늘어날수록 메모리 사용량은 증가하고, 이는 전체적인 앱 실행 중 퍼포먼스의 감소로 이어질 수 있습니다.

Single Activity Architecture는 하나의 액티비티만을 이용한다는 점에서, 앱의 메모리 점유를 줄이고 퍼포먼스를 향상시킬 수 있는 것이 큰 장점입니다.
제가 SAA를 적용하면서 특히 크게 느낀 장점은 바로 모든 Navigating을 중앙에서 관리할 수 있다는 점이었습니다. 따라서 테스트가 용이하였고, 코드 작성에서 일관성을 챙길 수 있었습니다.
단점은 Multi Activity에 비해 진입 장벽이 높은 것과 잘못된 상태 관리는 불필요한 자원 점유로 이어질 수도 있겠다는 것 정도로 생각해 볼 수 있을 것 같습니다.

제가 SAA를 적용해보면서 어려웠던 점은 외부에서 앱의 특정 화면을 실행시키는 경우였는데, 만약 Multi Activity였다면 intent-filter를 적용하는 것으로 쉽게 이루어냈을 것이지만, Single Activity의 각 화면들은 Intent에 의해 컨트롤되지 않으므로, 외부에서의 실행을 수동으로 컨트롤해주어야 했습니다. 따라서 외부에서 앱을 실행시킬 때 보내주는 arguments들을 Activity에서 받아서 어떤 화면을 실행시키려는 건지 판별하여 Fragment까지 직접 navigating을 해주는 것으로 구현했었습니다.

[tunaunnie]

1. 여러 개의 Activity를 이용하여 앱을 구현했을 때

• 장점: 각 페이지가 각각 독립적인 생명 주기를 가져서 상태를 관리하기 편리합니다.
• 단점: Activity 사이에 데이터를 전달할 때 Intent를 사용해야 해서 불편합니다.

2. Single Activity Architecture를 적용하며 앱을 구현했을 때

• 장점: 여러 개의 Activity를 사용하여 화면 전환을 구현했을 때보다 각 화면 사이의 경계가 흐립니다. 그래서 화면 전환이 많아져도 중앙에서 (MainActivity) 상태를 관리하기 용이합니다.
• 단점: 처음 배웠을 때 진입 장벽이 높습니다....
  (@serializable을 적용한 data object나 class가 전달이 안 되기도 하던데 원래 지원이 안 되는 경우도 있나요......?)

3. SAA 구조를 적용해 보면서 어려웠던 점 : 부르는 Screen의 인자를 잘 맞춰주지 않아서 화면 전환은 되는데 empty screen으로 넘어가져서 문제를 찾느라 시간을 많이 허비했습니다. 하지만 잘만 익히면 여러 개의 액티비티를 사용하는 것보다 훨씬 효율적이고 간결할 것 같아 앞으로도 계속 적용해보면서 익숙해져가고 싶습니다😊

[HAJIEUN02]

여러 개의 Activity를 이용해서 구현하는 경우 단순하고 구조가 명확해 이해가 쉬웠습니다. 각 Activity가 필요할 때만 로드되도록 스택 관리만 해주면 되기 때문에 메모리 관리도 비교적 쉬웠습니다.
하지만 액티비티간 전환 시 새로 인스턴스가 생성되기 때문에 사용자 경험적으로나 비용적으로나 SAA에 비해 불리한 부분이 있습니다. SAA를 이용하는 경우 상태 관리를 통한 데이터 전달이 용이합니다. 다만 구조가 복잡하고 메모리가 잘 지워지고 있는지 확인하기 어렵습니다.

이번 과제를 수행하면서 NavGraph, NavController나 NavHost 등 개념적으로는 공부했지만 구현하려고 하니 쉽지 않았습니다. 얼른 익숙해져서 SAA의 신이 되어보겠습니다,,🥹
이번 과제에서 가장 시간을 많이 잡아 먹은 건 바로 인자를 잘못 쓴 걸 발견하지 못하고 화면이 전환되지 않아 처음부터 다시 로직을 하나하나 읽어보느라 3시간이 넘게 걸린 건데요. 각 Screen마다 갖고 있어야 하는 Navigator 구현 시 어차피 다 비슷비슷해서 복사 붙여넣기하고 이름만 바꾸는데, 앞으로는 이러지 말아야겠다는 다짐을 했습니다..

[wjdrjs00]

여러 Activity를 이용하는 방식:

• 각 화면을 하나의 Activity로 구현하여, 다른 Activity에 대한 영향없이 독립적으로 관리할 수 있다는 장점이 있습니다. 하지만, Activity 전환 시 새로운 인스턴스를 생성, 파괴하는 과정에서 메모리 할당 및 해제가 이루어져 성능에 영향을 준다는 단점이 있습니다.
• 여러 Activity를 이용하는 방식은 지난주차 과제에서 처음 접할 수 있었는데, registerForActivityResult와 Intent를 활용하여 해결한 Activity간 데이터를 전달하는 방법이 어려웠던거 같습니다.

Single Activity Architecture 방식:

• 하나의 Activity만을 사용하기에 여러 Activity를 사용하는 방법보다 메모리 관리가 효율적이라는 장점있지만, SAA에서 화면 전환을 위해 사용하는 jetpack navigation이 어렵다는 단점이 있습니다..
• saa를 위해 이번주 과제에서 jetpack navigation을 활용했는데, 화면 전환 과정에서 앱이 꺼지는 문제가 발생했습니다. 알고보니 인자의 초기값을 지정하지 않아 직렬화 과정에서 오류가 발생하는것이 원인이였던거 같습니다. 이전까지는 서버에서 받은 값이 있어 발견해지 못했던 부분이였는데, 이번 과제를 통해 문제점을 확인할 수 있었고 초기값을 설정해서 해결가능했습니다.

[serioushyeon]

여러 Activity사용 시에는 각 액티비티가 독립적이므로, 화면 전환과 관리가 상대적으로 단순하고, 독립된 생명주기를 가지므로, 각 화면별로 구체적인 라이프사이클을 쉽게 관리할 수 있습니다.
하지만 액티비티 간 전환 시에 화면이 재생성되고 메모리가 다시 로드되면서 성능적인 부하가 발생할 수 있으며 앱이 커질수록 액티비티의 개수가 많아져 코드가 복잡해지고 유지보수에 어려움이 생길 수 있습니다.

Single Activity Architecture(SAA)사용 시 모든 화면을 하나의 Activity 안에서 관리하므로 코드 구조가 단순해지고, Fragment나 Compose의 재사용성이 높아져 유지보수가 쉬워집니다. Fragment나 Compose 전환은 Activity 전환보다 가볍기때문에 성능이 개선됩니다.
하지만 처음 배우는데 진입 장벽이 있습니다.. 설계를 더 꼼꼼히 해주어야 한다는 생각이 들었습니다.

어려웠던 점, 트러블 슈팅:
compose로 saa 적용이 처음이고 type-safe navigation방식으로 구현하려다 보니 관련 자료를 찾아보는데에 상당한 시간을 보냈습니다. 깃허브에 여러 repository를 검색 하면서 참고하면서 구현했습니다... 화면만 전환하는 것은 비교적 빠르게 구현했으나 bottomnavigation을 따로 관리하는데에 문제가 생겼습니다. 현재 라우트와 정의되어있는 라우트를 비교해서 홈, 검색, my일때만 BottomBar를 표시해야했는데 현재 라우트를 구하는 과정에서 null이 들어가서 LaunchedEffect와 navController.currentBackStackEntryFlow.collect로 현재 라우트를 정상적으로 받아왔습니다.
또한 라우트명을 비교할때 navcontroller로 구해오는 라우트는 패키지명까지 다 들어가는데(org.sopt.and.navigation.Screen.Home), 제가 정의한 라우트 명은Screen.Home.toString()시 Screen.Home과 같이 구해져서 Screen.Home.javaClass.canonicalName를 사용하여 구해왔습니다.

[hwidung]

- 장점
모든 UI가 하나의 Activity 내에서 Fragment로 구성 돼 있으므로 성능이 가벼워짐을 느꼈다.
ViewModel을 활용하기 좋은 구조라고 생각한다. 한 Activity 내에서 ViewModel을 공유할 수 있기 때문.

- 단점
Navigation에 대해 잘 정의해주어야 한다. 그리고 처음에 route에 대해 하드코딩 하는 점에 대해 다른 방법은 없나? 라는 질문을 갖게 됐다.

- 어려운점
NavHostController와 NavController의 역할 및 사용법이 아직 익숙하지 않아 인자로 잘못 전달하여 오랫동안 오류를 못찾았던 점이 있었다.
다른 ViewModel에 접근해야 할 때 인자로 넘기는 과정이 생소하여 어려움이 있었다.

- 해결한 점
sealed class를 사용하여 데이터 객체를 생성해서 가독성을 높였다.
ViewModelFactory을 사용하였다. -> ViewModel이 다른 클래스의 인스턴스가 필요할 때, 생성자에 인자로 전달하기 위해 팩토리를 사용하고, ViewModel의 생성 시 필요한 의존성을 쉽게 주입할 수 있다.

[Hyobeen-Park]

Activity

• 장점 : 각 화면이 독립적으로 존재하여 역할을 명확히 분리할 수 있고, 구현 난이도가 낮다
• 단점 : 앱이 커질수록 메모리 사용량이 늘어나고 앱이 무거워진다

사실 저는 activity만으로 앱을 구현하던 시절에는 SAA 자체를 모르고 있었고,, 규모가 큰 앱을 구현해보지 않았어서 어려운 일도 크게 없었습니다ㅎㅎ

SAA with Fragment

• 장점 : activity와 마찬가지로 구현 난이도가 낮고, activity에 비해 훨씬 가볍다
• 단점 : SAA 구현 난이도는 낮지만 그 외 다른 기능을 구현할 때 어려움을 느낄 수 있다, graph 만들 때 생각을 잘 해야 한다

SAA를 알게 된 후로 Fragment를 활용해서 앱을 구현해봤었는데 화면 전환 등에 어려움은 크게 없었습니다! 다만 activity에서 구현하는 것이 익숙했던 저는 fragment에서 기능 구현할 때 어려움을 느낄 때가 종종 있었어요! 지금은 정확한 상황이 기억이 안나는데(ㅠㅠ) activity와 fragment의 코드가 완전히 동일하지는 않아서 적응이 필요했습니다 그리고 손 가는대로 graph를 짰다가 엉망진창이 되어 다시 만들었던 기억도 나네요ㅎㅎ

SAA with Jetpack Navigation

• 장점 : 화면 전환과 데이터 전달이 아주 쉽다 메모리 측면에서 효율적이다
• 단점 : 진입장벽이 높다

개인적으로 화면 전환과 데이터 전달은 Jetpack Navigation을 사용하는 것이 activity와는 비교가 안될 정도로 너무 편해서 좋아합니다ㅎㅎ 근데 처음 세팅할 때가 너무 어렵죠.. 진입장벽이 높은 것이 가장 큰 단점이라고 생각합니다. 그리고 저는 스택관리가 가장 어려웠던 것 같아요!! 열심히 공부하겠습니다ㅎㅎ
저는 이번 과제 구현하면서 로그인 - 회원가입 화면을 연결했는데 갑자기 화면이 꺼지는 오류가 있었어요! 로그인/회원가입 부분에서 문제가 있다고 생각해서 열심히 코드를 뜯어보고 있었는데요 테스트를 해보던 중 데이터 전달하는 과정을 추가했을 때 문제가 발생한다는 것을 알게 되었습니다

@Serializable
data class SignIn(
    val email: String,
    val password: String,
) : Route

로그인 루트를 이렇게 설정해뒀는데 처음 앱이 켜질 때는 email, password가 전달되지 않아서 생기는 문제였어요.... startDestination을 정의할 때 email, password에 빈 문자열을 전달해서 해결했습니다 얼른 sharedPreference 추가해서 거기에 저장하고 싶다는 생각을 했습니다ㅎㅎㅎㅎ

[hyeeum]

SAA 및 jetpack navigation 을 사용하면서 화면 간 데이터 전달이 간소화되었다고 느꼈습니다. 기존에는 intent를 통해서 관리를 해주었다면 이번 과제에서는 단순 parameter로 넘겨주는 방법을 사용하며 이전 화면의 데이터를 전달할 수 있었습니다.

단점으로는 처음 적용해보는 사람한테는 이해하는 데 시간이 걸리는 것 같습니다. 저와 같은 경우에는 기존 파일들이 각 기능에 맞게 분리되어있었는데 이 패키지 구조를 유지하면서 navigation을 사용하려니 더욱 헷갈렸던 것 같습니다. + 단순 navigation까지는 괜찮았는데 이제 이걸 bottom bar와 연결하면서 조금씩 이해했던 내용이 꼬이는 듯한 느낌을 받았습니다...

아직 이유를 찾지 못하였으니 기존 @serializable 어노테이션을 붙여 data class/data object 직렬화했는데 컴파일 과정에서 적용되지 않는 오류가 있었습니다. 그래서 처음에는 composable("route_name")을 통해 route이름을 문자열로 사용했습니다. 이후 모든 작업을 끝낸 후 다시 시도해보니 다행히도 그때는 직렬화 과정에서 오류가 안나 다시 composable<route_name> 으로 코드를 변경했습니다.

비록 처음에는 이해하는데 시간이 걸리겠지만 navigation이 주는 백스택 관리,상태 저장 등 옵셔널한 기능들이 다양하고 간편하기 때문에 이를 잘알고 적용한다면 코드가 더욱 간소화되고 가독성있게 작성될 수 있을 것 이라는 생각이 들었습니다 :)

[t1nm1ksun]

SAA with jetpack Navigation

• Activity가 많아지면 앱이 무거워짐
• Single Activity를 통해 Activity를 하나만 만들고, 네비게이션으로 화면이동을 하면 훨씬 앱이 가벼워짐
• ViewModel을 통해 data를 공유하기 쉬워짐 (Intent 사용x)

이런 장점만 있는 줄 알고 써왔는데 단점도 있더라구요

• 하나의 Activity안에서 (xml의 경우) 프래그먼트 간에 생명주기에 대해 생각해야할 부분이 많고 그로인해 생각지 못한 에러가 발생할 때가 있음
  ( Fragment들 간의 동작이 비동기로 처리되기 때문에 동기/비동기에 문제가 발생)
• 러닝커브 (진입장벽이 좀 있음)

느낀점: 네비게이션으로 화면전환하는게 익숙해서 그런지 Intent로 관리하는것 보다 편리했지만 단점도 추가적으로 알게되었습니다~

[beom84]

여러개의 Activity

• 여러개의 Activity를 사용해 구현시 구조가 명확하기때문에 구현이 쉽다는 장점과 앱이 무거워진다는 단점이 있습니다.

SAA

• Activity가 하나에서 화면전환이 용이하다는 장점이 있습니다
• 처음 배우고 구조를 짜는과정에서 많은 오류와 시행착오가 생긴다는 단점이 있습니다..

경험

• intent를 통해 화면전환 해본적이 많이 없어서 activity간의 화면이동자체가 새로웠는데 이후에 Jetpack Navigation을 사용하니 훨씬 편리하고 쉽다고 느껴졌습니다.
  또한 Serialization을 annotation 선언후 인자를 쉽게 주고받으니 더 간편하다고 느꼈습니다.
  그러나 구현하기 쉬운만큼 내부적으로 많은 로직이 들어가 수많은 오류를 견뎌내었고 잘 사용하려면 깊은 공부가 필요하다는걸 느꼈습니다

[Roel4990]

Jetpack Compose에서 Single Activity Architecture를 사용하면 NavHost와 NavController를 통해 화면 전환을 선언적으로 관리할 수 있어 UI 구성과 네비게이션 로직의 분리가 쉽습니다. 그러나 Composable 간의 상태 전달과 BackStack 관리가 복잡해질 수 있습니다.

여러 개의 Activity를 사용하는 구조는 각 화면이 독립적이고 직관적으로 관리되지만, Intent를 통한 데이터 전달이 번거롭고 화면 수가 많아질수록 코드 중복과 유지보수가 어렵습니다.

Jetpack Compose로 SAA를 구현하면서 처음이었기 때문에 많은 코드를 참고했고, 이러한 구조가 익숙치 않아서 이해하는데 시간이 걸렸던거 같습니다. 좋은 구조와 좋은 방식을 많이 참고해서 해봐야겠습니다. 그 Topbar랑 bottomNavigation을 구현하는데 시간이 좀 걸렸습니다. 잘만들어진 코드를 참고해서 구현했습니다.

두 방식 모두 장단점이 있지만, Jetpack Compose와 SAA의 조합은 UI와 간결한 네비게이션 구조를 제공해, 특히 복잡한 앱을 개발할 때 더 유리하다고 느꼈습니다.

[jm991014]

여러 개의 Activity

화면 당 하나의 Activity를 사용하므로 직관적이며 단일 책임 원칙을 지키기 좋은 구조입니다.
벗 액티비티가 많아지면 앱이 무거워지기도 합니다.

SAA

네비게이션을 통해 일관되게 화면을 관리할 수 있었지만 러닝커브가 좀 높은 것 같습니다.. bottom navigation과 연결하는 과정에서 많은 시행착오를 겪었습니다.

비록 러닝커브는 높지만 SAA로 구현한다면 효율적이며 간결한 코드를 작성할 수 있을 것 같습니다.

[kamja0510]

여러 개의 Acitivity의 장단점

각 view가 독립적인 생명 주기를 가지는 점이 깊게 드가면 편리할 수 있을 것이라 생각하지만 메모리를 많이 차지하는 것이 큰 단점인 것 같습니다. 저번 주에 사용했던 registerForActivityResult도 메모리 사용이 많을 경우 열려있던 Activity가 죽어 callBack을 받지 못하는 것을 방지 하기 위해 나왔다고 알게 되었는데 이렇게 여러 activity가 죽을 것을 방지하며 새로운 방식들이 나올거면 activity를 적게 쓰는 방법으로 가는 것이 낫다고 생각합니다.

Single Activity 구조

어렵다는 것이 단점이라고 많이 나오는데 저는 여러 activity를 써본적이 거의 없어 그냥 화면이동이란 여려운것이 구나 하고 살고 있습니다. 장점으로는 여러 activity의 단점을 해결하기 위해 나왔으므로 메모리를 적게 사용하는 장점이 있습니다.

내 경험

이번에 SAA를 구현해보면서 graph를 만들어놓고 화면이동을 하니 되게 직관적이고 쉬울 줄 알았는데 하나의 navigation에서 전체를 관리하려다 보니 되게 오래걸리고 힘들었습니다. 그리고 후에 뷰를 짤때도 이제는 navigation자체도 복잡하다 보니 UI에 대한 코드가 문제인지 navigation코드가 문제인지도 헷갈리는 상황이 생겼습니다. 그냥 무작정 다 고쳐보면서 해결을 했었는데 조금 더 깊게 공부하여 이해하고 쓰도록 노력하려합니다. 쓰다가 생각난건데 이번 과제 스택관리도 안했네요.

[SYAAINN]

대부분 비슷한 경험 및 학습을 진행하신거 같고 저 같은 경우도 역시 동일합니다.
특히나 Jetpack Navigation을 이용하여 화면 간 데이터를 전달하는 과정에서
원시타입들은 route에 query 형식으로 붙여서 backStackEntry를 통해 전달할 수 있었지만,
data class 등 원시타입이 아닌 데이터들을 전달하기 위해서는 추가적인 기술 적용이 필요했습니다..

시간이 부족하여 적용을 해내지는 못했지만 완료하게 된다면 따로 글을 작성하여 공유해볼 수 있도록 노력하겠습니다.
참고로 공부해보실 분들을 위해 몇 가지 참고자료를 첨부하도록 하겠습니다.

[1] 유튜브 : Philipp Lackner
[2] 한끼족보 레포지토리
[3] 33,34기 안드로이드 파트 박동민님 블로그

[chrin05]

여러개 Activity

• 코드 분리가 화면 별로 이루어지기 때문에 구조가 명확합니다. startActivity로 쉽게 화면이동이 가능합니다. 또한, 화면마다 각각의 생명주기를 가지기 때문에 메모리 관리 측면에서 유용한거 같습니다.
• 데이터 전달 시 Intent를 이용하여야 해서 복잡해집니다. 또한, Activity마다 공통 요소들이 존재해 코드 중복이 많습니다.

SSA

• ViewModel과 SavedStateHandle을 사용하며 앱 상태를 보다 일관성 있게 관리 가능합니다. Jetpack Navigation을 이용하여 내비게이션을 선언적으로 구현할 수 있고, 백스택 관리가 자동화됩니다. 여러 화면이 동일한 ViewModel을 공유할 수 있어 상태와 데이터를 일관성 있게 유지할 수 있습니다.

이번 과제를 해보면서 익숙하지 않았어서 적용하는데 많은 시간이 걸렸던 거 같습니다.😅 구현을 하고 나니 NavGraph로 화면 이동에 대한 부분을 한 곳에서 관리할 수 있어서 좋았던 거 같습니다. SSA를 조금 더 잘 알고 적용한다면 더 효율적으로 화면이동을 구현할 수 있을 것 같습니다.

[MinseoSONG]

여러 개의 Acitivity를 이용하여 앱을 구현했을 때
장점

• 메모리 관리 편함
• 구조가 직관적이라 코드 흐름 파악이 쉬움
  단점
• 화면 간 데이터 전달 시 Intent를 통해 넘겨야하므로 상대적 복잡
• 앱이 무거워짐

SAA를 사용하여 앱을 구현했을 때
장점

• 앱이 가벼움
  단점
• 백스택 관리가 어려움

평소 SAA를 통해서 화면 전환을 하는 편이었어서 SAA가 모든 부분에서 여러 개의 Activity를 사용하는 것보다는 더 좋구나 라고 생각하고 있었는데 그게 아니라 각각의 장단점이 있다는 것을 알게되었습니다. 그리고 제가 평소에 구현하던 SAA와 세미나 때 구현하던 방식이 달라서 또 놀랐습니다. 방식이 하나만 있는 줄 알았는데, 여러 방법을 공부해봐야겠다는 생각을 했습니다.

[1971123-seongmin]

여러 개의 Activity 구현

장점

• 메모리 관리가 편하다
• 코드를 이해하기 쉽고 구현이 쉽다.

단점

• 액티비티가 많아지면 앱이 무거워진다.

SAA 구현

• 장점 앱이 가볍고 빠르다.

• 메모리를 적게 사용한다.

• 따로 graph를 만들어서 네비게이션을 관리하지 않고 하나의 네비게이션으로 모든 네비게이션을 관리해서 복잡하고 어렵다.

• 뷰를 짤 때도 뷰와 네비게이션이 연결된 부분이 있어서 조금 복잡하다고 느꼈다.

[hyoeunjoo]

여러개의 activity를 사용하면 activity별로 백스택을 관리하기 때문에 사용자가 이전 화면으로 돌아갈때 메모리가 자동으로 해제되어 메모리 관리가 조금 더 용이하다는 장점이 있다고 생각합니다. 그렇지만 이와 동시에 activity 전환을 할때마다 화면이 재구성되는 문제가 발생하기 때문에 딜레이가 생길 수 있습니다. 저또한 1주차 과제를 구현했을 때 화면을 이동할때마다 딜레이가 실제로도 꽤나 길게 느껴져서 UX적으로 좋지 않다고 생각했습니다.

이와 달리 SAA를 사용하게 되면 화면 전환이 가볍고 복잡한 네비게이션 구조에서 효율적이라고 생각했습니다. 이후 앱이 커지고, 복잡해지고, 전달해야하는 데이터들도 많아진다면 분명 여러 Activity를 쓰는 것보다 성능면에서 큰 이점을 보이는 것은 당연해보입니다.

[yihwanggeun]

여러 Activity 방식 : 가장 장점이라고 할 수 있는 부분은 직관적이라는 것 같습니다. 각 activity에서 모든 생명주기가 관리되고 각 Activity별로 담당하고 있는 역할이 있기 때문에 직관적이고 개발하기 편한 것 같습니다. 단점은 Activity 전환하는 경우에 추가 메모리가 필요해서 퍼포먼스에 영향을 줄 수 있다고 해요!

SAA 방식 : Screen와 ViewModel을 사용해서 데이터를 관리해요. 이때 제가 느끼기에 가장 중요한 장점은 Activity에 공통 ViewModel을 하나 두고 Screen별로 ViewModel을 둬서 공통 데이터와 개별 데이터를 자유자재로 사용할 수 있다는 것이었어요! (근데 이렇게 해도 되는건가요?? 공통 ViewModel을 하나 두고 개별 ViewModel까지 2개의 ViewModel을 Screen을 써도 되나..?) 단점은 화면이 많아지게 되면 그 Depth도 복잡해져 관리가 어려워진다는겁니다! NavHost와 NavGraph를 관리하기 힘들었던 경험이 있습니다!

[imtaejugkim]

여러 Activity를 사용하면 메모리 관리가 편하고, 데이터 전달이나 화면 이동등의 행동이 SAA 아키텍쳐 패턴보다 상대적으로 편하다고 느꼈습니다. 하지만 많은 activity가 존재할 수록 앱은 무거워질 수 밖에 없다는 단점이 있습니다.

이와 반대로 SAA 패턴은 상대적으로 가벼우며 코드를 재사용 함으로써 중복을 줄일수 있다는 장점이 있습니다. 하지만 NavGation 등 아키텍쳐가 복잡해질 수도 있다는 단점이 있습니다.

이번에 처음으로 compose를 공부하면서, navigation의 코드가 살짝 복잡하다고 느꼈지만, 아키텍쳐의 설계가 확립되고 나면 진행속도가 빨라진다는 것을 체감할 수 있었습니다!

[yskim6772]

여러 개의 Activity를 사용하여 구현하면 각 화면이 Activity로 분리되어 있기 때문에 각각의 생명주기와 UI를 독립적으로 관리할 수 있다는 장점이 있다고 생각합니다. 그러나 Activity의 개수가 많아질수록 앱은 무거워지며, 메모리나 속도 측면에서 단점을 지닙니다.

반면 Single Activity Architecture를 적용하게 되면, Jetpack Navigation을 활용하여 백 스택 관리나 복잡한 내비게이션을 보다 더 간단하고 일관되게 구현할 수 있으며, Fragment 간의 데이터 전달이 뷰모델이나 LiveData를 통해 이루어지는 등 데이터 전달에 있어서도 장점을 지닙니다. 그러나 의존성이 증가하는 문제가 발생할 수 있고, Fragment 간 전환 시의 생명주기 관리가 필수적입니다.

이번 과제를 하면서 처음에 구조를 짜는 과정이 다소 복잡했어서, NavHostController 초기화 시점에 ViewModelStore가 설정되지 않았어서 오류가 발생하는 등 이를 해결하는 데 시간이 좀 걸렸던 것 같습니다.

[sayyyho]

여러 개 Acitivity

• 장점
  • 메모리 관리가 편함
  • 구조가 직관적임
• 단점
  • 앱이 무거워짐

SAA

• 장점
  • 앱이 가벼움
  • 메모리 적게 사용
• 단점
  • 백스택 관리가 어려움
  • 진입 장벽...

처음 SAA를 통해서 화면 전환을 해봐서 러닝커브가 높았습니다... 그럼에도 훨씬 효율적인 방식이라고 느껴서 더 공부해서 제대로 사용해야겠다는 생각이 들었습니다!

[0se0]

• 싱글 액티비티 (네비게이션 활용)

[10 best practices for moving to a single activity](https://www.youtube.com/watch?v=9O1D_Ytk0xg)

1. 액티비티 범위의 활용:
    - 여러 목적지(화면)를 하나의 액티비티 내에서 관리하며, 공유된 뷰 모델을 통해 데이터를 교환하면 애플리케이션의 상태를 더 일관되게 유지할 수 있다.
2. 네비게이션 아키텍처 컴포넌트 사용:
    - 네비게이션 아키텍처 컴포넌트를 사용하여 화면 간 전환을 간소화하고, 코드의 구조를 더 명확하게 할 수 있다. 이는 개발 과정을 단순화하고 유지 보수를 용이하게 할 수 있다.
3. Safe Args 사용:
    - Safe Args 플러그인을 사용하여 타입 안전성을 보장하고, 네비게이션에서 필요한 데이터를 안전하게 전달할 수 있다. 이는 버그 발생 가능성을 줄여 준다.
4. 비즈니스 로직의 분리 및 테스트 용이성:
    - 비즈니스 로직을 UI로부터 분리하여 독립적으로 테스트 가능하게 함으로써, 애플리케이션의 견고성을 높일 수 있다.
5. 프래그먼트 시나리오로의 테스트:
    - 독립적인 프래그먼트 테스트를 통해, 개별 컴포넌트의 동작을 보다 정확하게 검증할 수 있다.
6. NavController의 모의 사용:
    - NavController를 모의하여 네비게이션 동작을 테스트함으로써, 실제 환경에서의 UI 동작과 유사한 조건을 만들어 테스트의 정확도를 높일 수 있다.
7. 의존성 주입의 간소화:
    - 프래그먼트 팩토리와 생성자 주입을 사용하여 프래그먼트의 인스턴스를 더 유연하게 생성할 수 있다. 이는 구성 요소 간의 결합도를 낮추고 의존성 관리를 개선한다.
8. 멀티 태스크 관리의 용이성:
    - 단일 액티비티 구조에서도 멀티 태스킹을 효과적으로 관리할 수 있으며, 사용자 경험을 향상시킬 수 있다.
9. 앱 아키텍처의 단순화:
    - 단일 액티비티 아키텍처는 개발자에게 더 간단하고 일관된 아키텍처를 제공하여, 전체적인 애플리케이션의 구조를 이해하기 쉽게 만든다.
10. 경험에 따른 구조적 결정:
    - 기존의 복잡한 앱 구조를 간소화하고, 사용자 경험을 기반으로 합리적인 아키텍처 결정을 내릴 수 있다. 이는 개발 프로세스를 더 효율적으로 만들고, 앱의 성능을 최적화한다.

[kangyein9892]

여러 개 Acitivity

장점
구조가 직관적이여서 구현하기가 편하다
스택 관리가 편하다
단점
activity를 많이 사용하게 되면 앱이 무거워진다.

SAA

장점
앱이 가벼워지게 되고, 메모리를 적게 사용한다.
단점
스택 관리가 어렵다

처음 SAA를 적용하면서 진입 장벽이 너무 높고 어려웠던 것 같습니다. 하지만 구조를 잘 짠다면 편할 것 같아요. 앞으로 더 잘 사용해보고 싶습니다.

[angryPodo]

저는 아직 Single Activity Architecture (SAA)를 직접 적용해 보지는 않았지만, 여러 개의 Activity를 사용하면서 앱이 무겁고 전환 시 메모리 사용량이 증가하는 느낌을 많이 받았습니다. 특히 여러 Activity 간 화면 전환이 빈번할 때 꽤 많은 메모리 소비가 느껴졌습니다.

하나의 Activity에서 모든 화면을 관리하게 되면 메모리 사용이 줄어들고, 앱의 전반적인 퍼포먼스가 개선될 수 있을 것 같습니다. 또한, Jetpack Navigation과 ViewModel을 이용해 화면 전환과 데이터 공유를 중앙에서 관리할 수 있다는 점이 매우 매력적으로 다가옵니다. 이러한 방식은 Activity마다 별도로 데이터를 전달하거나 상태를 관리해야 하는 번거로움을 줄여줄 것으로 기대하고 있습니다.

러닝커브가 있어서 아직 공부하는 중이지만...
앞으로 SAA를 적용하면서 이러한 장점들을 경험해보고, 기존 여러 Activity 방식에서 겪었던 문제들을 개선해 나가고 싶습니다.

[jangsjw]

이번 과제를 하면서 Single Activity 구조에 대해 처음 알게 됐습니다!
여러개의 Activity를 사용하는 경우,
장점은 구조가 직관적이고 UI 구성과 상태 관리가 명확합니다.
단점은 여러 Activity가 생기면 Activity 스택 관리가 복잡해지고, 특히 많은 화면을 전환하는 앱에서는 메모리 소모되기 때문에 메모리와 성능에 관해 단점이 있습니니다.

Single Activity Architecture 사용 하는 경우,
장점은 Fragment와 NavController를 사용하면 일관성 있고 효율적인 네비게이션 구현이 가능합니다!
메모리 효율성: 메모리 소모가 줄어들고 Activity 스택 관리를 최소화할 수 있어 성능이 향상됩니다.
상태 관리의 용이성: ViewModel과 LiveData 등을 활용해 데이터와 UI 상태를 쉽게 공유하고 유지할 수 있습니다.
단점은 여러 Fragment를 사용할 때 UI 구성 및 상태를 유지하면서 일관성 있게 관리하는 것이 어려울 것 같다고 생각됩니다.