Tag: 编码

学习Swift和iOS开发第6部分：循环

循环是重复的代码块，我们可以用来对Swift中的多个数据执行一项操作。 DRY原则指出“不要自己重复”。这是一种已存在很长时间的编码原则，但是Swift中的循环是重复代码的块。 如何使用循环是一种好习惯？ 虽然循环反复重复相同的代码，但这样做是在单个循环的范围内进行的。 例如，我们可以从数组中传入数据，并且可以对该集合的每个项目执行相同的操作。 这是Swift语言非常有用的组件。 在这篇文章中，我们将学习3种流行的Swift循环类型。 让我们变得循环！ 🙃 搭建游乐场 首先，如果尚未打开Xcode，请点击Create New Playground 。 给它起一个类似Loops的名称，然后单击Next 。 选择某个位置以保存此.playground文件，然后单击“ Create以保存它。 您应该看到类似以下的屏幕： 删除左侧的所有样板代码，但根据需要保留import UIKit 。 为什么要使用循环 假设我们有4名员工在公司工作。 每个员工的薪水不同： 员工1：$ 45,000 员工2：$ 100,000 员工3：$ 54,000 员工4：$ 20,000（对不起，兄弟）。 创建4个变量（每个雇员一个），并将每个变量的值设置为上面的相关薪水： 导入UIKitvar employee1Salary = 45000.0 var employee2Salary = 100000.0 var employee3Salary = 54000.0 var employee4Salary = 20000.0 我们刚刚完成了2016年第四季度，我们度过了非常成功的一年。 我们希望给每个员工加薪10％。 在您的游乐场中，键入： 导入UIKitvar employee1Salary […]

进入科技世界：转变职业的技巧

Viviane Chan是CBC的iOS应用开发人员。 （Ashar Shoaib / CBC） Viviane Chan的iPhone极大地改变了她的职业生涯。 Viviane，现为CBC iOS Apps开发人员，曾任建筑设计师。 她与客户见面，寻找解决方案并监督从设计到施工的项目。 但是她手掌上的小型设备有一些特别之处，这启发了她改变方向并为自己找到了一条新路。 她回忆说：“我意识到，这种设备将对我们对自然和公共空间的感知产生深刻的变化，它将改变我们的行为以及我们获取信息的方式。” “向手持技术的转变令我着迷； 我想成为其中的一部分。” 当Viviane开始转行时，她几乎没有编码经验。 她通过阅读书籍和博客，访问lynda.com和raywenderlich.com上的课程以及在Lighthouse Labs参加iOS Bootcamp进行了很多自学。 自换档以来，Viviane在CBC担任了职务，她得到了一位导师的技术指导，导师对此提供了极大的帮助。 您可以在这里看到Viviane最近关于她如何构建增强现实原型的一些工作。 我们强调Viviane的道路，因为尽管她的处境可能是独特的，但她的建议却是普遍的。 用她的话来说，这是薇薇安（Viviane）关于改变职业的建议： 识别何时需要继续前进 您需要对即将要做的事情充满热情，并且需要准备进行重大更改。 对我来说，选择很容易。 我觉得我已经完成了我以前的职业生涯想要实现的目标，并准备进行一次新的冒险。 注意财务挑战 财务稳定是职业转变的重要组成部分。 在过渡阶段，您将不得不考虑继续教育的成本和收入损失。 如果您是职业中期，您可能赚到了一定数量的钱，可能要花一些时间才能回到同一水平。 在获得一定程度的经验和技能之前，您不会在技术上赚很多钱。 了解您的工作与生活平衡将被颠倒 我是两个女孩的妈妈，这让我很忙。 我与家人交谈，并告诉他们，我四个月都无法工作，学习和求职。 对我而言，重要的是，他们了解我正在经历人生的转型，需要他们的支持，但这只是暂时的。 我非常感谢我的家人在过渡期间加倍支持我。 回顾过去，我很高兴为我的孩子们树立榜样-向他们表明，女性可以从事令人兴奋的科技职业并拥有家庭。 通过专注和努力，您可以实现任何想要的事情。 准备不舒服 您可能刚刚辞去了一份薪水不错的工作，并得到舒适和尊重。 现在，您将成为会议室中最不了解的人。 在您生命中的这个阶段，这很奇怪和尴尬，但同时，这是暂时的。 接受失败的希望 您正在做出巨大的改变。 这是新事物，不能保证，但是您需要对此表示满意。 您可能会失败，也可能会成功。 归根结底，斗争是真实的，但这也是暂时的。 如果坚持不懈，您将克服挑战并实现长期目标。 CBC的数字产品挤满了以有趣甚至有时令人惊讶的方式找到我们的人。 如果您想了解更多关于我们的空缺职位的信息，可以在这里阅读更多内容。

