Tag: xcode

Xcode 9中颜色集的功能

我一直想将所有资产都放在一个地方,并保持一种结构化的方式来处理xco​​de中的所有资产。 Xcode 9带来了颜色集,以便在情节提要和代码之间保持颜色。 那给我们带来了很多资产管理。 好的介绍,让我们完成一些工作。 转到Xcode 9并创建一个新项目或打开一个现有项目。 选择Assets.xcassets 右键单击,您将获得一些选择 选择“新颜色集”并为其命名,例如“ PrimaryColor”。 现在,您可以像对待任何UIView或UILabel一样从属性检查器中选择颜色并为其着色 完成后,移至您的UIViewController并选择一个UIView。 在属性检查器中,您将可以找到“命名颜色” 欢呼!!! 现在您可以在情节提要,XIB中使用这些颜色。 并且,如果任何设计师希望您更改#hex值,只需返回到您的Assets并进行更改即可。 它将在任何地方得到体现。 那么,当您处于情节提要或xibs中时,这将起作用,如何在代码中使用相同的东西。 self.view.backgroundColor = UIColor(名称:“ PrimaryColor”) 很简单吧 好吧,我可以留给您这个,您可以继续自己探索,但我想再给您一点额外的好处。 我使用的方式是在素材资源中添加所有颜色,并在情节提要和xib中使用相同的颜色。 但是我不喜欢直接使用字符串“ PrimaryColor” 。 如果您敏锐的眼睛,您会发现Assets.xcassets下方有Colors.swift。 这是Colors.swift内部的内容 因此,当您必须获取PrimaryColor时,只需使用 self.view.backgroundColor = AppColor.PrimaryColor.color 这使代码更干净,让我开心🙂

Xcode调试工具:快速入门指南

了解调试工具的方法将使您成为一个更好,更高效,更快乐的程序员。 了解一些方便的技巧,以帮助您入门。 在本文中,我将分享一些有关如何使用Xcode中集成的调试工具的提示。 我将向您展示一些LLDB命令以及如何将它们与断点一起使用。 希望我会为您提供新的武器来分析您的代码并查找错误。 Xcode在其主窗口中集成了一组调试工具。 下图显示了在断点处暂停应用程序时Xcode调试器的布局。 本地数据库 LLDB是一个开源调试器,它是LLVM编译器开发套件的一部分。 它与Xcode捆绑在一起,您可以在窗口右下角的控制台中找到它,如上图所示。 以下是一些基本的LLDB命令: 救命 help命令列出了所有可用的命令。 如果您想了解有关特定命令的更多信息,可以键入help 以获取有关该特定命令的所有详细信息。 打印 打印命令非常有用。 它使您可以在控制台上打印变量值,从而不必诉诸诸如记录变量值或简化程序行为之类的技术。 上图显示了一种非常常见的做法,其中包括记录变量以检查其值。 通过在给变量赋值后放置一个断点(第5行),程序将暂停执行。 如图所示,在这里我们可以使用print命令检查变量的值。 LLDB会进行前缀匹配,因此如果键入prin , pri或p会很好。 您还可以使用$ 0引用结果和类型,例如,p $ 0 + 10获得109的结果。 表达 expression命令也非常有用,因为它允许您修改变量的值。 在上面的示例中,我们使用表达式命令将count的值更改为80。 如您所见,它不仅改变了调试器中变量的值,而且实际上改变了程序中的变量值。 您可以从print命令的结果中观察到这一点。 断点 下图显示了Xcode的断点管理器。 在这里,您可以管理程序中的断点列表,并执行其他操作,例如删除或启用和禁用断点。 一种非常普遍的做法是使用断点来停止程序的执行,检查其状态并搜索错误。 但是,还有更多…… 断点为我们提供了其他可能性,正如我们在本文中已演示的那样。 通过使用断点,我们证明了我们可以指示程序何时停止,以及使用LLDB在其上运行命令,从而使我们能够检查和修改变量。 Xcode允许我们创建符号断点,从而可以节省大量时间来查找错误。 要创建符号断点,请单击XCode调试管理器左下角的“ +”按钮,然后选择“符号断点”。 将出现一个弹出窗口,允许您插入任何符号,并且只要在程序中的任何位置或在Apple的代码中执行此符号,断点将导致程序停止。 在图片中,您可以看到一个示例。 我将变量计数转换为NSNumber类型的对象。 我插入了符号[NSNumber numberWithUnsignedInteger:] ,以便在进行转换时使程序停止。 如您在图片中所见,即使在该特定代码行中没有断点,执行符号时程序也会停止。 结合LLDB和断点 将LLDB命令与断点结合使用会带来很多可能性。 我将向您展示两个实际示例,以演示如何结合使用这两种工具,以帮助您从程序中获取更多信息,并根据需要对程序进行更改。 […]

