構造化プラットフォームAPIの調査(Android / iOS / Windows)
okuoku現代的なOSは何らかのCでない高級言語の上にOS APIを構築し、その言語の利用を強制することである程度妥当なプログラミング体験を得られるようにしている:
- Android - Java - Kotlin
- iOS - Objective-C - Swift
- Windows - (COM) - C#
これらの標準言語を使用しないケースでは何らかの方法でバインディングを用意する必要がある。
サマリ
バインディングは手動を基本としている 。バインディングに使用できそうなメタデータ(Androidの api.xml 、 iOSのBridgeSupport XML)が用意されているケースがあるがそれらの品質は悲惨で、手動での補正が必要になっている。
そもそも下火である 。開発者を囲い込むためプラットフォーマーはポータビリティを意識していない。
手動での補正を無くせないか
手動での補正はIDEの補完やターゲット言語(C#とかPython)でのnaming conventionのために行われることが多いように見える。これらを諦めることで手動での補正を減らしたり無くしたりすることは可能なんではないかという気はする。
okuokuAndroid
Xamarinは伝統的な jar2xml とより新しい class-parse の2つのバインダを提供している。 jar2xml は .net6移行時に廃止予定。
メタデータの手動補正ぶんは https://github.com/xamarin/xamarin-android/tree/51f56aacd9946231672f8c173e265bfe68cb52da/src/Mono.Android の metadata や *.csv にある。
今のところGoogle公式のライブラリにはKotlin専用のものは無いため、jar2xmlにひたすら掛けていけば、とりあえずAPIを呼べる程度のものは出てくるのではないだろうか。。？
okuokuiOS / macOS
MonoTouch 時代からの伝統 btouch が依然存在する。これはAPI定義を .cs ソースコードで書き、それを渡すことで適当なバインディングを生成してくれる。この元の .cs コードを生成するツールとしてはObjective Sharpieがある。
Objective Sharpieは内部的にはClangを使っているらしい -- ソースコードが無い。
... これだったら普通にClangにASTをjsonなりなんなりで出力させてパースするのとそんなに変わんない気がする。
okuokuWindows
WinRTには仕様として.winmdファイル、また通常のC APIにはWin32 metadataプロジェクトがある。
もっともMSはあまりOSプラットフォームとしてのWindowsを推していないのであまり重要ではないだろう。