1. 程式人生 > >java.lang.IllegalStateException: No activity

java.lang.IllegalStateException: No activity

錯誤提示:

Java.lang.IllegalStateException: No activity
at Android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1075)
at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1070)
at android.support.v4.app.FragmentManagerImpl.dispatchActivityCreated(FragmentManager.java:1861)


at android.support.v4.app.Fragment.performActivityCreated(Fragment.java:1474)
at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:931)
at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1088)

.......

這個問題是在解決上一篇文章(http://blog.csdn.net/leewenjin/article/details/19409863)中指出的問題後出現的。問題解決方法是參考文章:

http://stackoverflow.com/questions/15207305/getting-the-error-java-lang-illegalstateexception-activity-has-been-destroyed

bug出現的原理問題及解決方法是
This seems to be a bug in the newly added support for nested fragments. Basically, the child FragmentManager ends up with a broken internal state when it is detached from the activity. A short-term workaround that fixed it for me is to add the following to onDetach() of every Fragment which you call getChildFragmentManager() on:

解決方法重寫onDetach()

[java]  view plain  copy   在CODE上檢視程式碼片 派生到我的程式碼片
  1. @Override  
  2.     public void onDetach() {  
  3.         super.onDetach();  
  4.         try {  
  5.             Field childFragmentManager = Fragment.class.getDeclaredField("mChildFragmentManager");  
  6.             childFragmentManager.setAccessible(true);  
  7.             childFragmentManager.set(thisnull);  
  8.   
  9.         } catch (NoSuchFieldException e) {  
  10.             throw new RuntimeException(e);  
  11.         } catch (IllegalAccessException e) {  
  12.             throw new RuntimeException(e);  
  13.         }  
  14.       
  15.     }  

其中的 Field 是

java.lang.reflect.Field

引起bug的原因
If you look at the implementation of Fragment, you'll see that when moving to the detached state, it'll reset its internal state. However, it doesn't reset mChildFragmentManager (this is a bug in the current version of the support library). This causes it to not reattach the child fragment manager when the Fragment is reattached, causing the exception you saw.