使用Swift的iOS实用Firebase

该课程的原价为199美元，但在有限的时间内，您只需10.99美元即可获得完整的课程。 优惠券数量有限，请不要等待太久🙂使用下面的优惠券链接： https://www.udemy.com/practical-firebase-for-ios-using-swift/?couponCode=ILOVEFIREBASE 大家好， 在过去的几个月中，我一直在努力学习新课程“ 使用Swift的iOS实用Firebase ”。 我很高兴地宣布，该课程现已出版，可以出售。 我一直认为，学习某件事的最好方法就是去做。 适用于iOS的实用Firebase使用Swift反映了我边做边学的经验。 在本课程中，我们将创建多个实际应用程序，这些应用程序将使我们看到Firebase平台的强大功能。 让我们看一下将在本课程中构建的不同应用程序： 高水位 High Waters应用程序离我的心很近，因为它影响了我当地的休斯顿社区。 该应用程序的目的是通知用户水灾地区。 用户可以在地图上放置一个指示被淹区域的图钉。 任何人都可以看到该图钉，而无需刷新应用程序。 销的位置将保留在Firebase数据库中。 杂货应用 Grocery App是一款偶像应用程序，用于了解Firebase中的父子关系。 该应用程序还向用户介绍了Firebase身份验证系统，该系统允许用户使用自己的自定义凭据进行注册和登录。 用户能够创建新的购物清单，然后将项目添加到购物清单。 根据用户的凭据，每个购物清单与杂货一起保留。 WhatsUp聊天 诸如WhatsApp，Facebook Messenger，微信，Viber等聊天应用程序已成为我们社会不可或缺的一部分。 在本节中，我们将构建一个名为“ WhatsUp”的完整聊天应用程序。 WhatsUp聊天应用程序将允许用户向聊天室中的其他用户发送文本消息和照片。 本节将向您介绍JSQMessagesViewController，它使创建类似聊天的界面变得很容易。 学生还将学习如何使用Firebase存储将照片上传到Firebase平台。 我对本课程感到非常兴奋，希望您会喜欢学习并将Firebase与iOS应用程序集成。 该课程的原价为199美元，但在有限的时间内，您只需10.99美元即可获得完整的课程。 优惠券数量有限，请不要等待太久🙂使用下面的优惠券链接： https://www.udemy.com/practical-firebase-for-ios-using-swift/?couponCode=ILOVEFIREBASE 看完课程后，请给它评分并复习。 您的评分非常重要，它有助于添加更多内容并支付账单😉 谢谢， Azam

如何有效地打开拉取请求

