_development,

Android SDK Tools r14でのライブラリープロジェクトの変更

android

Changes to Library Projects in Android SDK Tools, r14を訳してみました。

要点

• ライブラリープロジェクトのIDがfinal定数じゃなくなったので、switch使ってたところは必要に応じてEclipseのリファクタリング機能でif/elseに置き換えてね
• ツールのアップデートでライブラリープロジェクトがおかしくなることがあるので、手順に従って修正してね
• 以前のバージョンの振る舞いを共存させられないかは、調査中だよ

以下、訳

(@zaki50さんによる翻訳のほうが正確なため、そちらを読まれることをおすすめします)

　先週、私たちはAndroid 4.0用のSDKと新しい開発ツール一式(revision 14)をリリースしました。

アップデートされたツールは多くのビルドの変更、ビルドのパフォーマンスの向上を含んでいます。

　そしてまた、ライブラリーのメインのプロジェクトからの使われ方に対する、ある内部的な変更を含んでいます。

　これは、ライブラリーのサポートとコードの再利用性の向上のための第一歩です。

　この変更は、既存のプロジェクトに小さな影響があります。

いくらかの開発者は、更新されたツールへのマイグレーションで問題が発生しています。

　このあと説明する、ライブラリープロジェクトに関する変更と、マイグレーションの問題の解決方法を読んでください。

　以前、ライブラリープロジェクトは、アプリケーションのリソースとソースコードをコンパイルするための、追加のリソースとソースコードのフォルダーとして使われていました。

　ほとんどのケースでは、これはうまく動きましたが、２つの問題がありました。

1. 私たちは開発者のみなさんから、コンパイルされたソースコードとリソースを含んだ単一のjarファイルとしてライブラリーを配布できないか聞かれました。Androidのリソースの特徴であるコンパイルされたIDがこれを阻止していました。
2. ライブラリープロジェクトの実装は、Eclipse上ではとても不安定でした。プロジェクト内のフォルダではない、外部の追加のソースフォルダーを自動的に処理するのは困難です。（ユーザーのローカルのインストレーションパスを意識しないで行う場合？）

　r14では、私たちは、コンパイル済みコードを基にしたライブラリーのメカニズムによって、双方の問題を一度に解決する決断をしました。

　単一のjarファイルとしてライブラリーを配布することによりEclipseでの不安定な実装は解決するでしょう。

　あなたはすでにリリースノートを見たかもしれません。　この新しいメカニズムへの移行はいくつかのケースで既存のプロジェクトに影響を及ぼします。しかし解決は簡単です。

　この変更による最初の影響は、新しいライブラリープロジェクトはリソースIDをfinal修飾子をつけずに生成することです。

　これは、Javaコンパイラーが、ライブラリーのコードの値をインライン化できないことを意味します。つまり、ライブラリーの(IDによって分岐する処理の)コードにはswitch文を使うことはできません。

　これに対するには、Eclipseが提供しているリファクタリング機能を使って既存のIDに対するswitch文をif/elseに変換します。

二番目の影響は、いくつかのプロジェクトは新しいメカニズムにうまくマイグレートできないことです。

プロジェクトは、dexビルドのステップで重複したクラスが追加されようとしている旨のエラーでコンパイルに失敗します。

　ADT 14　は、古いプロジェクトを新しいメカニズムにマイグレートしますが、古いメカニズムの不安定さによりこの現象が起こります。

　この現象は、プロジェクトを古いメカニズムと新しいメカニズムの両方で、ライブラリーを二度参照するようにしてしまいます。

　この現象に遭遇したら、Package Explorerで、<libraryname>_srcという名前の外部ソースフォルダーを見つけてください。

　スクリーンショットは、その例です。

この現象からプロジェクトを修正するには、次の手順で外部ソースフォルダーを削除する必要があります。

1. ソースフォルダーを右クリックして、BUild Path > Remove from Build pathを選択します。
2. ダイアログがポップアップします。フォルダーを完全に除去するために、"Also unlink the folder from the project"をチェックしてください。

　このライブラリープロジェクトの変更によって、私たちは再利用可能なコンポーネントのための、より良いサポートの下地をつくりました。

　私たちは、より簡単にコンポーネントを作れるように、取り組みを続けます。

　私たちの目標は、開発者が素晴らしいユーザー体験をもたらす、すべてのフォームファクターに適合するアプリケーションを簡単につくれるようにすることです。

　いくらかの開発者はまた、ライブラリープロジェクトは自分たちのプロジェクトだけで使っていると言いました。　彼らにとってはバイナリーバージョンの配布は必要ではなく、ソースを基にした今までのメカニズムの方が好ましいのです。

　私たちは、新しいメカニズムで、どうやってこれをサポートするか調査しているところです。

　最後に、このページ(http://tools.android.com/knownissues)で、私達がトラッキング（とその修正作業）している、現在のr14ツールの少しの既知の問題について目を通してください。

　私たちはツールに対して、これらのほとんどを修正するアップデートの作業中で、近いうちにリリースしたいと思っています。

ツイートする

Permalink | コメント(0) | トラックバック(0) | 09:57