AndroidではSharedPreferencesとPropertiesのいくつかの組み合わせが使用されています
最近暇になって、会社の製品クライアント全体は基本的に安定した商業化の運行に入った.
後で処理するのは、パートナーとのバージョン管理です.
例えば、A、B、Cの3つのパートナーは、応用上、モデル全体が基本的に変わらず、次のいくつかの伝達パラメータを変更したり、応用自体の設定パラメータを変更したりする可能性があります.
もちろん、これは簡単です.アプリケーションごとにパッケージ化する前に、死んだ商家のバージョン番号を修正すると言ってもいいかもしれません.
その後、卵の痛みを比較する需要が提案されました.私たちが応用したトップページやインタフェースの表示順序をコントロールすることができます.
理論的にはリスト表示制御も簡単です.つまり、私のすべての情報はサービス側から取得され、順序などの制御が完了しています.
完全にサービス側に置いて完成することができます.
しかし、これはまた1つの問題を考慮して、1つの需要で、もしネットがない場合、私は戻っていない情報で、インタフェースは空白ではありませんか?
解決するなら:1.キャッシュは考慮できますが、ネットワークがない場合は最後に保存した内容を読み込みます.しかし、当社の製品のトップページ情報は、リアルタイムで操作されるものであり、そのようなものではありません.
ニュースアプリケーションは、ユーザーの操作には影響しません.
2.デフォルトのインタフェース構成を設定します.すなわち,ネットワークがない場合には,少なくとも,埋め込みコンテンツがない場合には,指定されたピクチャおよびプロンプトの文字表示を表示することができる.
では、この構成情報を1つの構成ファイルに書くことができ、アプリケーションのインストール時に書き込みの好みを書くことができます(なぜ書き込みをするのかについては、もちろん、次回の読み取りパラメータレートを適用することを考慮するためです.)
以下は、私たちが自分のニーズを応用して実現した簡単な構想です.
Step 1:assetsファイルの下にpropertiesファイルを作成し、構成バージョン番号を書き込む(このソートはクライアントにとってリスト表示ソートの問題に関連するため、
パッケージを適用した後、それは死んでしまいました.その後期は本当にソートを変更する必要があります.例えば、人気リストが上下に変動した場合、私はサービス側でコントロールするしかありません.)
このバージョン番号の機能は、アプリケーションの起動時にサービス側に最新のプロファイルを取得することです(つまり、サービス側にも対応するバージョン番号があり、同じ場合はフラグ値を返し、異なる場合は最新の構成を返します).
Step 2:app起動時に、判断してpropertiesファイルをSharedPreferencesに書き込むと、アプリケーション起動のたびに書き込むことはできないでしょう.
このような操作も合理的ではありません.すなわち、プロファイルが書き込まれたかどうかを判断するためにフラグビットが必要です(すなわち、プロファイルはインストールを適用するときに一度だけ書き込むだけです).
ではconfigstatusを設定して判断しましょう.
この時、また一つの問題が起こります.もし私がアップグレードを適用したら、私の知っている限りでは、今あなたがアップグレードを適用して上書きした後、好みのファイルはすべてあるようです.つまり、アンインストールがはっきりしていないので、
では、新しいバージョンのプロファイルはconfigstatusが存在すると判断したため、書き込まれません.
そこでタグビットを考えていますが、こちらではバージョン番号を適用しています.アップグレードするたびにバージョン番号が変更されると、アップグレード後にpropertiesファイルを再書き込みする必要があると判断できます.
以上が書き込み判定コードです.
Step 3:トップページに適用すると、リスト額の表示順序が好みから取得できます
基本的な流れはこうです.
バージョン番号が違う場合は、好みを更新します
これにより,サービス側がリストを制御する順序ができ,ネットワークがない場合にデフォルトリストを表示できるという問題が解決される.
当社のような同じアプリケーションのマルチバージョンの場合、プロファイルの導入はより迅速かつ明確に制御されます.
後で処理するのは、パートナーとのバージョン管理です.
例えば、A、B、Cの3つのパートナーは、応用上、モデル全体が基本的に変わらず、次のいくつかの伝達パラメータを変更したり、応用自体の設定パラメータを変更したりする可能性があります.
もちろん、これは簡単です.アプリケーションごとにパッケージ化する前に、死んだ商家のバージョン番号を修正すると言ってもいいかもしれません.
その後、卵の痛みを比較する需要が提案されました.私たちが応用したトップページやインタフェースの表示順序をコントロールすることができます.
理論的にはリスト表示制御も簡単です.つまり、私のすべての情報はサービス側から取得され、順序などの制御が完了しています.
完全にサービス側に置いて完成することができます.
しかし、これはまた1つの問題を考慮して、1つの需要で、もしネットがない場合、私は戻っていない情報で、インタフェースは空白ではありませんか?
解決するなら:1.キャッシュは考慮できますが、ネットワークがない場合は最後に保存した内容を読み込みます.しかし、当社の製品のトップページ情報は、リアルタイムで操作されるものであり、そのようなものではありません.
ニュースアプリケーションは、ユーザーの操作には影響しません.
2.デフォルトのインタフェース構成を設定します.すなわち,ネットワークがない場合には,少なくとも,埋め込みコンテンツがない場合には,指定されたピクチャおよびプロンプトの文字表示を表示することができる.
では、この構成情報を1つの構成ファイルに書くことができ、アプリケーションのインストール時に書き込みの好みを書くことができます(なぜ書き込みをするのかについては、もちろん、次回の読み取りパラメータレートを適用することを考慮するためです.)
以下は、私たちが自分のニーズを応用して実現した簡単な構想です.
Step 1:assetsファイルの下にpropertiesファイルを作成し、構成バージョン番号を書き込む(このソートはクライアントにとってリスト表示ソートの問題に関連するため、
パッケージを適用した後、それは死んでしまいました.その後期は本当にソートを変更する必要があります.例えば、人気リストが上下に変動した場合、私はサービス側でコントロールするしかありません.)
このバージョン番号の機能は、アプリケーションの起動時にサービス側に最新のプロファイルを取得することです(つまり、サービス側にも対応するバージョン番号があり、同じ場合はフラグ値を返し、異なる場合は最新の構成を返します).
Step 2:app起動時に、判断してpropertiesファイルをSharedPreferencesに書き込むと、アプリケーション起動のたびに書き込むことはできないでしょう.
このような操作も合理的ではありません.すなわち、プロファイルが書き込まれたかどうかを判断するためにフラグビットが必要です(すなわち、プロファイルはインストールを適用するときに一度だけ書き込むだけです).
ではconfigstatusを設定して判断しましょう.
この時、また一つの問題が起こります.もし私がアップグレードを適用したら、私の知っている限りでは、今あなたがアップグレードを適用して上書きした後、好みのファイルはすべてあるようです.つまり、アンインストールがはっきりしていないので、
では、新しいバージョンのプロファイルはconfigstatusが存在すると判断したため、書き込まれません.
そこでタグビットを考えていますが、こちらではバージョン番号を適用しています.アップグレードするたびにバージョン番号が変更されると、アップグレード後にpropertiesファイルを再書き込みする必要があると判断できます.
private ConfigurationUtils(){
sp = mContext.getSharedPreferences(Constant.CONFIGURATION_FILE_NAME, Constant.CONFIGURATION_FILE_MODE);
if(!exsitSharedPreferences()){
LogUtil.log("ConfigurationUtils", "SharedPreferences , ");
defaultProperty = new Properties();
file2SharedPreferences(defaultProperty,sp);
}
};
static class Holder {
static ConfigurationUtils instance = new ConfigurationUtils();
}
public static ConfigurationUtils getInstance(){
Log.i("ConfigurationUtils", " --ConfigurationUtils.Holder.instance");
return ConfigurationUtils.Holder.instance;
}
/**
*
* @return
*/
public static boolean exsitSharedPreferences(){
String currentVerName = "null";
try {
currentVerName= mContext.getPackageManager().
getPackageInfo(Constant.packageName, 0).versionName;
} catch (NameNotFoundException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
return sp.getString("configuratonstatus", "0").equals("0")
|| !sp.getString("version", "0") .
equals(currentVerName) ?false:true;
}
/**
* assets propties SharedPreferences
* @return
*/
public static boolean file2SharedPreferences(Properties prop,SharedPreferences preferences){
try {
sp.edit().clear().commit();
//
prop.load(mContext.getAssets().open("jifenka.properties"));
Iterator it=prop.entrySet().iterator();
while(it.hasNext()){
Map.Entry entry=(Map.Entry)it.next();
String key = (String) entry.getKey();
String value = (String) entry.getValue();
preferences.edit().putString(key, value).commit();
}
preferences.edit().putString("configuratonstatus","1").commit();
} catch (IOException e) {
// TODO Auto-generated catch block
return false;
}
return false;
}
以上が書き込み判定コードです.
Step 3:トップページに適用すると、リスト額の表示順序が好みから取得できます
/**
* key Stringvalue
* @param context
* @param key
*/
public static String getStringValueBySpecifiedKeyInConfigSp(Context context, String key){
String value ;
SharedPreferences sp = context.getSharedPreferences(Constant.CONFIGURATION_FILE_NAME,
Constant.CONFIGURATION_FILE_MODE);
value = sp.getString(key, "0");
return value;
}
基本的な流れはこうです.
バージョン番号が違う場合は、好みを更新します
/**
* 。
* @param context
* @param infoMap
*/
public static void setConfigInfoSp(Context context,
Map<String, String> infoMap) {
SharedPreferences sp = context.getSharedPreferences(
Constant.LOGIN_INFO, Constant.CONFIGURATION_FILE_MODE);
Set<String> set = infoMap.keySet();
for (Iterator it = set.iterator(); it.hasNext();) {
String s = (String) it.next();
sp.edit().putString(s, infoMap.get(s)).commit();
}
}
これにより,サービス側がリストを制御する順序ができ,ネットワークがない場合にデフォルトリストを表示できるという問題が解決される.
当社のような同じアプリケーションのマルチバージョンの場合、プロファイルの導入はより迅速かつ明確に制御されます.