masonry

昨天主要有两个扯淡的问题. 计算不同设备屏幕宽度的比例, 使用了一个带参数的宏定义, 结果宏定义中的参数, 没有加括号, 结果遇到了一些比较扯淡的布局乱掉的问题, 检查的好久才发现, 这个问题有点隐蔽. 以后多加注意, 使用宏定义作为参数时候, 一定要加括号. 另一个是布局相关的问题, iOS10以前, 有些地方我使用 frame + masonry 混合来布局, 大部分都使用masonry, 局部使用frame还是比较方便的, 结果是, 相关控件, 第二次刷新时候会出问题. 当时也找了很久才发现这个问题. 猜测, 应该是iOS 10中, 混合使用frame+masonry时候, 系统将无法识别到底该用哪种方式布局, 即使设置 view.frame = CGRectZero; 也会被默认认为是有值的. 解决方案: 单独使用masonry或者frame中的一种方式布局界面. 来源： oschina 链接： https://my.oschina.net/u/2501614/blog/755529

Apple 算是最重视应用开发体验的公司了.从Xib到StoryBoard,从Auto Layout到Size Class,每一次的更新,都会给iOS应用的开发带来不小的便利.但是,对于绝对多数iOS攻城狮来说,我们依然还是很害怕写UITabelVIew的自适应布局.当然,害怕不是因为我们不会写,或者本身有什么特殊的技术点,而是因为太麻烦.当然,文章的后半部分,会给出相应的解决方案,毕竟本文不是为了吐槽而吐槽. UITabelView的自适应布局有多麻烦? 数据类型的不确定性:种类越多,页面越复杂. 以网易新闻的客户端为例,可能的数据包括文字新闻,图片新闻,图集,推广,视频等.每一种数据,又根据来源或点击量等细分出许多不同的状态.基本上每种数据类型,都至少需要一种单独的Cell去呈现,每一个Cell的布局,都要单独去写.所以说,数据的类型将直接决定页面本身的复杂度. 数据长度的不确定性: 不确定字段越多,迭代成本越高. 上图取自新浪微博.稍微有点经验的iOS攻城狮,都猜到我要吐槽什么了吧!没错,就是同种数据类型,但是内部字段的长度可能不同,而且还要都要给他们显示出来!其实我也很希望自家的应用都像网易那样,固定长度显示新闻,显示不完,就直接截断--可惜那样的应用都是别人公司的应用.可能你会说: 顶部给个非微博正文区域给个固定高度;文字区域动态计算出高度;图片部分,图片高度固定

