이번 포스팅부터는 패키지 시리즈를 다뤄보고자 한다.
최근 네이티브 SDK 라이브러리를 플러터에 적용하고 있어 공식 문서와 경험을 토대로 시리즈 포스팅을 이어나갈 생각이다.
- 패키지 만들고 pub.dev 등록하기
- 플러그인에 안드로이드 네이티브 SDK 연동하기(.jar 라이브러리)
- 플러그인에 iOS 네이티브 SDK 연동하기(.framework 라이브러리)
🎯 pub.dev와 패키지
pub은 다트와 플러터의 package manager이다.
pub이라는 이름의 유래에는 "주로 술집(pub)에서 다트를 플레이한다" 라는 비공식? 답변이 있다. 공식적으로 언급한 아티클은 보지 못했는데 이유가 맞는거 같다!
패키지를 만들고 pub.dev 사이트에 업로드할 수 있고,
누구나 패키지를 이용할 수 있으며 패키지는 영구 보관된다.
혹시 개인 사용 용도로 쓰는 패키지라면 pub.dev에 올리지 말고
깃허브 같은 개인 저장소를 이용하거나 조직이라면 패키지 저장소를 만들어 사용하는 방법도 있다.
패키지 종류
Dart Package: Dart 패키지로 다트 언어만으로 구성된 라이브러리
흔히 Package라고 부릅니다.
Plugin Package: 안드로이드, iOS 등 하나 이상의 플랫폼 언어와 함께 작성된 것으로 네이티브 코드를 포함하는 라이브러리
흔히 Plugin이라고 부릅니다.
Dart만으로 충분하면 패키지를, 배터리 플러그인과 같이 각각 네이티브에서의 기능 구현이 필요한 경우 플러그인을 만드시면 됩니다.
저는 안드로이드, iOS 네이티브 SDK를 플러터 SDK로 만들어야 되므로,
플러그인을 만들어야 합니다.
패키지 프로젝트 생성
flutter create --org dev.tykan --template=plugin --platforms=android,ios my_flutter_sdk앱 프로젝트 생성할 때와 같이 flutter create <output_directory> 커맨드를 사용한다.
순서대로 설명하면,
- --org 옵션: 조직 도메인입니다. 도메인을 리버스한 형태로 쓰인다.
- --template 옵션: 생성하는 프로젝트의 템플릿으로 디폴트는 app이지만, 플러그인 예제를 만들 계획이므로 plugin
- --platforms 옵션: 패키지가 지원하는 플랫폼을 설정할 수 있다.
- <output_directory>: 프로젝트 폴더명을 넣으면 된다.
-a, -i 옵션을 통해 안드로이드, iOS 각각에서 사용할 언어를 지정할 수 있다.
기본값은 안드로이드 Kotlin, iOS Swift다.
그럼 이렇게 깔끔하게 생성된 프로젝트를 확인할 수 있다.
원격 레포지토리에 올리기
이제 패키지를 관리할 깃허브 저장소를 만들자.
워낙 검색하면 넘쳐나는 내용이라 간략하게만 보자.
깃허브 레포지토리 생성 시 라이센스 파일도 만들어주므로 사용하기 편하다.
깃허브에서 public 레포지토리를 생성하고, 연결해주면 된다.
// 깃 초기화
git init
// 원격 저장소를 연결
git remote add origin https://github.com/[your_git_path]
// pull 땡기자 (깃허브에서 만들어진 라이센스 파일 넣기 위해서)
git pull origin master
// 커밋 생성 후 push!
git add .
git commit -m "init commit"
git push origin master저장소 주소는 패키지의 pubspec.yaml에서 homepage 또는 repository에 넣어주면 된다.
둘 중 하나는 반드시 설정되어야 pub.dev 사이트에 등록할 수 있다.
pub.dev에 배포하기
소스코드를 작성하고 이제 배포해보자.
실제 publish 하기 전에 미리 dry-run을 해서 문제가 없는지 확인할 수 있다.
flutter pub publish --dry-run아래와 같이 뜨면 문제가 없는 것이다.
문제가 있다면 에러메세지를 보고 수정해주면 된다.
문제가 없다면 최종적으로 publish한다.
flutter pub publish끝! 👏👏👏
👀 책임감있게 유지보수!
패키지 저장소에 본인이 만든 패키지가 업로드 되었고,
누군가는 이 패키지를 사용해서 프로젝트를 하고 있으므로
즉각적인 대응은 아니더라도 항상 관심을 가지고 대응하는 노력이 필요하다.
내 패키지 코드를 보고 다른 개발자가 개선 제안을 하거나
문제점에 대해 리포트 해주므로 오픈소스의 장점을 백분 활용하자!
저도 프로젝트 진행시 필요한 패키지가 없으면 만들어서 배포하는데
현재 2개 패키지를 관리하고 있습니다.
패키지 보러가기버그 리포트나 코드에 대한 건강한 토론은 언제든 환영합니다 :)
