Tag: 移动

使用RxSwift编码更快

人们通常谈论反应式编程，特别是RxSwift作为描述应用程序逻辑的最终方法-事件链，错误处理，异步。 但是不要忘了RxSwift还是一个工具，它允许您向任何内容添加反应式扩展。 RxSwift有一个相当大的创意社区。 RxSwiftCommunity的github配置文件当前具有55个不同大小和用途的存储库。 所有这些的根本是反应式编程。 下面我将讨论已经成为我的Podfile必需的依赖项。 Rx键盘 我们都喜欢用键盘覆盖一个密码字段，不是吗？ 我不会数行代码，也不会描述我对使用NotificationCenter厌恶。 只要看看通过事件序列的概念来表达键盘高度的变化是多么酷。 让我提醒您，这里有所有Rx运算符。 您可以使用debounce ，或在此处与另一个Observable结合使用，依此类推。 这是我最喜欢的声明性代码的示例： RxKeyboard.instance.isHidden .drive（backgroundFadeView.rx.isHidden） .disposed（作者：disposeBag） 我可以解释一下，当键盘被隐藏时，我将隐藏backgroundFadeView ；如果键盘可见，则将其显示。 但是您乍一看就知道了。 手势 当UIButton不够用时，这是一种非常普遍的情况。 让我们比较一下语法： 同样，我可以解释一下，我们仅过滤.ended手势并计算翻译。 但是很明显，即使您不熟悉此框架或RxSwift。

iOS中的视觉：文本检测和Tesseract识别

让我告诉你一个故事。 两周前，我参加了奥斯陆的愚蠢黑客马拉松比赛，在那里人们提出了一些愚蠢的想法，并一起遭到黑客攻击。 当我刚刚看过唐纳德·特朗普（Donald Trump）的大数字计数剪辑时，我认为制作一个有趣的iOS应用程序可能会是一个好/愚蠢的想法，该应用程序可以识别所有数字并通过特朗普的声音判断数字是否足够大。 首先，我们需要设置摄像机会话，因为我们需要捕获图片以进行文本识别。 相机逻辑及其预览层封装在自定义视图控制器CameraController 。 仍然在BoxService ，我们应该在检测到的矩形中裁剪图像以进行OCR（光学字符识别）。 我们以捕获图像的坐标进行计算，然后插入一个较大的图像以拍摄稍大的图像以适应顶部和底部边缘。 代码从VNFaceObservation的Convert Vision boundingBox调整为rect以绘制图像： 现在，我们已经有了准备用于文本识别的图像。 让我们使用OCRService 。 我个人喜欢纯Swift解决方案，因此SwiftOCR是一个完美的选择，据说它的性能要比Tesseract好。 所以我尝试了一下。 API再简单不过了。 Tesseract是“是用于各种操作系统的光学字符识别引擎。 它是免费软件，根据Apache许可证2.0版发布，自2006年以来由Google赞助开发。” iOS端口在GitHub上是开源的，并具有CocoaPods支持。 因此，只需将Podfile pod ‘TesseractOCRiOS’放入Podfile就可以了。 与自述文件和TestsProject中一样，需要tessdata ，它包含Tesseract可以使用的语言信息。 如果没有此tessdata则框架TesseractOCR会大喊一些有关缺少TESSDATA_PREFIX.警告TESSDATA_PREFIX. 对引用的“ tessdata”文件夹中存在的语言文件的严格要求。 从此处下载tessdata ，添加它作为对Xcode项目的reference 。 蓝色表示该文件夹已添加为参考。 您可能还需要将libstdc++.dylib和CoreImage.framework到目标中： Tesseract 使用Tesseract很容易。 记住要导入TesseractOCR而不是TesseractOCRiOS: 现在，我们可以使用AVPlayer在MusicService类中播放声音。 生成并运行该应用程序，将您的相机指向一些数字，点击屏幕，然后应用程序应检测到文字，识别该数字并播放有关特朗普的声音。 这个应用程序可能不是很有用，但可以进行调整以更实际地使用，例如跟踪房间预订，电话号码分析或简单的文本扫描。 我希望你能学到一些东西。 以下是一些其他链接，可帮助您开始在iOS上进行文本检测： 适用于iOS的Tesseract OCR教程：了解如何在iOS中使用Tesseract框架，并详细说明使用它时可能遇到的一些问题。 通过iOS的ML框架在您的掌中利用机器学习：如何在SwiftOCR中使用视觉。 tesseract.js：以Java语言实现的Tesseract。 它与iOS无关，但是最好在其他平台上使用Tesseract的重要性。 视觉中的对象跟踪：在WWDC 2018上，iOS中的视觉发生了有趣的变化。对象跟踪和自定义模型训练方面有很多改进。 在静态图像中检测对象：Apple官方示例代码，使用Vision框架定位和划分图像中的矩形，面，条形码和文本。 将iOS的Google ML Kit集成到人脸检测，文本识别等功能中：Google今年在Google IO上推出了ML […]

