인앱 (데이터팩) 플러그인 아키텍처 패턴: 모듈 + Dynamic Delivery ???

Question

미술관 관람 앱을 제작 중입니다. 

사용자는 6개 미술관 x2 (유료, 무료)의 플러그인 (미술관 데이터 팩 = 이미지+db)을 인앱 구매 설치하게 됩니다.

1개 미술관 기준으로 대부분의 기능을 구현하고, 추후 확장 팩을 위해 리팩토링하고 있습니다.

[ (미술관 관람) 코어 앱모듈 + (미술관 데이터 팩) 라이브러리 모듈 플러그인 + 인앱 ] 을 생각하고 있는데,

어떤 구조로 가면 좋을까요?

플러그인 아키텍처 패턴이 있던데, 이게 괜찮을까요? 

아니면, 2018 에 나온 Dynamic Delivery (Dynamic Feature Module) 이 좋을까요?

구닥다리와 신삥 기술 사이에서 헤메는 기분입니다.

고맙습니다.

 

Comments

Dynamic Delivery 는 신기술이라 보류하고, 플러그인 아키텍처로 하렵니다.
일단 다음 자료를 뜯어 보고 있는데, 너무 오래됐네요.
http://mylifewithandroid.blogspot.com/2010/06/plugins.html

Answer 1

"Plugin Framework/Architecture Pattern" 관련 수집한 정보를 공유합니다.

# 플러그인 아키텍처 기본 개념
+ https://speakerdeck.com/appfoundrybe/cross-app-communication-and-plugin-architecture-in-android
- Cross-app Communication: Intent/BrReceiver, ContentPr, Services
- UserPI Discovery: CoreApp Hardcode Ref. / term / JSON / WebView
- HostAppPI Discovery:  PackageManager, P.Broadcasts
- PI Communication: MetaData, B.Receiver ->
- Remote Service Binding: P.Manager, AIDL protocol -> IPC
- GUI PI: WebViews, RemoteV., ownParcelable,
- Validation in Host
- Security: use signature level permissions

 

# 가능한 대안 (Java)

+ "Rolling your own" plugin framework
+ java.util.ServiceLoader
+ Java Plugin Framework https://github.com/pf4j/pf4j   http://jpf.sourceforge.net/
+ OSGi - Dynamic Module System for Java
+ https://bndtools.org/
+ META-INF/services/* / the Java Service Provider Interface.
+ https://sourceforge.net/projects/platonos/files
+ Plugin Framework for Java (PF4J) http://www.pf4j.org
+ Jin-Plugin - https://code.google.com/archive/p/jin-plugin/

참조:
ww.reddit.com/r/java/comments/9z96fb/recommended_way_to_implement_plugin_architecture/
https://stackoverflow.com/questions/1613935/java-plugin-framework-choice
https://stackoverflow.com/questions/465099/best-way-to-build-a-plugin-system-with-java

 

# Android Plugin Framework Tutorial
+ Service Based Plugin Framework (2010)
mylifewithandroid.blogspot.com/2010/06/plugins.html
-- PluginApp + PluginPackages(2PI) + DynamicDepolyment
-- plugin = service -> Intent(PICK_PLUGIN): category(manifest)  <- Android PackageManager
+ Plugins with user interface (2011)
mylifewithandroid.blogspot.com/2011/01/plugins-with-user-interface.html
+ Invoking Services (2008)
mylifewithandroid.blogspot.com/2008/01/invoking-services.html
+ Better practice? (trade secrete issue...)
stackoverflow.com/questions/20388354/plugin-architecture-via-service-alternatives
+ http://androidsrc.net/creating-android-app-plugin-architecture-tutorial/
- https://github.com/pritamworld/PluginAccessApplication
- AIDL interface +  interprocess communication (IPC)
- Main App (host) + 2 Plug-Ins (services)
- Identify the plug-Ins: Intent (androidsrc.intent.action.PICK_PLUGIN)
- Attach an intent filter listening to the intent in plugin’s AndroidManifest.xml (Category List)
- Android PackageManager: PI list + Category
- Pluginapp updates the plugin list: ACTION_PACKAGE_ADDED, ACTION_PACKAGE_REMOVED and ACTION_PACKAGE_REPLACED intents

 

# 플러그인 관련 디자인 패턴 Pugin Design Pattern
- https://ko.wikipedia.org/wiki/옵서버_패턴 : 상태변화통지
- 중재자 https://m.blog.naver.com/2feelus/220658501378 : 상호작용 캡슐화(M:1) 매니저? - 중재자 Mediator (API) / 구현체 Concrete M. / 동료 Colleague  https://copynull.tistory.com/145
- 커맨드 https://moonshoo.tistory.com/5 : 메소드 캡슐화 /지연 /분리 - 명령자와 실행개체 분리 인터페이스화 :요청자-작업자 //  명령command /수신자receiver /발동자invoker /클라이언트client
- 메멘토 https://daru-daru.tistory.com/68 실행취소 롤백 originator, memento, caretaker  https://palpit.tistory.com/205

 

# Android PlugIn Framework Sources
github.com/romannurik/dashclock
github.com/romannurik/muzei
github.com/reshaping-the-future/better-together
github.com/Qihoo360/DroidPlugin
Dynamic Loader https://android-arsenal.com/details/1/2828
VirtualApp https://android-arsenal.com/details/1/3856
Virtual APK https://android-arsenal.com/details/1/6302
routerSDK https://android-arsenal.com/details/1/5332
https://github.com/geometer/FBReaderJ-plugin-tts
https://github.com/mmin18/AndroidDynamicLoader
https://github.com/DroidPluginTeam/DroidPlugin