Pits and asking for doubts.
One, Android dangerous permissions, from the official documents of the pit???
Android developers know that before Android 6.0, permission requests only need to be declared in the Androidmanifest.xml file. Android 6.0 starts, the permission request has changed, the dangerous permission needs to apply dynamically in the application, previously wrote an android dynamic request dangerous permission notes, detailed reference: Android 6.0 dynamic request dangerous permission.
Take a screenshot and see the official Android Note:
Then look at the grouping of dangerous permissions:
This means that dangerous permissions are grouped, and other permissions in the same group are granted by default as long as one of the permissions is authorized. For example, after I authorize the application to have read memory card permissions, the application also has the right to write the memory card, in fact, it is true.
The problem, however, is the code that uses GPS to get location information:
Locationmanager Locationmanager = (locationmanager) getsystemservice (Context.location_service); Locationmanager.isproviderenabled (Locationmanager.gps_provider)) {if (Activitycompat.checkselfpermission (this, Manifest.permission.ACCESS_FINE_LOCATION)! = packagemanager.permission_granted && activitycompat.ch Eckselfpermission (Mainactivity.this, Manifest.permission.ACCESS_COARSE_LOCATION)! = Package manager.permission_granted) {//Request permissions//...} else{Location location = locationmanager.getlastknownlocation (Locationmanager.gps_provider; if (location = null) {Double latitude = location.getlatitude (); Double longitude = location.getlongitude (); } }}
Through the official Dangerous permission group, we can also see: the Location permission group contains: ACCESS_FINE_LOCATION
and ACCESS_COARSE_LOCATION
two permissions, according to the above instructions, two permissions as long as there is a successful application authorization, you can successfully obtain latitude and longitude. -- Goose, when the successful application of ACCESS_COARSE_LOCATION
permissions, the program will still collapse, error message prompts, need to get ACCESS_FINE_LOCATION
permission .
Second, Spinner's SetSelection () method, originates from oneself to take for granted pit!!!
The drop-down list control in Android spinner has a method setselection (int position) that shows the first few items. This method may not be effective??? Always show the first item???
------------------------------------Split Line----------------------------------
When doing two spinner linkage, Spinner2 populates the data according to the Spinner1 selection and then uses Setseletion (2) to set the default. The results show that Spinner2 is always the first item, but the actual selection is indeed the position of position 2.
Workaround:
Old Code:
spinner.setAdapter(adapter); spinner.setSelection(2);
There are two solutions:
(1)
spinner.setAdapter(adapter); spinner.setSelection(2,true); //spinner会重新layout
(2) Recommended
spinner.setAdapter(adapter);![](https://images2018.cnblogs.com/blog/758949/201807/758949-20180726224508174-131546620.jpg) adapter.notifyDataSetChanged(); //通知spinner刷新数据 spinner.setSelection(2);
So, what is the cause of this? I think this is a bug. This usually happens after the data is re-populated, and in addition to using setselection (int position), it can be displayed correctly.
The implementation mechanism of setselection (int position, Boolean animate) and setselection (int position) is significantly different when the former is called to re-layout, Immediately triggers the onitemselected function, which acts as a direct click by hand. And the latter set the next choice location: setnextselectedpositionint (position); Then request layout, and Requestlayout is not executed immediately, just a schedule. However, the latter may lose some state when reloading the data and then layout.
The above split line content is reproduced: original link: https://www.xuebuyuan.com/672724.html
-------------------------------------Split Line------------------------------------------
Then goose, I'm going to say the pit is not like this, I don't have two Spinner linkage, and the problem I appear is this, on the code
Layout file:
<?xml version="1.0" encoding="utf-8"?><RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android" xmlns:tools="http://schemas.android.com/tools" android:layout_width="match_parent" android:layout_height="match_parent" tools:context="com.example.sharpcj.helloworld.MainActivity"> <Spinner android:id="@+id/sp_test" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_centerInParent="true"> </Spinner></RelativeLayout>
Java code:
package com.example.sharpcj.helloworld;import android.support.v7.app.AppCompatActivity;import android.os.Bundle;import android.widget.ArrayAdapter;import android.widget.Spinner;import java.util.Arrays;public class MainActivity extends AppCompatActivity { private Spinner mSpTest; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); String[] strs = new String[20]; for (int i = 0; i < strs.length; i++) { strs[i] = "第" + i + "项"; } mSpTest = findViewById(R.id.sp_test); mSpTest.setAdapter(new ArrayAdapter<>(this, android.R.layout.simple_list_item_1, strs)); int index = Arrays.binarySearch(strs, "第11项"); mSpTest.setSelection(index); }}
Operation Result:
What???
Why is that? Spinner said that this pot is not back, in fact, this pit blame myself for a reason, because of the wrong use of Arrays.binarySearch(Object[] a , Object key)
this method, it is assumed that the return value is to find the index of the array. In the code, the actual value of index is-2.
Online to find a bit of information:
binarySearch(int[] a, int key)
The rule for this method is this:
- 1. If a keyword is found, the return value is the position index of the keyword in the array, and the index starts at 0
- 2, if the keyword is not found, the return value is a negative insertion point value, the so-called insertion point value is the first element larger than the keyword position index in the array, and this position index starting from 1.
binarySearch(Object[] a, Object key)
the source code for the final call method is as follows:
// Like public version, but without range checks. private static int binarySearch0(Object[] a, int fromIndex, int toIndex, Object key) { int low = fromIndex; int high = toIndex - 1; while (low <= high) { int mid = (low + high) >>> 1; @SuppressWarnings("rawtypes") Comparable midVal = (Comparable)a[mid]; @SuppressWarnings("unchecked") int cmp = midVal.compareTo(key); if (cmp < 0) low = mid + 1; else if (cmp > 0) high = mid - 1; else return mid; // key found } return -(low + 1); // key not found. }
With respect to the Object type, this dichotomy, written by Oracle God, does not read the code for indexing.
Android location permissions as well as arrays looking for index pits