Swift，Xcode和iOS我的冒险
书签忍者是一个Web应用程序，可在台式机和移动设备的浏览器中运行。 在移动设备上，它具有看起来像本地移动应用程序的移动专用Web UI。 在桌面浏览器中，它使用书签和浏览器扩展，可以将当前网页链接发送到Ninja。 当前，在移动设备上，您只能通过通过电子邮件将链接发送到专用电子邮件地址（点击共享然后选择电子邮件）来执行此操作。 但是，使用此解决方案，您将无法添加标签或设置目标选项卡/类别，而无法在书签和扩展名的帮助下在桌面浏览器中进行操作。 因此，现在该为移动浏览器找到更好的解决方案了。 最终的解决方案是本机移动应用程序，它实际上是移动浏览器的共享扩展应用程序。
计划A
最初的计划是开发一个完整的本机iOS应用程序，该应用程序通过RESTful API与Ninja服务器通信。 3年前，当我学习Java类时，我了解了REST，但是我从未使用过REST，因此经验为零。 此外，引入REST也会影响服务器端，而不仅是客户端iOS应用程序，因此还有更多工作要做。
另一个挑战是Swift。 5年前，我开始在Objective C中开发iOS游戏。我从事该游戏的时间为一年。 然后我放弃了，我没有完成项目。 我还记得我不是Objective C和Xcode的忠实拥护者。 我读到Swift比Objective C有很多改进，所以我非常期待熟悉Swift。
计划B
当我开始担心该项目所需的工作量时，尤其是考虑到REST和Swift的不确定性时，计划B就出现了。 我的想法是通过在iOS应用中拥有Webview来简化事情。 实际上，在Web视图中，就像在浏览器中一样，您通过https访问Ninja服务器，并且UI看起来像本机移动应用程序（使用PrimeFaces mobile / jQuery mobile）。 使用此解决方案，我可以赢得以下成就：
- 完全不需要REST，因为我通过https访问Web视图中的服务器
- 只需编写更少的Swift代码（所有“添加书签”功能都已包含在已经用Java开发的webview中）
- 用户身份验证也可以在webview中完成（已经使用Java开发）
我认为这是一个很棒的主意，因此我决定采用计划B。以这种方式实施iOS共享扩展只用了几天。 我可以为计划B节省很多时间，所以我认为这是一个不错的决定。
仍然不是Swift和Xcode的忠实拥护者
尽管实际上只花了几天时间就编写了共享扩展名，但是Swift和Xcode还是令人失望。 在使用Xcode在Swift中进行Java和Eclipse编程之后，感觉就像倒骑了。 我无法更好地解释我的感受，但我认为有些人可能知道我的意思。 我只想谈谈我的一些经历：
- 我觉得API支持并不是真的对开发人员友好。 创建项目时，我必须选择共享扩展目标。 例如，这是关于在浏览器中共享网页。 因此，我认为获取标题和URL有点是something.getUrl（）和something.getTitle（）。 不，不是这样。 您必须编写15（！）行代码才能获得url和标题。 而且我没有在苹果官方开发文档中找到这15行代码，而是在不同的论坛和Stackoverflow上找到了这15行代码。
- 向后兼容性…当我在网上搜索某些东西时，发现的大多数Swift代码都在Swift 1或2中。当我尝试使用这些功能时，结果发现它们中的大多数已被折旧，删除或重命名。 3.因此，每年都有新版本的iOS发布时，我必须更新代码，重新生成并重新提交应用程序吗？
- 我无法调试…断点不起作用，“打印”没有打印到控制台。 我在网上搜索了此问题，并找到了很多有关此主题的讨论。 我尝试了所有建议的方法，但没有帮助。 最后，在代码中添加了iOS“ tweet”音效，以检查代码的这一部分是否运行。 嗯，不是专业的调试技术……
- 我觉得Swift的语法和Objective C的语法一样尴尬。好的，我同意这是一种个人主观判断。
我并没有深入研究Swift，但是即使只是摸摸表面，我也遇到了很多问题。 的确，我只开发了一个简单的共享扩展程序，我没有其他领域的经验，他们可能还可以，我不知道……尽管如此，我很高兴能提出一个可以节省很多时间的解决方案时间。
我的幸福并没有持续多久
在开始阅读有关Apple App Store提交准则的信息之前，我感到非常高兴和满意。 很快发现，许多开发人员在提交包含Webview的应用程序时遇到了问题。 这似乎是一个敏感区域，使用Web视图可能是拒绝的原因。 更大的问题是，Apple似乎不喜欢Webview登录，他们更喜欢本机登录（当使用本机iOS控件实现登录时）。 这几乎糟透了……并立即破坏了计划B。这也意味着计划A可能是唯一的选择。 拉屎。
结论
计划A的采用将意味着很多额外的工作（尤其是考虑到我在这么短的时间内使用Swift的经历）。 我已经在以前的一篇文章中写过关于如何决定要实现哪些功能的文章。 我认为完成计划A所需的工作量与此新功能将带来的客户价值不成比例。同样，该功能只是我的主意，并不是客户的要求。 待办事项中还有其他一些较小的功能，它们具有更高的客户价值，但所需的工作却更少。 现在，我宁愿和他们一起去。 甚至还有一个很小但有用的功能，它将改善移动设备上当前的“添加到忍者”用户体验。 所有这些功能都必须在服务器端用Java开发。 最重要的是，我决定推迟“添加到忍者”本地iOS应用。 稍后，当我回到该项目时，我可能会完成计划B（网络视图之一），并有机会将其提交给App Store。 但是被接受的机会确实很小。 所以这个故事实际上是关于计划A的。我们将会看到。
我有百感交集。 一方面，我很难过，因为我喜欢挑战，这绝对是一个巨大的挑战。 另一方面，我有些放心，因为我仍然觉得自己不是Swift（Objective C）的忠实拥护者，我更喜欢Java。 但是现在我很高兴终于可以在下周返回Java。