将ApplicationContext用于对话框是否安全? [英] Is it safe to use the ApplicationContext for a Dialog?

问题描述

我正在运行一个应用程序，该应用程序从Fragment内部生成对话框警报作为网络回调.这要求您传递一个可用的Context参考.因为我使用的是Fragment，所以我使用的是getActivity().由于回调依赖于网络，因此getActivity()可以有时返回null .这会使我的代码崩溃.

I'm running an application that generates a dialog alert from within a Fragment as a network callback. This requires you to pass in an available Context reference; since I'm using Fragments, I use getActivity(). Due to the network-dependent nature of the callback, getActivity() can sometimes return null. This crashes my code.

要变通解决此错误，我希望改为为对话框提供ApplicationContext. 在应用程序的生命周期中一直存在 ，所以我知道它不会被撤回.另外，Dialog的内容与付款确认有关，因此我认为它的显示范围合理，而与某些Window没有严格的关系.

To work around this error, I was hoping to supply the ApplicationContext to the dialog instead. It is a singleton that persists for the lifetime of the application, so I know it won't be withdrawn. In addition, the Dialog's content is with regards to payment confirmation, so I believe there's reasonable scope for it to be displayed without a strict relationship to a certain Window.

这是安全的实施方式吗?我要避免这种不可避免的情况，而应该完全改用更健壮的模式吗?

Is this a safe implementation? Am I avoiding the inevitable, and should move to a more robust pattern altogether?

推荐答案

这是安全的实施方式吗?

Is this a safe implementation?

恕我直言，不.

从策略上讲，我希望您的应用在某些情况下会崩溃(例如，在网络I/O完成时您的应用处于后台)，并且我希望您的对话框不一定会遵循适当的主题.由于您的对话"似乎与活动无关，因此应该以对话为主题的活动形式为.这样可以解决您的可靠性问题和主题问题，但是如果您的网络I/O花费的时间比您预期的长，仍然有可能在用户使用其他应用程序时显示对话框(主题活动).

Tactically, I would expect your app to crash in some situations (e.g., your app is in the background at the time the network I/O completes), and I would expect your dialog to not necessarily honor the appropriate theme. Since it seems like your "dialog" is not tied to an activity, it should be an activity, in the form of a dialog-themed activity. That solves your reliability problem and your theme problem, though there is still the possibility that you display a dialog(-themed activity) while the user is in some other app, if your network I/O takes longer than you anticipate.

从策略上讲，无论您的应用程序的UI层发生什么情况，您似乎都在乎网络I/O的结果.在这种情况下，您的应用程序的UI层不应是直接接收网络I/O结果的那一层，并且感觉您的片段现在正在这样做.使用与UI分离的内容(IntentService，JobService，裸线程，ThreadPoolExecutor)来管理网络I/O.让它使用事件总线(LocalBroadcastManager，greenrobot的EventBus)告诉UI层网络I/O已完成，以及UI层是否不响应事件(因为它在后台，您只需要注意)到显示UI时发生的事件)，请举起Notification或进行其他细微的操作，以使用户知道结果.

Strategically, it seems like you care about the results of your network I/O regardless of what happens in the UI layer of your app. In that case, your UI layer of your app should not be the one directly receiving the results of the network I/O, and it feels like your fragment is doing that right now. Use something that is decoupled from your UI (IntentService, JobService, bare thread, ThreadPoolExecutor) for managing the network I/O. Have it use an event bus (LocalBroadcastManager, greenrobot's EventBus) to tell the UI layer that the network I/O completed, and if the UI layer does not respond to the event (because it is in the background and you only pay attention to events when the UI is visible), raise a Notification or do something else subtle to let the user know about the results.

这篇关于将ApplicationContext用于对话框是否安全?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！