Android 6.0ランタイム権限要求の簡単なパッケージ

16287 ワード

前に書く
春術を経験したばかりで、多くの知識点があまり使わないと印象がぼやけてしまい、面接では論理的にはっきり言えないことを深く感じています.これも私にふだん多くブログを书く必要性を深く体得させて、これまでずっとブログを书く动力がなくて、一方ではブログを书くのが本当に1件の时间の事だと感じて、一方では自分の日常の学习の上のいくつかの体得と経歴が他人に鑑赏する価値がないと感じます.今思えば、ブログを多く書くことで、少なくとも自分の後で知識を温めることができ、キーボードを叩く今でも印象を深めることができます.では、今日作ったランタイム権限リクエストの簡単なパッケージから始めましょう.自分が続けてブログを何編か書いてほしいです.
ランタイム権限
ランタイム権限の特徴
Android 6.0(API 23)以降、ユーザは、アプリケーションのインストール時に一括して付与するのではなく、アプリケーションの実行時に権限を付与し始める.この取り組みは、アプリケーションのインストールプロセスを簡素化する一方で、ユーザーのプライバシーをよりよく保護します.もちろん、すべての権限が実行時にユーザーに動的に申請される必要はありません.危険な権限だけがユーザーがアプリケーションを明確に承認して使用する必要があります.システム権限の詳細については、通常権限と危険権限を参照してください.
ランタイム権限要求API
具体的には、アプリケーションがユーザーの連絡先を読み取る権限を備えているかどうかを確認し、必要に応じて権限を要求するために、実行時に要求する権限を参照してください.

// Here, thisActivity is the current activity
if (ContextCompat.checkSelfPermission(thisActivity,
                Manifest.permission.READ_CONTACTS)
        != PackageManager.PERMISSION_GRANTED) {

    // Should we show an explanation?
    if (ActivityCompat.shouldShowRequestPermissionRationale(thisActivity,
            Manifest.permission.READ_CONTACTS)) {

        // Show an expanation to the user *asynchronously* -- don't block
        // this thread waiting for the user's response! After the user
        // sees the explanation, try again to request the permission.

    } else {

        // No explanation needed, we can request the permission.

        ActivityCompat.requestPermissions(thisActivity,
                new String[]{Manifest.permission.READ_CONTACTS},
                MY_PERMISSIONS_REQUEST_READ_CONTACTS);

        // MY_PERMISSIONS_REQUEST_READ_CONTACTS is an
        // app-defined int constant. The callback method gets the
        // result of the request.
    }
}