Masonry debug 出现错误的地方，加入key就可以在冲突的时候输出相应的信息。 MASAttachKeys(greenView, redView, blueView, superview); [blueView mas_makeConstraints:^(MASConstraintMaker *make) { //you can also attach debug keys to constaints make.edges.equalTo(@1).key(@"ConflictingConstraint"); //composite constraint keys will be indexed make.height.greaterThanOrEqualTo(@5000).key(@"ConstantConstraint"); make.top.equalTo(greenView.mas_bottom).offset(padding); make.left.equalTo(superview.mas_left).offset(padding); make.bottom.equalTo(superview.mas_bottom).offset(-padding).key(@"BottomConstraint"); make.right.equalTo(superview

Trying to not use a jQuery script for a masonry effect so looking to CSS for alternatives. I am trying to use column count, which appears to be working but not as expected. So the columns are there, but sometimes the items in the container are being split across more than one as you should be able to see in this example: http://jsfiddle.net/DTcHh/3858/ #builds { width: 100%; } .cols { -moz-column-count:4; -moz-column-gap: 3%; -moz-column-width: 25%; -webkit-column-count:4; -webkit-column-gap: 3%; -webkit-column-width: 25%; column-count: 4; column-gap: 3%; column-width: 25%; } .item { height:

Masonry 源码： https://github.com/Masonry/Masonry Masonry是一个轻量级的布局框架 拥有自己的描述语法 采用更优雅的链式语法封装自动布局 简洁明了 并具有高可读性 而且同时支持 iOS 和 Max OS X。 我们先来看一段官方的sample code来认识一下Masonry [view1 mas_makeConstraints:^(MASConstraintMaker *make) { make.edges.equalTo(superview).with.insets(padding); }]; 看到block里面的那句话: make edges equalTo superview with insets 通过链式的自然语言 就把view1给autolayout好了 是不是简单易懂? 使用 看一下Masonry支持哪一些属性 @property (nonatomic, strong, readonly) MASConstraint *left; @property (nonatomic, strong, readonly) MASConstraint *top; @property (nonatomic, strong, readonly) MASConstraint *right; @property (nonatomic,

iOS界面布局之四——使用第三方库Masonry进行autolayout布局 一、引言 在前面博客，我们讨论了使用iOS原生的框架代码来进行autolayout布局。在使用中，我们会发现，无论是代码量还是结构的清晰度，都十分不能让我们满意，在storyBoard中只需要几条线就可以搞定的事情，用代码缺要写冗余的一大堆。并且有些时候，故事版并不能解决所有问题，某些控件必须我们手写，这样的话，我们就不得不进行代码的autolayout布局，幸运的是，Masonry可以帮助我们轻松愉快的完成这一任务。 使用代码进行autolayout布局： http://my.oschina.net/u/2340880/blog 。 二、使用Masonry 这里说的大部分内容均来自Masonry和官方gitHub，将其内容进行了翻译和解释，源地址如下： https://github.com/SnapKit/Masonry 。 1、布局的控件属性对照 无论是用storyBoard还是代码，在设置控件之间layout关系的时候，我们都需要设置控件的位置属性。在下面的方法中，这个位置属性就是NSLayoutAttribute对象，他决定的控件对象的参照位置： +(instancetype)constraintWithItem:(id)view1 attribute:(NSLayoutAttribute

写iOS 程序的时候往往需要很多第三方框架的支持，可以大大减少工作量，讲重点放在软件本身的逻辑实现上。 GitHub 里面有大量优秀的第三方框架，而且 License 对商业很友好。一下摘录一下几乎每个项目都想集成的几个框架。 1. Mantle Mantle 让我们能简化 Cocoa 和 Cocoa Touch 应用的 model 层。简单点说，程序中经常要进行网络请求，请求到得一般是 json 字符串，我们一般会建一个 Model 类来存放这些数据。这就要求我们编写一系列的序列化代码，来把 json 转换为 Model 。这很费时间，容易错，不容易修改。 Mantle 很好的解决了这个问题，而且更易用。 GitHub ： https://github.com/Mantle/Mantle 参考： 工具篇： Mantle 源码篇： Mantle CocoaPod 集成： pod 'Mantle', '~> 1.5.4' 2. Masonry IB 时代，如果你还在用代码绝对布局就太 low 了。随着苹果发布 iPhone6 、 iPhone 6 plus 。 iOS 设备将会出现越来越丰富的屏幕尺寸，我们不可能根据每个尺寸做一套布局。所以，使用 autolayout 就很有必要了。在 storyboard 中，可以非常方便的使用 autolayout ，但是为了更好的协作开发

我们组分享会上分享了页面布局的一些写法，中途提到了AutoLayout，会后我决定将很久前挖的一个坑给填起来（还有好多坑就不说了，说了不填更毁形象了）。 可使用的框架首推Masonry，关于为啥选择Masonry看看官方文档就明白了 https://github.com/SnapKit/Masonry ，官方称AutoLayout所有功能Masonry都支持。这次项目界面方面我就全部使用了Masonry。 AutoLayout的一些基本概念 利用约束来控制视图的大小和位置，系统会在运行时通过设置的约束计算得到frame再绘制屏幕 两个属性Content Compression Resistance（排挤，值越高越固定）和Content Hugging（拥抱）,Masonry代码如下 //content hugging 为1000 [view setContentHuggingPriority:UILayoutPriorityRequired forAxis:UILayoutConstraintAxisHorizontal]; //content compression 为250 [view setContentCompressionResistancePriority:UILayoutPriorityDefaultLow forAxis

随着iPhone6/6+设备的上市，如何让手头上的APP适配多种机型多种屏幕尺寸变得尤为迫切和必要。（包括：iPhone4/4s，iPhone5/5s，iPhone6/6s，iPhone 6p/6ps）。 在 iPhone6出现以前，我们接触的iPhone屏幕只有两种尺寸：320 x 480和320 x 568。所以在那个时候使用传统的绝对定位（Frame）方式进行界面控件的布局还是比较轻松的，因为我们只需要稍微调整一下Frame就可以适配这两种 大小的屏幕了。也许这也是为什么虽然AutoLayout从IOS6就已经出现了，但是对于AutoLayout的使用和普及好像都不怎么火热。不过直到 最近随着iPhone6/6+设备的出现，AutoLayout又被众多开发者重新审视和重视了。毕竟APPLE推出AutoLayout就是为了帮助开 发者的APP更方便简单的适配将来不同苹果设备的不同大小屏幕。 首先我们来看一下APPLE官方是如何描述Auto Layout的：Auto Layout 是一个系统，可以让你通过创建元素之间关系的数学描述来布局应用程序的用户界面，是一种基于约束的，描述性的布局系统。所以我们现在要开始摒弃使用传统的 设置 frame 的布局方式的思维来开发视图界面了。因为在 Auto Layout 中，当你描述完视图对象之间的约束之后， Auto Layout