我们都为不同的iOS项目做一些特定的UI控件,有时甚至看到可以在其他项目或将来的项目中重复使用的部分。 这是一个很好的机会,可以为我们节省一些时间,并学到新的东西并变得更好。 本文基于我以前发布的iOS控件CircleProgressBar的经验,它在GitHub上有350颗星,安装了2k多个独特的应用程序,下载了254k多个下载,并且此控件仍按预期运行。 我相信这是由于我在将控件公开之前做出的初步决定以及不定期的支持和存储库管理。 为什么要开源? 我确实相信开放源代码,我们所有人都看到许多强大的图书馆和背后的强大社区。 我们大多数人每天都使用许多此类库,例如AFNetworking / Alamofire或SDWebImage。 无需实施自己的解决方案(即使它是“轻量级”的),然后在每次您需要支持新协议或功能(例如缓存)时对其进行扩展,则可以更有效地利用成千上万其他开发人员使用和现场测试的现有库。 但是除了这个伟大的事业之外,我只是想分享自己的代码,我认为这是一次很棒的新体验,一次新的冒险。 我的控制很简单,我认为没有什么可以解决的,不能改善。 我想:“我会把它放出来等待。” 但是我对获得的成果和所学到的东西感到非常惊讶! 这就是为什么我鼓励您自己尝试一下的原因,因为起初很难理解我们可以从中得到什么,但是只有当您开始给予您更多的响应时,您才可以尝试。 何时开放源代码? 我们创建的某些内容并不意味着要共享或很难共享。 我相信您应该问要共享的组件的第一个问题: 为什么有人要使用它? 就像SOLID原则中S代表“单一职责原则”一样,最好是您的库仅解决一个主要问题:处理http请求,管理ftp连接,显示日期选择器等。 像许多Utils库这样的多功能库通常不经常使用,因为大多数开发人员只需要使用“一个字符串操作”,该操作比添加其他依赖项更容易复制粘贴。 只需向任何前端开发人员询问有关JQuery的信息,以及他们如何喜欢它。 尽管它在某些具有特定元素查询的繁重项目中可能非常有用-一些开发人员非常懒惰,以至于他们将其添加为对微型项目的依赖,但是当他们需要的只是简单的getElementById函数时, getElementById可用纯JavaScript。 另外,使您的库尽可能独立也是非常重要的,因为您拥有的依赖关系越多–每次主要iOS版本更新后,人们希望依靠您的库并花费大量时间修复所有内容的人就越少。 当您最终决定要对代码的某些部分进行开源时,无论是控件还是库,都一定要准备一些额外的时间,以便为类和代码最终确定和准备清晰的接口。 如何开源? 现在我们到了最有趣的地方-终于做到了。 依存关系 尽可能删除所有依赖项。 与遵循一系列依赖关系来修复某些问题然后再次更新您的存储库以更新所需的依赖关系版本相比,某些问题更容易在您的存储库中内联修复。 我见过很多次,当某些控件依赖十六进制颜色库获取2-3个默认颜色常量时。 如果使用它来定义常量值,那么具有这种依赖性是没有意义的。 只需将其替换为简单的UIColor(R:G:B:A:)调用即可描述相同的颜色。 为了控制自己,我决定避免任何依赖关系,并且在主要的iOS版本中,我不需要进行任何更新。 该控件只是按预期工作。 因此,除非确实有必要-删除依赖项,并使控件尽可能独立。 我还看到了依赖于某些特定架构(例如MVVM)的不同控件。 控件的创建者在他的项目中使用MVVM或VIPER真的很酷,但是尝试考虑标准的Apple控件库,他们会强迫您使用其MVC吗? 您可以将任何标准的Apple Control与任何体系结构一起使用,那么为什么要为您的控件添加这种依赖关系并减小库的可能客户端的范围呢? 类接口 要为您的库或控件中的类创建一个清晰的界面,请尝试将其视为一个新用户,只希望解决您的控件正在解决的问题。 尝试以这个新来的新用户接触您的图书馆,这个新用户对您需要解决的所有问题一无所知。 尝试考虑什么是最适合此类用户的界面,它将阻止他进入您的代码来学习什么以及为什么。 这可能是一个非常有创意的步骤,我可能无法提供太多有关此信息,而不是分享我的经验。 在我的库CircleProgressBar中,我只想拥有一个进度条,而不是水平填充条可以以圆形方式围绕中心移动。 我假设用户期望可以使用一些熟悉的界面,所以我决定将标准UIProgressView用作类界面的基础。 我实现了相同的方法setProgress:animated:和只读属性progress 。 这里的想法是,您可以简单地用UIProgressView替换InterfaceBuilder中的现有UIProgressView ,而无需更改使用它来更新进度或检查状态的任何代码。 客制化 当您的控件解决了开发人员的问题时,并不需要与每个UI / […]
预习 资源 项目 https://github.com/calmone/iOS-UIKit-component 参考 UIWebView https://developer.apple.com/reference/uikit/uiwebview NSBundle https://developer.apple.com/reference/foundation/nsbundle 快乐编码😄
您将在本演练中制作此应用程序。 首先,您需要下载Xcode,它具有制作iOS应用所需的几乎所有内容。 转到Mac App Store并下载。 步骤1.创建一个Xcode项目 开启Xcode 打开Xcode。 您将看到欢迎窗口。 在窗口中,单击“创建新的Xcode项目”。 在iOS部分中,选择“应用程序”,然后选择“单视图应用程序”。 点击下一步。 您只需要在此关心产品名称和语言。 产品名称 :将其命名为HelloWorldApp 。 机构名称 :您可以将此空白留空。 如果需要,请命名 组织标识符 :使用组织标识符和您的应用名称,Xcode将为您的应用创建一个唯一的标识符。 在这种情况下, com.satorusasozaki.HelloWorldApp是唯一标识符。 将应用程序发布到App Store时,将需要标识符。 语言 :选择Swift。 设备 :您可以选择iPhone,iPad或Universal。 通用都支持。 我们现在将选择Universal。 将所有复选框都留空,因为我们不需要此应用程序。 布局 这是Xcode的基本布局。 所有文件都位于最左侧的区域,称为“ 导航器区域” 。 中间是编辑器区域 。 在右侧的实用程序区域中 ,您可以更改指定文件的设置,并执行一些更详细的操作。 检查点:在模拟器上运行该应用程序。 您可以通过单击设备名称来选择要在其上运行应用程序的设备。 这次选择iPhone 5。 单击“停止”按钮旁边的“播放”按钮。 如果系统提示您“是否在Mac上启用开发人员模式?”,请单击“启用”。 应用程序模拟器启动,您将看到与iPhone屏幕类似的屏幕。 下一步,我们将在此屏幕上构建基本的UI。
加入Essential Developer Academy并观看整集! 在本集中,我们将按照“加载提要用例”的要求开始实现RemoteFeedLoader (API)模块。 如何测试驱动API层实现 模块化设计 单例 :何时何地,更好的替代方案,重构步骤逐步消除由单例产生的紧密耦合 控制依赖项 :查找全局共享实例(隐式)与注入依赖项(显式),依赖项注入 我们有三个主要指南,用于设计和实现RemoteFeedLoader 。 用例中列出的步骤,上一集中定义的功能接口以及测试驱动的开发。 即使RemoteFeedLoader将是实现,我们也不会从遵循协议开始,因为它会要求我们考虑太多。 相反,我们可以通过测试驱动RemoteFeedLoader实现来采取更小(更安全)的步骤。 协议目前只是一个准则(功能接口的一部分),因此我们可以在最后遵循它。 我们继续演示RemoteFeedLoader的合作者RemoteFeedLoader的进化设计。 我们展示了这样的协作者如何可以从具体的单例开始,如何遵循由单元测试支持的详细过程,以确保当我们重构为更加模块化(基于协议)的解决方案时系统的行为不会改变。 HTTP客户端通常被实现为单例,只是因为定位共享实例可能更“方便”。 但是,我们认为,这种方法可能会被视为反模式,因为它会在模块之间引入紧密的耦合。 在我们的例子中, HTTPClient没有理由成为一个单例,因此能够与协作者通信的更合适的解决方案是使用依赖项注入。 然后,我们可以将定位协作者并将其注入到作曲者模块(例如Main)的责任,因此我们可以只专注于在其他组件之间传递消息。 加入Essential Developer Academy并观看整集! 在GitHub上跟踪项目的进度。 现在订阅我们的Youtube频道, 每周收看免费的新剧集。 最初在 www.essentialdeveloper.com上 发布 。 如果您喜欢本文,请访问我们的网站https://essentialdeveloper.com,并获得更多类似的深度定制内容。 在以下位置关注我们:YouTube•Twitter•Facebook•GitHub
因此,在用户登录并有机会熟悉一下您的应用之后,您已经深思熟虑地放置了Apple的推送通知提示,因为您知道在全新安装时显示该提示是有帮助的。 用户点击不允许 。 我们知道加入推送通知对于提高用户参与度的重要性,因此我们可以考虑添加一个预提示来解释启用推送的好处。 事实证明,根据增长工程师John Egan所说,这实际上可能会损害我们的选择率。 我们可以采用一种侵入性较小的方法,而不是在不需要的警报上堆积,并在应用程序设置的第一部分的正面和中心显示推送权限。 尽管我们无法再次显示Apple的提示,但是我们可以引导用户使用其设备上的“设置”。 将一个UISwitch添加到Push Notifications单元中,该开关的状态由UIApplication.shared.isRegisteredForRemoteNotifications的返回值设置。 选中后,我们可以显示我们自己的警报。 从这里,我们可以将用户直接带到UIAlertAction完成块中的常规设备设置。 如果让settingsURL = URL(字符串:UIApplicationOpenSettingsURLString){ UIApplication.shared.open(settingsURL) } 用户将自动导航到“设置”,在此他们可以重新打开通知。 作为一项很好的措施,我们还可以添加一个NotificationCenter观察器,并且当检测到推送通知订阅更改时,重新加载单元格以显示更新的UISwitch状态。 这样一来,推力又恢复了。 通过在设备上自动导航到“设置”,用户不必花时间在应用程序外部搜索应用程序的通知权限,并且我们不必再为每次安装时分配的Apple设置担心。
介绍 随着Swift 5即将发布,人们对其新功能-ABI稳定性有了很多期待。 尽管该消息已广受好评,但人们对ABI的稳定性有一些误解。 在本文中,我将尝试消除一些误解,并解释ABI稳定性将如何永久改变Swift。 什么是ABI稳定性? 简而言之,ABI稳定性意味着Swift标准库和运行时可以嵌入OS本身,而不是随应用程序捆绑提供。 目前,您构建的每个应用程序均随附Swift标准库和运行时的副本,以确保该应用程序可以在不同的OS版本上运行。 在Swift的早期,这曾经是必不可少的,因为作为一种新兴的新兴语言,它易于快速发展和发生重大变化。 但是Swift已经存在了一段时间,并且已经成熟到我们现在可以考虑在操作系统级别集成它的程度。 为了使这成为可能,Swift ABI需要变得稳定,这是对Swift 5的主要关注。 目前,只有Apple OS平台会受到影响,例如iOS和MacOS。 Swift核心团队打算在将来对像Linux这样运行Swift的非Apple平台进行类似的更改。 ABI稳定性的好处 在您的应用程序中拥有Swift标准库的副本具有很大的影响力,因为这会使您的应用程序规模变大。 所有这些都将在Swift 5中进行更改。通过将Swift标准库和运行时嵌入到OS中,可以减小应用程序包的大小,并减少应用程序的下载量。 ABI的稳定性宣称Swift正在成为一种成熟的编程语言。 结果是我们不太可能看到Swift的重大变化。 当您回想起我们从Swift 2迁移到Swift 3时的痛苦时刻,这似乎是一种好处,但有一个警告。 我们将在文章中对此进行进一步讨论。 ABI稳定性的另一个好处是,它将使我们更加接近使第三方Swift二进制框架更加实用—我们将在本文结尾处进一步讨论这一点。 使Swift ABI稳定的尝试并不新鲜 已经有尝试使Swift ABI稳定下来。 ABI稳定性最初是在Swift 3中提出采用的,但最终被推迟了。 Swift 4也发生了同样的事情,因为Swift Core团队已经宣布它是一个艰巨的目标,现在看来Swift 5将实现ABI稳定性。 Objective-C是ABI稳定的,可以预见,因为它是一种更为成熟的语言,并且已经存在了很长时间。 在操作系统级别已经存在一个Objective-C运行时,这意味着Objective-C可以轻松地在不同的编译器版本上运行。 这有助于解释为什么与Swift应用程序相比,Objective-C应用程序具有较小的应用程序下载大小。 但是随着Swift成为稳定的ABI,这可能是促使Objective-C坚持者转换为Swift的动力,因为它将成为一种更可行,稳定和成熟的语言。 ABI稳定性与编译器兼容性有关 二进制文件是已编译的源代码。 ABI或应用程序二进制接口定义二进制文件通过其进行通信的规则。 ABI听起来很像API或应用程序编程接口的工作方式,只是ABI的工作水平很低。 在运行时,Swift程序二进制文件通过ABI与其他库和组件进行交互。 ABI是应用程序二进制接口,或者是独立编译的二进制实体必须符合的规范才能链接在一起并执行。 这些二进制实体必须在许多底层细节上达成一致:如何调用函数,如何在内存中表示其数据,甚至元数据在哪里以及如何访问它们。 本质上,当Swift成为ABI稳定版时,这意味着不同的Swift版本将在OS级别的同一编译器上运行。 因此,Swift 5应用程序和假设的Swift 7应用程序将能够在同一编译器上工作。 您可以将其视为所有未来Swift版本都必须遵循的标准化ABI。 为此,您需要将ABI锁定到将来的编译器版本可以生成符合稳定ABI的二进制文件的程度。 但这会带来重大后果。 […]
Merhaba土耳其语Kitokuyucuları,UIKit serisi ilekarşınızdayız! Bugünkükonumuz UITextField。 Vakit kaybetmedenbaşlayalım😉 Öneri! 请按一下UIButton和UILabel,然后再单击Linklerden bilgi alabilirsiniz。 🤗 UILabel UIButton UITextField Nedir吗? UITextFieldkullanıcıileetkileşimegiren ve genelliklekullanıcınınbir metin girmesiiçinkullanılanUI elementidir。 巴尼尔(GenelBakış) UITextField sadecekullanıcınınmetin girmesiiçinkullanılmaz。 İsterisindebir metin degösterilebilir。 UITextField elementinin文本区域,游标区域背景和背景区域。 UITextField elementini kod veya接口生成器aracılığıylaekleyebilirsiniz。 库兰尼姆·阿兰拉里 Kullanıcıileetkileşimliolan bir uygulamadaçoğuzamankullanıcıadı,soyadı,şifre,yaş,telefonnumarasıgibi birçokbilgikullanıcıdanistenir。 请参见UITextField元素。 UITextFieldYapısı 光标: Yazıalanındakidikey inceçizgidir。 Klavyeden girilen bilginin etkiedeceğiyerigösterenarayüzelemanıdır。 占位符:在UITextField elementin中,请参见UITextField elementin中的内容。 Girşmişbir uygulamayaptığımızdabirden fazla […]
所以我在研究RxSwift,结果发现 “ Rx允许以声明的方式构建应用程序。” 我对此没有给予太多关注,我们称之为“ 范式 ”,因为我习惯了逐步编程(命令式编程)。 我不知道这种情况的存在,也对此一无所知,但是实际上了解编程范例实际上是有帮助的,因此,作为开发人员,当我们进行编码时,我们可以知道应该采用哪种编程范例。 所以,让我们开始吧, 在研究“命令式和声明式编程”时,通常会遇到类似的定义,即, 命令式编程告诉我们如何做,而声明式编程告诉我们我们想发生的事情。 那是什么意思呢? 让我们更深入地了解一些简单的代码片段 声明式编程描述了您试图完成的工作,而没有定义如何执行。 那么,您观察到了什么? 对于第一个命令式编程示例来说,它通常具有更多的行代码,这是非常明显的区别。 另一个是,它明确遵循分步指令以从数组中获取偶数。 在声明式编程方法中,它利用了一个现有函数filter 。 命令式编程提供了灵活性,但带来了复杂性,声明式编程隐藏了复杂性并提供了简单性 应用命令式和声明式编程的编程语言 所以回到我学习RxSwift的研究时, 如果Swift是命令式语言,并且RxSwift允许我们以声明性方式进行编码,那怎么可能呢? 基本上,声明式编程是对函数的抽象,而该函数所基于的则是命令式实现。 这种编程通常更加安全和规范,这使我们的程序员可以编写易于理解的代码。 因此,即使某些语言是必需的,我们仍然可以以声明性的方式进行编码,以便当我们作为团队进行编程时,它使我们能够以更加安全和可扩展的方式进行编码。
上一部分,我们介绍了有关iOS,Swift和好的方法的一般问题。 这部分也相同,但包含之间的所有差异 。 类与结构 2. 枚举-关联与原始 3. 存储属性与计算属性 4. 映射vs过滤vs compactMap vs reduce 5. 转义,非转义,尾随,自动关闭 6. 开放vs公共vs内部vs文件私人vs私人 7. IBOutlet与IBAction 8. 强vs弱vs无主 9. 运营与GCD 10. 应用程式状态 11. 框架与绑定 12. 强制展开vs自动展开vs可选绑定 13. UIViewController生命周期: 14. KVO和KVC 15. CoreData vs SQLite vs Realm 在第3部分中将与您见面,并提供一组不同的技巧和技巧来破解iOS开发人员面试。 编辑: 第3部分 准备好了 !!! 谢谢阅读。 您可以通过以下方式与我联系: https://www.linkedin.com/in/kmuralidharan91/
因此,您已经尝试了一切。 子类化导航控制器,试图在视图控制器生命周期的某个地方(任何地方)压缩一些代码,甚至恢复到在Storyboard中进行某些工作(对于那些以编程方式呈现的人)。 似乎没有任何作用。 到现在。 可以将以下代码片段插入didFinishLaunchingWithOptions函数结尾附近的AppDelegate.swift文件中。 真好! 如果您有任何意见或问题,或者找到另一种设置导航栏颜色的方法,请与我们联系。