• Library Lifecycle
    • Design ( optional 한 process지만, 많은 시간을 사용함 )
      1. 어떠한 문제를 해결하고자 하는가
      2. 어떻게 문제를 해결하고자 하는가 ( solution research )
      3. 실제로 구현 가능한가 ?
      4. 구현하고자 하는게 어떤 의존관계를 갖는지 의존관계 정립
      5. 어떠한 형태로 사용될 지 청사진을 그림
      6. 인터페이스 디자인
    • Develop
      1. API 평면화 ( Minimize API Surface )
        • 외부로 노출된 API가 제거되거나, 오류가 난 경우엔 build fail이 많이 날 수 있음
        • 즉 외부로 노출된 API가 많으면 많을수록 유지보수가 힘들어짐
        • 외부로 노출된 API가 특정 부분에만 제한된 경우, 클라이언트 입장에서는 훨씬 수월하게 migration을 할 수 있음
        • internal / private 등 접근 제한자를 정말 잘 활용해야 함
        • extension의 경우 특별히 주의해서 관리 할 것
        • internal keyword를 활용하더라도, java에서는 그대로 활용 가능 함 → JvmSynthetic 어노테이션을 활용 할 것
        • Jetbrain explicit API Mode
          • 활성화 하게되면, 외부로 노출되는 모든 타입에 명시적으로 가시성을 붙여주어야 컴파일 에러가 안나도록 해주는 Mode
          • 안붙여주면 컴파일 에러
          • Jetbrain explicit API warning mode
            • 위는 컴파일 에러지만, 이건 워닝만 띄워줌
        • Jetbrain - Binary compatibility validator
          • jetbrain plugin
          • module.api 파일이 생성됨
            • 파일에 있는 모든 api 스타일이 정의되어 있음
            • 이 파일만 보고, 코드리뷰를 진행 할 수도 있음
      2. Resource Manage
        • AAR 파일 속의 resource 파일을 보자
        • 만약 라이브러리 내에서 리소스를 지워버리면, 라이브러리를 활용하는 클라이언트에서 컴파일 에러가 발생 할 수 있음
        • xml의 리소스에도 public tag를 추가 할 수 있음
        • 외부로 노출시키고자 하는 xml에 대해 선택적으로 노출 시킬 수 있음
        • public이 없는 경우엔, ide에서 자동완성을 해주지도 않고 / IDE에서 warning을 띄워줌
        • 안드로이드에서 제공해주는 Lint 체크 덕분에 이게 가능
        • 라이브러리 안에 있는 동일한 xml 명과 유저가 개발한 동일한 xml명이 동일 할 때 버그가 발생 할 수 있음
          • resource prefix 옵션을 추가 해 주면, resource의 이름 앞에 고유한 prefix를 붙여서 빌드 해줌
          • 따라서 고유한 이름을 보장 받을 수 있음
      3. R 클래스 관리
        • 예전엔 R이 생성이 제대로 안되서, 고생 했던적이 많음
        • app 모듈 → myLibrary 모듈 → material 모듈 의존 상황 가정
        • R파일 생성
          • material모듈 안에 R파일 모두 생성 됨
          • myLibrary 모듈에서는 myLibrary 모듈 / material 모듈 안에 있는 모든 값이 포함된 R 파일 생성
          • app 모듈에서는 myLibrary / material / app 모듈 안에 있는 모든 값이 포함된 R파일 생성
        • 위와 같이 R파일이 많아질 때엔, 컴파일 타임에 엄청나게 많은 영향을 미침
        • 이런 경우에 gradle.properties에 android.nonTranstiveR 옵션을 활성화 해보자
        • 그러면, 모든 값이 다 R파일로 넘어가는게 아니라, 의존하고 있는것만 넘어가기 때문에 빌드타임 개선이 기대 될 수 있음
        • balloon 라이브러리 경우, 총 1만 바이트의 용량 감소가 있었음
        • service 개발 할 때에도, nonTransitiveR 옵션을 잘 활용해보자
          • 리소스가 들어있는 full name package를 적어주면 import 가능
          • namespacing을 통해 R클래스를 깔끔하게 처리 할 수 있음
    • Preparation
      • 주석을 정말 열심히 달고, 문서화를 정말 열심히 하려고 함
      • Dokka plugin
        • 외부에 노출되는 모든 API에 대해 문서화를 해줌
      • README를 제품 사용 설명서라 생각하고, 정말 Documentation 작업을 엻심히 함
    • Release
      • Apache maven
        • maven은 remote 저장소라기 보다는, build automation tool임
      • maven → mavenCentral() / jcenter() ( 지원 종료 ) / google()
      • sonatype에 배포가 생각보다 쉽지않은데, 태환님 / 스트림에 올라간 블로그 포스팅 참조
      • JitPack은 배포하는것이 정말 훨씬 쉬움
    • Verifying
      • 지속적으로 / 꾸준히 검증해야함
      • 커뮤니티를 주로 활용하고 있음 ( Github / reddit / linkedIn ... )
      • blog post를 활용하는것도 좋은 방법
      • Sample project를 활용해서 홍보를 하기도 함