良好的设计方案帮你轻松实现对话框的设计

　　我们在玩游戏的过程中常常会出现一些对话框，询问我们是否要进行某项操作，本篇教程将告诉你怎样设计实现Cocos2d-x中的对话框。

　　我们时常需要这么些功能，弹出一个层，给与用户一些提示，这也是一种模态窗口，在没有对当前对话框进行确认的时候，不能继续往下操作。在设计如此功能之时，怎么设计比较合理 ~ 是这篇文章要讨论的问题。一叶 不倾向于提供给一个完整的解决方案，给一堆源码。而会靠诉你如何根据你自己的需要去完善它，授人以鱼不如授人以渔 ~

　　功能分析

　　我们设计一个对话框，对话框上有几个按钮(个数可定制)，当然有个标题，会让别人一眼看出它之功用，里面可以有些详细的提示文字，需要是模态窗口，而且窗口的大小可变，这样能够更好的适应不同的屏幕的大小。当然还有一个重要的功能，弹出效果 ~ 虽然从技术角度来说，实现起来并不难，或者说非常简单，但这会以一个很好的用户体验展示给用户。

　　为了使用方面，我将接口设计的尽量简洁，便于使用，如下所示，至于内部的实现，那就随意了，接口函数是暴露在外面的，给别人使用，所以根据需要首先将它定义好，会让你的实现步骤思路清晰 ：

　　从使用方面的角度来说，定义了以上函数，以供外部调用，完成基本的功能需求。当然还有些隐藏的函数，如setContentSize。

　　现在我们在开始下一步设计之前先确定好我们的设计思路：

　　首先onEnter 动态组建弹出层；

　　然后是实现弹出层的触摸优先级，操作要与显示相一致；

　　接着是回调函数的实现；

　　最后则是弹出层的调用。

　　onEnter 动态组建弹出层

　　前文提到过，需要的模态窗口大小是可变的，通过 ContentSize 来获取，如果没有设置 ContentSize ，那么采取的方案是，窗口大小与传入图片一样大，反之，将窗口设定为指定大小。我们知道有很多类似于这样的属性设置修改等，对于完成这样一个功能来说，有两种方式。

　　其一，实时设置，实时刷新，比如在 static PopupLayer* create(const char* gackgroundImage) 的实现里面，创建一个精灵，并设置好图片，添加到当前层，如果调用了 setContentSize 我们再在此方法获取精灵后去修改这个精灵的大小(很显然在本文，并没有实现 setContentSize 方法，但并不影响解说)。

　　其二，保留属性，动态组建。这样一种实现是在 static PopupLayer* create(const char* gackgroundImage) 方法内部，只保存图片的名称，而 setContentSize 也可以只专注于自己的工作即可。最后在一个适当的执行时期，根据以上两个参数，动态创建符合需求的精灵，而这个操作在 onEnter 里尤为合适。

　　再以一个当前用到的例子，来说明 实时刷新 与 动态组建 的区别。看到定义中有一个 addButton 的方法，它是为了可以在当前对话框中添加一个或者几个按钮，而添加几个?当然并不确定，但确定的是，它们的位置会随着按钮个数的不同而不同，如果一个按钮，将居中显示(一分为二)，如果两个(三等份距离)，如果是实时刷新，我们在每一次 addButton 方法里面创建一个新的按钮，还需要设置正确的位置，当然在设置新位置的时候，你需要去判断是否已经存在按钮，还需要修改q前面按钮的位置，可以预见，每添加一次，都需要去实时刷新之前设置过的值，如果代码逻辑简单还好，如果逻辑非常复杂，依赖属性之多，那么那将不好控制。如果使用 动态组建，在 addButton 方面里面我们只需要用一个集合(类似机制)来保存所有的按钮信息，仅此而已，然后在 onEnter 中，读取这些信息，以实时添加按钮至界面之中，而在运行到这里之时，属性基本已经确定了(这里是按钮个数)。只需计算一次各按钮的位置，这样的逻辑处理就相当清晰了 ~

　　可以说动态组建就一定比实时刷新要好么?当然不是。一个采用实时刷新的例子： 在 Cocos2d-x 的 CCControl 的框架中，使用了实时刷新的解决方案，可以在很多地方看到类似 needsLayout() 这样的操作，在设定一个控件的属性之后，需要根据属性更新控件的布局等。

　　对于 实时刷新 与 动态组建 这两种方式，需要根据实际情况来选择，以简化我们的开发，而在文本中，基本是以动态组建的方式设计，因为在弹出层运行之时，所有的属性就已经确定，它没有必要再去根据属性实时刷新。

　　弹出层的触摸优先级，操作与显示相一致

