The pitfalls and tips of Android development

1. android:clipToPadding

This means whether the drawing area of ​​the control is inside the padding. The default value is true. If you set this property value to false, you can achieve a layout effect with less effort. Let's take a look at the effect picture first.

In the above figure, there is a gap at the top of the ListView by default. After sliding up, the gap disappears, as shown in the following figure.

If you use margin or padding, you can't achieve this effect. Adding a headerView seems to be overkill and too troublesome. Here, clipToPadding combined with paddingTop is just right.

Similarly, there is another magical attribute: android:clipChildren. For details, please refer to: [Android] The magical android:clipChildren attribute (http://www.cnblogs.com/over140/p/3508335.html)

2. match_parent and wrap_content

In theory, these two properties are self-explanatory. One is to fill the layout space to adapt to the parent control, and the other is to adapt to the size of its own content. But if used incorrectly in a list such as ListView, it will be a big problem. The getView method in ListView needs to calculate the list items, so it is necessary to determine the height of ListView so that onMesure can do the measurement. If wrap_content is specified, it is equivalent to telling the system that if I have 10,000 items, you will calculate and display them for me, and then the system will create 10,000 new objects according to your requirements. Isn't that tragic? Let's take a look at a picture first.

Assume that ListView has 8 data items, match_parent needs to create 7 new objects, and wrap_content needs 8. This involves the reuse of View, so I won't discuss it in detail. So the settings of these two properties will determine the number of times getView is called.

This leads to another problem: getView is called multiple times.

What is multiple calls? For example, it may be called several times when position = 0. It seems very strange. It may happen to both GridView and ListView. Maybe the culprit is wrap_content. In the final analysis, there is a problem with the layout of the View. If the nested View is too complicated, the solution may be to measure the required height of the list through code, or use a little trick in getView: parent.getChildCount == position

 @Override 
 
 public   View getView( int position, View convertView, ViewGroup parent) { 
 
    if (parent.getChildCount() == position) { 
 
 // does things here 
 
 } 
 
  
 
 return convertView; 
 
 }

3. IllegalArgumentException: pointerIndex out of range

The scene where this bug occurs is still very speechless. At first, I used ViewPager + PhotoView (an open source control) to display pictures, and this problem occurred when zooming in and out with multi-touch. At first, I suspected that it was a bug in PhotoView, and I searched for it for a long time without any results. The terrible thing is that I don’t know how to try, and it always crashes. Later I found out that it was a bug left over from Android, and there was no check for pointer index in the source code. It is unlikely to change the source code and recompile it. Knowing that there is an exception, but unable to solve it fundamentally, if you don’t want it to crash, you can only try-catch. The solution is: customize a ViewPager and inherit ViewPager. Please see the following code:

 /** 
 
 * Customize the android.support.v4. view .ViewPager, override the onInterceptTouchEvent event, and capture system-level exceptions 
 
 */ 
 
 public class CustomViewPager extends ViewPager { 
 
  
 
 public CustomViewPager(Context context) { 
 
 this(context, null ); 
 
 } 
 
  
 
 public CustomViewPager(Context context, AttributeSet attrs) { 
 
        super(context, attrs); 
 
 } 
 
  
 
 @Override 
 
 public boolean onInterceptTouchEvent(MotionEvent ev) { 
 
 try { 
 
 return super.onInterceptTouchEvent(ev); 
 
        } catch (IllegalArgumentException e) { 
 
 LogUtil.e(e); 
 
        } catch (ArrayIndexOutOfBoundsException e) { 
 
 LogUtil.e(e); 
 
 } 
 
 return   false ; 
 
 } 
 
 }

Just replace the layout file using ViewPager with CustomViewPager.

4. The item click event in ListView is unresponsive

The click event of the listView Item suddenly becomes unresponsive. This problem usually occurs after adding controls such as buttons and checkboxes to the listView. This problem is caused by focus conflict. In Android, after clicking the screen, the click event will be assigned according to your layout. When you add a button to your listView, the click event will be assigned to the button in your listView first. So your click on the Item will become invalid. At this time, you need to set the click event for the outermost layout of your item or add the click event to a certain layout element according to your needs.

Solution: Set the descendantFocusability attribute in the root control of ListView (if the root control is LinearLayout, add the following attribute settings to LinearLayout).

 android:descendantFocusability= "blocksDescendants"  

The official documentation also states this.

5. getSupportFragmentManager() and getChildFragmentManager()

There is a requirement that a Fragment needs to nest 3 Fragments. Basically, you can think of using ViewPager to implement it. The starting code is written like this:

 mViewPager.setAdapter(new CustomizeFragmentPagerAdapter(getActivity().getSupportFragmentManager(), subFragmentList));

The problem is that the nested Fragment is sometimes not displayed for unknown reasons. At first, I had no idea where the problem was. When you don't know the cause of the problem, it is obviously troublesome to solve it. After searching again and again, I finally saw the same question on stackoverflow. It said that getChildFragmentManager() can be used. It's so magical!

 mViewPager.setAdapter(new CustomizeFragmentPagerAdapter(getChildFragmentManager, subFragmentList));

Let's take a look at the difference between the two. First, the description of getSupportFragmentManager (or getFragmentManager):

 Return the FragmentManager for interacting with fragments associated with this fragment's activity.

Then getChildFragmentManager:

 Return a private FragmentManager for placing and managing Fragments inside of this Fragment.

Basically, the difference is that Fragment's now have their own internal FragmentManager that can handle Fragments. The child FragmentManager is the one that handles Fragments contained within only the Fragment that it was added to. The other FragmentManager is contained within the entire Activity.

It has been made quite clear.

6. ScrollView nested ListView

Isn't this design strange? Two scrollable Views are put together, and they are nested. There was a requirement: the interface has 4 areas, namely company basic information (logo, name, legal person, address), company profile, company honors, and company reputation list. Each part of the content needs to adapt to the height according to the content, and it cannot be hard-coded. The first thing I thought of was to surround it with a ScrollView. Then encapsulate these 4 parts with 4 custom controls. Basic information and company profile are relatively simple. Honors need to use a combination of RecyclerView and TextView. RecyclerView (of course, GridView can also be used, with 3 columns and multiple rows) stores honor pictures, and TextView displays honor names. *** Part of the reputation list is of course ListView. At this time, the problem arises. It is necessary to solve the sliding problem of ListView placed in ScrollView and the display problem of RecyclerView (if the height of RecyclerView cannot be calculated, you can't see the content).