== vs ===

平等（==） 通过使用==运算符，我们可以检查两个值是否相等。 喜欢 因此，可以使用运算符比较基本类型。 但这不允许我们比较自定义类型。 例 为了使自定义类型具有可比性，该类型应符合Equatable协议。 身份（===） 此运算符是否检查变量是否指向相同的确切实例。 不过，应注意一件事，它仅比较AnyObject类型。 我希望你能猜出为什么。 谢谢阅读。 继续分享并保持关注。

iOS授权：如何以及何时？

您已经在iOS应用程序中拥有什么样的权限？ 对于应用程序，在首次运行时要求访问许多功能是很常见的：相机，位置，媒体库等。但是，建议仅在必要时和仅在应用程序使用它们时才询问它们。 在本文中，我们将看到如何以及何时向用户寻求许可。 一般来说，权限可以具有以下状态： notDetermined ：用户尚未获得访问授权请求 受限 ：该应用可以具有受限权限，例如：家长模式 拒绝 ：用户已明确拒绝许可 授权 ：用户授权该应用访问该功能。 该应用可在需要时免费使用该功能 应用程序可以请求许可，您的应用程序工作流必须考虑到用户可以从其系统设置中更新所有授权。 先决条件：更新plist 请求访问功能的第一步步骤是使用许可密钥和简短说明更新plist。 例如，对于摄像机，应添加NSCameraUsageDescription ，对于位置，应为NSLocationWhenInUseUsageDescription或NSLocationAlwaysUsageDescription等。 关联的值是将在系统授权弹出窗口中显示的句子。 有必要尽可能多地描述您为什么需要它。 如果不添加此描述，该应用程序将停止并且不会通过Apple验证。 完整的密钥列表可以在这里找到： 现在，我们将看到一些有关如何请求授权的示例。 位置 首先，您可以要求两种不同的授权类型：始终或使用时。 在iOS 10中，默认情况下，即使您请求“始终”许可，应用程序也会要求“使用时”授权。 进行此限制是为了强制开发人员仅在必要时启用“始终”选项，并保留用户的选择权。 此类型的权限将具有2个授权状态：authorizedAlways或authorizedWhenInUse。 要请求位置授权，您仅需要根据情况使用此功能： 调用此函数时可以找到当前状态： 相机 根据用于访问摄像机的类（UIImagePickerViewController或AVCaptureDevice），授权系统对于请求将有所不同。 第一个仅请求更新plist文件，显示UIViewController时，系统将自动提示用户。 第二个将要求调用此函数： 但是，如果您需要摄像机的授权状态，则对于两个摄像机用例，该功能是相同的： 日历 以与调用AVCaptureDevice授权请求相同的方式，通过功能requestAccess显示权限弹出窗口： 以及授权状态： 通知事项 对于通知授权，UNUserNotificationCenter类负责请求授权。 唯一的不同是您询问通知的当前状态的方式： 苹果公司的建议非常明确： “仅在您的应用明确需要时才请求个人数据。”，Apple，人机界面指南 一般而言，用户越来越怀疑应用程序在首次启动其应用程序时立即请求许可，甚至无法访问主要功能。 他们期望仅在访问需要授权的功能时才会询问他们。 不要犹豫，添加一个步骤，描述您的应用程序为何需要此授权。 Wassa是室内定位和计算机视觉方面的创新数字代理专家。 无论您是想帮助客户在建筑物中找到自己的出路，增强产品的用户体验，收集有关客户的数据还是分析某个地点的人流量和行为，我们的创新实验室都将科学的专业知识带给您最大的设计灵感根据您的目标调整解决方案。 在 – 找到我们： ·Facebook和Twitter ·领英 ·GitHub […]

iOS 12通知更改：通知中心将成为Apple用户的主要收件箱

