@nightar 请给我发一封邮件吧， Google Forms 应该是全部邀请了。你 V2EX 资料中没找到 email 信息

@mornlight
@debiansid

登陆错误我试试能否加上更详细的报错


@zonghua
搜索帖子没有实现，搜索节点肯定是先下载节点列表啊


@chuanP
好的


@dotpig 这个问题我还没有复现过，您是不是越狱了？
我手上只有 iOS 8 的越狱设备。


另外，昨天晚上 11 点之后申请内测的小伙伴，我会在今天中午 12:30 邀请。因为上午在上课 ：），手机上 iTunes Connect 显示不正常。

3. 其他零碎问题

3.1 去掉“工作” @robinlovemaggie @KillAd
可以。但是前面大家的意思似乎是 V2EX 也需要修改掉。

3.2 自动登录 @adminsb
谢谢，三天内会在测试版本加入这个功能。

3.3 实现原理 @cielpy
对，确实是解析 HTML 。没有其他的方式了。

2. UI 问题

由于自己缺乏艺术细胞和积累，设计实在是有很多槽点。


2.1 App 图标： @lizhenda
这个图标是我暑假写代码写到很无聊的时候拿 Paper by 53 画的，自己小学时候虽然学过点简笔画、国画但是都没坚持，现在美术基础基本为零，因此只能画得“抽象”一些啦。


2.2 Status Bar: @Hamniba
谢谢，今晚我就修改！

2.3 Background Color: @amon @comanboy
今晚我就修改为白色背景。

2.4 应用内的图标：@amon
这些 icons 改为与 navigation bar 一样的蓝色如何？或者放浅一些，灰色？

2.5 UI 设计方面的帮助: @sheephe
首先，十分感谢！不过对于合作模式，我们有必要深入探讨。由于今天事情有点多，先给您发送一封简单的邮件探讨。

不好意思，刚下课，集中回复下各位。

1. 名字问题：

@jwenwang
@cyberdak
@kiroli
@shawngao

上课的过程中想了想确实应该取一个独立的名字（ Dribbble 有很多第三方客户端，好像官方明确要求不能叫 Dribbble ）。我考虑了几个备选方案，欢迎继续吐槽：

- Krasus ：《魔兽世界》中一个龙族英雄（克拉苏斯）的名字，自己比较喜欢的角色。因为这些名字比较冷门， App Store 搜索应该还可以。
- Chromie ：同上，是一只青铜龙（克罗米）的名字，《魔兽世界》玩家肯定经常见到她。
- Leo ：狮子座，自己的星座，前两个方案都有版权问题的顾虑（自己不是很懂这个），这个可以不用担心版权问题。

当然只是头脑风暴地一想，还没想到更好的。

@cyberdak 好的，之前没有考虑过这个问题，我会尽快想出个名字。

@jwenwang NEXT ？说实话自己不擅长起名，最近喜欢拿《魔兽世界》里的龙类的名字做项目名。不过觉得作为与几个客户端同时竞争的 app ，起一个诡异的名字，是不是会影响用户认可度。没有关系，等下一步完善之后再发 NEXT 。


@maemolee 支持 iPad 目前在我的计划中，不过目前功能和操作便捷性上还不够，我打算先完善一下这些。

V2EX 又出现股票贴了，赶紧出货

@shuson 我靠，一语惊醒梦中人！我赶紧把 AssistiveTouch 取消了

@clker https://github.com/imWildCat/HappySdufe/releases/tag/1.0.0-beta1

@yyfearth 抱歉，可能拿其他语言的方案来比较有点“关公战秦琼”的味道。但是我的主要意思是站在一个初创团队或者您说的“已经有了成熟的 Web 系统之后需要开发移动 App 这样的情况”。虽然 Xamarin/RubyMotion 面向的是不同语言的开发者，但是无法忽略的一个事实是，这两种方案的资料太少（或者说用户群太小），即使有实现类似 cross-platform 的方案，也不够成熟。我觉得既然打算开发 App 了，肯定不能局限于某种语言（.net / Ruby ），所以我不认同您说的“因为一个是 .Net 一个是 Ruby 主要针对的开发人员不一样”。下面简要说说我为什么不看好这两个方案。

1. Xamarin ： Xamarin 开发分 native 的方式（我记不清怎么称呼这种开发方式）和 Xamarin.Forms 。 native 类似用 C# 包装的原生 API ，学习这类开发还是得去查阅 iOS / Android 官方文档，成本不见得低，而且后期维护成本可能更高。对于 Xamarin.Forms ，我 13 年夏天买了学生版本的 Xamarin Business Plan ，一直希望能用 Xamarin.Forms 来实现自己的 Idea 。自己觉得写足量的 Custom Renderers 就可以获得原生的体验，但是现实不尽人意。抛开语言的因素不谈，私以为 Xamarin.Forms 是可以与 React Native 作比较的， Custom Renderer 正好对应 Native UI Components ， Dependency Service 对应 Native Module 。

2. RubyMotion ： Ruby 是我喜欢的语言，但是对于 RubyMotion ，我最不认同的一点，和 Xamarin 的 native 方式一样，预期调用写好的 wrapper API ，还不如直接写 Java/OC/Swift 。类似 Xamarin.Forms/React 的方式也有社区实现过，但是我之前给官方提问的时候，他们表示官方不会实现这种方式的，参见： https://groups.google.com/forum/#!topic/rubymotion/psWWoGQewCk 。

3. NativeScript 的方式与 RubyMotion 类似。

对上面这些方案的看法，与 http://fex.baidu.com/blog/2015/05/cross-mobile/ 这篇文章的观点类似：

> 可以看到用法和官方 SDK 中的调用方式是一样的，只不过语言换成了 JavaScript ，并且写法看起来比较诡异罢了，风格类似前面的 Hyperloop 类似，所以也同样会有语法转换的问题。

这么做最大的好处就是能完整支持所有系统 API ，对于第三方库也能很好支持，但它目前最大缺点是生成的文件体积过大，即便什么都不做，生成的 apk 文件也有 8.4 MB ，因为它将所有 API binding 都生成了，而且这也导致在 Android 下首次打开速度很慢。

所以，我觉得我拿这些方案对比是合理的，尤其是站在一个初创团队（并没有局限某种语言）的角度上来讲，出发点仅仅是节约开发成本（当然不可避免牺牲一定的用户体验）。

当然，我个人的开发可能比较激进（愤青？），我也经常与某位支持 RubyMotion 的朋友吵得不可开交，谁也不能说服谁。但是我发这个帖子的目的，也算是抛砖引玉，让大家都说说自己的观点，以便他人参考；并不是要评出个一二三来。不过主楼和此楼都是站在楼主的角度讲，难免有失偏颇，请见谅。

我觉得对于我们写代码的，如果要选择一个跨平台方案学习，选择的出发点应该是学习成本比较低（比较常用的语言、文档完善、用户群大，方便搜索）、潜在应用范围大的。至于具体怎么判断，我觉得大家自行思考为好 ：）

@kikyous 不敢苟同，用 Icnic 实现个安卓平台的地图就知道了

作者提得问题我很认同，可是很希望听到您的解决方案。即使是软文也可以啊

老用户有份吗

@huson 现在的 path 还不够模块化吗？具体怎么写才叫模块化？

@huson 是的，那么如何解决呢，不在一个文件中 import * 也不行吗