Tag: swift

自定义字符串可转换

什么是“自定义字符串可转换协议”?在项目模式及以后的项目中如何提供帮助? 协议是什么的快速更新: 协议指定了某些事物应实现的一组行为,而没有提供针对这些行为的实现。 然后,该协议可以 由类,结构或枚举采用,以提供这些要求的实际实现。 满足协议要求的任何类型都被称为 符合 该协议。 我将首先创建一个名为Cat的类,并使用其属性名称,年龄和颜色。 我还创建了两个名为“ cuddles”和“ puddles”的猫的实例。 如果您发现我尝试打印这些实例时发现的所有打印内容均为“猫”。 这不是很有帮助,因为我看不到猫的属性,也无法区分两只猫。 我可以像下面所做的那样打印每个属性的插值字符串,但这可能会变得非常乏味且耗时: 让我们尝试采用自定义的String Convertible,但是要记住,要符合该要求,我们需要在该类中创建一个“ description”属性,并在其中返回一个字符串。 注意,当我们打印时,我们不需要调用description属性。 我们仅打印Cat的实例,它会自动打印description属性。 无论哪种方式,调用print函数都将打印相同的内容: 输入协议时,您可能会注意到还有另一个名为Custom DebugString Convertible的协议。 有什么不同? 好吧,实际上没有多少。 为了符合要求,有一个属性要声明,就像“自定义字符串可转换”一样。 在这种情况下,该属性称为debugDescription。 当您寻找更详细的信息(例如……)时,应将此协议用于调试目的。 当您尝试调试代码中的问题或者只是为了检查代码以确保其按您期望的方式工作时,我们最终会抛出很多打印语句。 出于多种原因,这两个协议可能是很好的工具,尤其是在使用自定义类时: 1.使用类时,它可以打印出有用的,有用的属性值。 2.在团队中工作时,description属性使您可以“描述性”,以便团队可以轻松读取代码中的输出。 3.采用和遵循非常容易,为什么不使用它呢!

UIDynamics在Playground的基础

总览 UIDynamics是由Apple创建的引擎,可根据定义的行为修改符合UIDynamicItem协议的类的实例的中心 , 变换和界限 。 UIView和UICollectionViewLayoutAttributes默认情况下符合UIDynamicItem协议。 在本文中,我们将重点介绍UIViews。 我可以在我的Github帐户中找到完整的Playground。 我完全建议下载并使用它,以查看每种行为的工作原理。 其中一个示例的示例: 搭建游乐场 在研究本文时,我发现Playground是实现和完善UIDynamic行为的非常有用的工具,因为它真的很容易设置并且非常快地从更改中获取反馈。 要创建一个具有以下视图的游乐场: UICollisionBehaviour 它模拟元素之间的物理碰撞。 有两种类型: 元素之间:添加多个项目。 反对障碍:通过添加边界或将参考视图用作边界。 但是自从iOS 9以来,Apple为此行为添加了新方法,从而提供了非常有趣的附加元素方法。 让我们看一下它们: 滑动附件:此附件在两个元素之间创建附件,第一个元素可以在与第二个元素相关的axisOfTranslation定义的假想轴中移动。 试图脱离该假想线将导致该轴的参考元素旋转。 限制附件:这就像将绳索绑在两个元素上一样,因此当锚点之间的距离大于length参数时,它将拖动第二个视图。 它不会影响变换或边界,这意味着元素不会旋转。 固定附件:行为就像将一根棍子绑在两个元素上一样,因此元素之间的相对位置不会改变。 销钉附件:模拟两个钉在一起的物体。 常见错误 这些是我在研究中发现的最常见错误,希望处于相同情况的人可以通过阅读以下内容节省时间: 尝试手动修改中心,边界或变换。 例如,添加手势以移动视图以更改其中心将不起作用。 它会与UIDynamics引擎发生冲突,并且不会应用物理行为。 为了解决这个问题,您可以将UIAttachmentBehavior与anchorPoint一起使用,作为用户点击的位置。 将UIDynamics + Auto Layout结合起来时,我并没有遇到大问题,当我删除附件行为并添加推入行为时,这只是一种疏远行为。 它没有从同一角度流畅地推动视图,而是重设了位置。 解决方案是在删除附件之一之前添加推送行为。 结论 UIDynamics是一个出色的工具,可以明智地使用它,可以为您的应用程序增加很多价值,或者只是从中获得乐趣。 与Playgrounds结合使用,可以非常轻松快捷地为新行为建模。 Apple的有关此主题的文档和文章并不十分深入,因此您必须猜测一些参数范围。 例如,其中一些甚至没有像UIAttachmentBehavior的FrictionTorque这样的正式单位。 为了结合一些基本行为来构建更复杂的行为,我决定写另一篇文章,解释如何构建受Swarm启发的模态行为。