临时授权附带安静的通知。 您可以请求将其发送到锁定屏幕的权限-并有可能遭到拒绝-或在试用的基础上自动将其悄悄发送。 如果您确实提示锁定屏幕通知，建议您不要在用户首次打开应用程序时进行此操作。 相反，要教育用户为什么他们会在适当的时间受益于通知。 吸引用户进入您的应用程序（无需选择加入）的一种好方法是使用应用程序内消息传递。 它也是管理选择加入流程的理想选择。 在我们 的应用内消息传递灵感指南中 获取有关如何使用它们的想法 。 iOS 12中的一种新型通知是“严重警报”。 这些声音具有很强的破坏性，播放大声（您指定的声音）并绕过“请勿打扰”和振铃开关。 请勿打扰：随着用户开始尝试“请勿打扰”并开始了解他们在哪里度过的时间以及对特定应用程序或应用程序类型设置限制，品牌商将需要加倍关注其效用和价值的通知策略。 屏幕时间：此新功能可以告诉您您使用最多的应用程序，向您发送最多通知的应用程序，控制时间限制（对我们所有人（尤其是我的孩子！）都有好处），安排停机时间并询问您是否您想保留或管理一段时间未使用的应用程序上的需要通知。 品牌必须确保他们正在向用户的屏幕传递价值。 如果这些通知具有很高的价值，可以提供实用程序并请求适当级别的许可（关键，显眼或安静），则客户可以从应用程序中获取大量通知。 在Urban Airship，客户通过更新和扩展我们的API，仪表板和SDK来快速响应平台变化，从而尽可能轻松地利用新功能是我们客户所钟爱的一部分。 我们目前正在计划对iOS 12的支持，并将像我们每年一样准备就绪。 敬请关注！ 如果您对我们即将推出的iOS 12支持有特定疑问，请联系您的客户经理或支持。 在您的iOS 12策略上需要帮助吗？ 我们在这里为您提供帮助： 想与我们的战略服务团队安排30分钟的免费咨询吗？ 我们很想听听您的通知策略中的痛点，并集思广益，设法帮助您解决这些痛点。 最初在 www.urbanairship.com上 发布 。

使用Swift进行iOS开发的8个优势

长期以来，Objective-C是用于创建OSX和iOS应用程序的主要编程语言。 从根本上讲，Objective-C是C的超集，具有附加的面向对象功能和动态运行时。 2014年，Apple引入了一种名为Swift的新编程语言，该语言被称为“不带C的Objective-C”。 Swift快速，安全，现代化，并在开发中实现了一定程度的交互性。 它包含许多特性，例如闭包，泛型和类型推断，这些特性使其更易于使用，从而简化了Objective-C中使用的通用模式。 它结合了C和Objective-C的功能，而没有直接的内置C兼容性以及随之而来的所有约束。 在Cocoa和Cocoa Touch的支持下，Swift彻底重新定义了我们对Apple产品移动应用程序开发的理解。 Swift与Objective-C 在Swift的大揭秘之后，开发界引起了很多惊喜和困惑，因为苹果公司声称这种iOS编码语言要比其前身更好。 因此，Swift成为许多组织讨论的中心。 自最初发布以来，它已被证明是一种整体上更为智能的编程语言，可以在iOS应用开发人员，品牌和最终用户自身之间建立更直接和有意义的联系。 我们概述了为下一个移动项目选择Swift而不是Objective-C的8个主要优点： 可读性 选择Swift的第一优势可以说是因为它的语法简洁，这使得它更易于读写。 在Swift上实现一个选项所需的代码行数量比Objective-C少得多。 这样做的原因是因为Swift放弃了许多旧式约定，例如在if / else语句内包围条件表达式的分号到结束行或括号。 另一个主要变化是，方法调用不会彼此放在一起，从而导致括号混乱。 相反，Swift中的方法和函数调用使用括号内的逗号分隔参数列表。 结果，该代码使用简化的语法更加简洁。 Swift代码更类似于普通英语，这使编写代码更加自然，同时使开发人员可以花费更少的时间查找有问题的代码。 这种可读性还使来自JavaScript，Java，Python，C＃和C ++的现有程序员更容易将Swift纳入其工具链。 保养 没有C先发展，Objective-C不可能发展。 相反，Swift没有这些依赖项，这使得维护起来容易得多。 C要求程序员维护两个代码文件，以缩短代码的构建时间和效率，这也可以延续到Objective-C。 但是，Swift放弃了这两个文件的要求，将Objective-C标头（.h）和实现文件（.m）组合到一个代码文件（.swift）中。 在Objective-C中，您必须手动在文件之间同步方法名称和注释。 使用Swift时，程序员可以花更多时间创建应用程序逻辑，并提高其代码，注释和受支持功能的质量。 更安全的平台 在竞争激烈的移动应用程序市场中，开发安全的应用程序应该是当务之急。 Swift的语法和语言构造排除了Objective-C中可能出现的几种错误。 这种稳定性意味着将减少崩溃和出现问题行为的情况。 它不会阻止程序员编写错误的代码，而是会减少犯错误的可能性。 这在开发过程中增加了额外的质量控制层。 Swift会使用nil代码，并在程序员编写错误代码时生成编译器错误。 使用Swift，您可以在编写代码时编译并修复错误，而Objective-C则无法实现。 因此，在进行错误测试时，Swift比Objective-C更好，更快地工作。 所有这些使我们有理由将Swift视为一种安全的编程语言。 更少的代码和更少的遗产 使用Objective-C，存在许多导致应用程序崩溃的问题。 Swift提供的代码不太容易出错，因为它对操作文本字符串和数据提供了内联支持。 此外，类不分为两部分； 接口和实现。 这样可以将项目中的文件数量减少一半，从而使处理起来更加容易。 在编写重复性语句或引起字符串操作时，Swift最终需要较少的编码工作。 使用Objective-C时，您需要组合两个字符串，这会使它很长。 使用Swift，您只需要添加’+’符号即可连接两个字符串。 速度 Swift在开发过程中还提供了多种速度优势，从而节省了成本。 例如，复杂对象排序的运行速度比Python中相同算法的实现快3.9倍。 这也比Objective-C好，后者比Python版本快2.8倍。 […]

