读源码系列(swift2048)-view篇

来源:互联网 时间:2017-01-22


前言

笔者是swift自学新手,希望借助阅读别人开源项目提升自己swift水平。文中将尽量使用文字描述来代替代码的堆砌,建议读者多参考源码,以便更好理解项目。文中难免有错误之处,欢迎各路大牛留言指正。


项目信息

swift-2048 github地址



项目主界面


该项目可以说一个带有实验学习性质的项目,其中部分功能没有实现或不完整。但2048游戏的基本功能均完整实现。笔者将分3篇文章,分别按controller、model、view的进行介绍。


本篇是最后一篇,将重点展开介绍view部分。
以往文章:
第1篇-controller篇
第2篇-model篇


正文

本文将从以下2点展开说明:


文件结构概括
游戏盘view
1.文件结构概括

笔者喜欢先从文件结构看起。该项目的view部分,有下面4个文件组成:


views/AccessoryViews.swift //辅助的views.里面含显示得分ScoreView和用来控制作用的ControlView(未实现也未使用)
views/GameboardView.swift //游戏盘view
views/TileView.swift //棋子view
AppearanceProvider.swift //外观的提供者,按规则显示提供颜色和字体大小

2.游戏盘view(GameboardView)

GameboardView代表游戏盘,TileView代表棋子。



游戏盘和棋子


GameboardView源码中


class GameboardView : UIView {
...
var tiles: Dictionary<NSIndexPath, TileView>
...
}

源码可见,GameboardView是以Dictionary结构来存储TileView。Dictionary中的key,是NSIndexPath,实际运用中将位置坐标x y(或raw col)转成NSIndexPath,例如:


tiles[NSIndexPath(forRow: row, inSection: col)] = tile //设置位置坐标为(row,col)上的TileView

各位移步看TileView的内部:


class TileView : UIView {
...
let numberLabel : UILabel//显示数字的label
var value : Int = 0 {
didSet {
backgroundColor = delegate.tileColor(value)//棋子的背景
numberLabel.textColor = delegate.numberColor(value)//数字的颜色
numberLabel.text = "/(value)"//值
}
}
unowned let delegate : AppearanceProviderProtocol //显示信息委托
...
}

TileView不复杂,UIView中是一个UILabel。然后数字和棋子背景因value不同而不同。显示的规则来自AppearanceProviderProtocol。


protocol AppearanceProviderProtocol: class {
func tileColor(value: Int) -> UIColor //根据值,返回棋子的背景颜色
func numberColor(value: Int) -> UIColor//根据值,返回棋子的数字颜色
func fontForNumbers() -> UIFont //返回数字使用的字体
}

该协议的的实现,按典型的switch-case的结构,有多少情况,只要预先设定好,即可:


class AppearanceProvider: AppearanceProviderProtocol {
func tileColor(value: Int) -> UIColor {
switch value {
case 2:
return UIColor(red: 238.0/255.0, green: 228.0/255.0, blue: 218.0/255.0, alpha: 1.0)
case 4:
return UIColor(red: 237.0/255.0, green: 224.0/255.0, blue: 200.0/255.0, alpha: 1.0)
...
}
}
...
}

那开发者为何使用AppearanceProviderProtocol呢?笔者猜想,这样可以将显示属性(颜色、字体)相关的逻辑从TileView的逻辑中独立出来,便于统一修改和调试。


读过上一篇model篇的读者,会发现这里的GameboardView-TileView与model中的SquareGameboard-TileObject比较相似,但是2者还是有本质上的差别:


相同点:2者都在各自领域(view和model)中,表示游戏盘和棋子
不同点:在model中,SquareGameboard组织TileObject的方式是数组。
struct SquareGameboard<T> {
...
var boardArray : [T]//实际使用过程中,泛型使用TileObject代替
...
}

在view中,GameboardView组织TileView的方式是Dictionary
class GameboardView : UIView {
...
var tiles: Dictionary<NSIndexPath, TileView>
...
}


为何是这样?笔者认为是model和view关注点不同