ユーザ応答後、[onRequestPermissionsResult()](https://developer.android.com/reference/android/support/v4/app/ActivityCompat.OnRequestPermissionsResultCallback.html#onRequestPermissionsResult(int,java.lang.String[],int[]))メソッドでは、ユーザーの応答に応じて対応する処理が行われます.公式ドキュメントのサンプルコードは次のとおりです.

@Override
public void onRequestPermissionsResult(int requestCode,
        String permissions[], int[] grantResults) {
    switch (requestCode) {
        case MY_PERMISSIONS_REQUEST_READ_CONTACTS: {
            // If request is cancelled, the result arrays are empty.
            if (grantResults.length > 0
                && grantResults[0] == PackageManager.PERMISSION_GRANTED) {

                // permission was granted, yay! Do the
                // contacts-related task you need to do.

            } else {

                // permission denied, boo! Disable the
                // functionality that depends on this permission.
            }
            return;
        }

        // other 'case' lines to check for other
        // permissions this app might request
    }
}

パーミッションリクエストのカプセル化
実際にランタイム権限の処理は複雑ではないことがわかります.では、なぜ私はランタイム権限を簡単にカプセル化するのでしょうか.

の一方で、ランタイム権限処理のコードは複雑ではないが、この論理が1つのプロジェクトに複数存在する可能性があることを考慮すると、実際の使用では、プロジェクトに多くの重複コードが発生する可能性がある.実行時の権限処理の全体的なプロセスは比較的明確で一致しているため、アプリケーションがその権限を備えているかどうかを確認し、必要に応じてその権限を要求し、ユーザーの応答に応じて相応の後続処理を行うことができ、私たちはこのプロセスをカプセル化し、必要なパラメータを入力することができ、残りのプロセスは特定のオブジェクトに依頼して完成すればよい.

の一方で、実際にランタイム権限の処理も、必ずしも想像したほど簡単ではない.例えば、実行時の権限をFragmentで処理するAPIは、Request runtime permissions from v 4を参照することができる.Fragment and have callback go to Fragment?のディスカッションです.また、以前、あるネットユーザーが、サービスでランタイム権限を動的に申請した後、後続の処理ができない(サービスに対応するコールバックメソッドがない)という問題に言及したことも見られた.これらの問題に対して、ランタイム権限処理を簡単にカプセル化し、これらの問題を統一的に処理できれば、ビジネスロジックコードを作成する際に、この方面の詳細を処理するのに困らなくてもいいです.

もちろん、実際には、実行時の権限処理をカプセル化したライブラリも多く、githubでandroid permissを検索すると、成熟したサードパーティのオープンソースライブラリがたくさん見つかります.繰り返しホイールを作るのはあまり良い習慣ではありませんが、私はやはり自分でパッケージを作ることを選びました.主に考えています.

ランタイム権限処理は全体的に簡単ですが、そのためにプロジェクトにサードパーティ製ライブラリを追加すると、プロジェクトに実際には使用できない方法が追加される可能性があります.

は私の個人的な符号化習慣と関係があり、私は1つの機能の処理プロセスの完全なコードを1つの場所に置くことに慣れています.私が後でコードを見に行く必要がある場合は、1つのファイルで繰り返しジャンプする必要はありません.したがって,ランタイム権限処理では,関連パラメータを入力して要求するとともに,関連処理後のコールバックメソッドも入力したい.

パッケージングの使用法
まず、パッケージの後に権限申請を行う方法を見てみましょう.

new PermissionRequest.Builder(MainActivity.this,
                        new String[]{DangerousPermission.CAMERA, DangerousPermission.CALL_PHONE})
                        .build()
                        .request();

ContextパラメータとPerimissionsパラメータを入力してPermissionRequestを構築し、requestメソッドを呼び出せばよい.もちろん、通常、ユーザーの応答に基づいて後続の処理を行う必要があります.

new PermissionRequest.Builder(MainActivity.this,
                        new String[]{DangerousPermission.CAMERA, DangerousPermission.CALL_PHONE})
                        .setCallBack(new PermissionRequest.CallBack() {
                            @Override
                            public void onSuccess(String permission) {
                                //   permission             
                            }

                            @Override
                            public void onFail(String permission) {
                                //   permission             
                            }

                            @Override
                            public void onGranted() {
                                //             
                            }
                        })
                        .build()
                        .request();

現在の使い方は簡単です.
パッケージング分析
Builderを使用してPermissionRequestを構築するときに入力される権限文字列は
DangerousPermission.CAMERA
標準ではなく文字列
android.Manifest.permission.CAMERA
このような権限文字列.ここでは、単に自分が使用している間に正常な権限に対して動的な申請をしないようにするため(正常な権限がパラメータとして伝わっても問題ありませんが、純粋に強迫症orz)、危険な権限を1つのクラスDangerousPermissionで格納します.

/**
 * Created by Wangzf on 2017/5/15.
 *    Android      
 *   https://developer.android.com/guide/topics/security/permissions.html?hl=zh-cn#normal-dangerous
 */

public class DangerousPermission {

    // permission-group.CALENDAR
    public static final String READ_CALENDAR = permission.READ_CALENDAR;
    public static final String WRITE_CALENDAR = permission.WRITE_CALENDAR;

    // permission-group.CAMERA
    public static final String CAMERA = permission.CAMERA;

    // permission_group.CONTACTS
    public static final String READ_CONTACTS = permission.READ_CONTACTS;
    public static final String WRITE_CONTACTS = permission.WRITE_CONTACTS;
    public static final String GET_ACCOUNTS = permission.GET_ACCOUNTS;

    // permission-group.LOCATION
    public static final String ACCESS_FINE_LOCATION = permission.ACCESS_FINE_LOCATION;
    public static final String ACCESS_COARSE_LOCATION = permission.ACCESS_COARSE_LOCATION;

    // permission-group.MICROPHONE
    public static final String RECORD_AUDIO = permission.RECORD_AUDIO;

    // permission-group.PHONE
    public static final String READ_PHONE_STATE = permission.READ_PHONE_STATE;
    public static final String CALL_PHONE = permission.CALL_PHONE;
    public static final String READ_CALL_LOG = permission.READ_CALL_LOG;
    public static final String WRITE_CALL_LOG = permission.WRITE_CALL_LOG;
    public static final String ADD_VOICEMAIL = permission.ADD_VOICEMAIL;
    public static final String USE_SIP = permission.USE_SIP;
    public static final String PROCESS_OUTGOING_CALLS = permission.PROCESS_OUTGOING_CALLS;

    // permission-group.SENSORS
    public static final String BODY_SENSORS = permission.BODY_SENSORS;

    // permission-group.SMS
    public static final String SEND_SMS = permission.SEND_SMS;
    public static final String RECEIVE_SMS = permission.RECEIVE_SMS;
    public static final String READ_SMS = permission.READ_SMS;
    public static final String RECEIVE_WAP_PUSH = permission.RECEIVE_WAP_PUSH;
    public static final String RECEIVE_MMS = permission.RECEIVE_MMS;

    // permission-group.STORAGE
    public static final String READ_EXTERNAL_STORAGE = permission.READ_EXTERNAL_STORAGE;
    public static final String WRITE_EXTERNAL_STORAGE = permission.WRITE_EXTERNAL_STORAGE;
}

現在、PermissionRequestの構築に必要なパラメータはContext、Permissions、PermissionRequestのみである.CallBackは、Builderモードを使用してPermissionRequestインスタンスを作成するのは、過剰な設計の疑いがあるようです(現在はsetCallBackメソッドのみが提供されています)が、PermissionRequestに追加のカスタマイズ機能(ユーザーが権限要求を拒否した後の対応ポリシーをカスタマイズするなど)を提供するか、Builderモードを使用してオブジェクトの作成を完了するかを考慮します.リクエストメソッドの具体的な実装を考慮する.以前はPermissionRequestを構築する際にCallBackに同時に転送して対応するコールバック処理コードを1つに書くことを想定していたが、公式APIでコールバックするロジックはonRequestPermissionsResult()メソッドで実現する必要があり、これは問題を生んだ:一方で私はパッケージを通じてonRequestPermissionsResult()などのAPIの呼び出しを隠すことができることを望んでいた.一方、onRequestPermissionsResult()メソッドは、発起権限要求に対応するContextで呼び出され、対応するコールバックメソッドが呼び出される必要があります.1つの比較的直感的な解決策は、onRequestPermissionsResult()メソッドの処理ロジックをBaseActivityに書き込み、実行時の権限を処理する必要があるActivityにこのBaseActivityを継承させることです.しかし、この解決策は優雅ではありません.

Java単一継承の特性のため、このような単一の需要のために貴重な継承資格を簡単に占有するべきではありません.もちろん、自分が現在の特定項目のために作ったパッケージであれば、元のBaseActivityにonRequestPermissionsResult()メソッドの処理ロジックを組み込むことも可能です.しかし、私が現在やっているパッケージ作業は、現在のプロジェクトとは独立したコンポーネントを完成させることを目的としており、このような解決策は現実的ではありません.

一方、BaseActivityという方式では、Activityでランタイム権限を処理するパッケージの問題しか解決できず、前述したFragment、Serviceの問題は解決できない.

そのため、別の解決策を求めなければならない.ドキュメントをめくっているとsupportにv4.app.FragmentのrequestPermissions()メソッドの解釈では、
This method may start an activity allowing the user to choose which permissions to grant and which to reject. Hence, you should be prepared that your activity may be paused and resumed.
これは私にいくつかのヒントを与えて、同様に、私たちも新しいActivityを起動して実行時の権限を処理することができます!このようにすべての問題が解決され、パッケージされたコンポーネントでActivityを起動してランタイム権限を処理し、onRequestPermissionsResult()メソッドの処理ロジックを隠すことができます.また、Activityでランタイム権限を処理しているため、PermissionRequestを呼び出すrequestメソッドがどのコンテキスト環境(Activity、Fragment、またはService)であるかにかかわらず、実際にはActivityで行われている処理であり、Fragment、Serviceで発生する可能性のある問題も存在しません.PermissionRequestの完全なコードを貼り付けます.

/**
 * Created by Wangzf on 2017/5/15.
 *              
 */

public class PermissionRequest {

    private Context mContext;
    private String[] mDangerousPermissions;
    private CallBack mCallBack;

    //         
    private List mDeniedPermissions;

    private PermissionRequest(Context context, String[] dangerousPermissions) {
        mContext = context.getApplicationContext();
        mDangerousPermissions = dangerousPermissions;
    }

    public void request() {
        checkDangerousPermissions();

        if (mDeniedPermissions.isEmpty()) {
            mCallBack.onGranted();
        } else {
            startPermissionRequest();
        }
    }

    private void checkDangerousPermissions() {
        if (mDeniedPermissions == null) {
            mDeniedPermissions = new ArrayList<>();
        } else {
            mDeniedPermissions.clear();
        }

        for (int i = 0; i < mDangerousPermissions.length; i++) {
            if (!checkDangerousPermission(mDangerousPermissions[i])) {
                mDeniedPermissions.add(mDangerousPermissions[i]);
            }
        }
    }

    private void startPermissionRequest() {
        RequestPermissionActivity.setRequestCallBack(mCallBack);

        Intent requestIntent = new Intent(mContext, RequestPermissionActivity.class);
        requestIntent.putExtra(Const.DENIED_PERMISSIONS, (Serializable) mDeniedPermissions);
        mContext.startActivity(requestIntent);
    }

    /**
     *               
     * @param dangerousPermission
     * @return          ，  true；    false
     */
    private boolean checkDangerousPermission(String dangerousPermission) {
        if (ContextCompat.checkSelfPermission(mContext, dangerousPermission) ==
                PackageManager.PERMISSION_GRANTED) {
            return true;
        }
        return false;
    }

    public interface CallBack {

        void onSuccess(String permission);
        void onFail(String permission);
        //          
        void onGranted();
    }

    public static class Builder {

        private PermissionRequest mPermissionRequest;

        public Builder(Context context, String[] dangerousPermissions) {
            mPermissionRequest = new PermissionRequest(context, dangerousPermissions);
            mPermissionRequest.mCallBack = new CallBack() {
                private static final String TAG = "CallBack";

                @Override
                public void onSuccess(String permission) {
                    Log.i(TAG, "onSuccess");
                }

                @Override
                public void onFail(String permission) {
                    Log.i(TAG, "onFail");
                }

                @Override
                public void onGranted() {
                    Log.i(TAG, "onGranted");
                }
            };
        }

        public Builder setCallBack(CallBack callBack) {
            mPermissionRequest.mCallBack = callBack;

            return this;
        }

        public PermissionRequest build() {
            return mPermissionRequest;
        }
    }
}

コードはすべて簡単で、何も言うことはありません.詳細は、PermissionRequestの作成時にContextパラメータが渡され、メモリの漏洩を防ぐためにPermissionRequestの構築方法で処理されたためです.

    private PermissionRequest(Context context, String[] dangerousPermissions) {
        mContext = context.getApplicationContext();
        mDangerousPermissions = dangerousPermissions;
    }

最終的にmContextに付与されるのは、受信したcontextではなくアプリケーションのコンテキストである.PermissionRequestでmContextを使用する必要があるシーンを考慮すると、アプリケーションが権限を持っているかどうかを判断したり、新しいActivityを起動したりするときに使用するだけで、アプリケーションコンテキストを使用すると完全に要求を満たすことができます.Builderの構成方法では、PermissionRequestのmCallBackに対してデフォルトインプリメンテーションが作成されていることに注意してください.このデフォルトインプリメンテーションの主な目的は、PermissionRequestにCallBackを設定しない場合に、RequestPermissionActivityのonRequestPermissionsResult()メソッドがCallBackの対応方法を通常通り呼び出すことができ、CallBackが空であるか否かを別途判断する必要がないことです.また、CallBackの具体的な方法は最終的にRequestPermissionActivityで呼び出されるので、CallBackをRequestPermissionActivityに渡す方法の問題も解決しなければなりません.この問題は私はいつも良い解決方法が思いつかないので、最終的にはRequestPermissionActivityで静的なsetRequestCallBack方法を乱暴に実現するしかありません.このメソッドをPermissionRequestで呼び出して、CallBackをRequestPermissionActivityに渡します.RequestPermissionActivityのコードを貼り付けます.

public class RequestPermissionActivity extends AppCompatActivity {

    private static PermissionRequest.CallBack mRequestCallBack;

    //         
    private List mDeniedPermissions;
    private String[] mDeniedPermissionsArray;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        getDatas();

        ActivityCompat.requestPermissions(RequestPermissionActivity.this, mDeniedPermissionsArray, Const.REQUEST_FIRST);
    }

    @Override
    public void onRequestPermissionsResult(int requestCode, @NonNull String[] permissions, @NonNull int[] grantResults) {
        super.onRequestPermissionsResult(requestCode, permissions, grantResults);

        switch (requestCode) {
            case Const.REQUEST_FIRST:
                boolean granted = true;
                for (int i = 0; i < grantResults.length; i++) {
                    if (grantResults[i] == PackageManager.PERMISSION_GRANTED) {
                        mRequestCallBack.onSuccess(permissions[i]);
                    } else {
                        granted = false;
                        mRequestCallBack.onFail(permissions[i]);
                    }
                }
                if (granted) {
                    mRequestCallBack.onGranted();
                }
                finish();
                break;
            default:
        }
    }

    private void getDatas() {
        Intent requestIntent = getIntent();

        mDeniedPermissions = (List) requestIntent.getSerializableExtra(Const.DENIED_PERMISSIONS);

        mDeniedPermissionsArray = new String[mDeniedPermissions.size()];
        Util.list2Array(mDeniedPermissions, mDeniedPermissionsArray);
    }

    public static void setRequestCallBack(PermissionRequest.CallBack requestCallBack) {
        mRequestCallBack = requestCallBack;
    }

}

ここではActivity Compat.ActivityではなくrequestPermissionsメソッドのrequestPermissionsメソッドは主にAPI 23以下の場合に対応するためである.
以上はパッケージ全体の流れですが、中ではパッケージの思考をくどくど話しているので、簡単な問題もいつの間にかこんなにたくさん話していました.このパッケージは全体的に粗いが,コールバックインタフェースの設計,特にユーザ応答後の関連処理は修正される必要がある.細かく記録しておくと、自分が使いやすい時に墓を掘ることもできます.パッケージの时も多くの博文を参考にして、初めていくつかのオープンソースライブラリの実现を见て、一绪にネット上で分かち合う大神达に感谢します.

[week 1-1]NLPタスクの理解

[Javascript]配列