介绍Bitrise上的模拟器的Xcode构建

您需要创建应用程序的演示版吗？ 没问题！ 使用 Bitrise 的新步骤构建.app文件， 并将其上传到模拟器。 我们已经推出了新步骤的Beta版： 用于模拟器的Xcode构建 。 此步骤将在iOS模拟器目标位置运行xcodebuild命令并生成一个.app文件，然后可以在模拟器上运行该文件。 .app文件可以上传到Appetize.io进行演示，测试等。 在Xcode build for simulator运行Xcode build for simulator之后，可以添加Appetize.io deploy 。 在此处阅读有关Appetize集成的更多信息。 该步骤所需的输入 ： project_path ：项目（或工作区）路径 配置：要使用的配置。 scheme ：要使用的方案。 Simulator_device ：模拟器名称。 （例如：iPhone 6s Plus） Simulator_os_version ：操作系统版本。 （最新的11.4等…） Simulator_platform ：iOS模拟器/ tvOS模拟器 步骤输出： BITRISE_APP_DIR_PATH：生成（并复制）的应用程序目录 BITRISE_APP_DIR_PATH_LIST ：此输出将包括主要目标应用程序的路径+每个相关目标的应用程序路径。 路径以`|字符分隔，例如： /deploy109787178/sample-apps-ios-workspace-swift.app|/deploy109787178/bitfall.sample-apps-ios-workspace-swift-watch.app | /deploy109787178/sample-apps-ios-workspace-swift.app|/deploy109787178/bitfall.sample-apps-ios-workspace-swift-watch.app BITRISE_XCODE_BUILD_RAW_RESULT_TEXT_PATH：这是原始构建结果日志文件的路径。 如果output_tool=xcpretty并且构建失败，则此日志将包含构建输出。 将iOS构建为模拟器的积极方面：您无需对项目进行代码签名（无需证书/无需配置文件）。 😎 让我们知道它是如何工作的，我们感谢所有反馈。 建设愉快！ 最初发布在 Bitrise博客上 […]

如何在Swift中使用扩展名格式化数字并节省时间。

是否曾经需要多次格式化数字或标签？ 创建扩展程序可能会将您的时间减少一半。 在本文中，我们将使用格式化数字的情况，可以用于显示某些事物的喜欢次数或任何事物的真实计数。 因此，我们的目标是将格式设置为12345至12,345 。 因此，现在您可以在应用程序的多个位置调用format格式，而无需每次使用时都声明整个功能。 只需致电： 结果将是： 12,345 。 就是这样，您可以在代码中需要多次执行的其他许多事情上应用相同的想法。 希望有帮助！ 感谢您的阅读，就像在下一篇文章中看到的一样。

简单的Xcode hack可以帮助优化开发人员的生产力。

上述代码摘自我的一个iOS项目，名为“ OptimusPrime”； 这是一个质数计算器，我用作演示项目，用于演讲，研讨会和疯狂测试。 借助我的颜色编码，我一眼就能分辨出以下几点： 系统保留关键字（粉红色） ：系统保留关键字不能以任何方式被覆盖，并且如果我们尝试这样做，编译将会失败。 我可能不知道Xcode中的每个系统保留关键字，因此最欢迎使用一种轻松区分它们的方法！ Apple拥有的属性，类和函数（青色） 与用户定义的属性，类和函数（柠檬绿） ：Apple拥有的和用户定义的对象，属性或函数以完全相同的方式工作，但是由其代码引起的错误是以完全不同的方式解决问题-尤其是因为我们可以修改实现而不是Apple的实现。 因此，有助于在两者之间进行一些定义。 硬编码的数字（紫色）和字符串（红色） ：包括我在内的大多数开发人员都同意不惜一切代价避免使用硬编码。 通过为它们提供专用的颜色集，我们也许能够更轻松地发现它们，从而更快地用常量替换它们。 注释（灰色） ：注释是代码的说明（或IDE屏幕文档的一部分），但不是编译或处理的实际代码的一部分。 因此，应将它们相应地着色为文件的不必要部分。 属性和框架声明，函数中的属性访问器（白色）：当更多关注时，我还可以看到函数调用比属性调用更明亮。 在我的特定情况下，我什至不需要花时间自定义调色板，因为IDE中的默认调色板之一可以满足我的需求和个人喜好。 但是，在以前的Xcode和macOS版本中，我确实必须使用“ Midnight”调板作为基础对其进行自定义： 在自定义方面，由于我的视力无法应付由默认对比度和大屏幕上的小字体引起的疲劳，因此我将柔化各种颜色的对比度并增加字体大小。 对我来说幸运的是，最新的Xcode版本中提供的新的Default（深色）调色板非常合适！ 其他视觉元素 在最初的屏幕截图中，您可能已经注意到了其他一些视觉元素。 这些元素虽然与颜色自定义无关，但为我提供了一些我认为在编码时有用的附加信息。 让我们回顾一下！ “当前正在编辑”行标记。 源代码编辑器中的当前行被突出显示，从而提供了一种轻松的方式来知道键入时我正在编辑的行。 这也很好地表明了您是否已滚动到编辑范围之外。 行号。 左边距中当前文件行号的存在有多种用途。 首先，在We Are Mobile First上，我们不喜欢大型源文件。 它们很难调试和维护。 正如我们有关健康编码实践的文章中所讨论的那样，我们使用单一责任原则。 如果文件太大，通常意味着我们可以将代码拆分为较小的任务。 通常，我尝试将文件保存在少于150行的代码内（不包括注释）。 其次，调试时查看行号很有用，因为编译器或调试器可能会引用触发错误的代码行。 最后，当使用版本控制工具时，在合并或同行审阅代码时查看行号会很有帮助。 关于版本控制工具的更新。 有些人可能已经注意到某些行中行号旁边的蓝色标记。 这些标记突出显示了相对于我们的版本控制工具中的最后一次提交已更改的代码行。 右垂直边距。 我们在几个项目上使用短绒棉。 我们使用的最常见规则之一是“一行中最多XXX个字符”。 在这种情况下，“ XXX”通常为120。我厌倦了触发编译器警告或错误，因此我将Xcode设置为在一行中的第120个字符处自动添加此垂直边距，因此可以直观地看到该限制。 折叠标记。 行号旁边的代码文件夹使我可以轻松折叠/展开代码段。 结论 在大多数当前的IDE中，具有视觉吸引力的设置很容易实现，但是我还没有看到很多开发人员可以自定义自己的设置。 这似乎很轻浮，但只需要花费五分钟的时间，从而可以帮助您提高视力并改善性能。 […]

斯威夫特的巴恩斯利·费尔恩（Barnsley Fern）

如果您不知道巴恩斯利·费尔恩（Barnsley Fern）是什么，可以在这里阅读有关它的更多信息。 简而言之，Barnsley Fern是一个可以使用迭代函数系统创建的分形。 函数对应于以下转换取决于概率： ƒ1（选择1％的时间） xn + 1 = 0 yn +1 = 0.16 yn ƒ2（85％的时间选择） xn +1 = 0.85 xn + 0.04 yn yn +1 = −0.04 xn + 0.85 yn + 1.6 ƒ3（选择7％的时间） xn + 1 = 0.2 xn-0.26 yn yn +1 = 0.23 xn + 0.22 yn + 1.6 ƒ4（选择7％的时间） xn […]