2012-02-07 11 views
8

私はAndroidライブラリプロジェクトに同じアプリ(有料/無料)の異なるバージョンのコードをリファクタリングしていますので、実際のアプリは単にライブラリをカスタマイズしてコードの重複を減らすことができます。Androidライブラリプロジェクト - コンテキストを取得する方法

私が不思議に思っていることの1つは、ライブラリーコード内の意味はgetApplicationContext()です。それは同じですApplicationContextは、子供のアプリから得るだろうか?元のアプリのgetApplicationContext()ではなく、ライブラリプロジェクトのgetApplicationContext()からSharedPreferencesにアクセスするとどうなりますか? SharedPreferencesファイルは同じでも異なっていてもかまいませんか?

アクティビティを使用してSharedPreferencesにアクセスした場合はどうなりますか?アクティビティがライブラリアクティビティであり、元のアプリではないことが重要ですか? SharedPreferencesは同じですか?

ご清聴ありがとうございます。

答えて

13

APKをパッケージ化した場合、すべてのクラスがメインのアプリケーションに属するだろうがあるので、一つだけのアプリケーションがあります。

getApplicationContext()。getPackageName()を呼び出すと、ライブラリのパッケージではなく、アプリケーションのパッケージ名が返されます。

私は無料/有料のアプリケーションと同じ設定をしており、クラスをライブラリプロジェクトに移動しても問題はありません。

ただし、ライブラリプロジェクトの完全なパッケージ名を使用するには、XMLファイル(マニフェスト、ウィジェットなど)をチェックする必要があります。

+0

私はいくつかのテストを行い、SharedPreferencesが影響を受けていないことを確認しました。 getPackageName()は、子アプリケーションのパッケージを返します。 Googleは図書館のための限定されたドキュメントを提供しています。 – amit

+0

私の場合、SharedPreferencesが影響を受け、それぞれの場合に 'getPackageName()'が同じ結果を返しました。しかし、 'context.toString()'には違いがありました。 –

1

ライブラリプロジェクトは、ほぼすべてのコードを1つのプロジェクトに持つようなものです。名前空間には注意が必要ですが、一般的にはうまくいきます。

あなたのライブラリーは、独自の名前空間は、メインアプリからTROアクセスしたいライブラリーでuk.co.app

活動をする必要が=

ライブラリパッケージ名= uk.co.lib メインアプリのパッケージ名を持っていますアプリケーションマニフェストに追加されました。ライブラリプロジェクトにAという名前の活動は、このようにメインアプリでマニフェストに追加されます:

<activity android:name="uk.co.lib.A"> 

へのアクセスの共有設定などは、いずれかの名前空間から同じ結果を与えるだろうし、アプリのプリファレンスを返します。

一つだけのApplicationContext

関連する問題