SOLID Swift:第二部分

这是SOLID Swift系列的第二部分:在本文中,我们将研究Liskov替换和界面隔离 。 如果您想追随单一责任原则和开放/封闭原则 ,请随时阅读第一部分。 如简介中所述,第一部分是关于SOLID的前两个原则。 单一责任原则和开放/封闭原则已经是改进代码的两种重要方法! 接下来的两个: liskov替换和接口隔离 。 旁注:如第一部分所述,原则不仅是黑白的,还应根据您的情况,需求和要求进行调整。 非常清楚地表明违反了Liskov替代原则的危险信号之一是: if shape is Rectangle { … } else if shape is Square { … } 如果要添加新形状怎么办? 也许是Triangle ? 我们将不得不在列表中添加另一个 if。 另一个流行的例子更加微妙,可能不会马上被注意到。 想象一下具有width和height属性的Rectangle结构。 Square可以从Rectangle派生,因为正方形也具有宽度和高度。 但是,区别当然是对于正方形, width == height和矩形,该规则不适用。 如果我们要更新Rectangle.width ,那就好了,这对于Square.width因为Square.height尚未更改,因此违反了平方的规则。 同样,这违反了LSP。 这听起来像开/关原理吗? 没错,开放/封闭原则与LSP息息相关。 LSP走得更远。 LSP的基本规则是:派生类型(例如Square)必须完全可以替代其基本类型(在这种情况下为Rectangle)。 我们必须确保新的派生类型不会改变其行为的基础。 在开发过程中要记住的有关接口隔离的主要规则是:不应强迫客户端依赖于不使用的接口。 想象一下,我们有一个Employee ,它具有两个功能: lunch()和work()因为那是每个Employee所做的,对吧? 我们定义一个协议:可以通过func lunch()和func work() ,我们定义了class […]

如何在macOS中制作标签

开发应用程序时常见的UI元素是标签。 在iOS和tvOS中,此元素称为UILabel 。 可能令您感到奇怪的一件事是macOS没有这样的对手。 相反,我们需要使用文本字段,更具体地说是NSTextField 。 为了保持传统,我们将两个平台的标签实现简单地比较两个世界。 这里没有什么特别的,我们创建标签,给它一个框架,分配一些虚拟文本,将白色设置为背景色,然后告诉标签调整大小以适合内容。 在生产应用中,通常不调用sizeToFit,除非在手动计算元素大小时需要标签的确切帧大小。 我通常会坚持大多数UI实现的约束。 关于iOS / tvOS的知识已经足够多了,让我们开始讨论一下如何在macOS上完成此工作。 我们首先创建一个NSTextField并设置一个框架。 接下来的事情是将文本添加到我们的标签中, NSTextField不提供类似于UILabel的文本属性。 相反,我们需要将stringValue设置为文本字段; 这与NSTextField的继承有关。 它继承自NSControl , NSControl具有与值相关的一堆属性,例如doubleValue , floatValue , intValue等。在处理从NSControl继承的其他类时,要牢记这一点。 如果要从NSTextField中提取文本值,则可以使用相同的属性来实现。 接下来是设置背景色,如果您还记得有关将背景色应用于NSView的文章 ,您会注意到这与该实现有所不同。 NSTextField具有采用NSColor的backgroundColor属性。 分层方法不适用于NSTextField 。 告诉标签为sizeToFit足以使标签显示在屏幕上,但这不会给我们想要的输出。 您会注意到我们在文本字段周围有一个边框,要摆脱它,我们只需将isBezeled属性设置为false和voila 。 现在看起来像是预期的,但是我们需要做的最后一件事是使它充当标签而不是文本字段,并且将isEditable设置为false。 就是这样,我们已经在macOS上创建了与UILabel等效的东西。