拉动请求是任何推送代码的世界级科技公司的必备工具。 它可以确保您的代码正在由其他工程师审核，并增强了被审核者对他们的代码符合工程团队所同意的一组标准的信心。 但是就像每杯️☕一样，质量在PR中扮演着重要角色。 质量低劣的公关人员可能会使被审核者和审稿人的口感不好，这通常是由于抨击和非建设性的反馈造成的。 它可能导致工程师之间的不信任和烦恼，直接影响代码库，甚至影响公司的文化。 但是，有效的PR可以引发有关最佳实践，代码约定和团队标准的良好有机对话。 PR中的代码修改将影响当前和将来形式的代码库。 最终，每个被批准和合并的PR都是构建产品和公司的LEGO块。 考虑到这一点，工程师确定如何打开有效PR的要点非常重要。 有效的公关人员应该就思想共享，最佳实践，工程惯例和团队团结进行对话。 创建有效的PR似乎是一项琐碎的任务，但是许多工程师陷入了不良习惯，甚至没有意识到。 这里有一些技巧，以提高您的PR游戏。 保持拉短要求 在审查代码之前，您如何惹恼其他工程师？ 使用10,000行以上的代码更改来打开大型请求。 眼疲劳，背痛和偏头痛只是工程师在滚动巨大PR时遇到的一些副作用。 让您的公关简短，简单，切合实际。 从历史上看，大型PR通常会被迅速批准并合并，因为审阅者会在代码中略过一遍，没有任何评论可望结束滚动。 如果团队完全不关心代码库的健康状况，但是如果您的团队追求质量和维护，请打开小而简洁的PR，作为附带的好处，您的审阅者会感谢您。 公关应该改变多少行没有神奇的数字，但是如果您在跟踪或描述代码在一个句子中的工作时遇到困难，请分拆公关。 另一个好的经验法则是，票证与PR之间的比例为1：1，并且如果票证看起来太大而不能将其分解为子任务票证，则可以确保较小的PR。 请记住，易于阅读的PR假定可以在工程师之间产生良好的对话和协作。 PR不能用于跟踪谁可以更改回购中的大多数线路。 具有较大PR的另一个副作用是，由于分支修改的文件很多，因此需要不断进行重新编制基准，以使分支保持最新状态。 保持简短简短是游戏的名称。 保持评论的建设性 收到非建设性和不完整的反馈是很普遍的，它会使工作贬值，并且不会使有关各方受益。 一些评论甚至看起来更好，因为它可能冒犯或侮辱了打开PR的工程师。 留下建设性的反馈会引起良好的对话。 在评论PR时，有以下一些注意事项： 不要告诉工程师您将如何实施该解决方案。 大家都知道有很多方法可以解决。 仅仅因为审阅者可以用另一种方式来做并不意味着工程师必须以某种方式来实现它。 只要代码遵循一组团队惯例和体系结构，就可以为它开绿灯。 不要过多地关注代码样式，例如多余的空格，而将其他代码放在换行符上。 将这些任务留给小子而不是人眼看。 不要浪费精力查找丢失的代码样式，而要专注于实际的实现。 给予积极的反馈。 给予积极的反馈会鼓励您的工程师。 收到建设性的反馈是很棒的，但是太多的反馈仍然会使被审核者感到束手无策。 我们所有人都打开了PR，以解决一个难题，同情您的被审核者，并告诉他们他们在重构方面做得很好，或者感谢他们修复了一段时间以来令人讨厌的错误。 请勿使用“只是”或“我以为我告诉过你……”之类的词或短语。 这些短语可能意味着受审者应该已经了解了一些事实，但未能使用此知识，而在大多数情况下，受审者对此一无所知。 通过暗示一些标准，可以使他们感到过时和沮丧。 相反，请教您的同事工程师，并为他们指出正确的方向。 每个人都喜欢可以教书，学习并保持友善的工程师。 以下是移情评论的一些示例： 而不是 “仅使用用户模型工厂”， 而是 使用 “签出用户模型工厂，那里的某个功能可能会帮助您尝试完成” 代替 “我不是告诉您不要分配这个Car对象”， 而是 […]

Swift中的可重用性和组成

