다른 프로젝트에서도 쓸 수도 있는 경우에는 최대한 확장성 있게(기본 Activity상속받는 경우와 거의 같은 형태로 쓸 수 있게) 작성하고 그렇지 않을 경우에는 개별프로젝트에서만 쓰는게 좋지않나 싶네요.

저도 저한테 나름 편하게끔 Activity구성해서 쓰고 있긴한데 기능이 많아질수록 말씀하신 문제들이 발생할 여지들이

생길 수 있을것 같습니다.

양날의 검이지요.

주로 액티비티에서 잘 사용할 만한, 편하게 사용할 만한 기능을 추가해서 구성하는데요,

편의성을 얻고 확장성을 잃게 된다 라고 봅니다.

그래서 저는 찍어내야 하는 액티비티는 상속구조를 활용하고,

아니라면 BaseActivity는 절대 안 만든다 라는 주의입니다.

요즘 추세(?)가 하나의 엑티비티로 모든 일을 하게되면서 FragmentActivity 를 주로 상속 받아서 쓰는데요. 

특정 엑티비티를 꼭 상속받아야 되는 라이브러리를 사용하게 되면 아주 골치아퍼 집니다 ㅠㅠ

그런 엑티비티는 반드시 샘플로만 소스 공개해서 제공 해야 된다고 생각해요. (애드립 처럼)

네이버 맵 네이버 맵 네이버 맵

그래서 요즘 객체지향 패턴에서 추천하는 방법이 클래스 상속보다는 인터페이스 상속을 추천하나 봅니다..

저도 공통 라이브러리를 클래스 형태로 관리하다 보면 Activity가 아닌 경우에도 말씀하신 문제가 발생하고

나중에는 Base 클래스를 고치는게 두려워지죠..

다들 비슷한 고민들을 하시는군요 ^^; 저도 BaseActivity를 만들어쓰다가 PreferenceActivity 등을 이용해야되는 상황이 오니 당황스럽더군요. 그래서 저는 그냥 BaseActivity에서 BaseAction 클래스로 기능들을 빼고, BaseActivity에서 BaseAction을 포함하는 구조로 변경해서 쓰고 있습니다. PreferenceActivity등 다른 Activity를 상속해야되는 상황이 되면, BaseAction을 포함한 BasePreferenceActivity를 구현해서 사용하고 있습니다.

물론 아즈라엘님 상황처럼 타사의 Activity들을 같이 써야하는 경우는 어쩔 도리가 없지만요 ^^;;

이래서 OCP (open-closed principle) 이 어려운거죠..ㅋㅋ 

이론으로 어케든 알거 같은데.. 결국 사용해 보면 쉽지 않은..ㅠㅠ

Activity는 상속을 많이 한 Class 입니다. 내부 중요 Callback들이 구현되어 있고요..

그래서 코드의 편의상 LifeCycle 빼 먹을 수 있는 것들을 미연에 방지하고자 

상속을 통해서 해결하는 코드들이 많이 있습니다만..

다른건 모르겠는데 Activity는 시스템에서 가장 중요한 부분이니 ..가급적 상속을 피해 주시는게

좋을거 같네요..

상속을 하지 않고 컨트롤용 클래스를 따로 만드시던가.. 메서드를 통해서 코드라인을 깔끔하게

바꾸는게 더욱 좋아 보입니다. 

그리고 왠만하면 is - a 보다는 has - a 로 해결하시는게 메모리 소모와.. 기타등등의 정신건강에 좋을거 같네요

개인적인 경험에 비추어 보았을 때, 그리 추천할 만한 것은 아닙니다.

보통 공통된 것들을 편하게 만들자고 그렇게들 만들어놓는데,...

만들다 보면 BaseActivity 가 변경되는 경우가 허다하게 발생합니다.

일줄이자고 만들어 놓은게 결국, 일을 더 늘리는 경우가 많이 생깁니다.

전 개인적으로 Activity 갯수가 늘어나더라도 단순하게 여러개 만드는 것을 선호합니다.

왜냐하면, 저 혼자 코드를 볼 때는 상속이나 기타의 개념들을 내 맘대로 쑤셔박아도 큰 문제가 없지만,

공동작업이나 팀으로 일 할 때에는 타인이 내 코드를 봤을 때 이해가 쉽고,

하나를 건드리더라도 다른 곳에 영향을 주는 걸 최소화 하려면(Side Effect),

Activity 갯수가 늘어나더라도 단순한 동작으로 여러개 만드는 것이 낫습니다.

BaseActivity 를 다른 사람이 잘 못 건드려서, App 전반적인 문제가 발생하게 될 수 있으니까요..