안드로이드와 스프링의 의존성 주입에 관해서

채팅앱의 UI 관련 코딩을 하다보니 자연스레 UI의 관련 기능들을 담을 하나의 컨테이너가 필요해졌습니다.

그리고 그 컨테이너가 안드로이드에서 제공하는 Activity라는 개념은 아닐까? 라는 생각이 들더군요.

 

UI 코딩 이전에는 채팅방 정보를 제공하는 서버를 프레임워크화 하는 과정에서 모든 의존성을 담당하는 하나의 클래스를 두었었습니다. 이 역시 스프링의 ioc 개념에서 들고 왔습니다.

다시 말해, 하나의 클래스에 모든 의존성 정보를 몰빵하고, 그 클래스에서 모든 의존성을 setXXX와 같은 메서드를 통해 주입합니다. 

이 방법은 애너테이션을 이용한 스프링의 방식처럼 세련되진 않지만, 그래도 클래스마다 필요로 하는 컴포넌트 객체들의 생존주기를 관리하는 코드를 넣지 않아 편리했습니다.

 

Activity라는 개념을 도입해 UI 코드들을 정리해나가는 클라이언트 앱에서도 이 방식을 유지하려 했으나,

ioc 방식이 여기에는 맞지 않을 수도 있단 생각이 들었습니다.

웹 서버같은 경우엔 약간 정적인 느낌이 있습니다. 그래서 초기에 의존성 관리를 담당하는 클래스를 이용해 초기화가 가능했습니다. 하지만 그에 비해 Activity가 동적으로 변해야하고, 다른 Activity로 넘어갈 때 전해지는 정보도 때에 따라 달라질 수 있기 때문에 초기에 모든 Activity를 생성해 주입하는 방식이 비효율적이겠다 라고 결론을 내렸습니다.

 

물론 이벤트 방식으로 구현한다면 가능할 것도 같습니다. 

이는 안드로이드에서 인텐트를 액티비티 레벨에 적용하는 것과 비슷해보입니다. 

직접 구현하기엔 프로젝트의 복잡도가 올라갈거 같아, 이는 다음으로 미루려고 합니다.