自动布局iOS 10.3,Xcode 8.3,Swift 3.1

在iOS应用中,设置UI设计具有多个选项,例如 车架:长 自动调整大小:每次都不正确 自动布局:有约束力,但简单 这是关于根据屏幕尺寸类别设置应用程序行为。 自动布局是关于约束的,每个人都希望将应用设置为通用,但有时对于横向和纵向而言,屏幕显示并不引人注目,因此要使应用极大地使用自动布局,请更改不同屏幕的约束,为此,我们不不必做任何事情,只需添加约束,它就会根据屏幕自动调整预览。 简单添加约束的样本。 然后旋转屏幕,它将看起来像这样。 但是它看起来一点也不好,因此调整约束(对于紧凑的“高度”为“任意宽度”),预览将如下所示。 那么哪个更好呢? 每当我们在iOS 10.x中设置约束时,默认情况下都会自动为所有屏幕尺寸设置(选择约束并在右侧打开属性。 选中时安装,表示默认情况下为所有尺寸等级设置。 如果要针对特定​​的屏幕尺寸删除它,则只需选择约束并单击+号,然后选择要为其删除的尺寸类别选项。 选择尺寸类别(任何宽度和紧凑高度),然后点击添加变化,默认情况下它将被选择。 只需取消选中它,即可不为任何Width和compact Height大小类添加此约束。 现在,没有为任何Width和compact Height大小类设置此约束(如果您不知道大小类,则可以谷歌搜索)。 并且在约束中有多个选择,例如乘数,内容包含优先级和内容抗压缩优先级。 因此,这将帮助您针对任何屏幕模式进行可调整的布局。 我们在下面的流程图中说明了如何为不同尺寸的类别设置约束,这些约束将自动与iPhone和iPad兼容。 作者: Sandeep Yadav | sandeep.yadav@startxlabs.com

WWDC ’17序言:走出我的联盟

我认为冒名顶替综合症完全低估了我对这里的其他奖学金生对自己编程技能的观察的反应。 当他们只投入其他人工作的1/100时,就永远不要让他们缺乏在给定领域的经验,但是无论如何,它仍然可以做到。 在这里,第一个晚上和这里是我见过的应用程序:一个教用户如何在Swift中编写蛇的应用程序,以及一个用户可以与WWDC徽标中的化身进行交互的应用程序。 这是使这两个才华横溢的孩子参加会议的两个应用程序。 两者都是在两周内使用Swift游乐场制作的。 这两个应用程序为这些孩子提供了参加会议的门票,这显然是为什么。 这完全有道理。 没有意义的是我到底怎么参加了会议。 我可能在6个月内每天使用xCode编程2-3个小时。 唯一能记入我名字的应用程序即使是氢氧化钠也是如此基础(化学书呆子适合您)。 我提交给会议的应用程序不过是几个按钮,它们播放了一些自定义的声音循环。 鉴于我的初学者,我没有办法应该在这里。 尽管是成千上万的申请者之一,尽管与其他程序员的经验水平相距仅数年之遥,但我还是获得了奖学金。 我允许世界抛出一些令人惊讶的讽刺作品,但这一事实必须太好了,以至于无法实现。 然而,尽管患有这种几乎残酷的冒名顶替者综合症,尽管我诚实地认为奖学金选择部门的某人把我的名字放在了错误的篮子里,但我将吸收从这个机会中得到的每一滴。 我只需要记住:问很多问题,保持谦虚,闭嘴,这样您就可以从最好的中学到东西。

想要の技术を见学してきました🙋

先周,Wantedly技术见学会に,ブログ枠として参加しました。 想要技术见学会〜iOS编〜(2017/05/31 19:30〜) 概要※参加者多数のため増席いたしました!の会社访问アプリー「Wantedly Visit」* 10… wantedly.connpass.com すでにgetter ・レポートブログなど,たくさんあがっています💁 Wantedly技术见学会〜iOS编〜#WT技术见学会 togetter.com.cn #WT技术见学会| [イベントレポート]想要技术见学会〜iOS编〜に参加してきました! 开发人员 おばんです,一人暮らしを开始してからAmazonのサービスを利用することが増え,今回のWWDC用品を购入する际する急ぎ便が无料になるということだったので势いでAmazon Primeに加入した田中です 。Prime Videoに期… dev.classmethod.jp “ Wantedly技术见学会〜iOS编〜”登坛资料まとめ#WT技术见学会| 通缉工程师博客 先日5/31(水)に,Wanteldyのサービスに使っている技术を绍介する「Wantedly技术见学会」の第1回を実施致しました。第1回は,iOS编ということで,技术顾问の杉上をはじめ,Wan… www.wantedly.com #WT技术见学会|「想要技术见学会〜iOS编〜」に参加しました! 冈美公司 https://wantedly.connpass.com/event/56920/5月31日夜,东京の旺地 #WT技术见学会|「想要技术见学会〜iOS编〜」に参加しました! 冈美公司 https://wantedly.connpass.com/event/56920/5月31日夜,东京の旺地

iOS中的轻量级持久性不应该那么难

简介Shallows —可重用,易于使用的缓存库 我认为您会同意,有时候在iOS中,本来应该很容易的事情变得很困难。 好吧, 不难 ,但是麻烦,不直观,而且绝对没有乐趣。 良好的例子之一是轻量级的持久性。 也许您想在磁盘上保存少量用户数据。 或缓存一些来自网络的信息。 甚至存储图像。 您知道这些事情很容易实现,但您却并非如此。 因为这些事情很棘手。 您将要编写很多代码( LightweightPersistenceManager ,还有其他人吗?),并且有很多事情您可能做错了,而且您的解决方案可能不会那么好或不能重复使用。 那不是你的错 只是在iOS上,轻量级持久性没有自己的抽象级别。 系统解决方案缺乏统一性,灵活性,并且往往向我们公开许多实现细节,有时会使依赖于此的代码不可测试。 Shallows的目标是提供缺少的抽象级别。 首先,这是GitHub存储库的链接: 德雷蒙德/浅滩 浅浅–🛶您的轻量级缓存工具箱 github.com 现在让我们开始吧。 抽象 认识Storage -在Shallows的轻量级持久性世界中,您的主要朋友。 Storage实例是完全抽象的-除键和值的类型外,它们不公开任何实现细节。 存储器可以执行“获取”和“设置”操作,这些操作都是易错且异步的。 让我们看看它们: storage.retrieve(forKey:“ batman”){(结果)在 切换结果{ case .success(让值): //用值做某事 案例。失败(让错误): //处理错误 } } storage.set(gordonImage,forKey:“ gordon”){(结果)在 如果result.isSuccess { //成功设置 } } 我们如何获得一个Storage实例? Storage对象是经过类型擦除的,它们实际上不包含任何逻辑。 但是Shallows提供了以下存储: MemoryStorage NSCacheStorage DiskStorage ,它是一个Storage 最后一个可能是最有趣的。 […]

Swift中Struct和Class之间的区别。

3.初始化方法。 不管是Class还是Struct,如果我们希望在创建实体的时候,可以顺便带入初始值,则Struct其中不需自行编写init方法,当我们去做呼叫的时候,即会呼叫来做初始化属性的动作。 而Class则没有这个功能,所以如果我们希望做到带入初始值,我们必须自行撰写一个init的方式,并且在其中将自身的属性分配给带入的初始值。 这个时候你可能会问,那struct里面可不可以用到init()方法? 答案是可以的,个人觉得会在结构里面再写一次init方式的时候,多半都是为了要去定义外部参数名称(外部参数名称)的时候,才会用到。 这边我顺便插播播一个东西 最初来说,您不能在值类型所定义的方法中去修改其本身所带的属性,例如:struct,enum。因此如果要做这样的修改,就必须在func前面加上mutating,这个关键字的意思就是告诉compiler,我允许这个功能去修改本身自带的特性,在功能运行完之后,本身自带的特性也会跟着改变啦! 大概以上几个的差异,如果还是很容易搞混的话,建议大家可以开一个操场,实际的去体会看看其中的相对~~但是总归一个大方向,构造保存较简单的资料,而类别则是用来储存较复杂的资料与操作这些资料! 以上内容跟大家分享,如果有任何疑问欢迎留言! 图片来自google搜索,如果有犯罪疑虑请来信告知,谢谢!

iOS中的架构模式

在最近的过去,我一直在花一些时间来了解大多数软件开发人员所犯的菜鸟错误。 老实说,我经常被召唤。 但是,我最内gui的一个错误是,在开始项目之前没有计划。 这对我们最好的人来说已经发生了。 从第一天开始,您就可以开始这个令人惊叹的全新闪亮项目。 这个项目的成功,潮起潮落可以这么说。 通常,这种兴奋会击中应该做出合理决策的大脑部分。 因此,您该怎么做,您会立即开始编写代码。 五天后,该项目开始呈螺旋式下降。 您开始想象自己对这个项目的判断有误。 毕竟,这可能不是一个很酷的项目,也许这是一个很好的旧诱饵和转换案例。 但是事实是,您就是问题所在。 这不是项目,从来没有。 该项目保持不变,是您改变了。 💔如果您不计划,那么很可能会迷失其中。 兴奋消散之后,您将得到的只是意大利面条代码。 然后,您很可能会放弃它,或者更糟糕的是,仍然编写可怕的,没有灵感的代码。 现在我们已经大声疾呼了,让我们看一下要计划的最重要的事情之一。 所有冰雹建筑模式! 👯 您问什么架构模式? 它是对常见问题的通用可重用解决方案。 你为什么要关心它? 架构模式使您和您的团队成员的工作更加轻松。 由于关注点分离,因此更容易调试和浏览代码库。 哇! 那是很多单词,没有代码。 现在您仍然在这里,我将为您提供一些代码。 🎉 聊够了,给我看看代码!!! MVC 我们将从这个非常常见但被误解的模式start开始。 MVC已经存在了很长时间。 您知道MVC,这就是隔壁的低维护模式。 如果您已经编写了iOS代码,则可能使用了MVC模式。 这是构建iOS SDK的模式。 这种模式将所有代码分为模型,视图和控制器。 模型; 这是数据所在的位置。 它负责持久性,建模对象和解析。 视图; 这负责与用户进行交互的所有内容,即在屏幕上看到的内容,例如标签和文本字段。 控制器; 这在模型和视图之间进行中介。 MVC示例 如上所示,该模型基本上是对数据进行建模。 在此示例中,它将膳食数据项描述为具有两个属性。 在此示例中,视图和视图控制器紧密耦合。 如果有人要问MVC中的视图和视图控制器之间有什么区别,我会说我不确定。 因此,MVC无法分离关注点 。 由于视图控制器趋于庞大并且几乎无法导航,因此它被命名为Massive View Controller。 […]