　　-128 是一个有意义的数字，它是 CCMenu 的默认触摸级别，如果我们不使用自带的菜单项，那么对于触摸级别的问题就很好处理了，随便一个稍微大一点的值，即可。但是你需要自己写按钮处理的实现。当然使用 CCMenu 也是有好处的，它封装了非常好用的点击操作。为了简化开发，这里就基于以 CCMenu 作为对话框按钮的操作实现。那么我们的 弹出层 触摸级别改设置为多少?

　　在我们设定触摸级别时，请记住一句话，操作与显示相一致。此话何意?现在设想这样一种情况，我们为了屏蔽弹出层以外所有的层的操作，而将弹出层级别置为 -129 ，这样便保证了它是模态的了(一般而言，除了 CCMenu 的级别，用户自定义也无需这么大)，但是如果当前弹出层上方还有其它的层(也可以是弹出层的父节点上方有其它层，如多层的 UI 设计)，并且其上也有 CCMenu 按钮，那么就出现了显示在 弹出层上放层中的 CCMenu 按钮不能点击，这不科学!实际，在弹出层的 CCMenu 也不能点击，只是我们可以通过将弹出层的触摸消息传递给层中的 CCMenu 解决。所以设置为一味的追求最大的触摸优先级，并不可取，它不能很好的做到 操作与显示相一致，而优先级小于 CCMenu 并不能屏蔽下方的其它 CCMenu 操作，所以对于弹出层本身，它设置为 -128 是合理的，对于同样级别的这些元素来说(弹出层和CCMenu)，能够做到，显示在最上方的优先处理。如果在弹出层上方还有层，是可以点击的，为什么不呢!而我们要做的是，通过逻辑控制，让弹出层节点，最后添加到场景的最上方。

　　对于 操作与显示相一致 的一个解决方案，可以参考一叶的另两篇文章，多层 UI 触摸事件的轻量级设计，和 CCScrollView 实现帮助界面、关卡选择。当然那里并没有用到 CCMenu，而是独立创建了一套规则。

　　回调函数的实现方案

　　由于我们使用了 CCMenu 作为按钮，所以完全可以将 CCMenu 的回调函数，当作参数传入进来，这样处理确实很简单，但是另一个问题，我门需要在事件处理完之后，关闭当前层，那这就不能仅仅如此了，需要进一步封装，将弹出层的按钮回调函数设置为内部实现，然后在 回调给它的上层，之后关闭对话框(关闭的操作由对话框层来完成)，对于回调一般有两种方式，一种是 delegate 回调，这需要定义接口，由上层，继承实现接口，并把自己当作参数，传入弹出层，由弹出层调用 delegate 的接口方法实现，在 Cocos2d-x 里面很多地方用到此方式。而另一种则是 函数绑定，就像 CCMenu 那样的绑定函数。

　　在这里，一叶选择了后者，如果当前弹出层固定一个或者两个按钮，那么我将使用 delegate 来实现函数回调，它会使回调步骤更为清晰，但是，这里设计的是按钮个数可变，功能也不尽相同，使用回调函数，绑定 CCNode 参数，以其 tag 标示，点击的是哪个按钮，当然这里也并不是说使用那种方式是绝对的好坏。delegate 对参数传递来说，更为严谨。 void setCallbackFunc(CCObject* target, SEL_CallFuncN callfun); 的定义是类似 CCMenu 的回调机制，一个 CCNode 作为参数，其 tag 用以标示当前点击的是哪个按钮。

　　弹出层的调用

　　这里一张截图，其中 popup 按钮是个 CCMenu，弹出层中两个按钮也是 CCMenu，而层本身的触摸优先级别也是 -128 ，都是同级，那就依我所言，操作与显示相一致，唯一要注意的是逻辑的控制，什么时候弹出层，由哪个节点弹出层(一般由场景基层来负责)，以保证它显示在最上方。

　　通过以上的讨论实践，完成了对话框的基本模型，它实现了以下功能：

　　一个可以弹出的对话框实现

　　模态窗口的实现(需要逻辑的控制)

　　多按钮的支持，位置自适应，提供回调函数

　　提供标题和内容设置

　　支持 九图 ，控制适应弹出框大小

　　当然还有许多其它并没有照顾到的功能，或者不完善的地方，这就需要用户自己扩展，定制了，如，这样一个层，至少应该是单例的，任何时候只应该存在一个，可以用单例模式实现，对于弹出层的内容方面，这里只有标题和内容，并且标题位置固定，按钮的位置还可以更灵活的设置等。

     好啦，本篇教程到这里就结束了，希望各位同学在看完本篇教程之后有所收获~