一人(+α)のアドベントカレンダー初日(...途中寝落ちして、公開時間に間に合わなかったけど、、)。
Kotlin+RoboVMで挑む、クロスプラットフォーム開発試行錯誤。

なぜ、Kotlin+RoboVMなのか、あと、Swiftも学んでいる理由などを記す。

1)　クロスプラットフォーム開発　概況

いくつものスマートフォン向けのクロスプラットフォーム開発用言語の動きがあった2015年。

クロスプラットフォーム開発環境と言語の関係について私の視点(業務アプリ)で軽くまとめる:

By C# => Xamarin/Unity等 : 既に商用として定着。業務アプリもゲームも。
By (Alt)JS => Cordova/Monaca/Titanium/ReactNative等 : 群雄割拠。新参ReactNativeが盛り上がり。
By (Alg)Java => RoboVM等 : Android Studioベースの環境でのJVMベースの開発。近時インテルも参入
By Swift => Silver : VisualStudioベースでiOS/Android/.NET開発ができる(まだまだこれから)
その他 Ruby/C++/Haskell/ML系(Ocaml/F#)/Lisp系(Clojure他)/Scalaなどなども名乗り :Qtは昔使ったことがある。RubyMotion+Jruby,cocos-2dあたりがちょっと気になったことあり。

(注、"その他"のところは、前の項目と若干かぶっているし、自分には調べられてない)。

2) クロスプラットフォーム開発へのインセンティブ

クロスプラットフォーム開発を取り組む大きな理由は、iOS/Android/...向けの共通モジュールを活用することによる工数削減だろう。
でも、現実としては、クロスプラットフォーム開発ノウハウの獲得自体に相当の手間がかかる。加えて、変化を続けているiOS環境とAndroid環境(とその他の環境)を同時に相手にする以上、それぞれの環境をキャッチアップする手間もかかるのだから。だから、できることならば、開発、保守、追加開発...というアプリのライフサイクル全体に対する工数削減を実現したい。

既に、ゲーム業界では、C# & Unityベースでのクロスプラットフォーム開発を本業とする人々が多く生まれている。最近のゲーム業界というものにまったく疎いのだけれど、Unityでのクロスプラットフォーム開発に取り組む人々に"今風のゲームらしさ"のノウハウが、蓄積されているものとは想像できる。
今後も、iPhoneとAndroid(とその他)の併存が続くと考えられる中で、Unityプラットホーム自体が穏当な進化を続けるならば、Unityベースのクロスプラットフォーム開発コミュニティは維持されていくのだろうし、教育アプリなどをUnityで作ろうという動きも続くことだろう。

クロスプラットフォーム開発には、中長期的視点で取り組みたい。

3) クロスプラットフォーム開発の現実

JavaScriptでクロスプラットフォーム開発なTitaniumに取り組んだ人の書いたクロスプラットフォーム開発の辛みのような記述を、何度か目にしている。TitaniumでQtの人と、Xamarinの人のコメントも併せて読むと、興味深い。クロスプラットフォーム開発者にとって、自分が取り組む環境がどのように、クロスプラットフォーム開発の現実に付き合っているが、とても大事。あと、ハマりどころの情報共有も。

一般論としては、UI(View)周りのコードの共通化はかなり厳しく、ロジック周りのコードの実装の共通化ををクロスプラットフォーム開発のメリットとして捉えるべきということになるだろう。

付記 : WebView こわい!?

自分の場合、マイクロソフトのVisualStudio2015上のSilverなるSwift互換言語でちょっとしたAndroidアプリを作ってみようと考えた(経緯:イロモノHelloAndroid)時に、Titaniumの根幹と関わるwebviewは、今でも辛いところ多そうだなと改めて思った。

記録メモを少し書いておこう:

①初歩的ミス

Android StudioでwebViewを使ってみる！と同様のやり方をSwiftで書いてみたところ、new WebViewClient()のところでエラーが。
せっかくVisualStudioを使っているのだから、インテリセンスなるものにアドバイスを受けようとしたことろ、セミコロンを使ってみろとのアドバイス。

・・Swiftでセミコロンなわけあるか、バカちんが！、と思い、しばらくググッてから、気がついた。
そもそも、SwiftのClassはnewするわけでない...バカちんは自分だった...基本文法大切だね。

②Swift&Androidでwebviewのお試しコード

Swiftのコードだけど、import android...が並ぶとJavaっぽく見えるかな?

MainActivity.swift

import java.util
import android.app
import android.content
import android.os
import android.util
import android.view
import android.widget
//名前空間android.webkit以下のクラスをimport
import android.webkit

public class MainActivity: Activity {


    public override func onCreate(savedInstanceState: Bundle!) {

        super.onCreate(savedInstanceState)
        ContentView = R.layout.main
        var myWeb = findViewById(R.id.webView1) as! WebView
        //リンクをタップしたときに標準ブラウザを起動させない
        myWeb.setWebViewClient(WebViewClient())

        //最初にgoogleのページを表示する。
        myWeb.loadUrl("http://www.google.co.jp")

        //jacascriptを許可する
        myWeb.getSettings().setJavaScriptEnabled(true)
    }
}