使情节提要协作可管理

提交前进行审查 当然,情节提要文件不是用Swift或Objective-C编写的,但是您在击入commit之前仍应仔细查看XML源代码的每个更改,以确保尝试推送的更改确实是您要进行的。 Xcode进行了一些常规更改,在故事板文件上进行协作时应避免提交: 轻微的框架变化 如前所述,您可能会注意到Xcode可能会对整个Storyboard文件进行了许多小的更改,例如rect高度更改了.5。 如果要创建一个功能和一个View Controller,则应该可以通过查看属于新Vi​​ew Controller的XML块(以View的名称开头)来判断这是否是您所做的更改这样的控制器: Xcode和设备版本中的差异 我强烈建议您和您的团队提前沟通要在项目中使用哪个版本的Xcode,有时您会被添加到项目的中间,或者将工作带回家,而忘记了使用其他版本的Xcode。您的家用机器。 这是您开始在Storyboard XML顶部看到更改的时候—最常见的更改是版本 , toolsVersion , systemVersion和设备 设置 。 这些自动更改可以从提交中删除,因为其他开发人员也很可能也具有类似的自动更改,从而导致需要解决的冲突。

IBM Kitura Bluemix-XCode设置

第一部分是如何在Mac上创建Kitura Project并将其推送到Bluemix上。 有很多方法可以做到这一点。 我选择以下方式,因为我希望能够在xcode上编写所有代码并运行本地服务器进行调试。 您可以在以下存储库中找到项目的完整源代码: zirinisp / XCodeKituraBluemix XCodeKituraBluemix – IBM Kitura Bluemix的入门Xcode项目 github.com 克隆Kitura-样品 打开终端并输入以下内容 git clone https://github.com/IBM-Bluemix/Kitura-Starter.git 重命名项目(可选) 打开Package.swift并将应用程序名称(Kitura-Starter)更改为所需的名称。 打开manifest.yml并将命令:更改为新的应用名称。 转到Sources文件夹,然后将Kitura-Starter文件夹重命名为新名称。 在xcode上运行 运行以下命令以生成Xcode项目: 迅捷包generate-xcodeproj 这将生成一个.xcodeproj文件。 在Xcode上打开 在顶部选择可执行文件: 然后运行(cmd + r)。 这将构建并运行Web应用程序。 因此,您可以忽略命令行生成和运行命令。 完成后,打开一个野生动物园窗口并访问:http:// localhost:8090 哪个应该给您Kitura入门样本页面 添加包裹 请记住,使用此设置,如果要添加新的swift程序包,则必须运行 迅捷包generate-xcodeproj 再次,因此新软件包将安装在xcode项目上。 我希望有一天xcode可以整合该过程,并且能够自动进行。 调试 您可以尝试在Controller.swift文件的getHello函数上添加断点。 然后访问localhost:8090 / hello,断点将被激活。 这非常有用,因为我们可以使用xcode的调试器。 为什么我不使用IBM Cloud Tools 我尝试使用它们,它们似乎使开发过程过于复杂。 我找不到在多台计算机上使用它们的方法。 我同时在iMac和MacBook上进行开发,并使用源代码控制来同步项目。 IBM […]

为iPhone和iPad构造iOS XCUITests

