commitAllowingStateLoss()和commit()片段 [英] commitAllowingStateLoss() and commit() fragment

问题描述

我想在网络后台操作之后提交一个片段.成功的网络操作之后，我正在调用commit()，但是如果活动进入暂停或停止状态，则会崩溃，并说IllegalState异常.

所以我尝试使用commitAllowingStateLoss()及其现在正常工作.

我浏览了几篇博客和文章，其中说commitAllowingStateLoss()不好用.

在处理活动暂停和停止状态的网络操作之后，如何处理提交片段?

解决方案

我想向Aritra Roy添加信息(到目前为止，我读过，这是一个很好的答案).

我以前遇到过这个问题，我发现主要问题是您试图在另一个线程中进行一些异步操作(HTTP，计算等)，这是一个很好的实践，但是您必须告知您用户在收到答案之后.

主要问题在于，由于它是异步操作，因此无法保证用户仍在您的活动/应用程序上.而且，如果他离开了，则无需进行UI更改.此外，由于android可能会因内存问题而终止您的应用/活动，因此您无法保证能够得到答案并保存以进行恢复. 问题不仅在于用户可以打开另一个应用程序"，还在于可以通过配置更改来重新创建我的活动"，并且您可能正在尝试在活动重新创建期间进行UI更改，这确实非常糟糕.

使用"commitAllowingStateLoss"就像在说我不在乎UI是否真的处于良好状态".您可以做一些小事(例如，激活gif表示下载已结束)……这不是什么大问题，因为一般"用户将继续使用您的应用程序，因此此问题实际上不值得处理./p>

但是，用户做了一些事情，您试图在Web上获取信息，信息准备就绪，并且当用户恢复该应用程序时必须显示该信息...主要词是" resume ".

您必须将所需的数据收集到一个变量(如果可能的话，是一个可打包或原始变量)中，然后以以下方式覆盖"onResume"或"onPostResume"(用于活动)函数.

public void onResume/onPostResume() {
    super.onResume/onPostResume();
    if(someTreatmentIsPending) {
        /*do what you need to do with your variable here : fragment 
        transactions, dialog showing...*/
    }
}

其他信息: 本主题，尤其是@jed答案，以及@ pjv，@ Sufian评论. 此博客以了解为什么错误的发生，以及为什么建议/接受的答案起作用.

最后一个字: 以防万一您想知道为什么使用服务比asyncTask更好".就我所知，这并不是真的更好.主要区别在于，正确使用服务可让您在活动暂停/恢复时注册/注销处理程序.因此，当您的活动处于活动状态时，您总是会得到答案，从而防止该错误发生.

请注意，这不是因为没有发生该错误，表明您是安全的.如果直接在视图上进行更改，则不涉及fragmentTransactions，因此，不能保证在重新创建，恢复，重新启动应用程序或进行任何其他操作时，更改将保留并重新创建.

I want commit a fragment after network background operation. I was calling commit() after successful network operation but in case activity goes to pause or stop state it was crashing app saying IllegalState exception.

SO I tried using commitAllowingStateLoss() and its working fine now.

I gone through few blogs and articles it says commitAllowingStateLoss() is not good to use.

Whats the way to handle commit fragment after network operation handling activity pause and stop state?

解决方案

I'd like to add informations to Aritra Roy (so far i readed, it's a really good answer).

I encountered the problem before, and i found that the main problem is that you are trying to make some async operations (HTTP, computations, ...) in another thread, wich is a good pratice, but you must inform your user AFTER receiving answers.

The main problem is that as it is async operations, there is no guarantee that the user is still on your activity/app anymore. And if he went away, there is no need to do UI changes. Moreover, as android may kill your app/activity for memory issues, you have no guarantees to be able to get your answer, and save it to be restored. The problem is not only "the user can open another app" but "my activity can be recreated from configuration change" and you may be trying to do UI changes during activity recreation which would be really, really bad.

Using "commitAllowingStateLoss" is like saying "i don't care if the UI is not really in the good state". You can do it for little things (like activate a gif saying your download ended)... That's not a big issue, and this problem is not really worth dealing with it as "in general" the user will stay on your app.

But, the user did something, you're trying to get informations on the web, information is ready, and you have to show it when the user resume the app... the main word is "resume".

You must gather the data you needed into a variable (and if you can, a parcelable or primitive variable), and then, override your "onResume" or "onPostResume"(for activities) functions in the following way.

public void onResume/onPostResume() {
    super.onResume/onPostResume();
    if(someTreatmentIsPending) {
        /*do what you need to do with your variable here : fragment 
        transactions, dialog showing...*/
    }
}

Additional informations : This topic and especially @jed answer, and @pjv, @Sufian comments to it. This blog in order to understand why the bug occurs, and why proposed/accepted answers work.

Last word : Just in case you wonder "why using a service is better than asyncTask". For what i understood, that's not really better. The main difference is that using service properly allow you to register/unregister handlers when your activity is paused/resumed. Therefore, you always get your answers when your activity is active, preventing the bug to occurs.

Notice that's not because the bug does not occurs that you are safe. If you made changes directly on your views, there is no fragmentTransactions involved, therefore, no guarantee that the change will be retained and recreated when the app is recreated, resumed, relaunched, or anything else.

这篇关于commitAllowingStateLoss()和commit()片段的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！