Android drop-down Refresh bottom action bar hidden issues

Recently wrote the drop-down refresh, found a problem, is that there is a requirement is this: the request page is a tab switch interface, an interface has the bottom action bar, not pull the refresh, the other interface does not have the bottom action bar, but can be pulled down to refresh.

As usual, I used relativelayout in the XML file, declaring the layout_above of the drop-down refresh component as the bottom action bar, and then discovering a strange phenomenon when testing: if the bottom action bar is visible at the beginning, In another run drop-down refresh the interface will appear in the same position as the bottom action bar, the same size, but the color takes the system default layout, if set to invisible, this problem will not occur.

<BottomviewAndroid:id= "@+id/bottom"Android:layout_width= "Match_parent"Android:layout_height= "Match_parent"Android:layout_alignparentbottom= "true"/><RefreshlistviewAndroid:layout_width= "Match_parent"Android:layout_height= "Match_parent"Android:layout_above= "@id/bottom" />

After debugging, the bottom action bar is indeed set to be invisible when the dropdown is refreshed, so the object of this puzzle is not the bottom action bar.

Looked up some information, although did not find the same problem with me, but the most likely is in the relativelayout, if layout_above corresponding components are gone out, there may be a problem of layout confusion.

In this case, a different way: Declare the bottom action bar layout_bellow for the drop-down refresh component. Unfortunately, the same problem still arises.

Well, since there may be problems with the relative relationship of the components, think about whether you can dynamically add the correspondence.

Android can still provide this scheme, can get the layoutparams of components through View.getlayoutparams, and then dynamically add and delete relative relationships through addrule and Removerule methods. Unfortunately, Removerule and Addrule are not sold as a package, removerule need a higher API to support it.

Think about the compatibility issue, or abandon this practice.

In combination, the possible problem is that the pull-down refresh requires a drop-down area, and this area is determined when the view has just been drawn, and if the subsequent correspondence is disrupted, the system may also generate a default layout to clarify the area.

A better solution comes out: The bottom action Bar is also used as a drop-down refresh area, that is, with the drop-down refresh component as a layout.

The problem is solved, but I don't feel very comfortable: my drop-down refresh component is generic, as long as the drop-down refresh function is not started, it is completely a ListView, and also free to configure the interface without data. Now because of a need to add a special to the bottom of the action bar, even if you can control its visibility to some extent can guarantee that it is available, but if I want to replace the bottom of the action bar?

So I started to put the bottom action bar can also be encapsulated in.

The solution at the outset is to declare a base class component with an object-oriented inheritance relationship, but in fact, the Android XML file does not recognize the inheritance of the component, and cannot let the subclass component be used where the base class component is declared.

Since inheritance does not work, the combination is used.

Declaring a class that holds a reference to the bottom action bar of a custom layout allows it to be controlled.

 Public class contactbottomoperation {    private  basebottomoperation bottomoperation;         ...}

But to be free to replace the layout, you must pass in the ID of the layout, which is then controlled by the class's rendering of the layout.

 Public Basebottomoperation initbottom (int  ID) {     bottomoperation.setvisibility (view.visible);     Bottomoperation.init (ID);      return bottomoperation;}  Public class basebottomoperation{...        Public void init (int  ID) {       this);}   }

The problem is solved, but still find an uncomfortable place: Click the event?

Because I just hold a reference to the layout, I can't let the class implement Onitemclicklistener, listen to the Click event, and the custom bottom action bar will only know what the control is like when it's rendered.

In fact, this problem is not a problem at all, I can get the control class to the bottom of the Action bar control, and then set the corresponding event, but can not use butterknife such a tool to simplify the code.

Rlsave = (relativelayout) Bottom.findviewbyid (R.id.rl_save); Rlsave.setonitemclicklistener (New Onitemclicklistener () {     @Override     publicvoid  onClick (...) {         save ();     }}}

Thinking that Butterknife was using the principle of reflection, I began to wonder if reflection could solve my problems.

This solves the problem by passing in the view and calling methods that need to be monitored, so that the view and event bindings can be completed.

Bottomoperation.setitemclick (Rlfav, This, "Favorite"); Public voidSetitemclick (View view,FinalObject Object,FinalString MethodName) {View.setonclicklistener (NewOnclicklistener () {@Override Public voidOnClick (View v) {Class classobj=Object.getclass (); Try{Method Method= Classobj.getmethod (MethodName,NULL); Method.invoke (Object,NULL); } Catch(nosuchmethodexception e) {LOGUTIL.E (e.tostring ()); } Catch(InvocationTargetException e) {LOGUTIL.E (e.tostring ()); } Catch(illegalaccessexception e) {LOGUTIL.E (e.tostring ()); }      }});

Actual coding always encounter a variety of wonderful problems, but the problem is not solved on the finish, often the problem is the solution is the real beginning.

Android drop-down Refresh bottom action bar hidden issues