这个开发者账号发布的APP都是你自己的？

1楼 @adad184 是呀。。 不是有什么功能抄袭你了吧？我经常到处“借鉴”～～ ^^

没。。 挺好的 就是那个仿clear有点怪怪的

3楼 @adad184 支持卤煮下，希望卤煮大麦~~~ ps：到时候如果想加广告的话，记得联系我~~ :-D

3楼 @adad184 恩，其实那个还是有点特点的，能保存一份历史记录，查看以往的所有条目。～～ 而且也更轻量，是用完就扔的那种便签。

我自己是这么觉得的。 [流汗]

4楼 @prepostrous 这个有google广告，只是我在后台把广告关闭了，我觉得用户少广告没啥用，还影响使用体验。

美工也自己做的么？

用了下

总体感觉还行。图标可以弄的更好看一点。

提个建议： 1.扫描的时侯不要自动打开闪光灯。

最好默认不开。然后有选择打开的按钮

2.更改扫描条码扫描的按键位置。

我搜了三次书有两次不小心按到扫描了。(;´༎ຶД༎ຶ`)我习惯性的把它当返回按钮了。

6楼 @freecunix 恩，前期是需要养用户的。

7楼 @icodor 恩，美工也自己。。

8楼 @theme ^^ 非常感谢，恩，闪光灯我还没学会那。正在弄。这个版本问题还挺多的。

我正在做：

1:笔记能提交图片。

2:书榜页面，想做成跟随手指翻页，拖动合并边栏。（就和网易新闻一样的）

3:分享到qq，这个刚解决，qq和扫描条码的库冲突。。

哎，不过用户太少了，有点觉得没必要在投入精力的感觉。个人开发太难做了，也没钱推广。现在经济来源几乎100%靠私活，有点想去找工作，放弃了。

11楼 @freecunix 还得推广下。没用户没动力啊。毕竟还是得赚钱啊。要不然没精力和动力去做啊。

12楼 @theme 不知道怎么推广，除了发点帖子什么的，自己搞一稿，没有渠道了。问过刷榜／广告什么的，太贵了，弄不起。

13楼 @freecunix 我也想接私活做，但是不能独立开发，不知能不能合作开发。我的QQ：393893272

赞楼主啊，豆瓣自己的移动端App真的是各种渣，标记这种核心需求居然一直不出App，弄了一堆骗钱的应用。

我其实更想要一个“我听”。。。

14楼 @paulery2014 合作。。除非你有私单分享给我。我自己的都觉得不够做。。

15楼 @大橙子 恩，的确觉得豆瓣自己的app都挺烂的，～～ 依赖别人有个弱点，他不给api就没法实现功能了。而且，担心火了之后会被黑。

我去看看有音乐api没，^^

不错啊，如果有兴趣在北京找项目什么的，可以联系我啊。 （这个不违规吧？）

试用了一下，不错哦。豆瓣自己的笔记做的太水了，到现在也不适配iphone5

18楼 @crope ^^ 有什么项目？

19楼 @sharkaz 恩，就是因为豆瓣太水，我才萌生了自己做一个用的想法。

在iPod Touch(iOS 5.1.1)上下载了试用一下，“在读”列表里随便戳一本书的条目就闪退了。

22楼 @loveisbug ... 最低要求ios6，其实最开始我想只支持ios7来的。

23楼 @freecunix 兼容性是这样写的啊。

兼容性： 需要 iOS 5.0 或更高版本。与 iPhone、iPad、iPod touch 兼容。 此 App 已针对 iPhone 5 进行优化。

24楼 @loveisbug 恩，发布时候选错了，最开始打算支持ios5的。。 新版本还没通过。

我看xcode5都不能ios5模拟器调试了，手上也没有ios5的设备了，就没支持了～

这个项目时间有点长，刚开发时候还是xcode4.x...

24楼 @loveisbug ～～ 忘记调到目标设备ios6了。。

我是新手～ 感觉你的设计蛮好的。不过好像“所有标签”下的各标签无法正确匹配相应的分类。 //插一个截图链接... link text

27楼 @代笔人与抒情体

点击标签，不属于标签的图书会被折叠成窄行，并且不显示图片。

因为豆瓣没提供获取指定标签图书的api，把所有书都拉下来自己匹配的话，收藏太多会超过豆瓣访问次数限制，所以只好用了这个折中的办法。。。

2楼 @freecunix 试用了，设计和流畅度都很赞，留几点建议

1. 底部的标签顺序可考虑调整为在读、想读、读过，以使用频率排序
2. 评价好像没有同步
3. 看到一本可能是我想要的书，我都会先到豆瓣读书查下，我的使用流程基本是：搜索找到书籍条目页面，查看评分、人数和书籍简介，看看目录，看看最有用的书评和书摘，直到决定加入想读（如果可以马上读的就是在读），否则就放弃；当比较闲或者想看某一主题的时候，就浏览想读列表，选择书籍；读过我一般用的很少，基本就是标记一下。另外我没有在豆瓣上添加笔记的习惯（所有不提供数据导出功能的UGC网站都是耍流氓）。
4. 应用里的各种元素都是很全的，就看LZ如何定位自己的产品，依此突出和弱化某些功能的显示，还有各种使用情况下的流程，比如对于未收藏的书籍，最普遍的应该是先显示书籍介绍和用户评论等内容，而后决定是否收藏，移动端是个消费平台（从比例上看，留下笔记的人也是少数），所以最核心的功能应该是浏览书籍介绍（评论和笔记的被阅读量不太清楚，也是一项内容）。
5. 以上是初步使用对产品的建议，方向性的问题，是否有足够多在移动端使用豆瓣读书的需求，至少根据我的使用习惯我更倾向于PC端。
6. 如果这个需求是成立的，产品也改到足够满足这个需求，运营推广有两条路，一种靠口碑，速度慢但是后劲大，一种各种Banner广告，就是要有决心敢投入。（可以参考豆瓣的运营情况）
7. 使用他人的API，风险是难免的，先例很多了，以豆瓣的节操，只要你使用正常的公开API，应该问题不大，为保险可以考虑逐步通过建立自己的体系规避风险。（纯属个人感觉，仅供参考）
8. 有多大的目标，困难、压力、纠结都是相应的，如果最坏的结果自己可以承担，那就可做，当然也要想到最好的结果。
9. 向所有不是只是为了赚钱而做事的人致敬！

29楼 @temberature 非常感谢，正在优化，现在有书评了。其实最想做的是直接下载电子书，但是还没有好的解决方案。。

我怎么感觉日下载量100多 挺多的。。。

30楼 @freecunix 正版电子书可以考虑提供各个平台的链接，多看，豆瓣，字节社等等。

32楼 @temberature 恩，这个对方不开放api的话不好弄。。 除非都是免费资源。

31楼 @王半仙 前段时间上新品推荐日下载有500左右，现在又回到了100多，我觉得app下载500以下基本就算失败了。。

33楼 @freecunix 呃 日下载500？