model关注整个游戏的逻辑,即游戏盘中的每一个有效的位置都要被管理起来。TileObject不仅代表有数字的棋子,也代表空棋子。所以,游戏盘中所有棋子(位置)是连续的,可以用数组表示。
view关注显示,即只关心游戏盘中有数字的棋子(移动、插入等)。TileView只表示有数字的格子,不表示空棋子(空位置)。在游戏过程中,有数字的棋子数量小于游戏盘中棋子位置的总数量,而且棋子与棋子之间没有连续的关系。故而使用数组就不适合了,而采用Dictionary,并用位置坐标(NSIndexPath)做key就比较合理。

查看GameboardView的代码,你会发现GameboardView没有配套的委托协议。
没有委托协议意味着:只存在viewController主动调用(通知)GameboardView,反过来GameboardView不需要通知viewController。进一步讲,GameboardView只负责显示,不负责与用户交互。(看过前面文章的读者应该会记得,该项目的用户交互是由滑动手势发起的)


笔者统计,GameboardView被controller调用的方法是以下4个:


b.reset()
b.moveOneTile(from, to: to, value: value)
b.moveTwoTiles(from, to: to, value: value)
b.insertTile(location, value: value)

除了reset之外,其他3个方法,基本和model的协议是一样的。因为controller就只负责以简单方式通知view(代码上,就是直接调用view的方法)。以移动一个棋子的委托方法为例(model委托的分析,请参见model部分的文章)


 func moveOneTile(from: (Int, Int), to: (Int, Int), value: Int) {//controller实现的model的委托
assert(board != nil)//board就是GameboardView
let b = board!
b.moveOneTile(from, to: to, value: value)// 直接调用view的方法
}

下面是moveOneTile方法:


 func moveOneTile(from: (Int, Int), to: (Int, Int), value: Int) {
...(略,检查参数代码)
let (fromRow, fromCol) = from
let (toRow, toCol) = to
let fromKey = NSIndexPath(forRow: fromRow, inSection: fromCol)
let toKey = NSIndexPath(forRow: toRow, inSection: toCol)
//上面是得到棋子view的key
guard let tile = tiles[fromKey] else {
assert(false, "placeholder error")
}//得到旧位置的棋子(旧位置上一定会有棋子)
let endTile = tiles[toKey]//得到新位置的棋子,可能不存在(单棋子移动分成移动和合并2种情况。只有合并情况才有新位置上的棋子。具体见model篇)
var finalFrame = tile.frame
finalFrame.origin.x = tilePadding + CGFloat(toCol)*(tileWidth + tilePadding)
finalFrame.origin.y = tilePadding + CGFloat(toRow)*(tileWidth + tilePadding)
//旧位置的frame,计算成新位置的frame
tiles.removeValueForKey(fromKey)
tiles[toKey] = tile
//然后在字典中更新,删除旧的,在放进新的
...(略,移动动画和pop动画,有兴趣可查阅源码)
}

用文字说明流程:


1》参数是坐标,转成NSIndexPath,在字典中找到棋子view
2》tiles字典更新,将原来位置的棋子从字典原来位置删除,覆盖到新位置
3》原来位置的棋子view,计算新位置的frame,使用动画移动到新位置。新位子原来的view删除。如果是合并(新位置原来有格子),需要pop动画


另外2个方法也是差不多的套路:
moveTwoTiles 移动2个格子,过程与前面基本一致:


1》参数是坐标,转成NSIndexPath,找到棋子view(2个原来位置的棋子)
2》tiles字典更新:将一个原始棋子view从字典原来位置删除,覆盖到新位置。另外一个原始位置的棋子view从字典中删除
3》计算新位置棋子的frame。然后2个原来位置的棋子,动画移动到新的位置,然后删除一个,只保留一个。并显示pop动画


insertTile 新增格子


1》参数是坐标,转成NSIndexPath。
2》计算frame,创建新的TileView。加入游戏盘view,然后插入字典中
3》动画显示。


总结

笔者经过分析model时的逻辑洗礼,再分析view部分时,头脑就清晰多了。
处理model的委托时,基本就是2步:1》修改保存棋子view的字典。2》移动棋子view


(该项目的view部分还有一些处理逻辑文中没有提到(例如游戏盘背景的显示、棋子动画,得分view等),有兴趣的读者可自行查看源码了解。


非常感谢您的阅读!您的留言、打赏、点赞、关注、分享,对笔者最大的鼓励:P


相关阅读:
Top