프로토타입으로 작성한 Feedback Dialog에서는 서비스에서 Dialog를 띄울 수가 없기 때문에 WindowManager에 뷰를 추가하는 방식으로 구현했었는데, 이 경우 XML을 이용할 수가 없어서 순수 자바코드만으로 뷰를 구성해야 했고 이미지 리소스 또한 사용할 수 없다는 문제가 있다.
Pro Android 4 책을 살펴보던 중 Library Project에 관한 내용이 나왔고, 이를 이용하면 기존에 소스코드 상에서 구현한 Feedback Dialog의 문제점을 해결할 수 있을 것 같아 몇가지 테스트를 해보았다.
개발자가 SDK를 사용할 때 최소의 코드만으로 기능을 사용할 수 있도록 하는 것이 SDK의 구현 목표이기 때문에 사용자 프로젝트의 AndroidManifest.xml 등에 SDK 사용을 위해 다른 것들을 추가하는 것을 최소화하는 것 또한 포함된다.
따라서 라이브러리 프로젝트의 Activity를 사용함에 있어서 이를 사용자 프로젝트에서 Activity 등록을 해주어야 하는지를 확인해봤는데, 라이브러리의 매니페스트에 액티비티를 추가했더라도 사용자 프로젝트에서는 그것을 인식할 수 없다.
책에서는 암시적/명시적 차이만 있을 뿐이라고 했지만 버전에 따라 다르거나 책이 쓰여진 시점과 지금과 차이가 있는 모양이다. 결론은 라이브러리 프로젝트의 액티비티를 사용하려면 사용자 프로젝트에서 해당 액티비티의 패키지 경로를 포함한 액티비티 이름을 이용해서 매니페스트에 등록해주어야 한다.
두번째로 라이브러리 프로젝트의 리소스를 그대로 사용할 수 있는가?
결론부터 말하자면 리소스를 사용할 수 있다. 다만 리소스 식별을 위한 id가 라이브러리 프로젝트와 사용자 프로젝트가 중복되는 경우 사용자 프로젝트의 리소스에 우선순위가 있거나 애초에 라이브러리 프로젝트의 리소스는 등록이 되지 않는 것 같다.
xml 레이아웃의 경우 파일 이름을 id로 사용하므로 파일 이름이 같은 경우에 id 충돌이 발생하고 (런타임이나 컴파일 타임에 예외는 발생하지 않는다.) 리소스의 경우에는 @+id를 이용해 등록한 id가 같다면 충돌이 발생한다. (포럼에서 해당 이슈에 대해 대화를 나누는 것을 보면 이 문제를 비롯해 라이브러리 프로젝트에 있어서 아직 문제가 많고 계속해서 개선이 진행되고 있다고 한다.)
안드로이드 프레임워크 레벨에서 리소스 id에 대한 네임스페이스를 구분할 수 없으므로 간단하게 네이밍 컨벤션을 통해 이름 충돌이 일어나지 않도록 해야겠다.
간단하게는 salina_ 접두어를 사용하는 쪽으로 진행해야겠다.
혹은 이러한 문제를 역이용해서 사용자가 피드백 다이얼로그의 룩앤필을 바꿀 수도 있을 것 같다.
즉, 특정 이미지 리소스에 대한 파일 이름과 사이즈 규격을 가이드를 통해 알려주면 이를 사용자 프로젝트에 추가하게 되면 사용자 프로젝트의 리소스가 우선이므로 가능성이 있을 듯하나.. 아직은 라이브러리 프로젝트가 지속적으로 개선이 되고 있으므로 추후 변동사항이 생기는 경우에는 해결이 안되므로 좀 더 고려해봐야 할 문제이다.
Salina 