Requestfeature () must be called before adding content exception encountered in Android development

Origin

The previous blog post described several ways to implement full-screen display of activity content. However, some problems have been found in the implementation, which is summarized in this blog post. Start by explaining the development environment, I am using Android Studio 1.5.1, so you may not encounter this problem when using Eclipse ADT development or a lower version of the SDK. First look at the implementation code in the OnCreate () method:

 1   @Override  2  protected  void       OnCreate (Bundle savedinstancestate) { 3  super  .oncreate (savedinstancestate);  4   Requestwindowfeature (window.feature_no_ TITLE);  5   GetWindow (). SetFlags ( WindowManager.LayoutParams.FLAG_FULLSCREEN, WindowManager.LayoutParams.FLAG_FULLSCREEN);  6   Setcontentview (r.layout.activity_main);  7 } 

Very simple two lines of code, but running the code when the application is directly crashing. Watch the app's crash message in Android Studio and see just one simple message:Threadid=1:thread exiting with uncaught exception (GROUP=0X419F6C50). There is no way to know where the error, because the code is less, only so two lines. So I searched the Internet for the debug method of AS, summed up the method of catching the exception in Android studio.

Android Studio captures exception scenario one

We know that the Java language provides a try-catch mechanism to capture runtime exceptions. So think about whether we can also take advantage of the Try-catch tool when troubleshooting Android runtime exceptions? Add it up and try it out:

To run the app again in the emulator, you can output the following information in the Logcat:

You can now see the specific exception information:requestfeature () must be called before adding content. has reached the result we want, but this method has a drawback: it is necessary to estimate where the anomaly roughly appears, it is easy to use try-catch parcel it. As for what this anomaly represents, let's not say it now, and then look at the second anomaly capture scenario.

Android Studio Capture Exception Scenario two

This scenario is viewed online, using a static method of Therad, first defining an instance of Thread.uncaughtexceptionhandler, and then setting the default processor in the program as an uncaught exception:

1 Private FinalThread.uncaughtexceptionhandler handler =NewThread.uncaughtexceptionhandler () {2      Public voiduncaughtexception (thread thread, Throwable ex) {3LOG.E ("TestApplication", "uncaught exception is:", ex);4         //Log It5     }6 };7 8 @Override9 protected voidonCreate (Bundle savedinstancestate) {Ten Thread.setdefaultuncaughtexceptionhandler (handler); One  A     Super. OnCreate (savedinstancestate); - requestwindowfeature (window.feature_no_title); - GetWindow (). SetFlags (WindowManager.LayoutParams.FLAG_FULLSCREEN, WindowManager.LayoutParams.FLAG_FULLSCREEN ); the Setcontentview (r.layout.activity_main); -}

This scenario requires only one Thread.uncaughtexceptionhandler instance, and does not need to estimate the approximate location of the occurrence of the exception. The resulting output information is as follows:

The exception information is also very clear, can see the exception throws the stack information, so as to quickly track the location of the bug. So what does this anomaly tell us? To be literal, the requestwindowfeature () method must be called before the view can be added. But it used to be so, and I have never seen such an anomaly. So he searched for a solution on the StackOverflow. Simply put the requestwindowfeature () in the first line of the call. Why is it? The key reason is that my new project activity in Android Studio 1.5 is inherited from the Appcompatactivity class by default. In that post there are some workarounds: (1) Change the base class from appcompatactivity (or actionbaractivity) to activity. This allows you to not put Requestwindowfeature on the first line. (2) or use the Supportrequestwindowfeature () method instead of the Requestwindowfeature () method, so that it does not need to be placed on the first line to invoke. There are three ways to solve the problem. As for the reason, the post is also divergent opinions, not good explanation. The general reason, however, is the problem with the Compatibility Pack Google provides for Android.

The relationship between Actionbaractivity and appcompatactivity

In StackOverflow's post, there was a reference to a base class actionbaractivity that had been deprecated by Google. This class has been deprecated in the current SDK, from the source code, Actionbaractivity is now inherited from the appcompatactivity of an empty class, tightly for backwards-compatibility considerations. Google has suggested that developers gradually use toolbar to replace Actionbar in previous versions, so it is reasonable to discard actionbaractivity and use appcompatactivity as a base class in a new version.

So, where is the new appcompatactivity? According to the documentation, Appcompatactivity is a more general class of design implementations, with the use of appcompatdelegate as the core of the logic implementation. The existence of this delegate is in order to better implement the material design concept that Google implements. Sometimes you might want to use material design components in an older version of the activity (which is not inherited from Actionbaractivity and not inherited appcompatactivity classes). At this point, the delegate can meet this requirement very well. Just implement the Appcompatdelegate method in this old activity and rewrite the methods of Addcontentview (), Setcontentview () in the old activity, And in these methods, callback appcompatdelegate in the corresponding method, you can add a material design-style view component for legacy activity.

Reference

• Http://stackoverflow.com/questions/29797172/whats-the-enhancement-of-appcompatactivity-over-actionbaractivity
• Http://stackoverflow.com/questions/16939814/android-util-androidruntimeexception-requestfeature-must-be-called-before-add

Requestfeature () must be called before adding content exception encountered in Android development