2011年12月13日

[Android][翻訳] Android SDK Tools r14でのライブラリプロジェクトへの変更点

2度目の翻訳です。
英語の勉強のつもりで訳し始めましたが、これは1ヶ月半もかかってしまいました。
(大半は3DSでマリオを遊んでいたせいですが)
英語の初級者にこの分量は無理があるような気がしてきました。
すでに未訳の記事が10件ほど…。
全部訳すのか、それとも記事を選択して訳すのか、考えたいと思います。


元の記事
http://android-developers.blogspot.com/2011/10/changes-to-library-projects-in-android.html

--------------------------------

25 OCTOBER 2011

Posted by Xavier Ducrohet, Android SDK Tech Lead at 11:30 AM

Changes to Library Projects in Android SDK Tools, r14

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


Last week, we released the SDK for Android 4.0 and a new set of developer tools, now in revision 14. The updated tools include a lot of build changes, many that improve build performance. Also included is an under-the-hood change in how libraries are used by main projects − a first step in improving library support and code reusability. While the change should have little impact on existing projects, some developers have had issues when migrating to the updated tools. Please read below for more information about the change to library projects and how to solve migration issues.


先週、私たちはAndroid 4.0 SDKと新しい開発者ツール一式をリリースしました。リビジョンはもう14になります。
このアップデートされたツールには多くの変更点が含まれます。その多くはパフォーマンスの改善が行われています。
メインのプロジェクトから利用されるライブラリの使い方のような内部的な変更も含まれます。
ライブラリのサポートとコードの再利用性を改善することはその第一歩です。
その変更は既存プロジェクトに少し影響を与えます。いくらかの開発者たちはアップデートされたツールに移行するときに問題を抱えます。
ライブラリプロジェクトの変更点と移行の際の問題の解決方法についての詳細は以下をお読みください。


Previously, library projects were handled as extra resource and source code folders to be used when compiling the resources and the application’s source respectively. While this worked fine for most cases, there were two issues.

これまで、ライブラリプロジェクトはリソースやアプリケーションのソースをそれぞれコンパイルする際に使用される別のリソースやソースコードフォルダとして処理されていました。
多くの場合問題なく動作しますが、2つの問題がありました。

1. Developers asked us for the ability to distribute a library as a single jar file that included both compiled code and resources. The nature of Android resources, with their compiled IDs prevented this.

1. 開発者たちは、コンパイルされたコードとリソースを含む単一のjarファイル形式のライブラリに分割してできることを私たちに訪ねます。
Androidのリソースの性質上、コンパイルされたIDがそれを阻みます。

2. The implementation of the library projects was extremely fragile in Eclipse. Adding extra source folders outside of the project folders is non-trivial when it needs to be handled automatically, in a way that doesn’t expose a user’s local installation path (which is required for people working in teams through a source control system such as SVN or git).

2. ライブラリプロジェクトの導入はEclipseの中でとても不安定です。プロジェクトフォルダの外側に自動的に処理される必要のある別のソースフォルダの追加することは簡単ではありません。ユーザーのローカルなインストールパスを見る方法がありません(それにはSVNやgitのようなソース管理システムを通して同じチームで作業している必要があります)。

For r14, we decided to fix both issues at once, by moving to a compiled-code based library mechanism. This solves the implementation fragility in Eclipse and will allow us to, later, enable distribution of libraries as a single jar file.

r14では、コンパイルされたコードを基本としたライブラリ構造に変更することで、私たちはこの2つの問題を一度に修正することにしました。この修正はEclipseにプロジェクトを導入する際の不安定さを解決しました。そして、後には単一のjarファイルでのライブラリの配布ができるようになるでしょう。

As you might have seen in the release notes, moving to this new mechanism can affect existing projects in some cases, but there are simple fixes.

あなたはこの新しいライブラリ構造への移行はいくつかの既存プロジェクトに影響を与えること、しかし、簡単な修正で済むことをリリースノートで確認する必要があるでしょう。

