인자로 Activity 자체를 받는것에 어떤 문제점이 있을까요?

Question

안녕하세요.

궁금한게 있어서 글을 남기네요.

다름이 아니라 제가 주로 기능별로 클래스를 많이 분리하거든요.

그러다보면 Main과 NoticeManager라는 클래스가 나눠집니다.

NoticeManager는 공지사항이 잇는지 체크하고 액티비티에 띄워주는 역할을 하는데요.

음..지금까지 주로 구글 샘플소스나 프레임워크 까서 거기에 있는 패턴이나 구조를 많이 따라했습니다.

주로 Callback위주의 구조로 클래스들을 설계하였습니다.

예를들어 Main에 콜백인터페이스를 구현해놓고 B라는 클래스에서 작업이 완료되면 Main으로 콜백이 오게끔 그런 구조로 했었는데..

지금 위에 말씀드린 공지사항을 출력해주는 기능을 분리시켰는데

공지사항은 다이얼로그로 뿌려주거든요.

그래서 파라미터로 Activity activity 이렇게 액티비티의 참조변수 자체를 받고 있습니다.

그리고 다이얼로그의 생성자에 new Dialog(activity, style) 이런식으로 생성하구요..

이런 방식에 어떤 문제가 있을까요?

그리고 마지막으로 제일 궁금한건데

위와같이 Activity 자체의 레퍼런스를 받아서 객체로 형변환 시킨후 예를들어

(Activity activity) 이렇게 받아서

((MainActivity)activity).메서드  이런방식으로 메인엑티비티에 있는 메서드가 호출이 가능하던데

이렇게 액티비티 자체를 받아서 객체화 시켜서 액티비티 내부에 있는 메서드를 사용하는 방법에 문제가 없을까요?

Comments

기능별로 클래스를 분리하는 건 관리외 테스트가 용이해지는 좋은 practice라고 생각합니다. 그리고 dialog와 같은 경우는 activity를  넘겨야 에러가 안날겁니다.
그리고 type cast를 하신 것은 별로 권장할 방법은 아닌데 MVVM같은 패턴을 쓰시면 ui에 덜 종속된 앱 개발이 가능합니다. 반가운 것은 android binding library 가 지원되기 때문에 mvvm의 구현이 수월해졌다는 겁니다. 한번 검색해 보세요.

Answer 1

Dialog로 한정 짓는다면 생성시 액티비티가 필요하지 않은 DialogFragment를 사용한다던지 하고 위에서 말씀하신 Activity에 인터페이스를 만들어서 showDialogFragment() 를 만든다던지 하면 기존 방식대로도 구현은 가능하겠네요. https://developer.android.com/reference/android/app/DialogFragment.html 예제코드도 대략 그런 형태구요.

근데 다이얼로그와 상관없이 일반적으로 봐서 activity를 인자를 줘서 작업을 처리하는게 무조건 문제라고 말할수는 없긴한데요. 문제점은 activity의 경우 라이프 사이클을 가지고 있기 때문에 activity를 받아서 멤버 변수로 저장해두고 사용한다던지 하는 경우는 activity가 종료된 후에도 그것을 계속 가져있어서 메모리 문제가 생기는 경우가 있죠. 여기저기서 context사용하는게 많아서 나도 모르게 문제가 생겨 버리게 될 가능성이 높습니다. 그런 부작용이 있을수 있기 때문에 가급적이면 activity는 그대로 쓰기보다는 callback interface로 필요한 기능 정의해서 사용하는 것인데 그런 부작용이 없는 것이 명확한 케이스라면 상관없지 싶습니다.