尼采，梭罗和黑森最有可能试图逃避他们一生的一个概念：依赖性。 即使一个人不同意或拥护他们的哲学，程序员应该还是必须？ -在编程时运用他们的思维方式。 让我们先定义问题： 耦合 想象一下，没有一部可以拆卸的汽车。 从座椅到车轮，从底盘到天窗都是一体的。 如果由于在高速公路上钉了一些讨厌的钉子而使轮胎漏气，我不能只买新轮胎，就需要买一辆新车。 因此，我们将此设计称为耦合设计，或者以一种更真诚，更礼貌的方式进行； 愚蠢的设计。 编程没有什么不同。 如果某个类或功能的更改需要我重构程序的许多其他部分，那么我已经设计了这款不可拆卸的汽车。 不酷 一点都不酷。 那么，当我们意识到我们的代码紧密耦合时，我们该怎么办？ 我们花了片刻的沉默。 我们意识到我们编写了一些糟糕的代码，并宣誓不再这样做。 靠这些话活着： 封装 ， 单一责任和继承构成 。 我将以一些简单的示例开始，这些示例说明了我们如何在程序中尊重这些概念，然后将其构建为相当（但不是真的）复杂的示例。 钢琴家或小提琴家 您的功能签名应严格执行其声称的功能； 不多一点。 让它成为钢琴家或小提琴家，而不是两者。 所以我有一个函数应该打印字符串中某些字符的数量： func printNumber（of char：Character，in string：String？）} 如果让string = string { var count = 0 对于字符串{中的s 如果s == char {count + = 1} } 打印（数） } } 此功能做不到预期的。 如果为空字符串，则不打印任何内容，而应打印“ 0”。 […]

如何为快速Codable编写强大的模型并再次使用该模型。

