목적
스터디 2주차 공부 정리
뭘 해볼까 하다 위경도를 가져와서 지오코딩을 하는건 너무 쉽다.
그래서 지오코딩이 어떤 방식으로 돌아가는지 알아두면 좋을것같아서 이 포스트를 남긴다.
내용
깃헙 리드미 읽어보기
지오코딩 플러그인은 'federated plugin architecture'연합 플러그인 아키텍처 방식을 따른다고 한다.
연합 플러그인
다른 플랫폼에 대한 지원을 별도의 패키지로 분할하는 방법 (Android, iOS, WEB, IoT)
연합 플러그인은 아래의 패키지로 구성된다.
- 앱 대면 패키지 : 플러그인 사용자가 플러그인을 사용하기 위해 의존하는 패키지.
- 플랫폼 패키지 : 플랫폼별 구현 코드가 포함된 하나 이상의 패키지
- 플랫폼 인터페이스 패키지 : 모든 플랫폼 패키지가 앱 대면 패키지를 지원하기 위해 구현해야하는 인터페이스를 선언한다.
지오코딩 플러그인은 다음의 패키지로 구성되어 있다
1. geocoding : 앱 대면 패키지
2. geocoding_platform_interface : 플랫폼 인터페이스 패키지
플랫폼 패키지가 없는것같은데 미디엄 문서를 둘러보자.
이 가이드의 1부에서는 Android, iOS 플러그인이 사용하는 MethodChannels를 사용하여 Flutter 플러그인에 웹 지원을 추가하는 방법을 배웠다고 한다. 이런 방식은 몇가지 단점이 있다고 한다.
단점 1. 메소드 채널을 통해 플러그인 메서드를 호출하면 불필요한 오버헤드가 있다. 웹에서는 전체 앱이 하나의 js 번들로 컴파일되기때문에 플러그인코드는 불필요하게 메서드 호출을 바이트 배열로 직렬화하며, 바이트 배열은 웹 플러그인에 의해 즉시 역직렬화 된다.
단점 2. 컴파일러가 사용하지 않는 플러그인 코드를 제거하는것을 어렵게 만든다. 웹 플러그인은 메서드 채널에 의해 전달된 메서드 호출의 이름을 기반으로 적절한 메서드를 호출하므로 컴파일러는 플러그인의 모든 메서드가 활성상태이며 트리셰이크를 제거할 수 없다고(연결 상태를 끊을수 없다는 말인듯) 가정해야한다.
이 아티클에선 플러터 플러그인을 추가하는 다른방법을 알아보자. 플러터 팀이 소유한 플러그인 중 하나 (ex. flutter/plugins OR FirebaseExtended/flutterfire repo) 에 웹 지원을 추가할 계획이라면 너는 이 방법으로 구현해야한다.
장점
단일 패키지로 결합하지 않고 여러 패키지로 분할하는 이유는 유지보수성과 성장에 더 좋기 때문이다.
- 플러그인 작성자는 지원되는 모든 flutter 플랫폼(안드,맥,웹,ios)에 대한 도메인 전문 지식이 필요하지않음
- 원래 플러그인 작성자가 코드를 검토하고 가져올 필요 없이 새 플랫폼에 대한 지원을 추가할 수 있습니다.
- 각 패키지는 별도로 유지 관리하고 테스트할 수 있습니다.
연합 플러그인으로 만들면 누구나 새 플랫폼에 대한 지원을 구현할 수 있다. 예를들어 플러터가 닌텐도 스위치를 미래에 지원한다면 스위치 전문가는 새로운 api를 모두 배울 필요 없이 플러그인에 대한 지원을 추가할 수 있다. 새로운 스위치 플러그인을 검사할 수도 있으며 표준을 충족하는경우 "승인된 구현" 으로 만들 수 있습니다. 즉, 플러그인 사용자가 플러그인을 사용하기 위해 특별히 의존할 필요도 없습니다!
플랫폼 인터페이스
메소드채널을 사용하지 않고 플러그인에 대한 웹 지원을 어떻게 구현할 수 있을까? package:url_launcher 플러그인 패키지가 플랫폼별 구현 (ex. url_launcher_web)에서 요구하는 사항을 정확하게 설명하는 추상화를 생성합니다. 이 접근 방식은 플러그인 패키지가 플랫폼 구현과 통신하는 방법을 추상화하고 플러그인 패키지가 플랫폼에서 요구하는 동작과 데이터에 대한 설명으로 대체한다. 플러터 플러그인의 맥락에서, 우리는 이 추상화를 플랫폼 인터페이스라고 부른다
=> 요약하면 플랫폼 인터페이스를 통해 추상화하고 플랫폼 패키지의 요구사항을 만족하는 인터페이스를 만든다
url_launcher 플랫폼 인터페이스 밑그림
플랫폼 인터페이스의 예를 제공하기 위해서 package:url_launcher 플랫폼 인터페이스를 살펴보자. url_launcher의 첫번째 웹 구현은 메소드채널 설정이다. 메소드채널 설정은 url파라미터를 가진 launch 메서드를 호출하기 위해 리슨한다.그래서 플랫폼별 백앤드가 package:url_launcher 와 함께 작동하려면 Future launch(String url)을 구현해야한다.
url_launcher를 위한 합리적인 플랫폼 인터페이스는 다음과 같다
abstract class UrlLauncherPlatform {
Future<bool> launch(String url);
}플러그인과 플랫폼 인터페이스 통합
flutter/plugins 깃헙 레포에서, 우리는 연합 플러그인의 스타일에 적응해 왔다. 너는 모방해야한다 이 스타일을 만약 니가 풀리퀘를 랜딩하기를 원한다면 새로운 플랫폼 지원을 추가해라 공식적으로 지원되는 플러그인들중 하나가 새로운 플랫폼 지원을 추가하는것을 원한다면 플러그인을 새로운 연합플랫폼인터페이스 포멧으로 마이그레이션 해라 아래 3가지 단계면 된다.
-
_platform_interface 패키지 추가
-
플러그인이 플랫폼 인터페이스를 사용하도록 마이그레이트
-
_web 패키지를 추가해라 이 패키지는 플랫폼 인터페이스를 상속받는다.
이것이 실제 플러그인에서 어떻게 수행되는지에 대한 예제를 통해 작업해보자
예제: url_launcher 패키지 마이그레이팅
package: url_launcher
|
|
package:url_launcher_platform_interface
|
|
package:url_launcher_web플랫폼 인터페이스 패키지 생성
첫번째로, 우리는 플랫폼인터페이스 패키지를만들것이다, 그리고 존재하는 코드를 사용하기 위한 우리의 연합 플러그인 디렉토리 레이아웃을 재배열할것이다. 이 예의 목적을 위해서 우리는 레포 안의 플러그인이 배치되었다고 가정한다. flutter/plugins 깃헙 레포처럼(반면에 플러그인은 packages/url_launcher처럼 디렉터리 안에 플러그인이 살아있다). 구체적으로 우리는 이러한 레이아웃이 있다고 가정한다
- README.md
- packages/
- some_other_plugin/
…
- url_launcher/
- pubspec.yaml
- lib/
…
- android/
…
- ios/
…url_laucher를 하위 디렉터리로 이동시킴
$ git mv url_launcher url_launcher_tmp
$ mkdir url_launcher
$ git mv url_launcher_tmp url_launcher/url_launcher
$ git commit -m "url_launcher를 url_launcher/url_launcher로 이동"url_launcher_platform_interface 패키지 생성
package/url_launcher 마지막 단계에서 생성한 디렉터리로 이동합니다.
$ mkdir url_launcher_platform_interface
url_launcher_platform_interface를 실제 패키지로 만들기 위해 몇개의 파일을 추가해야합니다 라이센스 파일의 경우 일반적으로 git cp로 가져올 수 있다. CHANGELOG.md를 포함하는 파일을 만들어야합니다.
