去掉原文

去掉原文

Author: shenyansycn

issue-39/权限 － 第三篇.md

@@ -9,22 +9,14 @@
 * 校对者: 
 * 状态 :  翻译中
 
-With Marshmallow a new permissions model was added to Android which requires developers to take a somewhat different approach to permissions on Android. In this series we’ll take a look at ways to handle requesting permissions both from a technical perspective, and in term of how to provide a smooth user experience.
-
 在Marshmallow（棉花糖，Android6.0版本）中Android添加了一个新的权限模块，需要开发者在授权的时候做一些不同的处理。在这一系列中，我们从技术角度看下如何处理请求的权限和如何提供流畅的用户体验。
 
 ![Icon_no_permission](https://i0.wp.com/blog.stylingandroid.com/wp-content/uploads/2015/12/Icon_no_permission.png?w=240)
 
-Previously we looked at how we can incorporate the logic for checking that we have the required permissions, but next we’ll look at how we can actually request the permissions that haven’t been granted.
-
 我们已经知道了如何检测我们需要的权限，现在我们看下如何请求被拒绝的权限。
 
-The happy flow (for us as developers, at least) for this is that we ask the user to explicitly grant us a required permission, the user grantes it and everyone is happy. But, as we discussed previously, we need to cover the cases where the user denies us the permission we’ve requested.
-
 令人高兴的流程是（至少对于开发者来说），我们直接询问用户授权需要的权限，用户授权了，大家都高兴。但是，就像我们之前讨论过的，我们需要考虑到用户没有授予权限的情况。
 
-Let’s first look at the logic for the happy path as this is relatively straightforward:
-
 现在让我们看下，我们直接提出请求的操作：
 
 PermissionsActivity.java
@@ -87,12 +79,8 @@ public class PermissionsActivity extends AppCompatActivity {
 }
 ```
 
-We have a startActivityForResult() method which is a simple utility method which other Activities must use to start the PermissionsActivity with a given set of required permissions. So the flow is pretty straightforward once we have the required permissions. However, you may be wondering why we need this – surely we launched the Activity because we already determined that we don’t have the required permissions? The reason that we need this is for some of the following edge cases – if the user leaves this Activity temporarily, and grants the permission in Settings, then returns then this flow will be followed.
-
 我们有一个非常实用的startActivityForResult()方法，其他Activity必须使用这个传入需要请求的一套权限来启动PermissionsActivity。所以我们可以直接一次都请求所需要的权限。然而，你可能会疑惑我们为什么需要这个－我们启动Activity是因为我们已经知道我们没有获得所需要的权限么？我们需要这个的原因是如下的这些小概率情况－如果用户临时离开了这个Activity，在设置中授权了权限，然后再回来的时候这个流程会次执行。
 
-But what about when we don’t have the required permissions – we’ll need to request them:
-
 但是当我们没有所需要的权限时怎么办－我们需要请求它们：
 
 PermissionsActivity.java
@@ -130,16 +118,10 @@ public class PermissionsActivity extends AppCompatActivity {
     .
 ```
 
-This is the core of the process. We call requestPermissions() which passes control to the OS to request the permissions that we require. I always make a point of passing both normal and dangerous level permissions here even though we get automatically granted normal permissions. The reasoning behind this is that if what is now considered a normal permission was changed to a dangerous permission in the future then everything would still work.
-
 这就是处理核心。我们调用requestPermissions()请求我们需要的权限。我这里总是强调标准和危险级别的权限，虽然我们自动获得标准的权限。背后的原因是，如果标准权限在未来变为一个危险的权限，那么仍会正常工作。
 
-requestPermissions() operates in a similar manner to startActivityForResult() – we pass control to another Activity and then get a callback once that Activity completes. In this case the callback method is onRequestPermissionResult(). This checks that all of the requested permissions have been granted and either passes control back (either through finish() or invoking MainActivity, as before), or things become a little more complex: We have requested the required permission, and the user has denied it.
-
 requestPermissions()的操作和startActivityForResult()的操作很像 － 我们在另一个Activity中处理，然后在本Activity中用一个回调做为结束。这个例子中的回调函数是onRequestPermissionResult()。它检测了所有被授权的权限和要么返回处理（要么通过finish()，要么重新唤醒MainActivity，就像之前那样），要么事情变为稍有复杂：我们请求所需要的权限但用户拒绝了。
 
-The first time we ask the user for a particular permission following installation the user will be given with a simple choice: Allow or deny. If they deny us permission and we request it again they will also have a checkbox labelled “Never ask again”. If the user checks this and taps “Deny” then any subsequent requests that we make for the same permission will automatically be denied. Unfortunately we have no way of knowing if this has happened we will just get a PERMISSION_DENIED response. Bearing in mind that this particular permission is critical to the operation of this app we need to further inform the user of why this permission is required and, if they still refuse to grant it, exit the app:
-
 首先，安装时我们会问用户一个特殊的权限，用户可以选择：允许或拒绝。如果拒绝了权限，我们会在此请求，这时会有一个单选框“不再询问”。如果用户选择了一个单选框并按了“拒绝”，之后的任何权限请求都会被自动的拒绝。不幸的是，我们的权限被拒绝了，我们并不知道用户是否执行了上面的操作。考虑到这个特殊的权限是App运行所急需的，我们需要明确告诉用户为什么我们需要这个权限，如果仍然被拒绝，那就退出App：
 
 PermissionsActivity.java
@@ -177,33 +159,20 @@ public class PermissionsActivity extends AppCompatActivity {
 }
 ```
 
-I have deliberately kept the actual text used here somewhat vague because every app will need to explain its precise reasons for needing the permission in question. Also, for the sake of clarity, I have no way of providing different information for different permissions as only one dangerous permission is being requested. However is a real app you will probably need to determine which permission is missing and provide appropriate information for each.
-
 我故意让这里的说明文本说的有点含糊，因为每一个app都要解释需要这个权限的具体原因。同样，为了清晰明了，当只有一个危险权限被请求时，我没有办法没有针对不同权限提供不同的信息。然而，一个真实的app，你很可能需要确定哪一个权限缺失了和针对每一个缺失的提供一个恰当的描述信息。
 
-So here we can see the flow when the user initially denies the permission, exits and subsequently grants the permission:
-
 这里我们可以看到当用户最初拒绝了这个权限，退出和后来的权限的授予。
 
 [video](https://youtu.be/0YBb_lmsyIM)
 
-
-If the user permanently denies permission (by checking “Never ask again”) the flow becomes a little more complex for the user because we cannot provide a link directly to the Permissions Settings page for our app so we need to provide some instructions to help the user:
-
 如果用户永远拒绝了权限（通过“不再提醒”选择框）。接下来会稍微复杂，因为我们不能提供一个我们app权限设置页面的直接链接，所以我们需要给用户提供一些说明：
 
 [video](https://youtu.be/gqFIJvMqIpQ)
 
-It would be nice if we could alter the flows between the two kinds of denial. The first video shows that we have to tell the user to alter things through Settings even though we subsequently see that exit and re-launch prompts them once again to allow or deny. Unfortunately we have no way of knowing if the user has selected “Never ask again” so we have to work against the worst-case scenario.
-
 需要注意的是是否我们改变了这两者之间的流程。第一个视频展示的是我们告知用户通过设置改变，即使我们随后看到了退出和重新启动后再次提示的允许或拒绝。不幸的，我们没有办法知道用户是否选择了“不再提示”，所以我们要做最坏情况的打算。
 
-That said we now have a relatively simple, reusable method of requesting the critical permissions for our app. In the final article in this series we’ll look at non-critical permissions and consider some best practise.
-
 即便如此我们现在有一个相对简单，可以重复使用的请求我们应用关键权限的方法。在这个系列的最后一篇文章我们来看看非关键权限和更多的练习。
 
-The source code for this article is available [here](https://github.com/StylingAndroid/Permissions/tree/Part3).
-
 源代码在[这里](https://github.com/StylingAndroid/Permissions/tree/Part3)。
 
 © 2016, [Mark Allison](https://blog.stylingandroid.com/). All rights reserved.

issue-39/权限 － 第四篇.md

@@ -9,47 +9,27 @@
 * 校对者: 
 * 状态 :  翻译中
 
-With Marshmallow a new permissions model was added to Android which requires developers to take a somewhat different approach to permissions on Android. In this series we’ll take a look at ways to handle requesting permissions both from a technical perspective, and in term of how to provide a smooth user experience.
-
 在Marshmallow（棉花糖，Android6.0版本）中Android添加了一个新的权限模块，需要开发者在授权的时候做一些不同的处理。在这一系列中，我们从技术角度看下如何处理请求的权限和如何提供流畅的用户体验。
 
 
 ![Icon_no_permission](https://i0.wp.com/blog.stylingandroid.com/wp-content/uploads/2015/12/Icon_no_permission.png?w=240)
 
-Previously we looked at the mechanism for determining missing permissions and requesting them at runtime. We’ve looked at required permissions (i.e. those that are core to the primary function of your app), but what we have yet to discuss is non-essential permissions – those which are require for some nice features your app, but are not part of the core function. For example a camera app which is denied the “Camera” permission will be pretty useless for its main function of taking pictures; but if it can also geotag pictures (for which it requires “Location” permissions), but the geotagging feature can simply be disabled if the user does not grant the permission.
-
 之前我们看了检测缺失权限的机制和运行时的请求。我们考虑了所需要的权限（即那些你app的主要核心功能），但是我们还讨论了非必需的权限 － 你app的一些更好的特性所需要的权限，但不是你核心功能的部分。例如，一个相机app被拒绝了“Camera”权限，它的主要功能拍照就会变得没有任何用处；但如果它也能设置地理标签（需要“Location”权限），如果用户没有授予这个权限，地理标签的这个特性也是不可用的。
 
-Unfortunately there are no hard and fast rules regarding non-essential permissions as the correct time an place to request such permissions will be governed by the organisation and information architecture of your app. Once important thing to remember is that it is best to request such permissions in the context within which they are required. For example, to use the geotagging example, when the user has just taken a picture at the point where the geotagging would occur would be the perfect time to ask the user for the necessary permission.
-
 不幸的是关于非必需权限没有一个精确的定义，因为请求这样的权限的正确时间取决于你app的原理与架构。要记住更重要的事情是最好在它们被需要的时候请求。例如，地理标签的这个例子，当用户想要设置标签的时候才询问用户请求授予需要的权限。
 
-It is also worth considering how obvious the need for a particular permission is. For geotagging it is pretty obvious why the “Location” permissions would be required to be able to tag a picture with the location at which it was taken. However the reason for the “Record Audio” permission that we’ll need to the next series of articles is somewhat less obvious so we need to explain why the permission is required so that the user can make a more informed decision about whether to grant or deny the permission. If the user doesn’t understand why a particular permission in needed then there is a higher chance that they will simply deny it.
-
 如何明显的说明需要特别的权限也是值得考虑的。对于地理标签要明显说明，为什么“Location”权限会被需要，是因为能标记一个图片所发生的位置。然而，我们下一个系列文章需要的“Record Audio权限的理由就不是那么明显，所以我们需要解释为什么需要这个权限，以便用户有更多的信息来决定是否允许或拒绝这个权限。如果用户不知道为什么一个特别权限被需要，那么会有很大机会用户会拒绝它。
 
-Another thing to consider is overwhelming the user. It may seem tempting to simply ask for all permissions up-front because it’s easier to code it that way. This is a mistake, in my opinion. If the user’s first impression of your app is simply being asked for one permission after another then there is a high chance that they may simply exit your app and uninstall if they son’t see any immediate value from your app. It is much better to ask for the bare minimum up-front and request other permissions in context. Not only will this help the user to understand why each permission is needed (and therefore increase the likelihood of them granting the permission), but will also enable them to perceive some value from your app much sooner than if they have to wade through a number of permission requests before they even get to your app on first launch.
-
 另一件值得考虑的是难对付的用户。看起来容易简单的预先请求所有的权限是因为那样更容易写代码。依我看来，这是错误的。如果用户对于你app的第一个印象是仅仅被请求一个又一个权限，又没有看到你的app的任何直接价值那么很有可能他们会退出并卸载你的应用。最好是最低限度的预先请求上下文中的其他权限。这不仅是帮助用户理解为什么每一个权限是被需要的（因此增加了他们授予权限的可能性），相对于他们费力的做完一堆权限的请求，这么做能使他们在第一次启动应用前更早的感受到你应用的一些价值。
 
-Another related point is to only actually ask for the permissions you need. Although this may seem pretty obvious sometimes. as software evolves over time, permissions which were once required can sometimes go out of scope and no longer be required. It is worth periodically having a review of your app’s permission requirements and remove any redundant permissions requests.
-
 另一个关键点时仅请求你需要的权限。虽然这有时是显而易见的。随着软件的发展，曾经需要的权限有时会超出范围和不是必须的。定期查看你app需要的权限和清除任何多余的权限请求是非常有必要的。
 
-Some may be wondering why I have not incorporated [shouldShowRequestPermissionRationale()](http://developer.android.com/reference/android/support/v4/app/ActivityCompat.html#shouldShowRequestPermissionRationale(android.app.Activity, java.lang.String)) check in my example code. The simple reason is that I feel that the flow of the implementation that I have is sufficiently well structured to provide further explanation of why the requested permission is required. However, for non-essential permissions which are requested in the correct context this mechanism may be a little more useful.
-
 有人可能会疑惑，为什么我没有在例子代码中包含[shouldShowRequestPermissionRationale()](http://developer.android.com/reference/android/support/v4/app/ActivityCompat.html#shouldShowRequestPermissionRationale(android.app.Activity, java.lang.String))检测。简单的原因是我认为对于接口实现流程我已经有一个很好的架构更近一步说明了为什么需要请求权限。不管怎样，在当前正文中请求非必需的权限这个机制可能稍微更有作用。
 
-One final thing to bear in mind is that if the user performs a “Clear Data” on your app it will not only clear all of the data but will also reset all of the permissions. The next time the user launches your app all previously granted permissions will now be denied. While this can be useful when testing your permission implementation, it is worth bearing in mind if you are responding to customer support questions where users may have done precisely this and are complaining that they keep having to grant the same permissions.
-
 最终需要记住的是，如果用户清空了你app的数据，这不仅仅是清空了所有的数据，还重置了所有的权限。用户再次启动你的app时所有之前授权的权限都会被拒绝。这对于你测试权限申请非常有用，同时为客服提供了应对用户提出“为什么我已经同意了权限还需要重新申请？”问题的准备答案。
 
-That concludes our look at the Marshmallow permissions model. In the next series of articles we’ll be making use of the techniques that we’ve covered here.
-
 总结下我们所看到的Marshmallow权限模型。在下一个系列文章中我们会用到我们这里用到的技术。
 
-Although no code has been added in this article, the code for the previous article is available [here](https://github.com/StylingAndroid/Permissions/tree/Part3).
-
 本章没有代码，前一章的代码在[这里](https://github.com/StylingAndroid/Permissions/tree/Part3)。
 
 © 2016, [Mark Allison](https://blog.stylingandroid.com/). All rights reserved.