Of course, there are already similar questions and solutions on the Internet.

Give a URL:

Four solutions to the problem of nested ListView in ScrollView (http://bbs.anzhuo.cn/thread-982250-1-1.html)

The problem with ListView is relatively easy to solve. The elegant way is to write a class that inherits ListView and then override the onMeasure method.

 @Override protected void onMeasure( int widthMeasureSpec, int heightMeasureSpec) { 
 
 int expandSpec = MeasureSpec.makeMeasureSpec( Integer .MAX_VALUE >> 2, MeasureSpec.AT_MOST); 
 
    super.onMeasure(widthMeasureSpec, expandSpec); 
 
 }

ListView can override onMeasure to solve this problem, but RecyclerView cannot override this method.

In the final analysis, there are two ways to calculate the height. One is to dynamically calculate RecycleView and then set setLayoutParams; the other is similar to the solution of ListView, define a class that inherits LinearLayoutManager or GridLayoutManager (note: not inherit RecyclerView), and rewrite the onMeasure method (this method is more complicated, so I won’t show it here, and I will introduce it in my next article).

The height is calculated dynamically as follows:

 int heightPx = DensityUtil.dip2px(getActivity(), (imageHeight + imageRowHeight) * lines); 
 
 MarginLayoutParams mParams = new MarginLayoutParams(LayoutParams.MATCH_PARENT, heightPx); 
 
 mParams.setMargins(0, 0, 0, 0); 
 
 LinearLayout.LayoutParams lParams = new LinearLayout.LayoutParams(mParams); 
 
 honorImageRecyclerView.setLayoutParams(lParams);

The idea is this: after the server returns the honor picture, since it is displayed in 3 columns, you only need to calculate how many rows need to be displayed, then give the row spacing and the height of the picture, and then set setLayoutParams.

 int lines = ( int ) Math.ceil(totalImages / 3d);

At this point, this strange requirement has been resolved.

But when sliding, there is a lag. You must think it is a sliding conflict. It should be that the sliding of ScrollView interferes with the sliding of ListView. What should I do? Can I disable the sliding of ScrollView?

Baidu, you will definitely be able to search for the answer. First, the code:

 /** 
 
 * @author Leo 
 
 * 
 
 * Created on 2015-9-12 
 
 * Intercept ScrollView sliding events 
 
 */ 
 
 public class CustomScrollView extends ScrollView { 
 
  
 
 private int downY; 
 
 private int touchSlop; 
 
  
 
 public CustomScrollView(Context context) { 
 
 this(context, null ); 
 
 } 
 
  
 
 public CustomScrollView(Context context, AttributeSet attrs) { 
 
        this(context, attrs, 0); 
 
 } 
 
  
 
 public CustomScrollView(Context context, AttributeSet attrs, int defStyleAttr) { 
 
        super(context, attrs, defStyleAttr); 
 
        touchSlop = ViewConfiguration.get(context).getScaledTouchSlop(); 
 
 } 
 
  
 
 @Override 
 
 public boolean onInterceptTouchEvent(MotionEvent e) { 
 
 int   action = e.getAction(); 
 
 switch ( action ) { 
 
 case MotionEvent.ACTION_DOWN: 
 
            downY = ( int ) e.getRawY(); 
 
 break; 
 
 case MotionEvent.ACTION_MOVE: 
 
 int moveY = ( int ) e.getRawY(); 
 
            if (Math. abs (moveY - downY) > touchSlop) { 
 
 return   true ; 
 
 } 
 
 } 
 
 return super.onInterceptTouchEvent(e); 
 
 } 
 
 }

As long as you understand the getScaledTouchSlop() method, it will be easy. The annotation of this method is: Distance in pixels a touch can wander before we think the user is scrolling. It means that when sliding, the hand must move more than this distance to start moving the control, and if it is less than this distance, it will not trigger the movement.

It looks very ***.

But there is another problem: it takes too long to load this interface every time. Every time I start this interface from other interfaces, it will be stuck for 1~2 seconds, and the time varies depending on the performance of the mobile phone. It is not due to network requests. The data is fetched by the child thread and has nothing to do with the UI thread. This experience is very unpleasant.

A few days passed and it was still the same. I was about to demonstrate it to my boss. I would be scolded ten times for such an experience.

Is it related to the nesting of ScrollView?

OK, then I refactored the code. No more ScrollView. Just use a ListView, and then add a headerView to store other content. Because the control is well encapsulated, it is OK without much layout change. Once it runs, it is smooth and everything is solved!

It's such a simple question, why do we have to nest it with ScrollView?

Stackoverflow has told you a long time ago, don’t nest like this! Don’t nest like this! Don’t nest like this! Important things must be said three times.

ListView inside ScrollView is not scrolling on Android

(http://stackoverflow.com/questions/6210895/listview-inside-scrollview-is-not-scrolling-on-android)

Of course, starting from Android 5.0 Lollipop, a new API is provided to support embedded sliding, so that requirements like this can be well implemented.

Here is a website. If you are interested, please check it out yourself. We will not discuss it here.

Android NestedScrolling in action

(http://www.race604.com/android-nested-scrolling/)

7. setText(null) of EmojiconTextView

This is an enhanced version of TextView in the open source emoji library com.rockerhieu.emojicon. I believe many people have used this open source toolkit. There is no problem with using setText(null) on TextView. But after setting Text(null) on EmojiconTextView, it crashes directly and displays a null pointer. At first I suspected that this view was not initialized, but it was not. So let's debug it.

 @Override 
 
 public void setText(CharSequence text, BufferType type) { 
 
    SpannableStringBuilder builder = new SpannableStringBuilder(text); 
 
    EmojiconHandler.addEmojis(getContext(), builder, mEmojiconSize); 
 
    super.setText(builder, type); 
 
 }

There seems to be no problem with setText in EmojiconTextView. Click SpannableStringBuilder to see the source code:

 /** 
 
 * Create a new SpannableStringBuilder containing a copy of the 
 
 * specified text, including its spans if any . 
 
 */ 
 
 public SpannableStringBuilder(CharSequence text) { 
 
    this(text, 0, text.length()); 
 
 }

OK. The problem has been found, text.length(), it would be strange if it is not a null pointer.

 text = text == null ? "" : text; 
 
 SpannableStringBuilder builder = new SpannableStringBuilder(text);

Just add a line of judgment.

8. cursor.close()

Generally speaking, people will not forget to open and close the database, but they may not pay much attention to the use of cursors, especially the random use of cursors. For example, using ContentResolver combined with Cursor to query pictures in the SD card, it is easy to write the following code:

 Cursor   cursor = contentResolver.query(uri, null , MediaStore.Images.Media.MIME_TYPE + "=? or "   
 
                        + MediaStore.Images.Media.MIME_TYPE + "=?" , new String[] { "image/jpeg" , "image/png" }, 
 
                        MediaStore.Images.Media.DATE_MODIFIED); 
 
 while ( cursor .moveToNext()) { 
 
 //TODO 
 
 }

The cursor does not make non-empty judgments, and often when closing the cursor, an exception may be thrown without paying attention.

In the past, in the project, other problems often occurred because the cursor was not closed in time or the exception was not handled properly, and the problem seemed very strange and difficult to solve. Later, I refactored the use of cursors in the entire project, and no similar problems occurred again.

The principle is very simple, all Cursor declarations are:

 Cursor   cursor = null ;

And put it outside the try-catch; if you need to use the cursor, make a non-empty judgment first. Then use a tool class to handle the closing of the cursor at the end of the method.

 /** 
 
 * @author Leo 
 
 * 
 
 * Created on 2015-9-15 
 
 */ 
 
 public class IOUtil { 
 
  
 
 private IOUtil() { 
 
 } 
 
  
 
 public   static void closeQuietly(Closeable closeable) { 
 
        if (closeable != null ) { 
 
 try { 
 
                closeable. close (); 
 
            } catch (Throwable e) { 
 
 } 
 
 } 
 
 } 
 
  
 
 public   static void closeQuietly( Cursor   cursor ) { 
 
        if ( cursor != null ) { 
 
 try { 
 
 cursor.close ( ) ; 
 
            } catch (Throwable e) { 
 
 } 
 
 } 
 
 } 
 
 }

I think this way there is no need to use try-catch-finally in every place.

9. java.lang.String cannot be converted to JSONObject

When parsing the JSON string returned by the server, this exception was thrown. No problems were found during debugging, and it looked like a normal JSON format. Later, it was discovered that the JSON string had an extra BOM (Byte Order Mark). The server code was implemented in PHP, and sometimes developers would directly open and save it with Windows Notepad for easy modification, which introduced problems that were invisible to the human eye. In fact, it was just an extra "ufeff" thing, and the client code just needed to filter it.

 // in   case : Value of type java.lang.String cannot be converted to JSONObject 
 
 // Remove the BOM header 
 
 if (jsonStr != null ) { 
 
 jsonStr = jsonStr.trim(); 
 
    if (jsonStr.startsWith( "ufeff" )) { 
 
        jsonStr = jsonStr.substring (1); 
 
 } 
 
 }

10. Shape round rect too large to be rendered into a texture

Round rectangle too big?

At first, I found that the scrollView in acitivity slid intermittently, but in fact there was no nested list control such as ListView or GridView, and it contained only some TextView, ImagView, etc. I looked at the log output in Eclipse and found this warning level prompt. Could it be that I nested this circular rectangle in the outer layer? I used it in many places, why did the problem occur in this interface?

Later I found out that this rounded rectangle contained too much content, it exceeded the height of the phone and could scroll through several pages.

Someone on StackOverFlow said: The easiest solution is to get rid of the rounded corners. If you remove the rounded corners and use a simple rectangle, the hardware renderer will no longer create a single large texture for the background layer, and won't run into the texture size limit any more.

There is also a suggestion: to draw onto the canvas.

Specific link: How Do Solve Shape round rect too large to be rendered into a texture

(http://stackoverflow.com/questions/14519025/how-do-solve-shape-round-rect-too-large-to-be-rendered-into-a-texture-in-android)

I tried to use a custom LinearLayout control and draw it through canvas, but it didn't work. Removing the radius attribute does work, but what if I want to keep it?

There is also a workaround, by disabling hardware acceleration in androidManifest.xml, for granular control, I only disable this feature in this activity.

 <activity android:hardwareaccelerated= "false" />

That’s all I can think of for now, I’ll add more later.