我猜你正在开发一款 Android 的 V2 客户端，这个帖子是测试发帖和回复用 ;))))))

不会 OC ，只写 Swift 。帮顶！

我网易新闻客户端的昵称就是这样生成的。。。。后院的山楂树。。。

你说的这个问题在 Rails 里面挺常见的，特别是 Rails 的 Model 已经默认实现了数据库的一些基本操作不需要你再自己写。这种时候你就只需要考虑到底是把业务逻辑(Business Logic)放在 Service 层还是放在 Model 层。

一种思路是完全把逻辑放在 Service 里面， Model 仅仅是存数据。这种方法的好处是 Model 层会比较轻，就算是以后某个 Model 变了，比方说以前是 FullName ，现在你需要换成 FirstName 和 LastName ，那对于 UI 层的 Controller 或者 View 来说，这个变化是透明的，只需要 Service 里面把获取名字的函数调整一下就好了。但是这个设计的问题也很明显，就像你说的， Service 层会写很多重复代码，比如明明可以直接 Model.Name 的你就需要用 Service 的方法包装一层。

我个人觉得设计模式从来都不是绝对的，对于某些系统来说这种设计可能很适用，但是对别的系统这种设计很可能就太累赘。比如上面提到这种设计，如果你觉得现在系统处于项目早期，很多 Model 都有可能会进行变化，那么你完全可以把易变的那些逻辑在 Service 里面封装，其它一些你觉得长时间都不会变的，比如某个时间的本地化处理，那么完全可以在 Model 层里面实现。

总之一句话总结就是，程序架构没有绝对，只有适合，一定要根据你目前的项目来决定。而且一开始你可以对这些决定拿捏不准，没有关系，因为经历还浅，就算是高级架构师也不可能设计出永久不变的架构。等你以后做的设计多了，架构多了就知道，哦这种逻辑很可能会变要抽象出来，哦这种逻辑不太可能变化等等。一开始要有自信，敢去设计敢去实现，就算是后面要改也不要怕，改了说明你学习了进步了！

哈哈，这个帖子我也是笑了。。。

有本事就把工资单或者你开的公司报出来。说这么多有啥用，都这么牛逼还天天混 V2 。。。呵呵

@XhstormR 嗯，如果你够勇敢直接用+号也行:)

v23.1.0 好像也可以

@XhstormR 结果是这确实是个 Bug 。。。。看看这里 https://code.google.com/p/android/issues/detail?id=183127 。。。链接里面有解决方法，这个问题在 v24.1.0 里面才修复。。。

@XhstormR apk 有这个问题， nexus 5 真机。估计还是你代码的问题，放出全部来看看吧

@XhstormR 嗯，虚拟机有这个问题。

@XhstormR 试试把 layout_width 和 layout_height （特别是 layout_width)改成 match_parent. 我感觉一开始宽度是 0.

可以用命令行的 xcodebuild 试试。如果觉得打印的东西太杂乱，可以用 Facebook 的[xctool]( https://github.com/facebook/xctool)

直接在 AppBarLayout 下面加上 android:fitsSystemWindows="true"就好了，这个是标准的解决方法。

顶楼主，总有人喜欢总有人讨厌，不要太在意

呵呵， rMBP 都说要大更新了多少次了。。。目测这次也是这些人吹逼的

感觉在手机上学这些有点蛋疼。。。

Apple Store 是用的 price tier 来做。有一张很大的表，价格数值在很长一段时间内是固定的。如果你还要考虑动态汇率的影响，那就要结合一些实时汇率兑换 API ，这种应该一搜一大把

@zhuguangwenhust 感谢分享。不知道他们底层用的是什么技术，是不是 100%准确的呢