ie开发人员工具位置移动_我放弃成为移动开发人员的9个理由

ie开发人员工具位置移动

Back when I was in university, Android and iOS were still rather new platforms and everybody was excited about them. When there was some kind of coding workshop you almost certainly ended up building a small Android app. That is how I took my first steps in the Android ecosystem and probably also the reason why I became a Mobile Developer right after.

当我上大学时，Android和iOS仍然是相当新的平台，每个人都为它们感到兴奋。 当有某种编码研讨会时，您几乎可以肯定会最终构建一个小型Android应用程序。 这就是我在Android生态系统中迈出的第一步，也可能是后来我成为移动开发人员的原因。

In this article, I want to share the frustrating experiences I’ve had with the Android SDK and Flutter. Some of the points that I address also apply to the iOS SDK. I stopped working as a Mobile Developer a few years ago and hope that many things have changed for the better. But even back then I found the mobile ecosystem to be so misguided that I had to look for an alternative career path.

在本文中，我想分享一下我使用Android SDK和Flutter时遇到的令人沮丧的经历。 我要解决的一些问题也适用于iOS SDK。 几年前，我不再担任移动开发人员，并希望许多事情变得更好。 但是即使在那时，我仍然发现移动生态系统被误导了，以至于我不得不寻找替代的职业道路。

碎片化 (Fragmentation)

The biggest pain point for every Android developer is the huge variety of device configurations. I never quite understood why the better part of the SDK (especially the UI portion) was not a dependency of my app but embedded into the device. That basically forced me to work with the support libraries and debug my app for every targeted API level. In addition to this I constantly experienced random Samsung or Huawei devices crashing on code that worked just fine on the Emulator or my test devices.

每个Android开发人员最大的痛点是设备配置种类繁多。 我从未完全理解为什么SDK的更好部分(尤其是UI部分)不是我的应用程序的依赖项，而是嵌入到设备中。 这基本上迫使我使用支持库并针对每个目标API级别调试我的应用程序。 除此之外，我还经常遇到随机的Samsung或Huawei设备崩溃的代码，这些代码在Emulator或我的测试设备上工作得很好。

材料设计 (Material Design)

When I read comments on HackerNews or Reddit about Google’s Material Design, I sometimes feel like I’m the only person that actually likes it. I find it visually appealing and generally enjoy the user experience. The official documentation website came a long way and I consider it a prime example for great documentation. I was super excited when it was announced for Android! That being said, the transition from Holo to Material Design on the Android platform was not a smooth ride at all. It felt like the release was rushed. Very basic widgets were missing from the official Material Design support library for years to come. Even though you could sometimes admire them in Google’s own apps, they didn’t find their way into the support library. Developers were forced to build their own or grab an alternative implementation on GitHub of questionable quality. Along with a fair amount of visual inconsistency and implementation bugs the Material Design support library experience was probably the first time I paused to really think about and question the ecosystem.

当我阅读有关HackerNews或Reddit的有关Google的Material Design的评论时，有时会觉得我是唯一真正喜欢它的人。 我发现它在视觉上很吸引人，并且总体上享有用户体验。 官方文档网站走了很长一段路，我认为这是出色文档的一个很好的例子。 当它宣布用于Android时，我感到非常兴奋！ 话虽这么说，在Android平台上从Holo过渡到Material Design并不是一件容易的事。 感觉像是发布被赶了。 未来几年，官方的Material Design支持库中缺少非常基本的小部件。 即使您有时可以在Google自己的应用程序中欣赏它们，但它们并没有进入支持库。 开发人员被迫在GitHub上构建自己的或获取质量可疑的替代实现。 除了相当多的视觉不一致和实现错误外，Material Design支持库的经验可能是我第一次停下来真正思考和质疑生态系统。

Buttons? Date pickers? Left as an exercise for the reader

纽扣？ 日期选择器？ 留给读者练习

没人愿意遵循的最佳做法 (Best practices that nobody bothers to follow)

It’s a challenging task to build a rock solid Android app. That is mostly because the SDK is developer hostile. It’s amazing that in theory an Android app can idle in the background indefinitely, consuming no system resources and pop back right into its previous state when the user desires. That is at least the case if the developer has successfully implemented the state and lifecycle management.

