App项目实战之路(一):概述篇

我计划做一款App产品,包括Android和iOS,做完打算将Android和iOS客户端的代码开源,并将上架到应用宝和AppStore,之后还会不断迭代。而在做这款产品的过程中,我会尽量将一些相关的思考、决策、心得总结等整理成文分享出来。这个周期将会比较长,因此,文章我将以连载的方式发布。

项目简介

产品定位为垂直于程序猿的社交App。前期的社交性会偏弱,功能上会有点类似于微博。但我打算将发布内容分为两类:问答分享问答类似于StackOverflow的技术问答,程序猿可以发布技术问题,其他程序猿可以提供解答。分享则可以发布程序猿平时的生活趣事、学习笔记和技术文章等。用户关系则打算采用和微博一样的单向关注关系。另外,对每个用户会增加技术栈标签的设置。程序猿可以查看到与自己同技术栈的其他程序猿发布的内容,即使没有关注关系。

整个项目会涉及到原型设计、UI设计、API设计、移动端开发、服务端开发、服务器选型、应用上架,我打算全部自己一个人搞定,至少坚持到完成第一版的上架之后,才再考虑是否邀请其他人加入一起搞。

原型设计我采用墨刀,一款在线的原型设计平台,上手非常简单。网站还提供了视频讲解的新手教程,非常方便。

UI设计我打算采用Sketch,一款专为UI设计而生的工具。据闻可以智能标记字体大小、颜色、间距等。也自带了非常方便的切片工具,可以轻松将一个图标导出为适配Android和iOS的各种尺寸。不过,目前还没上手。另外,目前也正在学习色彩搭配相关的设计知识。

API我打算采用RESTFul架构,分别用POST、PUT、GET、DELETE方法对资源做CURD操作。使用RESTFul的难点在于如何定义好各种资源的表述,即URI的定义。

移动端开发则打算第一版只用原生实现,可能Android和iOS同步开发,即开发完Android的一个页面后,就开发iOS的同个页面。另外,iOS开发打算用Swift,尽量不用OC。

服务端开发打算用Spring Boot,数据库可能选用MongoDB。

服务器选型则还没想好,但应该也是在AWS和阿里云之间选一个。

应用上架,iOS上App Store是必须的了;而Android目前只考虑应用宝,其他市场上不上,到时再决定,这个可以不急。

功能需求整理

App第一版的功能需求,我想最简化,只实现核心功能必需的,其他功能,能不要就不要。最初时,我整理出的功能需求如下:

  1. 手机号 + 短信验证码注册
  2. 手机号 + 短信验证码登录
  3. 微信登录
  4. 上传图片
  5. 修改头像
  6. 修改昵称
  7. 设置用户技术栈标签
  8. 获取同栈之猿的内容列表
  9. 获取关注之猿的内容列表
  10. 获取同栈的用户列表(未有关注之猿时获取)
  11. 发布问题
  12. 发布分享
  13. 关注某条内容
  14. 取消关注内容
  15. 获取内容的评论列表
  16. 添加评论
  17. 回复评论
  18. 点赞评论
  19. 关注某用户
  20. 取消关注某用户
  21. 获取某人详细资料
  22. 获取某人的发布内容
  23. 获取某人关注的人
  24. 获取某人的粉丝列表
  25. 获取我的消息
  26. 提交意见反馈
  27. 退出登录

首先,注册登录我并没有使用密码的方式,而只使用短信验证码。主要是因为登录密码会引发一些麻烦的问题,比如如何安全传输?如何安全保存?2011年的CSDN、天涯、世纪佳缘等网站的“密码外泄门”,和2014年的携程“泄密门”,都证明了直接保存私密信息是不安全的。因此,我干脆不使用登录密码了。而且,因为没有登录密码了,相应的也不需要提供修改密码和重置密码的功能了。

接着,再考虑手机号 + 短信验证码的注册登录方式,其实也有问题:明显依赖于短信平台的稳定性和及时到达率。虽然有些平台提供了免费的短信验证码服务,但这些平台基本存在不稳定的情况,经常会出现收不到短信或隔很久才收到短信的情况。而稳定快速的短信平台都是按条数收费的,这成本有点高。那么,干脆点,取消手机号注册登录的方式算了,只要有微信登录就够了。

另外,因为微信登录后就可以获得用户的头像和昵称了,那么,其实,修改头像和修改昵称的功能其实也可以不需要了。

那么,最后整理的功能需求可以如下:

  1. 微信登录
  2. 设置用户技术栈标签
  3. 获取同栈之猿的内容列表
  4. 获取关注之猿的内容列表
  5. 获取同栈的用户列表(未有关注之猿时获取)
  6. 发布问题
  7. 发布分享
  8. 关注某条内容
  9. 取消关注内容
  10. 获取内容的评论列表
  11. 添加评论
  12. 回复评论
  13. 点赞评论
  14. 关注某用户
  15. 取消关注某用户
  16. 获取某人详细资料
  17. 获取某人的发布内容
  18. 获取某人关注的人
  19. 获取某人的粉丝列表
  20. 获取我的消息
  21. 提交意见反馈
  22. 退出登录

写在最后

目前的进度就是完成了原型设计,并整理好了功能需求。对了,还有设计好了App Logo。接下来要做的就是根据功能需求设计REST API

原文发布于微信公众号 - Keegan小钢(keeganlee_me)

原文发表时间:2016-08-07

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏携程技术中心

携程2015 Open House获奖项目:响应式的蜕变

响应式的蜕变 Ctrip Tech 本文不再从最基本的语法开始行文,而在列举一些最基本的信息之后,开始探讨传统响应式设计的问题,与在实践当中思考出来的改进方法,...

1999
来自专栏知晓程序

收藏级!小程序 10 大最强推广攻略,助你获取微信亿级流量 | 晓运营

1222
来自专栏PPV课数据科学社区

【学习】LinkedIn大数据专家深度解读日志的意义(二)

第二部分:数据集成   请让我首先解释 一下“数据集成”是什么意思,还有为什么我觉得它很重要,之后我们再来看看它和日志有什么关系。 数据集成就是将数据组织起来...

2714
来自专栏沈唁志

PHP技能树—大神的进阶之路

8344
来自专栏软件测试经验与教训

网上看到的面试题,我忍不住吐槽....

3678
来自专栏编程微刊

自媒体运营技巧:如何成功申请今日头条号?

1.7K3
来自专栏程序你好

混合持久化让微服务如虎添翼

1213
来自专栏IT大咖说

VMware云管平台运维管理

摘要 跨 SDDC 和多云环境从应用到基础架构的智能 IT 运维管理。与 vRealize Log Insight 和 vRealize Business fo...

7925
来自专栏ThoughtWorks

前后端分离,谁值得拥有? | TW洞见

今日洞见 文章作者来自ThoughtWorks:贾朝阳,图片来自网络。 本文所有内容,包括文字、图片和音视频资料,版权均属ThoughtWorks公司所有,任何...

3708
来自专栏眯眯眼猫头鹰的小树杈

猫头鹰的深夜翻译:Pattern: Service Mesh

在十几年前,我们无法想象一个分布式系统会是什么样子。它给我们带来了全新的架构思路,但同时也引入了一些问题。 当时这些系统非常少有而且架构简单,工程师们通过尽可能...

1232

扫码关注云+社区