Tag: 故事板

在UICollectionView中创建HeaderView

最近，我正在寻找在UICollectionView中创建SectionHeaderView的方法，与UITableView相比，它有点难。 我将逐步向您展示如何在CollectionView中创建标题 首先，您需要创建一个简单的CollectionView。 为此，您可以从互联网上找到很多教程。 以下是创建节标题的一些步骤。 转到情节提要，然后打开该CollectionView的属性检查器，如下图所示>标记“ Section Header”复选框>设置标题的背景颜色任意>在部分标题中添加标签。 2.创建节标题的类， 该类将成为UICollectionReusableView的子类。 代码如下。 FlickrPhotoHeaderView类：UICollectionReusableView { @IBOutlet弱var标签：UILabel！ } 3.转到情节提要>属性检查器>将HeaderView的标识符添加为“ headerID ”>打开身份检查器>添加您的类名（在本例中为“ FlickrPhotoHeaderView”）。 4.转到您的课程以及以下一些代码，如图所示。 添加以上代码后，您将能够创建CollectionView Header。

没有更多的故事板吗？

作为IOS尤其是新手开发人员，情节提要似乎是一条路。 即使对我来说，在IOS开发的最初1.5年中，我100％使用情节提要板。只需拖放插座并在属性检查器中进行编辑似乎比编程方法要快得多。 直到几个月前，一切都发生了变化……在处理我的个人项目时，我尝试导航到情节提要，而Xcode崩溃了。 认为这只是我每天发生的Xcode崩溃，所以我重新打开了项目，并且Xcode在10分钟内都没有响应。 在尝试导航到情节提要板几次失败的尝试之后，我尝试以编程方式创建布局。 从那天起，我再也没有使用过故事板。 前几个小时/天很艰难。 注册collectionViewCell吗？ NSLayoutAnchors？设置RootViewController吗？ 简单的拖放任务，现在需要阅读Apple Docs和StackOverflow来完成。 但是随着时间的流逝，我不仅因为属性检查器而学习了一些理所当然的东西，而且我还了解了所有出口/对象在后台如何工作。 让我的时间变得更有效率。 如果需要在另一个项目中创建相似的布局，则可以简单地复制并粘贴代码，如果需要快速更改约束，则只需搜索文件并进行适当的更改，即使构建项目的速度大大加快。 以下是我不再使用情节提要的5大好处的简短清单。 1.构建项目时的快速编译时间 2.真正理解UIKit 3.创建可重复使用的布局 4. 迫使您了解每个组件的实现 5.没有更多的SIGABRT崩溃！ 🙂

使用无故事板和显示的iOS UI开发– Ivan Jiang –中

使用无故事板和Reveal的iOS UI开发 在这个农历新年假期中，我通过开发一个名为BearFM的简单应用程序学习了iOS开发和Swift语言，这是一个新手。 我是一名前端开发人员，以写JS / TS，CSS和HTML为生。 我对“故事板”一无所知，并且更喜欢通过编程而不是所见即所得的方式来编写用户界面。 在尝试了情节提要之后，我放弃了： 它基于XML，我认为在版本控制中，编码的UI比故事板XML更易于阅读。 如上所述，由于Web开发的旧习惯，用代码编写UI比WYSIWYG 更加安全 ，而且我相信iOS开发人员能够完全控制代码中的UI，但不能完全控制故事板。 @IBAction我对@IBAction和@IBOutlet不太困惑，拖动和连接点确实不是我的事，并且仍然没有找出同时显示控制器和界面生成器的正确方法……由于这两个@IB带有@IB前缀的@IB在编译时不执行任何操作，它们只是提示接口生成器告诉UI和代码之间的关系，因此我让它们走了…… 因此，我使用代码而不是故事板来重写应用程序的某些屏幕，这是大多数教程建议的。 正如我所经历的那样，创建UIView实例，添加子视图和创建约束对于开发人员而言并不困难。 另一个大问题是，如何在运行时知道应用程序的UI层次结构，就像在Chrome Web Inspector中查看DOM一样？ 我还没有在Xcode中找到出路，而是露骨。 与Chrome Web Inspector一样，它是一个了不起的工具，它不仅为我提供了层次结构树，还为我提供了约束，布局警告和错误，这确实有很大帮助。 iOS开发是不同的，但是在某种程度上与Web开发类似，我有很多东西可以学习和娱乐。

没有情节提要，这有什么大不了的？