Apple的XCUITest框架是iOS应用程序UI自动化的热门且新兴框架,自从WWDC 2015推出以来,受到了广泛关注。 XCUITest允许我们在Swift中为iOS应用编写UI测试,这使iOS开发人员可以轻松为iPhone和iPad的iOS应用添加UI测试。 必须同时考虑XCUITests的iPhone和iPad,因为使用iPad上的应用程序的用户不能被忽略。 使用XCUITest,由于使用相同的框架(即XCTest)编写了单元和UI测试,因此持续集成和持续交付变得轻而易举。 在XCUITest之前,Appium,Calabash等工具允许使用其他语言(如Ruby或Java)编写UI测试,这成为CI / CD和iOS开发流程的难题。 XCUITest可以为iOS应用编写,但是iOS设备具有不同的变体,例如具有不同屏幕尺寸的iPad和具有不同屏幕尺寸的iPhone。 我们必须确保XCUITests可以在所有变体上完美运行,而不会引起很多重复。 如果XCUITest的架构正确,那么我们可以避免重复代码,并且仍然能够在不同版本上运行所有XCUITest。 在本文中,我们将介绍如何为iPhone和iPad构建XCUITest。 XCUI测试 XCUITest新手肯定应该观看WWDC视频,以了解XCUITest框架的基本功能。 XCUITest允许我们使用Apple自己的编程语言Swift为iOS应用编写测试。 它与其他第三方框架(如Appium,Calabash等)有很大不同。如果您想将XCUITest与Appium进行比较,请阅读这篇文章,以更好地了解每个框架。 如果您想了解所有新XCUITest功能的动手探索,请参考我以前的博客文章“使用Xcode 9的新XCUITest功能”,其中我已详细介绍了几乎所有功能。 您可以按照DZone上这篇博文中提到的为XCUITests设置面向协议的体系结构,第二部分可以在这里获得。 我们可以使用WWDC 2017演讲中有关可测试性工程的演讲中提到的一些技术来使XCUITest可扩展bu,重点是可测试代码。 UIDevice和XCUIDevice 苹果提供了UIDevice类来获取当前设备的表示,并提供了XCUIDevice类来模拟物理按钮和设备方向。 如果我们正确地组织了XCUIElement,那么在iPhone和iPad上进行架构测试就变得如此容易。 使用UIDevice API,我们可以使用以下代码获取当前运行测试的设备 如果UIDevice.current.userInterfaceIdiom == .pad { //做iPad的东西 } 使用XCUIDevice,我们可以使用以下代码将设备方向设置为横向或纵向 XCUIDevice.shared()。orientation = .landscapeRight 这两个API对在iPhone和iPad上设置XCUITests极为有用。 避免两个套房 在许多项目中,我看到人们为iPhone和iPad创建了两个单独的测试套件。 在iPad和iPhone中,有两种单独的Xcode方案可以执行测试。 在整个测试中也有条件执行,这对于管理测试套件很困难。 我们不需要像使用本文中提到的方法那样进行操作。 稍后,我们将尝试找到解决这些问题的方法。 组织XCUIElement 在iPad和iPhone上构建XCUITests时,以适当的格式组织XCUIElement非常重要。 我强烈建议使用Swift枚举来组织屏幕上的元素。 请将此帖子参考XCUITest的面向协议的体系结构。 在我最近的有关使用Swift枚举组织XCUIElement的文章中,我解释了如何按照屏幕组织元素。 假设我们的iOS应用程序有一个主屏幕,其中包含三个按钮和两个静态文本。 我们可以这样写枚举 导入XCTest 枚举HomeScreen:字符串{ case guestButton =“你好” […]

使用泛型和描述符在iOS上标准化图标,图像和占位符

创建良好的用户体验时,一致性是关键。 在显示图标,产品照片,占位符或加载微调框时,只需一个位置来定义它们的外观以及应如何在屏幕上显示这些内容,就可以使我们保持一致。 在iOS的世界中,我们使用UIImageView ,它允许我们显示图像并配置诸如contentMode , tintColor , backgroundColor类的东西,让我们不要忘记那些非常重要的UI测试的accessibilityIdentifier 。 我们正在努力做到两件事: 一个可以定义我们如何在应用程序中显示标准图标和图像的地方,包括应应用于每个图标和图像的图像视图设置。 一个干净的呼叫站点,可以应用这些图像,而不必担心如何以及何时加载和显示这些图像。 以下是一些我们要标准化的常见图像类型的示例: 加载微调器 :本地图像,无缩放比例的集中化图像,浅灰色背景,“ loadingImage”可访问性标识符。 下载的产品图片 :从URL下载,缩放以填充“ productImage”可访问性标识符。 占位符图像 :本地图像,没有缩放比例的集中化图像,灰色色调,浅灰色背景,“ placeholderImage”可访问性标识符。 下载失败图标 :本地图像,没有缩放比例的集中化图像,红色色调,浅红色背景,“ failureImage”可访问性标识符。 功能图标 :本地图像,无缩放比例集中显示,深灰色色调,浅灰色背景,“ featureX”可访问性标识符。 一些图像/网络库允许您在加载远程图像时提供占位符,但是我们需要比通常提供的更多控制权,以允许我们准确指定它们的显示方式。 当显示特定屏幕的图像时,我们不想担心图像的下载方式和时间。 我们只想对图像视图说:“显示此图标”,或“使用我们的标准占位符加载此图像”。 我们希望我们的呼叫站点尽可能简单。

Xcode 9.3中用于64位支持的新工具

支持32位应用程序且毫不妥协的最新macOS版本是macOS High Sierra。 通过在Xcode 9.3 beta中使用新的诊断工具并在macOS 10.13.4 beta中进行测试,确保您的应用程序的未来版本兼容64位。 默认情况下,此版本的Xcode还会构建64位应用程序。 支持的配置 Xcode 9.3 beta需要运行macOS 10.13.2或更高版本的Mac。 Xcode 9.3 Beta包括适用于iOS 11.3,watchOS 4.3,macOS 10.13.4和tvOS 11.3的SDK。 弃用macOS 32位支持 为了为将来的macOS版本做准备,在该版本中32位软件将不再运行而不会受到损害,从macOS High Sierra 10.13.4开始,将向用户通知启动依赖于32位软件的应用程序。 该警报在每个应用程序中仅出现一次。 开发人员可以在macOS 10.13.4中使用新的64位测试模式来测试软件的64位兼容性。 注意:强烈建议仅由开发人员或经验丰富的IT管理员启用此模式。 要启用64位模式: 启动终端 执行以下命令:sudo nvram boot-args =”-no32exec” 重新启动机器 64位测试模式可防止启动32位进程。 启动依赖于32位软件的应用程序会导致通知该应用程序无法打开。 其他类型的软件可能会无提示地失败,例如32位版本的Dashboard和WebKit插件,首选项窗格和后台进程。 一旦软件更新为以64位工作,请禁用测试模式。 要禁用测试模式: 启动终端 执行以下命令:sudo nvram boot-args =“” 重新启动机器 Swift和Apple LLVM编译器 现在,导入到Swift中时,带有以添加或删除开头的选择器的Objective-C方法将被统一命名。 以前,可以通过使用或不使用添加或删除后名称的一部分来不确定性地命名每次出现相同选择器的情况, 例如导入addThing:作为add( 🙂或addThing( […]

Como utilizar Wireless调试无Xcode 9

Apple宣布了无线调试功能,没有Xcode 9或WWDC17。 Essa功能允许使用通用的构建调试器的设备(iOS或tvOS),可以使用对应的USB和Mac操作系统。 在Xcode 9或更高级别上使用无线工具进行调试的必要工具,在iOS 11或更高版本上使用estar设备。 1- Abra seu projeto no Xcode 2- Conecte seu iPhone no USB(Apenas primeira vez para fazer aconfiguração) 3- Abra窗口/设备和模拟器(teclas de atalho Shift + Command + 2) 4- Selecione a Primeira aba“设备”,selecione seu设备,ao lado esquerdo 5- Selecione o复选框“通过网络连接”。 Dépreaaparecer oéconede rede na frente do sume device。 6- Desconecte seu设备可连接USB和Macestáconectado的mesmaconexão无线产品。 无线连接,没有任何可用的iPhone和iPod […]

如何在Swift中编写单元测试而不公开所有内容。

每当我参加讨论单元测试主题的会议演讲时,我都会听到两个问题。 1.我如何说服老板给我时间写这些书? (您没有。您只需编写它们。)和2.单元测试破坏了封装。 你是在告诉我我应该公开一切吗? 我在iOS / Swift的世界中工作,那里有解决特定问题的工具,但总体感觉是,我们必须破解向团队其他成员开放的所有功能,才能进入那里并测试一些变量当他们应该被设置时就被设置。 因此,在进一步详细介绍之前,请先进行警告。 本文的目的是激发话题,而不是倡导任何特定观点。 您采用的任何方法都有其优点和缺点,并且在继续进行计划之前,获取尽可能多的信息总是明智的。 自动化测试虽然不错,但是永远不会修复架构不良的应用程序。 我也不声称他们曾经做到过。 从坚实的基础开始建设总是比将绷带应用于需要推倒的东西总是更好。 ew 感觉很好。 好的,有点自以为是! 这到底是什么问题? 当我们在团队中工作时,每个开发人员都定义了一个API,团队中的其他成员在使用他们的代码时都可以访问。 重要的是,我们要给我们的团队成员一些容易理解的东西,否则他们可能会对我们的代码感到困惑。 如果一个类具有太多面向公众的功能,而另一个开发人员需要相当频繁地使用它,则可能会造成混乱。 与创建具有太多菜单选项的应用程序没什么不同。 用户不容易确定哪个选项是正确的选择。 但是实际上,这比那更糟。 其中一些选项可能会对应用程序致命。 有些变量和函数不应该在类之外使用,因为这样做可能会引入意外的行为。 这就是为什么我们每个人都决定为我们的同伴程序员定义一个api。 我们说“这是公共的,您其他开发人员可以在不破坏应用程序的情况下使用它”,“这是私有的。 没有人可以触摸它。” 这是很长时间以来的样子,并且确实运行良好。 这是传达意图的明确方法。 单元测试与私有方法 不幸的是,这种方法不适用于单元测试。 原因很简单。 在iOS中,您不能针对声明为私有的任何内容编写测试。 等等什么 您应该如何进入那里并测试所有内容? 您应该测试所有内容吗? 您应该只测试几件事吗? 你应该测试什么? 你不应该测试什么? 这变得令人困惑。 似乎没有关于它的手册,而且不同小组之间来回往来很多。 有素食主义者说,单元测试就像在吃蔬菜一样,看着自己变得不健康。 然后是另一个团队放弃了,因为似乎需要考虑太多,而他们的老板也不允许他们编写测试。 我被困在这里问,又是什么问题? 它必须是如此二进制吗? 在这里,我主张“仅仅公开一切”并不是一件坏事。因此,在这里,你也让我死死盯着我的建议的荒谬之处。 好的,那部分结束了。 不管你怎么想,我确实有一个问题。 您是否认为公共/私有的重要性取决于其他外部因素,例如团队规模,项目复杂性,代码可重用性等? 当然,BigCo的一个应用程序项目需要数百名团队成员研究相同的代码,而SmallCo的项目可能只有一两个人正在查看相同的代码。 它必须是。 在较大的公司中,不同人群之间的交流要少得多。 由于无法快速召集您讨论如何与您的班级一起工作,因此定义什么是私有的和什么不是私有的更为重要。 但是,在较小的公司中,只要有一点混乱,您就可以与该人配对。 […]

Xcode9 + Xcode Server =全面的iOS持续集成

在WWDC 2017上,Apple宣布了几乎所有iOS开发人员都满意的东西,主题为“Xcode和Xcode Server的签名新功能”。 很难解释,使用Xcode 9和Xcode Server在Apple平台(尤其是iOS和macOS)上执行持续集成变得多么容易。 Xcode 9之前的CI Xcode 9发行之前的iOS持续集成非常具有挑战性。 人们可能会尝试跟随 为使用证书和配置文件设置CI服务器计算机而进行了长期的战斗。 使用诸如Fastlane之类的基于Ruby的工具来自动化分析,构建,测试和代码签名的过程。 使用其他第三方云CI服务(例如TravisCI,CircleCI)或自托管解决方案(例如Jenkins,TeamCity)来使用bash脚本构建或Fastlane的自动构建 使用了诸如Facebook的xctool或LinkedIn的Bluepill之类的工具来并行化多个设备和模拟器上的测试。 使用第三方基于Ruby的工具(例如xcov,xcpretty)进行代码覆盖和测试报告。 将Xcode Server与macOS Server应用程序和Xcode Service for CI一起使用,但仍在与代码签名和并行执行作斗争。 带有Xcode 9的Xcode Server满足了所有这些要求。 您现在很少需要上面的东西。 Xcode Server可以轻松地为我们处理所有这一切。 感谢所有致力于开发人员工具以实现这一目标的开发人员。 让我们看看有什么变化 Xcode 9之后的CI 在Xcode 9中,我们在Xcode中集成了以下与CI相关的新功能 Xcode Server内置Xcode 9,因此无需单独的macOS应用。 Xcode Server bot具有新的选项卡,可在自动配置设备的多个设备和模拟器上进行代码签名和并行测试。 开发和发行签名的自动签名。 Xcode Server通过自动或手动签名创建分发IPA Xcode Sever不再启动仍然可以并行运行的模拟器。 现在,我们将看到实际上如何轻松设置和使用Xcode Server。 设置Xcode服务器 如前所述,Xcode Server不再需要macOS Server应用程序,它现在内置在Xcode中。 我们可以在Xcode Preference中看到“ Servers&Bots”标签。 我们可以使用本地Mac或其他Mac设置Xcode […]