blogAndroidとか技術とかその他気になったことを書いているブログ。世界の秘密はカレーの中にある!サンフランシスコから発信中。めぐる状況と個人的見解について書きます。クロスプラットフォーム開発フレームワークと比べたいという方の参考になれば幸いです。フラットに書くことを意識していますが、いち利用者としてのバイアスがあることをご了承ください。ここ一年で劇的に向上していて、特にプロジェクトの立ち上げ~機能開発までのプロセスはネイティブコードによる開発を上回っていると感じています。大きくは下記のような改善がありました。保存したときに特定のコンポーネントに対して変更を適用させる機能です。うまく動かず、開発者によってしばしばオフにされる機能でした。以下のような機能を備えています。サポートされています。よってストレスなく開発できるようになりました。ネイティブをラップしたサードパーティ製のライブラリを導入する場合、ネイティブのライブラリ設定を更新する必要がありました。クラスにそれぞれパッケージを追加するコードを書く必要があります。より自動的に書くことができるのですが、うまく動かないケースや追加で設定が必要なケース(推移的な依存関係の解決など)もあって、面倒な作業のひとつでした。ライブラリ追加だけで依存関係は解決されるようになります。標準で採用になりました。プロジェクト設定を書き換えたりする必要がしばしばあり、環境設定の複雑さを増していました。必要とするライブラリが導入しやすくなるといったメリットもあります。時間は短縮されました。環境構築やアプリのリリースは容易になりました。導入は必要ですし、さらにアプリのリリースについてはネイティブの知識もある程度求められます。なしに開発を始められるだけでなく、アプリの配布、リリース機能まで提供しています。使われているため、最新の機能を使うためには少々待つ必要がありますが、ちょっとしたアプリや動作検証は他のどのプラットフォームよりも速く作れるんじゃないかと思います。フレームワーク/アーキテクチャフレームワーク・アーキテクチャに関してもこの一年で大幅なアップデートがありました。課題としてレポジトリサイズの巨大化や内部構造の複雑化がありました。内部の複雑さやレガシーコードは問題で、一部の機能変更によって全体が影響を受けるために修正に時間がかかるケースが度々あったようです。そこでコア機能以外は切り離し、コミュニティで管理するようなスリム化が実施されました。受けつけ、バグ修正/リリースなどのメンテナンス性が向上したと述べられています。対して大きく劣っていました。チームが本腰を入れてきたようです。倍近く高速化されました。サポートがコミュニティの協力のもと実施されています。記述が簡易化されたことが素晴らしいなと思います。v0.59)で対応しています。起因のバグを踏んだ場合の調査を難しくしていました。沿ったバージョンが設定されるようになっています。指定することができます。コミュニティ作りに力を入れた年でもあります。非常に話題になり、開発者から多くの意見があつまりました。返答が投稿され、対応事項の優先順位がつけられました。放置されがちだったのですが、現在では継続的にレビュー/マージが実施されるようになっています。時点)に増え、ますます活発になってきていると言えます。移譲された結果、多くの個人管理されていたライブラリもこの傘下に入りました。この結果、破壊的変更を伴うような更新についてコミュニティが足並みをそろえて対応できるようになり、混乱が避けられるようになりました。上で対応方法及びルール作りの策定が行われ、コミュニティにより新たなツールが実装されました。設定ファイルの記法についてもそれらを参考に統一が図られるようになってきています。進化した一年でしたが、一方で未だに抱えている課題もあります。メジャーバージョンアップの噂がありません。インタフェースが安定しない、後方互換を壊す修正がいつ何時入るかわからないという点で開発者としては若干不安になります。configuration"といったコメントがしばしば見受けられます。色々な依存関係と複雑な設定が開発者をよく苦しめます。バージョン更新を怠るだけでビルドすら通らなくなることもザラです。よって少しずつ改善されてきていますが、メンテが遅れているライブラリで生じる不具合も非常に多いです。採用すべきですか」といった質問やアドバイスを求められたりするので、個人的な選定基準について触れておきます。ラーニングコストはかなり低くなるので非常におすすめです。エンジニアが肩代わりすることができるので、選択を視野に入れてよいと思います。利用するかも大きな判断基準になります。スタンダードですが、このライブラリで実現できる以上のことを実装したい場合は、ネイティブ実装は避けられないでしょう。モジュールの制約でネイティブライブラリをそのまま利用できないことがよくあるので、ネイティブの低レイヤー知識と経験*1が求められます。使うメリットは薄いので、いっそのことネイティブで実装したほうが長期的には良いと考えます。するハイブリッドアプリは全くおすすめしません。間の画面遷移の実装難度です。間でやり取りする必要があり、実装が容易に複雑化します。データトラッキングなども橋渡しの実装が必要になったり余計な工数が増えがちです。側で実装したほうがはるかに工数は少なく済むでしょう。配信も可能なのでイテレーションも高速に回せます。関してはネイティブと区別がつかないレベルであると言えます。採用している例もあります。方が開発体験も向上し品質もネイティブと遜色ないものが実装できると思います。ついては便利な反面、中長期的に見ると技術負債になると考えています。Eject(ライブラリを自分で管理する設定に切り替える)すると不要なライブラリの依存関係に苦しめられることになります。ネイティブの乗り換えるべきでしょう。開発方法の改善について議論が進められており、今年も引き続き活発に開発が続けられそうです。世界は意外と近いのかもしれません。contributionsはてなブログをはじめよう!tomoima525さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。