不，一点也不……实际上，我不想谈论使用情节提要的缺点，我只会告诉您一些不使用情节提要的缺点。 –在源代码管理上不会有大的冲突 ，尝试删除一些属性，然后告诉您的大学更改其边界，颜色等……您将看到冲突是多么令人恶心。 – 可重用性是编码UI而不是绘制UI的最好的方法。 以编程方式创建对象时，可以在需要类似UI的所有项目中的任何地方使用相同对象。 像这样的波纹管…… 现在，我可以在您的iOS项目中的任何地方使用此android单一线条样式，文本字段，它不必是电子邮件文本字段，最后，在现实生活中，您很少会遇到非定制的内容… CLEAN项目结构…看这个真实的项目示例，这是我从事的第一个示例，在我已经困惑的第五个控制器之后。 基本上，您将花费更多的时间来修复情节提要，然后编写代码… 当您使用情节提要启动项目时，它看起来还不错，但是它如何移动并变得更加复杂，导航将变得更加困难，有时我不知道我在使用哪个控制器。 从一开始，仅编写应用程序中的所有UI并不是那么简单，但是您编写的更多代码将使您有种感觉，即您将再也不会将VC拖放到情节提要中了，这就是我现在写的方式，大约四个月不使用它。

iOS i18n：XCode中的情节提要国际化

请注意，默认情况下已选中“ 使用基本本地化”复选框。 如果我们取消选中它，则XCode会询问我们要将可本地化文件移动到的特定语言环境。 在上面显示的对话框中单击“ 移动 ”会将故事板从Base.lproj移到en.lproj 。 这意味着我们的翻译人员必须跳入XCode并直接翻译情节提要，而不是简单地使用字符串文件。 我怀疑这是我们大多数时候想要的，因此我将在此处启用“基本国际化”。 注意» 如果禁用“基本国际化”然后重新启用，则可能必须遍历所有可翻译的故事板，并更改非基本语言的本地化文件类型。 XCode会将那些切换到情节提要文件。 如果需要，可以在检查器中将其还原回字符串文件。 由于我们使用的是基本国际化，因此无需做很多事情来确保我们的字符串（例如标签文本）是国际化/可翻译的。 我们只是从XCode免费获得它。 添加支持的语言环境 我们可以在项目设置中为我们的应用添加支持的语言环境。 我们只需导航到项目设置的“ 信息”选项卡，确保选择了整个项目（而不是特定的目标），然后单击 按钮在“ 本地化”下添加新的语言环境。 选择语言环境时，系统会询问我们是否要对新语言环境使用情节提要或字符串文件。 这将取决于您的项目需求，但是在大多数情况下，我们需要字符串文件，并且默认情况下会选择它们。 自动版面配置和i18n XCode的UI布局系统Auto Layout使用约束使UI视图适应不同的屏幕尺寸，方向等。AutoLayout实际上为我们完成了很多i18n工作。 让我们看看如何。 前，后，左和右约束 默认情况下，针对视图的前缘和后缘设置XCode中的水平约束。 视图的前沿是从左到右的语言布局中的左边缘，而从右到左的语言布局中的右边缘。 仅通过使用后缘和前沿，我们就获得了从右到左语言（如阿拉伯语和希伯来语）的大量支持。 我们可以在XCode的检查器视图中手动关闭此功能。 例如，当我们希望视图与语言方向无关时，这将很有用。 我们只需选择一个约束，打开“ 大小”检查器 ，然后单击“ 第一项”或“ 第二项”的下拉菜单。 然后，我们单击“ 尊重语言方向”选项以将其禁用为活动约束。 当我们这样做时，我们可以看到约束与视图的绝对左边缘有关，而与语言方向无关。 避免固定宽度约束 请注意，该文本在我们的某些应用标签中被截断。 对于i18n来说，这尤其是一个问题。 对于我们的开发语言，标签宽度通常可以很好地工作，但是没有考虑到相同标签的不同语言将具有不同的文本大小。 这可能会导致文本被截断并且信息丢失，从而可能使我们的用户感到困惑或烦恼。 当我们为标签设置固定宽度时，通常会发生文本截断。 我们可以通过删除固定宽度约束并使用尾随和前导约束来固定标签来解决此问题。 让我们浏览一下Open Plant Wiki中的视图并执行此操作。 这解决了我们的截断问题，并可以容纳更多的翻译。 试试看，然后重新运行该应用程序以查看效果。 注意自动版面设计警告 如果我们花时间研究XCode在构建接口时为我们生成的“自动布局”警告，则可以避免上述固定宽度问题。 […]