构建坚如磐石的Android应用程序是一项艰巨的任务。 这主要是因为SDK对开发人员不利。 从理论上讲，一个Android应用程序可以无限期地在后台闲置，不消耗系统资源，并在用户需要时立即弹出其先前状态，这是令人惊讶的。 如果开发人员已经成功实现了状态和生命周期管理，则至少是这种情况。

Developer Hello internet, my app crashes on orientation change how do I fix that?Internet It’s simple, just disable orientation changes

开发人员您好，互联网，我的应用因方向更改而崩溃，该如何解决？ 互联网很简单，只需禁用方向更改

Ouch. But this is unfortunately quite common.

哎哟。 不幸的是，这很普遍。

Did you ever work with Threads in Java? That stuff is super tough in an imperative code base with mutable variables all over the place. Well, guess what: it’s even more difficult with the Android SDK. If you want to manage a Thread from an Activity, you’re basically asking for a bad time. Luckily we got retained Fragments eventually that made this somewhat easier. But only at the price of getting Fragments in the first place.

您曾经在Java中使用Threads吗？ 在命令式代码库中到处都是可变变量的情况下，这些东西非常困难。 好吧，猜猜是什么：使用Android SDK更加困难。 如果您要管理一个Activity的Thread ，基本上是在要求不好的时间 。 幸运的是，我们最终保留了Fragments ，这使此操作更加容易。 但是仅以首先获得Fragments为代价。

During my career as a Mobile Developer I interviewed quite a few Senior Android Developers who, with very few exceptions, struggled to get these topics right.

在我作为移动开发人员的职业生涯中，我采访了许多高级Android开发人员，除了极少数例外，他们都努力使这些主题正确无误。

I always wished that Google did more to acknowledge these issues and worked with the community to solve them. The situation has probably improved with Kotlin, but the questionable foundations of the Android ecosystem are still lurking underneath.

我一直希望Google能够更多地了解这些问题，并与社区合作解决这些问题。 借助Kotlin，情况可能有所改善，但是Android生态系统的可疑基础仍在潜伏。

为无效的抽象设计样式和注释 (Design patterns and annotations for abstractions that don’t work)

Developers realized quickly that it is impossible to build a real world application on top of the abstractions provided by the Android SDK. The solution were new design patterns that are probably still popping up on a weekly basis: MVC, MVP, MVVM and MVI are the ones I remember. And since we could not use ordinary constructor calls to manage dependencies, we had to scatter annotations all over the code base. None of this should have been necessary. Java, and even more so Kotlin, are expressive enough to model all of these things in a transparent and straightforward way. But Android prefers huge XML definitions and reflective instantiation, so developers have to obfuscate their code with annotations and questionable design patterns. I honestly don’t have the words to express how bad this is.

开发人员很快意识到，不可能在Android SDK提供的抽象之上构建真实的应用程序。 解决方案是可能每周都会弹出的新设计模式：我记得MVC，MVP，MVVM和MVI。 而且由于无法使用普通的构造函数调用来管理依赖项，因此我们不得不将注释分散到整个代码库中。 这些都没有必要。 Java甚至Kotlin都具有足够的表现力，可以以透明，直接的方式对所有这些事物进行建模。 但是Android更喜欢庞大的XML定义和反射式实例化，因此开发人员必须使用注释和可疑的设计模式来混淆其代码。 老实说，我没有话来表达这有多糟糕。

拥有平台的未使用优势 (Unused advantage of owning the platform)

In a way, native iOS and Android development compete with the web as a platform. However, they have the enormous advantage of belonging to a single corporation, whereas the web has many stakeholders who want to influence its development according to their needs. Yet the web is a more vivid and innovative ecosystem. Just take a look at the success story of React: it’s undeniable that the component based approach to user interfaces is the sanest abstraction we came up with so far. Android managed to sleep through this trend for years until finally announcing “Jetpack Compose” which is still only available as a developer preview. Pretty much the same thing happened in the iOS world. So here we are, still inheriting from a 15k LOC android.view.View class with dozens of lifecycle methods while somehow trying to inject our merge XML file. iOS and Android could be the true pioneers and driving force here, but instead the competition has completely left them behind.

