by Varun Barad

由Varun Barad

Android开发中应避免的重大错误 (Critical mistakes to avoid in Android development)

As many pioneers and leaders in different fields have paraphrased:

正如许多不同领域的开拓者和领导人所说：

In any endeavor, it is important to know what are the top few things that need to be done right. But, it is equally important, if not more, to know the top few things which people should avoid at all costs.

在任何努力中，重要的是要知道需要正确完成的几件事。 但是，同样重要的是，要了解人们应不惜一切代价避免的头几件事情，即使不是更多。

My posts up until now have been about how to perform a particular task on Android. Heeding the above saying, today I will be writing about the first five mistakes which I think should be avoided by Android developers.

到目前为止，我的文章一直是关于如何在Android上执行特定任务的。 遵循上述说法，今天我将写我认为Android开发人员应避免的前五个错误。

没有将所有字符串都显示在strings.xml (Not putting all the strings to be displayed in strings.xml)

This provides for a poor internationalization experience, as you will have to design your own ways of displaying the correct version of a message based on the user’s locale.

这会提供较差的国际化体验，因为您将不得不设计自己的方式来根据用户的语言环境显示消息的正确版本。

If the messages are in strings.xml, then they can easily be translated and integrated into the app. The Android OS then seamlessly handles which string resource to use based on the locale that the user has set on their device.

如果消息在strings.xml中，则可以轻松地将它们翻译并集成到应用程序中。 然后，Android OS根据用户在其设备上设置的语言环境无缝处理要使用的字符串资源。

Here are a few of the reasons given by users to not use string-resources:

用户给出的一些不使用字符串资源的原因如下：

• Need context to access: if you wish to display that string to UI, you will inevitably need/have some kind of context there too. Just use that same context to fetch the string.

  需要访问上下文：如果您希望将该字符串显示到UI，您将不可避免地在那里也需要某种上下文。 只需使用相同的上下文来获取字符串。

• But I only need it in this one place: There is no telling when tomorrow you might need to have that same string in some other file. It is better to invest an extra minute to provide insurance against future problems

  但是我只在一个地方需要它：没有告诉您明天什么时候可能需要在其他文件中使用相同的字符串。 最好花额外的时间为将来的问题提供保险

• Complex string with run-time data: Friends, Android has you covered. There are parameterized strings supported by the platform with a syntax similar to the one used in Java’s String.format(). More than that, plural-strings (using different strings based on the quantity of something) are also supported. Check out this StackOverflow post for parameterized strings and the official documentation for plural-strings.

  包含运行时数据的复杂字符串：朋友们，Android已经为您服务。 平台支持带有参数化的字符串，其语法类似于Java的String.format()使用的语法。 不仅如此，还支持复数字符串(根据事物的数量使用不同的字符串)。 请查看此StackOverflow帖子中有关参数化字符串的信息，以及有关复数字符串的官方文档 。

不使用数据绑定 (Not using data-binding)

Who likes to write cumbersome findViewById calls and then maintain the reference to those views in their current namespace? Also, in that case we need to keep our view-id’s so that we are sure of which view-id we are using in findViewById . This is because autocomplete in Android Studio will suggest every id (from all layouts), but only those present in the current layout tree will be available to findViewById . Non-existent ones will return null (probably causing a NullPointerException).

谁喜欢编写繁琐的findViewById调用，然后在其当前名称空间中维护对这些视图的引用？ 同样，在这种情况下，我们需要保留view-id，以便确定在findViewById中使用的是哪个view-id。 这是因为Android Studio中的自动完成功能会建议每个ID(来自所有布局)，但只有当前布局树中存在的ID才可用于findViewById 。 不存在的将返回null (可能导致NullPointerException )。

Google has made it extremely easy to integrate data-binding into any app (new/existing) and eliminate all those pesky boilerplate view-reference stuff.

Google使其非常容易地将数据绑定集成到任何应用程序中(新的/现有的)，并消除了所有讨厌的样板视图参考内容。

A few of the benefits of using data-binding (over not using it) are:

使用数据绑定(而不是不使用它)的一些好处是：

• References to only present views available (trying to refer to an absent component will show an error while editing the file in AS. It will also throw a compile-time error instead of biting you at runtime.).
  仅引用可用的当前视图(尝试引用不存在的组件会在AS中编辑文件时显示错误。它还会引发编译时错误，而不是在运行时引起您的注意。)

• A bit faster due to it needing to traverse the whole layout-tree only once as opposed to every-time when findViewById is called.

  由于它只需要遍历整个布局树一次，因此比每次调用findViewById时遍历要快一些。

• Your working namespace (class/function) remains clean, and you don’t have to keep a reference to all the views.
  您正在使用的名称空间(类/函数)保持整洁，并且您不必保留对所有视图的引用。

