2015-07-13 1 views
9

Просматривая некоторые якобы «хорошие» источники источников, чтобы узнать подробности и трюки обработки контекста в Android, я столкнулся с одним шаблоном несколько раз, Понимаю.Зачем использовать ContextWrapper непосредственно в действии вместо имплицированного контекста из «this»

В чем преимущество использования ContextWrapper, когда вы могли одинаково хорошо использовать неявный контекст?

Например, почему использовать следующие в способе активности (определяется непосредственно в классе активность)

... 
ContextWrapper cw = new ContextWrapper(getApplicationContext()) 
File filesDir = cw.getFilesDir(); 
... 

Вместо того чтобы просто

... 
File filesDir = getFilesDir(); 
... 

, даже если getFilesDir() определяется в классе ContextWrapper Активность в любом случае является подклассом ContextWrapper, поэтому вы имеете прямой доступ к этому методу.

Какая потенциальная проблема (которую я не вижу) делает этот дополнительный адрес сложности?

+0

'' Application' расширяет ContextWrapper' также. – tynn

ответ

6

Я бы сказал (и, возможно, ошибаюсь), что в предложенном вами сценарии (и контексте) это может не повлиять. getApplicationContext().getFilesDir() можно было использовать так же легко.

Однако, я считаю, ContextWrapper может быть полезен в других сценариях. Насколько я понимаю, это шаблон адаптера. Вы можете обеспечить различное поведение только для определенных методов в то время как все другие прокси-соединения к исходной ссылке контекста вы передаете в

Заканчивать этот кусок кода из RemoteViews:.

// RemoteViews may be built by an application installed in another 
// user. So build a context that loads resources from that user but 
// still returns the current users userId so settings like data/time formats 
// are loaded without requiring cross user persmissions. 
final Context contextForResources = getContextForResources(context); 
Context inflationContext = new ContextWrapper(context) { 
    @Override 
    public Resources getResources() { 
     return contextForResources.getResources(); 
    } 
    @Override 
    public Resources.Theme getTheme() { 
     return contextForResources.getTheme(); 
    } 
};