Tag: Gsoc

在移动文本冒险中为OOC事件创建框架

编码开始：Systers的GSoC 我已经开始上一堂课，为我们的游戏PowerUp处理故事序列。 我认为它更多的是设计挑战，而不是编码挑战。 我想确保它易于使用，并且对其余应用程序功能的影响最小。 我希望其他人认为“嘿，还不错。 我可以为此创建内容并添加它。” 所以这是清单： 应该可以将其添加到应用程序中任何位置的视图层次结构中，并且这样做应该尽可能简单。 序列应可自定义，但数据模型应易于阅读和设计。 繁重的工作将由班级本身来完成。 另一个开发人员不需要三页的Wiki即可实现序列。 这没什么大不了的，但是需要正确地做。 我绝对不喜欢复杂的代码模式，这些模式会使很酷的工具体积庞大且无法使用。 1为了使它易于使用并立即被其他iOS开发人员所熟悉， StorySequencePlayer是UIView的子类。 即使类是控制器，也不必是UIViewController。 该计划是通过将视图呈现为叠加层并在完成呈现内容后使用委托来处理解雇来简化其生命周期。 在外部，唯一添加到现有视图控制器的代码应该看起来很熟悉： //获取模型，初始化并添加到视图 func startSequence（）{ 警卫队让模型= getTheModel（）其他{返回} let view = StorySequencePlayer（代表：自我，模型：模型） self.view.addSubview（view） } //取消最后一步时调用此委托方法 func sequenceDidFinish（发送者：StorySequencePlayer）{ sender.removeFromSuperview（） }

我不喜欢情节提要

公平的警告，这是一个故事，并且是一个咆哮。 有时人们只需要发泄一点，在这方面我可能会高于平均水平。 现在，我正在开发一个开源应用程序，几乎所有视图都使用情节提要。 我认为故事板没有在一段时间内得到处理，而当我第一次打开故事板时，我遭到了很多警告。 …uuuuggghhhhhhhh。 我最初是打开情节提要的，目的是评估支持iPhoneX所需的资源，但是后来我就为iPhoneX支持写了一个GitHub问题，顺其自然。 看，如果我恢复了更改并且再也没有打开情节提要，则无需查看警告。 😺 （我知道我最终将不得不处理它，但这可能是最好的，那时我并没有分心。） 我知道这没什么大不了的，但这根本不是我要处理的事情。 自动布局甚至不是问题。 这就是情节提要如何处理我不喜欢的自动布局。 拖动和调整大小并不总是足够精确。 自动添加约束几乎是行不通的。 而且经常不更改某些元素要求我删除并重做对其兄弟元素的约束。 不用了，谢谢。 测试互动？ 快速迭代？ 在定居之前尝试对不同设计进行一些小的更改时，可能会来回一点吗？ 没有情节提要，您将不会。 需要多个类似的视图吗？ 那么，让我们将十亿个IBOutlets连接在一起，然后等待二十分钟，以打开情节提要。 好，回到故事。 几经周折，我现在需要实际使用情节提要。 是的，我知道它们只是警告。 从技术上讲，我可以打开情节提要，现在暂时将其忽略。 但是我只是……不能 。 所以今天我修复了它们。 这些警告有什么大不了的？ 不。但是正如我想说的那样，这非常容易，而且我现在喜欢情节提要，这不是事实。 也许如果我过去更多地使用它们，那根本就不是问题，但看起来仍然很乏味。 我花了将近一个小时的时间来消除关于固定宽度UIButton的警告。 似乎应该没有警告，但是清理项目或重新启动Xcode都没有摆脱它。 最终成功了吗？ 我将按钮放在固定宽度的UIView中，将其约束设置为相同大小，然后警告消失了。 几何形状完全相同。 从技术上讲，层次结构更为复杂。 但是没有其他限制条件的组合就没有发出警告就达到了我想要的行为。 我只是不想花时间处理这种事情，并且即使该按钮是通过编程方式创建和定位的，即使使用自动布局，我也不认为我会看到这种警告。 我知道我的经历充实了我的见解，但我仍然不喜欢情节提要。 感觉就像我花了更多的时间来创建和布置视图。 它们的加载速度很慢，查看起来很麻烦，在源代码控制方面可能会很痛苦。 导航控制器和segue也很麻烦，尤其是在传递数据时。 我将在必要时使用它们，但暂时我将坚持以编程方式创建视图。 这是其他作者对此主题的更多阅读： 简单，灵活的UIKit布局，无需情节提要或自动布局 为什么我停止使用情节提要和Interface Builder