Tag: Garima Jain
迅捷代码段＃14 — UIAlertControllerStyle
您可以在这里找到其要点！ UIAlertControllerStyle 第一个扩展位于UIAlertControllerStyle ，它返回特定样式的UIAlertController实例，即– alert或actionSheet 。 所以现在我可以做这样的事情， 让alertController = UIAlertControllerStyle 。警报 .controller（title :, message :, actions 🙂 因此，我现在可以要求一个特定样式的控制器（而不是在UIAlertController的构造函数中传递样式类型） （如果您已阅读以前的摘录或博客文章，现在您可能已经知道我喜欢面向扩展的apis –更加简洁易读）。 串 现在，任何警报还将具有与之关联的一些操作。 因此，下一个扩展名是String因为每个动作都将具有标题，并且它返回UIAlertAction的实例， 让dismissAction =“ Dismiss” .alertAction（） let retryAction =“ Retry” .alertAction {/ *中的_重试逻辑* /} 因此，我现在可以要求在String上使用UIAlertAction ，而不是将标题传递给UIAlertAction的构造函数。 就是这样，现在让我们看一下整个api， 无需创建额外的类，我们已经能够编写如此短的api来构造任何类型的UIAlertController 。 您还可以使用相同的api制作actionSheet。 PS –为了简化起见，我使用了String ，但是如果您不喜欢它，则还可以为不同的动作创建一个Enum并将其扩展为具有类似的行为！ 如果您对 Swift-Snippets 的诞生感到疑惑， 或者想查看更多此类片段，可以在 这里 找到它们 😊
MVVM，您要做一项工作！？
想法💡 在过去的几年中， MVVM在iOS社区中赢得了一定的声誉。 几乎所有其他会议都至少有一个发言。 几乎所有其他博客文章都在谈论设计模式，特别是MVVM（就像这样的：p）。 所有这些表明，它必须非常擅长于其工作。 因此，让我们尝试了解它的实际作用。 动机💪 当我们制作一个iOS（或者您可以说一般而言，任何移动/网络）应用程序时，每个屏幕都具有多个UI组件，例如UIView ， UITextField ， UILabel ， UIImageView等等。这些组件需要自己处理很多工作逻辑。 因此，两者之间紧密耦合的机会很大。 现在耦合不好，因为它 增加了进行UI修改的成本 难以对此类代码进行单元测试 因此，为了使它们分离，我们经常尝试使用一些设计模式来添加一些抽象和模块化 。 这样的模式之一就是MVVM，它是由Microsoft推出的，它代表的当然是Model-View-ViewModel 。 我不会深入研究MVVM的详细信息，因为您一定不厌倦一遍又一遍地阅读它。 相反，我将谈论它所提供的功能以及我们可以在其他地方应用它。 如果您是第一次收听MVVM，那么Microsoft会提供一些非常好的文档，您可以在此处查阅，或者社区中也有很多不错的帖子。 它能做什么？ 🤔 MVVM只有一项工作-它只是将表示逻辑与UI分开。 让我们谈谈这种表示逻辑。 每个UI都需要以一种或另一种形式显示一些数据。 现在，由于数据以原始格式保存，因此无法直接显示。 因此，我们需要对其应用一些装饰性方法，以使其可用于UI。 到目前为止，还不错，但是没有人谈论这些数据从何而来。 它可能来自持久层，或者可能是api调用，或者可能两者兼有。 因此，究竟谁负责获取这些数据。 由于ViewModel是用于装饰数据的“唯一”负责人，因此也许我们可以像一些核心数据助手一样将数据获取逻辑也放入其中，或者可能是一些api逻辑。.aa，我们回到起点，从头开始听起来像控制器。 现在是时候退后一步，只将视图模型保留为表示逻辑了。 关键时刻！ 😲 因为，当我们研究MVVM（或此类设计模式）时，这个灰色区域（即谁获得数据）的定义不是很好，因此我们最终将此逻辑放入视图模型或控制器中。 因此，产生了大规模控制器或如今的大规模视图模型 。 但是没有人说您不能像提取表示逻辑那样提取数据。 因此，我们还应该从MVVM中学习到的是，我们应该抽象出不同的责任性，并将其置于不同的类别中。 只是MVVM没有谈论数据获取，但是我们可以使用导致MVVM的想法，即每个类都承担单个责任是一件好事。 我们可以通过多种方式实现这一目标，尽管现在我仅使用两种简单的方式进行讨论- concrete classes和protocols 。 例子🛠️ 在第一个示例中，我们将看到如何将Datasource注入到UserListViewModel以便我们可以抽象出将数据提取到单独的类中的逻辑，并使视图模型仅使用它， struct User { […]
使用协议和MVVM的可重用视图布局
想法💡 之所以将其命名为“可重用视图布局..”而不是简单地命名为“可重用视图..”，是因为在这里我不是指视图的对象级可重用性。 相反，我将讨论如何在protocol和MVVM的帮助下重用视图布局。 在这个过程中，我将分享我们如何使用一个protocol概述一个视图的界面， 基本不同的配置状态 ，该protocol将使我们能够将不同的view-models注入到一个视图中。 换句话说，这里的想法是设计视图布局的数据不可知模型。 MVVM 在继续之前，让我们先简单了解一下MVVM 。 这是目前最令人困惑的设计模式之一，因此只需要确保我们在同一页面上即可。 这是一种设计模式，其中，我们使视图依赖于称为视图模型的中间模型对象。 这个视图模型获取一些数据（与网络或持久层无关），并应用一些装饰方法，这些方法最终被视图消耗。 例如，如果我们有一个配置文件视图类– ProfileView ，我们可以创建它的视图模型ProfileViewModel进行配置并保存其状态。 class ProfileView: UIView { var nameLabel: UILabel! func configure(with model: ProfileViewModel) { nameLabel.text = model.nameTitle } } struct ProfileViewModel { var nameTitle: String { return “Profile Title” } } 捆绑 我们可以看到，使用MVVM时， ProfileViewModel与ProfileViewModel结合在一起ProfileViewModel进行任何类型的配置。 如果您的视图在整个生命周期中仅具有一种视图模型，则此方法效果很好。 现在，我们要重用ProfileView类，该类应该能够显示Owner配置文件和Guest配置文件。 枚举 为了支持这一点，我们可以将ProfileViewModel转换成一个所有者和来宾情况不同的枚举。 enum ProfileViewModel { […]