AndroidManifestにインターネット接続のpermissionを与えると、webにアクセスできる:
<uses-permission android:name="android.permission.INTERNET"/>

...こうした試行の過程で、Android エンジニアが Android の WebView で苦しんだ話
を発見し、AndroidのWebView 今でもこわいとこあるだろうし、Titaniumプラットホームの開発チームも大変なんだろうなと改めて思った。実のところ、mithril.jsと組み合わせ、WebView SPA+Swiftでクロスプラットフォームなアプリを作ってみようかとも思っていたのだが、、、プロトは良いにしても、その後はやはり怖そうだ...((((；ﾟДﾟ))))

...ぁ、SwiftでAndroidアプリを作ってみること、現時点でもお試しとしては楽しいと思うよ。

4) 自分がクロスプラットフォーム開発に取り組みたい理由 : 音声インターフェイスの今後の進化

自分は、iOS/Android向けのクロスプラットフォーム開発の"べき論"を以下のように捉えている。

ロジック実装を共通化することのメリットが有る場合に取り組むべき。
iOSもAndroidもメジャーな開発環境が存在し、情報もたくさんあるのだからその情報を積極的に収集してUI/UX開発すべき

クロスプラットフォーム開発について悲観的な見解の典型は、快適なUI/Viewはプラットホーム依存だよ、というもの。

快適なUI/Viewはプラットホーム依存ということに、自分も同意する。iOS機のエンドユーザー、Android機のエンドユーザー、それぞれが経験してきたユーザー体験を大切にすべき。ただ、両環境のAPIへのラッパーがしっかりと書かれたクロスプラットフォーム開発環境であれば、ネイティブのAPIを活かしたUI/View実装が行える。

今後は、エンドユーザーにとっての快適なUI/UXという視点について、音声を用いたユーザーインターフェースについても意識すべきだ。iPhoneでSiriを使っている人は多いだろうし、Android環境には、Googleの音声アシスタンスに加え他の有力選択肢もある。

参考:
http://www.tabroid.jp/news/2015/04/ohayougo0156siri.html

私生活で自分はほとんど音声インターフェイスは使っていないのだが、屋外でヘルメット型端末を使う場合など、業務上、音声インターフェイスが求められる場合のUI/Viewを意識している。

加えて、このあたり、コールセンターの人工知能化のトレンドと併せて捉えるべきだ。
今後さらに高機能大容量化していくスマートフォンでは、その気になれば、高度な音声アシストインターフェイスを持ったアプリを実行できる。エンドユーザーからの特定の問い合わせに素早く応えたいユースケースにおいては、サーバー側ではなくスマートフォン側でコールセンター的な人工知能を走らせることが考えられる。自分は、コールセンター的な人工知能というロジックを、iOS環境とAndroid環境と、そして、サーバー側とで共有することにクロスプラットフォーム開発のメリットを見出している。快適な音声インターフェイスのロジックは肥大する、と自分は考えている。
..."コールセンター的な人工知能のロジック"...については、長くなるので次回以降に。

このメリットを活かすためには、iOS環境とAndroid環境それぞれのAPIに追従し、クロスプラットフォーム開発向けの言語で実装することを自分は厭わない。できれば、手慣れたJVM環境で。

5)そこで、まずは、Kotlin+RoboVMに挑戦する。

とはいえ、iOS環境とAndroid環境と、場合によっては、Windows10系の環境とを等しく扱うことは困難。
Swift/Objective-CのiOS環境からAndroid側に歩み寄るか、Java/AltJavaなAndroid環境からiOS側に歩み寄るか。

自分の現時点での結論は、AndroidStudioベースのクロスプラットフォーム開発環境RoboVMで、KotlinなるAltJavaを使うこと。

Googleが推すAndroidStudioベースの安心感。少なくともAndroid向けの実装は安心してメンテし続けられる。
AndroidStudio環境で容易に実行できるKotlinのちょうど良さ感。Javaと親和性が高く、言語表現はSwiftと似ている。仮に、iOS開発はSwiftネイティブで、となっても、Kotlinからの移行コストは低めのはず。
AndroidStudioベースでの商用開発環境の提供を始めたRoboVMチームが、Xamarinチームとジョインしたところ。

最後の一つは、"ん?"かもしれない。RoboVMは"商用環境"であって、AndroidStudioのように無償ではない(試用期間はあるが、気軽に試すことに抵抗を感じる人がいるだろう)。また、Qtのように古くからある環境とくられると、"商用を始めた"ばかりなのも事実。当面は辛いのでは、と思う人もいるだろう。あとは、Xamarinって語感がなんとなく怖い...とか。

このあたりの"ん?"に応えていく試行錯誤を、この一人アドベントカレンダーで晒していきたいと思う。
Kotlinの良い所などを随時記しながら。適宜、Swiftで書いたコードと比較したりもする予定。

本日はこのあたりで。

現実的な業務アプリ向けクロスプラットフォーム開発環境を選定したい。

1) クロスプラットフォーム開発 概況