• You can use as few of the features in data-binding as just using it to eliminate findViewById calls to much more advanced features (like in this post, George Mount of Google tries to write a single adapter for all the recycler-views in an app).

  您可以在数据绑定中使用最少的功能，就像使用它来消除对更多高级功能的findViewById调用一样(如本文中 ，Google的George Mount尝试为应用程序中的所有回收器视图编写单个适配器)。

不隐藏API密钥 (Not hiding API keys)

This is a common problem which is domain-agnostic and made mostly by junior developers in almost all the areas. Once you commit some piece of code to version control it remains there forever. Even if you remove that API key in future commits, anyone who has access to that repository can view the key from its history and all sorts of problems can follow.

这是一个与领域无关的常见问题，几乎由几乎所有领域的初级开发人员提出。 一旦将某些代码提交到版本控制中，它将永远存在。 即使您在以后的提交中删除了该API密钥，任何有权访问该存储库的人都可以从其历史记录中查看该密钥，并且可能会出现各种问题。

You can take a look at this post to figure out how to hide your API keys from your repository while still including them in the build process and making them available in your code.

您可以看一下这篇文章，以了解如何从存储库中隐藏API密钥，同时仍将它们包含在构建过​​程中并使它们在代码中可用。

不考虑活动生命周期 (Not taking activity life-cycle into account)

Any type of configuration change will cause the current activity to be destroyed and created again. To make sure that the transition is seamless for the user, we need to store the state our app was in just before the configuration change. Then we can recreate it just how the user expects it to be using the state after our activity is created anew following the configuration change.

任何类型的配置更改都将导致当前活动被破坏并再次创建。 为了确保过渡对用户而言是无缝的，我们需要在配置更改之前存储应用程序所处的状态。 然后，我们可以重新创建它，就像在配置更改后重新创建我们的活动之后，用户如何期望它使用状态一样。

While on the subject, we should also store the app’s state when our current activity moves to stopped state. After that, our app may be killed as per the system’s need of resources.

在进行主题讨论时，当我们的当前活动变为停止状态时，我们还应该存储应用程序的状态。 之后，我们的应用可能会根据系统的资源需求而被终止。

不学习Android Studio中的键盘快捷键 (Not learning the keyboard shortcuts in Android Studio)

This might not be something which reflects in the code you write, but it highly affects your total workflow. Android Studio is built on top of IntelliJ Idea (an IDE famous for its keyboard friendliness). This means that there is a lot to be gained in developer productivity by simply investing a bit of time in learning different keyboard shortcuts. Here are some of my favorite resources to help you with that:

这可能不会反映在您编写的代码中，但会严重影响您的总体工作流程。 Android Studio是基于IntelliJ Idea(以键盘友好而闻名的IDE)构建的。 这意味着通过简单地花费一些时间来学习不同的键盘快捷键，就可以在开发人员的工作效率中获得很多收益。 这是我最喜欢的一些资源，可以帮助您：

• KeyPromoter — This is an IntelliJ plugin (available in AS) which would display a giant ugly dialogue, showing the shortcut command for the action you just performed, whenever you use your mouse to do something. Trust me, this one will annoy the hell out of you and kind of force you to learn those shortcuts. You can find and download it from the plugins section of Android Studio settings.

  KeyPromoter —这是一个IntelliJ插件(在AS中可用)，每当您使用鼠标做某事时，它都会显示一个巨大的丑陋对话框，显示您刚刚执行的操作的快捷命令。 相信我，这会让您烦恼，并迫使您学习这些捷径。 您可以从Android Studio设置的插件部分找到并下载。

• Cheat-sheet — This is an official printable cheat-sheet for the keyboard shortcuts by Jetbrains (the company behind IntelliJ). Versions for both Windows and Mac are available.

  备忘 单 - 这是 Jetbrains(IntelliJ背后的公司)的键盘快捷键的官方可打印备忘单 。 适用于Windows和Mac的版本。

• Official Guide — This is the official guide provided by Jetbrains to mastering keyboard shortcuts on IntelliJ platform.

  官方指南 — 这是 Jetbrains提供的用于在IntelliJ平台上掌握键盘快捷键的官方指南 。

• Also check out these two videos

  同时查看这 两个视频

那是所有人 (That’s all folks)

These are the five things which I think anyone working in Android development should focus on first. If you have any other suggestions regarding these or any other topics under the sky, do contact me on Twitter at @varun_barad.

这是我认为从事Android开发的任何人应该首先关注的五件事。 如果您对这些或其他主题有其他建议，请通过Twitter @varun_barad与我联系。

翻译自: https://www.freecodecamp.org/news/first-5-mistakes-to-avoid-in-android-development-51177007a4f6/