Android.App.Applicationのサブクラス化を回避する方法

Question

これまでは、アプリケーションのアクティブなデータベース接続を維持するために、サブタイプApplicationをサブクラス化しました。しかし、this SO answerApplicationによると、UIスレッドで実行されるため、私は間違いなくデータベースアクセスに使用しないと思うようになります。さらに、Xamarin Application docs（およびAndroidのもの）に従って：

通常、アプリケーションをサブクラス化する必要はありません。ほとんどの場合、静的なシングルトンは、よりモジュラーな方法で同じ機能を提供できます。シングルトンにグローバルコンテキストが必要な場合（ブロードキャストレシーバを登録するなど）、シンクレットを最初に構築するときに内部でContext.ApplicationContextを使用するContextを取得することができます。

は、私はアプリケーションリソースへのスタティックアクセスのいくつかの並べ替えを維持するために使用することができるものであることをContextを理解すると思うが、ドキュメント内の例はないと私は前にこのような状況が発生していませんでした。誰かが上記の注釈を説明し、アプリケーションのリソースを維持するためにContextの使用方法を関連付けることができますか？例へのリンクや例を挙げていただければ幸いです。

Answer 1

私が探しているドロイドの答えが見つかりました。

ドキュメントノートで参照としてデイブ・スミスは、上記の「静的なシングルトン」の simple exampleを提供してきました

：Context自体はCustomManagerの長寿に寄与しない

public class CustomManager { 
    private static CustomManager sInstance; 

    public static CustomManager getInstance(Context context) { 
     if (sInstance == null) { 
      //Always pass in the Application Context 
      sInstance = new CustomManager(context.getApplicationContext()); 
     } 

     return sInstance; 
    } 

    private Context mContext; 

    private CustomManager(Context context) { 
     mContext = context; 
    } 
} 

- その存在は単純に起因しています静的なシングルトン自体の性質。 （Xamarin Context.ApplicationContext）によって提供されるContextは、シングルトンによって必要とされる場合には単にアプリケーションContextにアクセスする手段に過ぎません。

this SO question and its top two answersで詳述されているように、実際の質問はそうではありませんが、どのようにしてグローバルアプリケーションデータをシングルトンにしたいのですか？前者を使用する場合と使用しない場合がある、追加の個別シングルトンを作成します。

私の考えでは、結局のところ、Applicationをサブクラス化することに満足していると思います。 Applicationクラスの一部の変形例では、直感的にアプリケーションデータを格納する方が意味があります。さらに、私は一般的にシングルトンを作成することについてある程度のOOPの不安を抱えています。このシングルトンはフレームワークによって管理されるため、基本的にグローバル変数（boo hiss）に至る典型的な不具合からの安全を保証するものではありませんが、少なくとも自分自身を圧倒するよりも少し安全です。

P.S. - 再：UIスレッドで実行されるApplicationを使用すると、静的なシングルトンを使用しているように見えますが、何も追加のメリットはありません。なぜなら、とにかくApplicationを使用しているからです。私はおそらく、hereというアドバイスに従い、プロセッサーの大量の操作にはAsyncTaskを使用すると思います。