修复启动屏幕显示的问题

我想您不会花更多的时间，请注意，打开应用程序时会发生这种情况，并且出现绿色，蓝色或红色状态栏。 并在不同情况下发生，例如共享热点，在后台使用位置，致电等。 我发现，如果我们隐藏状态栏，此问题将得到解决。 尝试1 我想使用第一个视图控制器将其隐藏 现在，当启动应用程序时，状态栏将被隐藏，并且启动屏幕将正确显示，而当启动应用程序时，状态栏将再次出现。 希望这对您的项目有所帮助，谢谢。

在情节提要板上创建颜色渐变

大家好，我叫Egor Sakhabaev，这是我在这里的第一篇文章🙂 今天，我将教您如何在情节提要上创建颜色渐变视图。 因此，让我们创建一个GradientView类： @IBDesignableclass GradientView：UIView {@IBInspectable var firstColor：UIColor = UIColor.clear {didSet {updateView（）}} @IBInspectable var secondColor：UIColor = UIColor.clear {didSet {updateView（）}} func updateView（）{}} 好的，我们创建了UIView类的GradientView子类，该子类具有2个属性：firstColor和secondColor。 当@IBDesignable指定应用于UIView或NSView子类时，它使Interface Builder知道它应直接在画布中呈现视图。 这样一来，您无需更改每次构建后即可运行您的应用，即可查看自定义视图的显示方式。 因此，我们需要在视图上应用颜色。 这就是为什么我们创建了updateView（）函数。 让我们继续： 覆盖类var layerClass：AnyClass {get {返回CAGradientLayer.self } } func updateView（）{让layer = self.layer为！ CAGradientLayer layer.colors = [firstColor，secondColor] .map {$ 0.cgColor}} 在这里，我们说我们的图层是CAGradientLayer.self，然后设置我们的颜色。 让我们在Storyboard文件中添加新的View，然后选择GradientView作为类，定义第一和第二种颜色。 开始了： 现在我们有一个垂直渐变视图。 让我们添加新属性isHorizo​​natal并更改我们的updateView函数，如下所示： @IBInspectable var isHorizo​​ntal：Bool = […]

情节提要技巧

今天在浏览另一个示例项目时，我再次注意到与故事板相关的大多数代码伴随着多少字符串文字和强制向下转换。 意识到这一点之后，我决定分享一些实践，使自己的视图控制器和情节提要处理代码更加自觉。 实例化视图控制器 让我们从实例化过程开始：我们依靠文件名来创建UIStoryboard实例，然后使用视图控制器标识符来调用instantiateViewController(withIdentifier:) ，所有这些混乱之后都是强制向下转换为实际类型。 View Controller实例化代码应该更加简洁，这是我要查找的示例： 为此，我们必须避免使用“大量故事板”模式，并将每个流保存在单独的文件中。 完成后，我们可以建立简单的约定，从而使我们可以将所有UIStoryboard内容隐藏在辅助函数中： 仅从代码实例化初始视图控制器。 通过segue访问同一情节提要中的所有其他视图控制器。 使用初始视图控制器类名称来命名相应的情节提要。 对于老式的NIB来说，这是显而易见的，但我们倾向于不将模式与情节提要一起使用。 建立约定后，我们可以轻松地实例化任何仅赋予其类的视图控制器，其他所有内容均以编程方式派生。 辅助功能代码应类似于以下代码段： 我想在这里指出两个棘手的时刻： 我们使用Bundle(for: self)代替nil或Bundle.main从动态框架正确加载资源。 那个怪异的dynamicCast(_:as:)函数帮助我们解决Swift限制，该限制禁止我们将initialViewController as? Self编写initialViewController as? Self initialViewController as? Self 。 执行前者会导致编译错误，指出“ Self仅在协议中可用或作为类中方法的结果可用”。 处理问题 使用情节提要板时查找字符串标识符的另一个受欢迎的地方是prepare(for:sender:)方法。 在这里，我们测试segue标识符和与此相关的向下视图控制器。 像这样： 该代码片段同时采用了两种不良做法：容易出错的字符串标识符比较，然后强制向下转换。 在我看来，在大多数情况下唯一重要的事情是目标视图控制器类型。 在这些情况下，我们可以简单地switch可能的目的地，并fatalError 。 以下代码段显示了它在您的代码中的外观： 感谢您的阅读，希望您在我的帖子中找到了有用的东西。