The first impact of this change is that the new library project requires the resource IDs generated by libraries to be non final. This prevents the Java compiler from inlining the values in the library code, and therefore prevents usage of the switch statement in the library code. To address such occurrences in your code, Eclipse provides a refactoring action to convert fromswitch statements toif/else (see here).

この変更による最初の影響は、新しいライブラリプロジェクトが要求するライブラリによって生成されたリソースIDがfinalではなくなることです。これによってJavaコンパイラがライブラリ内で値をインライン化できなくなります。また、このことによってライブラリ内ではswitch文にリソースIDを使うことができなくなります。あなたのコードでそのようなことが起こったときの対処法としては、Eclipseの提供するリファクタリング機能によって、switch文からif/else文に変換することができます。
(こちらを確認してください)

Second, some projects may not have been properly migrated to the new
mechanism, resulting in projects that fail to compile, with errors such as duplicated classes being added in the dex build step. ADT 14 should have migrated older projects to the new mechanism but the fragility of the old mechanism may have prevented it from happening. This makes projects reference the libraries twice, using both the old and new mechanisms, which then triggers the libraries classes being packaged twice. If you see this in your projects, look in the Package Explorer for extraneous source folders named with the pattern_src. The screenshot to the right shows an example of this.

2つ目に、いくつかのプロジェクトでは新しい構造にプロパティを移せないかもしれません。結果として、そのプロジェクトはコンパイルに失敗します。例えば重複したクラスが、dexを作成する段に追加されるなどのエラーが起こります。
ADT14では、古いプロジェクトを新しい構造へ移行すべきでしたが、古い構造の不安定さのためにそれはできないかもしれません。
これは作成するプロジェクトが、新旧両方の構造を使用するために、ライブラリを2度参照します。そして、ライブラリのクラスは2度パッケージされてしまいます。
これについてあなたがプロジェクトを確認するのなら、パッケージエクスプローラで_srcという形式で名付けられた外部ソースフォルダを見てください。右のスクリーンショットはその例です。

(画像は元のサイトを見て下さい)

To fix the project, you must remove the extraneous source folders with the following steps:

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

Right click source folder and choose Build Path > Remove from Build path A dialog will pop up. In it, make sure to check “Also unlink the folder from the project” to completely remove the folder.

ソースフォルダを右クリックして、Build Path > Remove from Build pathを選択するとダイアログが表示されます。その中で、“Also unlink the folder from the project”がチェックされていることを確認してください。それでフォルダの削除は完了です。

With this change to library projects, we pave the way to better support for reusable components. We will continue working to make components easier to create, work with, and manage. Our goal is to make it easy for developers to create apps with great user experiences that easily adapt to all form factors.

これによってライブラリプロジェクトが変更され、私たちはコンポーネントの再利用のためのより良いサポートができるようになります。
私たちは継続して、作成や作業、管理が簡単になるようなコンポーネントを作成していきます。
私たちの目標は開発者がすべての要因に簡単に適応できる素晴らしいユーザ体験をもたらすアプリを作るのを容易にすることです。

Some developers have also told us that they only use library projects internally, that they don’t need to distribute binary versions and would prefer to continue with a source-based mechanism. We are investigating how we could support this alongside the new mechanism.

一部のの開発者は、内部でのみ使っているライブラリプロジェクトについてバイナリーバージョンで区分する必要がないこと、そしてソースベースの構造を継続できる方を好むだろうということも私たちに話してくれました。
私たちは新しい構造ついてと並行してどのようなサポートができるのかを研究しています。

Finally, I wanted to point out that we are tracking a few known issues (and workaround for them) in the current r14 tools at this page: http://tools.android.com/knownissues.

最終的には、このページ(http://tools.android.com/knownissues)で、現行のr14ツールのいくつかのの既知の問題を追いかけていること(それと、その回避方法)を見てもらいたいと思っています。

We are working on a tools update that will include fixes for most of these. We are hoping to have it out shortly.

私たちはツールのアップデートに取り組んでいます。そのほとんどが修正の取り込みです。私たちは近いうちに決着をつけられることを望んでいます。
タグ:翻訳 android
posted by t2low at 22:58| Android