DateTools让NSDate功能更完整,可以让你更容易地去获取日期各个组件的信息,如年 月 日等.
DateTools 可以让你获取距离一个过去的时间点距离当前时间的字符串表示.和Twitter中很像,这个时间字符串有完整形式和缩略形式两种.你可以像下面这样使用:
// 如果工程支持国际化,并且模拟器或真机环境设为简体中文,则会输出:
如果你的工程支持国际化,DateTools
现在会自动支持以下语言的本地化:
使用 DateTools 可以很容易地获取日期对象的某一组成部分:
如果你不想使用公历,可以这样做:
DateTools 提供下列方法,比较两个日期的大小,返回结果为一个布尔值:
类似yearsFrom:
用于日期比较的方法包括:
已知开始和结束时间,可以使用下面的方法初始化时间段对象:
或者,已知起始或结束时间,同时知道时间段的总时长,可以用类似下面的方法创建时间端对象:
// 创建一个时间段,从现在开始,共5个小时.
可以通过 DTTimePeriod 的实例方法来获取时间段的相关信息:
可以对时间段进行移动,延长或缩短的操作.
当一个时间段被移动时,起始时间和结束时间会相应地同步迁移或推后.可以使用下面两个方法移动时间段:
可以通过保持起始点/中间时间点/结束时间点不变,然后改变开始或结束时间点,以得到延长或缩短时间段的目的:
// 通过前移起始时间,把时间段总时长从1分钟变为2分钟.
可以使用DTTimePeriod
的关系操作相关的方法,来判断两个时间段的相互关系,如是否包含,是否是同一段时间等.
下图表格列出了两个时间段所有可能的关系:
可通过下列方法判断两个时间段的关系:
你可以通过下面这个方法获取相对于另一个时间段的关系:
点击示例中 Time Periods 按钮,然后滑动滑块,可以更好地掌握时间段之间的相互关系
这两个时间段集合类,操作和 NSArray 很像.你可以添加,插入和移除 DTTimePeriod 对象,就像你在数组时的那样.唯一的不同是,两中集合存储时间段的方式.
DTTimePeriodCollection
和DTTimePeriodChain
,是为了简化基于多个时间段的逻辑处理.比如同一团队中,给不同的人设置任务的起始和结束时间,此时如果使用 DTTimePeriodCollection 来处理各个时间段,可以直接得到团队总任务的起始时间和结束时间.
DTTimePeriodCollection 是一个规则相对宽松的集合.默认无序(指的是顺序和各个时间段的起止时间无关.),但支持手动排序;拥有自己的属性,比如基于内粗存储的时间段计算出的此集合的开始时间和结束时间.这个结合允许存储有交集的时间段.
// 把时间段添加到集合中. // 从集合中获取时间段.
有三类给集合内时间段排序的方法:
也可以去获取一个 NSDate 对象或一个 DTTimePeriod 对象与一个 时间段结合的相对关系.例如,你可以通过 periodsIntersectedByDate: 方法获取所有与某个时间有交集的时间段.这个方法会返回一个新的 DTTimePeriodCollection 对象,里面包含所有符合条件的时间段.
有许多类似的方法,如下图:
DTTimePeriodChain 以较为严格的方式存储时间段对象. DTTimePeriodChain集合通常依据开始和结束时间存储时间段对象,并且有自己的属性,如 根据内部存储的时间段对象推断出来的此集合的开始时间和结束时间. DTTimePeriodChain 内部存储的时间段对象不允许有交集.这种集合很适用于连续会议或约会等日程类事务的建模.
// 添加时间段对象到集合中. // 如果后存入的时间和前一个存入的时间无法前后完全衔接,则后一个时间会适当前移或后移,以使前后时间段紧凑. // 获取集合中的元素.
新加入的时间段,时长不变,起始时间变为前一个时间段的结束时间,结束时间对应前移后后移.在非零位置新插入的时间,其后的时间段相应后移.在零位置插入的时间,集合的起始时间前移.操作图解如下:
这是一篇可能略显枯燥的技术深度讨论与实践文章.如何把设计图自动转换为对应的iOS代码?作为一个 iOS开发爱好者,这是我很感兴趣的一个话题.最近也确实有了些许灵感,也确实取得了一点小成果,和大家分享一下.欢迎感兴趣的iOS爱好者能和我一起研究讨论!
我觉得,如果真的能把一张设计图自动转换为代码,任何开发工程师都会感兴趣的.单以 iOS 应用为例, 在一个最常用的MVC架构的APP中,主要的代码,无非就是集中于: M 的网络请求部分, V的数据显示部分, C的逻辑交互部分.对于controller控制器层,往往需要结合业务逻辑去处理,代码量并不算大;对于Model数据模型层,我们有 , , 等,可以大大简化网络接口到数据模型的转换;对于View视图层,代码最繁杂,最枯燥无趣,迭代最让人头疼的部分,又有什么可以凭借呢?我没有详实的数据统计来确认各个iOS开发者的日常开发中,MVC各个层面,具体的时间成本如何;单从我个人角度来说, View布局的拆分与转换,占据了我 70% 以上的时间.我们公司通常是按单个完整任务来拆分工作的,单个任务的MVC三层,都是应该由一个人独立完成.每次都把大把时间浪费在"画UI"上,真的感觉好无趣,好浪费生命;临时遇到产品经理改动需求,可能一个对方看似更加"合理"的改动,我这边几乎要大动干戈!我想我对编程本身确实是感兴趣的,但是整天浪费时间在 UI上,真的感觉有点虚度光阴.所以说,在本不充裕的空闲里,我一直在思考的一个命题就是: 如何实现 UI 的自动化与独立化.
尽管作为一名iOS开发人员,我依然对苹果公司提供的开发技术及其发展方向持谨慎和保守态度.前一段时间,尝试使用 Xib来布局视图,遇到一些坑,但是熟悉之后,也确实比原来单纯基于绝对位置的纯代码布局更灵活些,也更快捷些.在此期间,我研究的一个重要话题就是如何实现Xib之间的嵌套复用,即在一个Xib上如何直接嵌入另一个Xib.乍听起来很简单,但是在亲身实践之后,才发现其难度.我不是来吐槽的,个中曲折不再一一赘述,下面是我研究的成果:
上图,是一个Xib模块,其中的色块部分,嵌套的是另一个Xib模块.最终显示是,色块会自动被对应的Xib模块替代.
* 可复用组件.用于编写可嵌套的 xib 组件. * 适用场景: 需要静态确定布局的页面内的UI元素的复用性问题. * 子类需要继承此方法,以完成自定义初始化操作. 不要手动调用此方法. * 子类可根据需要,具体实现此方法. * 便利构造器.子类应根据需要重写. * 子类应根据需要重写此方法.默认不做任何处理. * 是否从xib初始化此类. * 注意: 无论此类是否从xib或sb初始化,组件内部都将从xib文件初始化. // 这一句,是区别初始化方式后的,核心不同. /* 子类需要继承此方法,以完成自定义初始化操作. */ /* 子类根据需要,自行实现. */ /* 子类应根据需要重写这个方法. */ /*子类应根据需要重写此方法.默认不做任何处理.*/ /* 子类应根据自己需要,重写这个方法. */此策略已经在我们的项目中试用了一段时间,也已经填了些坑,多次优化,感兴趣的可以直接拿过去用.但是,基于XIB的视图模块化,终究还是需要手动的参与,对工作效率的提升也似乎达到了一个极限:因为它终究需要人工深度参与.关于它的讨论,暂时到此为止.
,是一个基于纯代码的AutoLayout库.初次涉及时,只是感觉它很方便,既有Xib的易读性,又有纯代码的灵活性.试用一段时间之后,突然想到: 或许借助masonry,建立一个纯代码的不依赖Xib的AutoLayout视图组件机制.
以上代码,是整个代码的核心,其巧妙之处在于:不使用constant,而是使用比例来指定约束.选取的是 width,height,right,bottom,而不是其他属性,其巧妙之处,大家试用下其他属性就知道了.
这个示例,取材自网易新闻.图示中已经标注了单元格的宽高,单元格内各个UI元素的width,height,bottom,right.此处UI设计师可根据屏幕尺寸出图,我们根据一份跟定的设计图,直接使用 (一个非常好用的标准工具)丈量标记即可. 因为我们是基于比例来添加约束,不同屏幕下,会自动等比变换.
这是一个简单的示例,为了方便演示,临时加上了:
这是运行时,我们看到对应属性,确实与UI元素关联了起来.
这是与数据结合之后的效果图.只是个初稿,还需要进一步调试.也就是说,以后再写UI界面,你的注意力将可以集中在 数据与视图本身的交互处理上.
我在此文着重分享了我目前正在研究的 基于masonry的视图模块化方案.在以后的工作和学习中,我会继续使用与完善,以期进一步提高写UI界面的效率.可能尚有不完备之处,欢迎大家共同提出讨论.