在某种程度上，本地iOS和Android开发与网络作为平台竞争。 但是，它们具有属于单个公司的巨大优势，而Web上有许多利益相关者想要根据他们的需求来影响其发展。 然而，网络是一个更加生动和创新的生态系统。 只需看一下React的成功案例：不可否认，基于组件的用户界面方法是到目前为止我们提出的最简洁的抽象方法。 Android设法应对了这一趋势，直到最终宣布“ Jetpack Compose”为止，“ Jetpack Compose”仍仅在开发人员预览版中可用。 iOS世界几乎发生了同样的事情。 因此，在这里，我们仍然从15k LOC android.view.View类继承了数十种生命周期方法，同时尝试注入我们的merge XML文件。 iOS和Android可能是真正的开拓者和推动力，但竞争却使他们完全落后。

With that in mind, congratulations Android!

考虑到这一点，恭喜Android！

用户界面开发：请将您的期望留在外面 (UI development: please leave your expectations outside)

The key to a beautifully crafted app is the user interface. Now I’ve already complained quite a bit about components still not being a thing in the section above, but there is more to that topic. Did you ever debug a glitch on a website? Open the dev tools of your browser, click the affected element and play with the CSS and HTML properties until everything looks right. In comparison to this, Android is an inaccessible blackbox. To be honest, I never fully groked the Android theming and styling mechanics and the tooling around it always seemed utterly useless compared to the accessibility of the web.

制作精美的应用程序的关键是用户界面。 现在，我已经抱怨了很多有关组件仍然不是上一节中的内容，但是该主题还有更多内容。 您是否曾经调试过网站上的故障？ 打开浏览器的开发工具，单击受影响的元素，然后使用CSS和HTML属性，直到一切看起来正确为止。 与此相比，Android是无法访问的黑匣子。 老实说，我从来没有完全厌倦过Android的主题和样式机制，并且与Web的可访问性相比，围绕它的工具总是显得毫无用处。

Want a drop-shadow around this box? Sure, use this wacky .9.png file or rely on API level 21 where you can render shadows properly (convex shapes only though 😀).

想要在此框周围添加阴影吗？ 当然，请使用这个古怪的.9.png文件或依靠API级别21，您可以在其中正确渲染阴影(仅通过con可以凸出形状)。

Sorry, you forgot to implement one of the four constructors in your custom View. But I’m not stopping you with a compile error, I’d much rather crash at runtime instead!

抱歉，您忘记在自定义视图中实现四个构造函数之一。 但是我并没有因为编译错误而停下来，我宁愿在运行时崩溃！

There are now phones with this super high density. Could you add the respective xxxhpi assets to your app, please? No, vector graphics are not supported, we don’t do this around here.

现在有具有这种超高密度的电话。 能否将各自的xxxhpi资产添加到您的应用中？ 不，不支持矢量图形，我们在这里不这样做。

— Monologues with the Android SDK late at night

—在深夜使用Android SDK独白

矢量图形 (Vector graphics)

Before Android 21 (5.0), proper vector graphics were simply not supported. The reasoning behind this was that the diversity of Android devices requires graphics that are carefully adjusted to the needs of every density level. Naturally, pragmatic developers created tools that turned my logo.svg into an ldpi/logo.png, mdpi/logo.png, hdpi/logo.png, xhdpi/logo.png, xxhdpi/logo.png and of course xxxhdpi/logo.png. Luckily Google changed their mind eventually and blessed us with VectorDrawable which supports a subset of SVG and has poor backwards compatibility. Granted, it was good enough to relieve the pain back then. However, it still boggles my mind how a development environment that prides itself of running on arbitrary device configurations could even exist without support for vectors for so long.

在Android 21(5.0)之前，根本不支持正确的矢量图形。 其背后的原因是，Android设备的多样性要求对图形进行仔细调整，以适应每个密度级别的需求。 自然地，务实的开发人员创建了将我的logo.svg变成ldpi/logo.png ， mdpi/logo.png ， hdpi/logo.png ， xhdpi/logo.png ， xxhdpi/logo.png以及xxxhdpi/logo.png 。 幸运的是，Google最终改变了主意， VectorDrawable我们祝福了VectorDrawable ，它支持SVG的一部分，并且向后兼容性差。 当然，这足以减轻当时的痛苦。 但是，仍然令我感到困惑的是，即使如此长时间不支持向量，以其能够在任意设备配置上运行而自豪的开发环境将如何存在。