在这篇文章中，我将不写什么是可编码协议以及如何使用它！ 取而代之的是，我将在一个很短的故事中告诉您如何用快速的语言为其编写最佳模型。 所以走吧… 如果您对编码技术不熟悉，我强烈建议您对其进行详细了解，然后再回到这里阅读其余内容。 你们中的大多数人都可以使用可解码来反序列化JSON文件。 但是如果您想在项目中再次使用该模型作为列表或数组又如何呢？ 或者只想从您的项目中的模型创建一个全局实例数组，并进行很多次映射。 不幸的是，许多初级开发人员将创建另一个模型结构并使用该模型结构。 但是它们可能会遇到可选选项或强制展开的问题。 假设此JSON文件为： { “ name”：“ John”， “ lastName”：“ Doe”， “年龄”：27 } 在此JSON文件中，我们有一个简单的用户数据。 所以我们从简单的模型结构开始： struct user_Model：Codable { 让名字：字符串？ 让lastName：String吗？ 让年龄：int？ } 在此模型中，我们使用“ let” ，并且必须在每个参数的末尾添加可选的“？” ，以避免反序列化错误。 如果该参数在该JSON文件中不存在，它将返回“ nil”而不是该参数。 因此，我们应始终处理“无”。 another另一方面，您无法通过安全展开来制作该模型的另一个实例。 这将发生： （testUser？.name）！ 这太错了。 也许您说我们可以使用Class而不是struct，然后使用： 必需的init（）{ } 并在那里初始化每个参数。 像这样 ： class user_Model：Codable { 变量名称：字符串 var lastName：String var age：Int 必需的init（）{ self.name […]

自学系列| iOS Swift | 第二课：介面开发（UIKit）第2部分

这篇文章承接第1部分 ，继续Udacity iOS App Nanodegree第二课的导读。 3.其他UI元素 UIImagePickerController 当App需要取用手机的相簿时，就可以使用UIImagePickerController让App跳出选择相片的画面，如左图。它需要遵循的Protocol有UIImagePickerControllerDelegate以及UINavigationControllerDelegate。 UIActivityViewController UIActivityViewController（如中图）经常在分享照片，或分享URL链接的时候，我们透过想要要分享的东西传到其他App上。 UIAlertController UIAlertController有某种形式，常见的有上右图那种从底下冒出来的选单，也有从萤幕中央跳出来的罢工（在左下图），它也可以结合UITextField构成简易的资料输入，例如下面右图。 4.多页画面 UINavigationController / UITabBarController 画面上方的是NavigationController，我们在第一课有使用过（可以看这篇），通常左边的按钮负责回到前一页，右边的按钮则可以实作不同需求，像是分享，跳出选单…等等。画面下方的是TabBarController，用于在不同页面之间切换。详细的实作Udacity课程影片讲了很多，这边就不多说了。 学完第二课，我们已经熟悉UIKit当中最常见的几个元素， 包含几乎所有App都会用到的UITableView，UICollectionView，可以在多页面之间转换的UINavigationController，UITabBarController，还有一些小工具如用来输入文字的UITextField，使用挑照片的UIImagePickerController，会跳出选单或警示的UIAlertController。 还有最最重要的 准备好前往下一课了吗？ 第三堂课：网路资料传输处理（网路） 第四堂课：手机上的资料储存（核心资料） 第五堂课：从发想到上架的方法论 如果喜欢这样的自学系列，请帮我拍拍手👏另外，我把之前写的程序学习相关文章集结在底下的列表，有闲来坐🤗 艺一网—文章列表 我们的【学程序＆软体创业】学习之路 medium.com

驯服iOS中的大量控制器（第1部分）

更新：第2部分现在可用 无论您的iOS应用多么简单，您仍然必须遵循MVC软件架构模式。 MVC模式将应用程序的职责分散在模型，视图和控制器之间。 不幸的是，大多数时候，责任最终落在了控制者的肩膀上。 这种做法导致了所谓的大规模控制器 。 我在IndieDevStock上介绍了“在iOS中驯服大量控制器”。 如果您想观看我的会议视频，请购买远程通行证。 大型控制器是不遵守单一职责原理的视图控制器。 这些控制器可能正在访问数据，调用Web服务，创建UI元素以及执行与控制器没有直接关系的其他任务。 这导致了技术债务和维护方面的噩梦。 这篇文章的主要重点是向您展示一些可用于驯服大型控制器的技术。 我们将从一个非常简单的应用程序“ Grocry ”开始。 杂货应用程序负责跟踪购物清单。 Grocry应用程序的界面如下所示： 即使该应用程序非常简单，但指定的控制器中的代码仍然很繁重。 这是段中的代码片段。 覆盖func viewDidLoad（）{ super.viewDidLoad（） initializeCoreDataManager（） //获取请求 let request = NSFetchRequest（entityName：“ ShoppingList”） request.sortDescriptors = [NSSortDescriptor（key：“ title”，ascending：true）] self.fetchedResultsController = NSFetchedResultsController（fetchRequest：请求，managedObjectContext：self.managedObjectContext，sectionNameKeyPath：nil，cacheName：nil） self.fetchedResultsController.delegate =自我 尝试！ self.fetchedResultsController.performFetch（） } 下面实现了负责初始化CoreData的initializeCoreDataManager： 私人函式initializeCoreDataManager（）{ 警卫让modelURL = NSBundle.mainBundle（）。URLForResource（“ GrocryDataModel”，withExtension：“ momd”）else { fatalError（“未找到GrocryDataModel”） } 警卫队，让ManagedObjectModel = NSManagedObjectModel（contentsOfURL：modelURL）else { […]

生物群落v2.0.0

去年下半年，我遇到了一个大型iOS项目有许多不同测试环境的情况，因此需要不断地在它们之间进行切换。 解决此问题的典型方法是创建构建变体，每个方案的设置都在编译时设置。 这是可行的，但事实证明非常耗时。 切换方案，重建和测试新配置… 考虑到必须有一种更好的方法，我在GitHub上搜索了一个允许的库，该库可以帮助我实现想要的工作。 但是一段时间后，我发现实际上没有一种类型安全的解决方案可以让我在运行时执行此操作。 所以，我做了一个。 Biome是一个轻量级框架，为Swift开发人员“规定”一种管理不同环境变量的方式。 与dotenv相似，您可以编码一组值以换入和换出不同的变量。 版本1 第一个版本很快被黑客入侵，以适应能够在每个环境中快速切换变量集而无需重新编译整个应用程序的最低要求。 它缺乏类型安全性，使用起来有点笨拙。 我知道这并不完全是我想要的，但是Swift并没有工具来实现我所追求的目标。 幸运的是，Swift 4引入了可编码协议，而我正是完成我要完成的任务所需要的。 在今年参加WWDC并与Swift编译器和标准库团队的一些非常有用的成员交谈之后，我对如何更新Biome以利用这些新工具有明确的愿景。 版本2 我很高兴地宣布，我已经将Biome更新到了2.0.0版！ 此版本带来： 类型安全的Biome对象，可在Xcode中提供自动完成开发人员代码的功能 Codable支持自动加载JSON和Codable对象 框架的改进接口 Swift 4.2的新Hasher和CaseIterable更改的预准备 100％单元测试覆盖率 您可以在此处找到Biome的存储库，并在此处找到版本2.0.0的发行版。

MVC-组织代码的模式

MVC代表模型，视图和控制器。 它是一种体系结构，您可以使用该体系结构来组织代码，以便任何人以及您每次引用代码时都可以轻松理解它，因为那样的好代码可以被包括您在内的任何人轻松阅读。 有两种方法可以执行任何工作：要么在开始时就没有任何计划/架构，要么只是想到一个想法，然后就着手进行工作（尽管这是一个糟糕的方法），或者先计划好工作，例如您将如何实现该想法或创建一种架构类型，以便您可以轻松地分析自己在做什么以及您将如何进一步发展（这是一种更好的方法）。 也许您将能够使用这两种方法来完成您的工作，但是使用第二种方法，完成任务的可能性将会增加，并且最终结果将是效率更高的理想结果。 例如，如果我们谈论建造一座建筑物，那么我们都知道，首先，建筑会绘制一张正确的地图，因此建造者会建造该建筑物。 我们将通过日常生活示例来了解MVC的概念，以便您可以轻松地将其关联起来，并且可以更轻松地理解该概念。 有什么看法？ 顾名思义，这是最终用户可见的应用程序部分（在阅读本文时，您是最终用户），该用户可以与应用程序的所有功能进行交互，并且可以能够输入一些数据以及以往的数据。 在应用程序的视图部分中定义了负责用户界面的所有代码。 让我们举个例子，假设您非常饿（您当时在吗？哈哈，开玩笑），然后您去一家餐馆浏览菜单并为您点菜，点菜在技术上是在您的数据中输入数据应用程序，您想要根据您的订单结果。 一段时间后，食物就在您面前，这与根据您的需要显示数据相同。 什么型号？ 显然，如果您正在开发将处理大量数据的应用程序，则数据处理是主要问题之一。 处理和处理如此大量的数据有时会令人头疼，但是这要归功于MVC模式的模型部分。 在这一部分中，我们定义数据的类型，即，如果我们要向用户询问用户名和密码，那么期望用户输入哪种数据类型（或者可以说，应用程序中处理数据的部分）相关功能定义模型）。 例如，如果我们的应用程序要求密码，并且密码必须至少包含7个字符，但是如果用户输入6个字符作为密码，则该密码将不被接受，因为这与我们的模型设计背道而驰。 继续我们的餐厅示例，在接受您的订单后，订单将发送给厨师以准备食物。 现在准备食物，厨师将打开冰箱，放所有配料。 在这里，您可以将冰箱与一个数据库相关联，该数据库将包含烹饪食物的所有成分，而此处cook是一个模型，该模型将根据他/她准备食物的需求从数据库/冰箱中获取数据。 什么是控制器？ 您所有的应用程序逻辑，即如何处理数据或如何访问用户请求或向用户显示什么，所有这些都在应用程序的控制器部分中定义。 它就像视图和模型之间的桥梁，或者顾名思义，它充当应用程序的视图和模型之间的控制器。 在我们的餐厅示例中，服务员充当控制器。 当食物准备好时，服务员将把食物从厨房拿到顾客那里，而厨师可能会拿着其他一些餐桌上的订单，因此服务员/控制器的工作是将正确的订单送达正确的桌子。 随着对MVC模式读取的越来越多的使用，代码的共享和可重用性也得到了提高。 想象一个应用程序，您在其中编写了所有代码（意味着没有代码分区），也就是说，所有代码都写在同一位置，并且相信我会造成很大的混乱。 同样，如果您在应用程序中使用MVC模式，那么可以在同一应用程序上一起工作的人很多，一个人处理视图部分，一个处理逻辑部分，依此类推。 MVC模式不仅限于特定的语言，该体系结构可用于任何技术。