死路 (Dead end)

Over the years, I started to worry more and more that my knowledge would become obsolete in the foreseeable future. Most of the things I learned were very specific to Android and only rarely applicable in the larger field of software development. Given its quirks I do not believe that native mobile development is here to stay in the long run and so I started to worry about the usefulness of the skills I acquired.

多年来，我开始越来越担心我的知识在可预见的将来会过时。 我学到的大多数东西都是Android特有的，并且很少适用于更大的软件开发领域。 考虑到它的怪癖，我认为本地移动开发不会长期存在，因此我开始担心所学技能的实用性。

扑 (Flutter)

When Flutter was announced, I got excited immediately. It promised to solve some of the major Android SDK flaws while giving me cross-platform support for free. So we actually started migrating our native Android app at my previous job to Flutter. And I got to say: Flutter keeps its promise.

宣布Flutter时，我立即感到兴奋。 它承诺将解决一些主要的Android SDK缺陷，同时免费为我提供跨平台支持。 因此，我们实际上开始将上一份工作中的本机Android应用迁移到Flutter。 我必须说：Flutter信守诺言。

• Android fragmentation issues are completely eliminated by Flutter’s embedded rendering pipeline
  Flutter的嵌入式渲染管线完全消除了Android碎片问题
• Right from the start it had an exhaustive library of high quality Material Design widgets
  从一开始就拥有一个详尽的高质量材料设计小部件库
• The snappiness of the hot reloading feature blew my mind
  热装功能的快感让我大吃一惊
• You get an unprecedented high quality look & feel cross-platform experience
  您将获得前所未有的高质量外观和跨平台体验

But unfortunately it wasn’t all great. And it’s a pity because the issues Flutter suffers from could have been easily avoided by a greenfield project.

但是不幸的是，这还不是很好。 遗憾的是，通过新建项目可以轻松避免Flutter遇到的问题。

• Dart is terrible: it’s a comparatively young language but it repeats a lot of the mistakes of its elderly predecessors (bad language design, null, statements instead of expressions, …)

  Dart很糟糕：它是一种相对年轻的语言，但是它重复了许多其前辈的错误(错误的语言设计， null ，声明而不是表达式……)

• Questionable design decisions in the Flutter SDK: instead of creating a better React, they made it worse. What could have been a simple function call tends to be solved by stateful OOP machinery (I recall the routing and handling of dialog widgets as especially painful here).
  Flutter SDK中可疑的设计决策：与其创建更好的React，反而使它变得更糟。 有状态的OOP机制可能会解决可能只是一个简单函数调用的问题(我记得对话框小部件的路由和处理在这里特别痛苦)。

结论 (Conclusion)

At some point it was evident to me that this is not the kind of tech I want to spend my time with. I promised myself I would never program for mobile platforms again. A well-designed, responsive website gets you pretty far these days and so this is my default option. It’s a single code base and just works on every client. If I absolutely had to create a mobile app, I would still choose Flutter, even if I only targeted Android. Working with the Android SDK is out of the question for me.

在某些时候，对我来说很明显，这不是我想与之共度的那种技术。 我向自己保证不会再为移动平台编程。 经过精心设计，响应Swift的网站现在已经可以带给您很多，因此这是我的默认选项。 它是一个单一的代码库，并且适用于每个客户端。 如果绝对必须创建一个移动应用程序，即使我只针对Android，我仍然会选择Flutter。 对我来说，使用Android SDK是不可能的。

That being said, I got to clarify that I highly admire and appreciate a well-crafted native application (on mobile as well as desktop). I have the utmost respect for the developers that create those with the tools available. I just don’t want to be one of them anymore.

话虽这么说，我必须澄清一下，我非常欣赏并欣赏精心制作的本机应用程序(在移动设备和台式机上)。 我对使用可用工具创建工具的开发人员表示最大的敬意。 我只是不想再成为其中之一。

This article is also available as a German translation

本文也可以作为德语翻译提供

翻译自: https://medium.com/swlh/9-reasons-why-i-gave-up-on-being-a-mobile-developer-795f5fb37c1e

ie开发人员工具位置移动