作者归档:兲宇

iOS9中Htmlparser里CFStringGetCStringPtr方法的兼容性问题

把系统升级到 iOS9 以后  现在的项目里里使用Htmlparser 去解析 Html 文本发现乱码,跟踪代码到:

-(id)initWithString:(NSString*)string error:(NSError**)error 里

调整编码无效,最后发现是由于iOS9中“Tagged Pointer NSStrings” 造成的,具体的原因如下所示

Tagged Pointer NSStrings

Starting with iOS 9 certain strings (ones with a suitable length and encoding) on 64 bit architectures will now use a “tagged pointer” format where the string contents are stored directly in the pointer. This matches behavior introduced on OS X in 10.10 Yosemite.

Similarly to the OS X targets, passing a tagged NSString to functions such as CFStringGetCStringPtr or CFStringGetCharactersPtr will return NULL in cases where it may not have before. As before it is important to check for the NULL return value and use the corresponding buffer fetching function:

<tt>char buffer[BUFSIZE];
const char *ptr = CFStringGetCStringPtr(str, encoding);
if (ptr == NULL) {
    if (CFStringGetCString(str, buffer, BUFSIZE, encoding)) ptr = buffer;
}</tt>

In addition, this change enables index and range checking to be performed more often when working with strings. So you may see runtime exceptions due to this change. In almost all cases these exceptions point to bugs in code, so please take them seriously.

This change will also break any code which treats NS/CFStrings objects as pointers and attempts to dereference them.

 

所以修改程序

-(id)initWithString:(NSString*)string error:(NSError**)error

{

if (self = [super init])

{

_doc = NULL;

 

if ([string length] &gt; 0)

{

CFStringEncoding cfenc = CFStringConvertNSStringEncodingToEncoding(NSUTF8StringEncoding);

CFStringRef cfencstr = CFStringConvertEncodingToIANACharSetName(cfenc);

const char *enc = CFStringGetCStringPtr(cfencstr, 0);

char buffer[255];

if (enc == NULL) {

if (CFStringGetCString(cfencstr, buffer, 255, kCFStringEncodingUTF8)) enc = buffer;

}

 

// _doc = htmlParseDoc((xmlChar*)[string UTF8String], enc);

int optionsHtml = HTML_PARSE_RECOVER;

optionsHtml = optionsHtml | HTML_PARSE_NOERROR; //Uncomment this to see HTML errors

optionsHtml = optionsHtml | HTML_PARSE_NOWARNING;

_doc = htmlReadDoc ((xmlChar*)[string UTF8String], NULL, enc, optionsHtml);

 

}

else

{

if (error) {

*error = [NSError errorWithDomain:@"HTMLParserdomain" code:1 userInfo:nil];

}

}

}

 

return self;

}

增加加粗部分

 

项目开发规范

开发规范

IDE

大家在开发过程中尽量使用PHPStorm工具,有利于减少沟通以及IDE不同造成的误差。

 

代码开发

 

注释规范

注释是编程中重要的一部分、以PHPDoc的规范为标准、便利于直接生成技术文档。

 

 

接口规范

功能分为两大部分:搜索功能和问答功能

使用接口方式、也就是后台开发中共用统一提供APP和前端一套接口

接口统一使用JSON格式返回、如:

[

    {

        “created_at” : “Tue Nov 30 14:34:35 +0800 2010”,

        “text” : “吃力不讨好的事情我是坚决不会再做了,RI你个仙人!发飙~~~~我只想说档次和素质在那里去了,你也就只能在这种地方混!“,

        “truncated” : false,

        “in_reply_to_status_id” : “”,

    },

]

 

格式的定义如下表所示:

项目

说明

API

get_cs_address.php

URL

http://rootcs.freepp.com/rootcs/2.0/get_cs_address.php

Param

 

POST提交。

l mobile: 本机的Mobile号码,E.164格式(必填)

l cc: 国码,不带加号(非必填)

注:cc为非必填项。

Error Code

(操作失败)

22000:系统维护中(此时,一并返回 pmsid=1),客户端停止后续的注册动作。

22002:非法的E.164号码(没有以+开头)

22999:参数错误

Return

(操作成功)

返回值类似CS的返回值格式,为多行的key=value格式。

l cs: 分配的CS地址,可以是ip地址,也可以是域名。

l otherreg:是否采用纯语音认证。0:否;1:是。

注:otherreg参数,在最新版本中,已经被废弃。

 

该文档也由同时开发人员共同维护维护。

错误代码说明

错误码格式为:

{

“error” : “20502”,

“msg” : “Need you follow uid.”

}

 

错误代码的具体规范:

错误代码分为两种:

系统级错误:表示系统级别的错误如系统错误、GET请求的参数超长等。具体规范是由10开头的共5位数字、如1000110002、末尾数字1开始逐渐自增。如下图所示

 

系统级错误

 

另外一种是服务级错误、表示具体某项业务中发生的错误。具体规范是由20开头的共5位数字、如2000120102。第三位表示具体的业务类型。0为基础类型、表示业务中一些基本用到的错误如用户不存在、图片过大等。假设1可以为问答、如问题不存在这样的内容。

 

 

服务级错误

 

错误代码文档由所有开发人员共同维护、当增加错误代码时增加在编码处并进行更新,让所有开发人员获知。

达邻项目前端开发规范

书写规范

HTML规范

1、所有标签必须嵌套规范,不允许出现内联元素内部嵌套块级元素(因为设计到手机开发,a标签内可以嵌套块级元素)

2、嵌套规则必须明晰,不能有多余嵌套,可以做多层嵌套调整兼容性

3、类名和ID必须明确,不公用的需用ID,公用的需用类名

4、注释必须,必须在所有页面模型前使用注释,注释需表明此模块的开始和结束。

LESS规范

因为本项目使用LESS开发,所以需要项目中的人熟悉LESS语法

1、公用的混合全部放在/less/framework/mixin目录下,同类的混合放在同一个文件中

2、合理使用嵌套规则,不应该有深层的嵌套

3、公用的变量文件,全部放在/less/framework/variables文件中

4、自己的less文件放在/less目录下,所有的项目需要包含在less/style.less文件中

5、每个模块需要创建一个less文件,less文件不应该过大

6、注释,每个less文件需要说明模块的详细信息,和作者信息,每个嵌套开始和结束加上注释

CoffeeScript规范

因为本项目使用CoffeeScript开发,需要遵循CoffeeScript开发规范

1、所有函数后必须有return,不返回值则return;如果需要返回最后一行则不用书写return

2、方法与方法间需要隔开两个空行

3、函数的回调不能过深,如果过深,需要拆解回调

4、注释必须明晰,每个函数需要标明返回值,返回类型,参数类型和参数值

 

 

命名规范

1、css类名规范以下划线为标准,如main_content,main_container,div_1,div_2,不使用驼峰。

2、cssID名以驼峰为准,如mainContentmainContainer, divFirst.divSecond

3、CS调用页面上为JS预留的接口,尽量不调用类名和css ID名,JS预留接口为ID名,如:JsMainContent,JsMainContainer

4、CS变量命名为驼峰命名,函数内部的临时变量命名为 开头, 如:_height,_width

5、CS常量命名为全大写,如:MAIN_WIDTHMAIN_HEIGHT

6、CS对象命名,首字母大写,如:Main

 

文件命名规范

文件命名必须清晰,明了,明确知道该文件的作用,所有文件遵循项目结构,使用驼峰式命名规范。

 

所有开发必须遵循以上的开发规则

Log定义和规范

一个项目各个log级别的定义应该是清楚明确的,是每个开发人员所遵循的;
即使是TRACE或者DEBUG级别的日志,也应该有一定的规范,要保证除了开发人员自己以外,包括测试人员和运维人员都可以方便地通过日志定位问题;
对于日志级别的分类,有以下参考:

FATAL — 表示需要立即被处理的系统级错误。当该错误发生时,表示服务已经出现了某种程度的不可用,系统管理员需要立即介入。这属于最严重的日志级别,因此该日志级别必须慎用,如果这种级别的日志经常出现,则该日志也失去了意义。通常情况下,一个进程的生命周期中应该只记录一次FATAL级别的日志,即该进程遇到无法恢复的错误而退出时。当然,如果某个系统的子系统遇到了不可恢复的错误,那该子系统的调用方也可以记入FATAL级别日志,以便通过日志报警提醒系统管理员修复;

ERROR — 该级别的错误也需要马上被处理,但是紧急程度要低于FATAL级别。当ERROR错误发生时,已经影响了用户的正常访问。从该意义上来说,实际上ERROR错误和FATAL错误对用户的影响是相当的。FATAL相当于服务已经挂了,而ERROR相当于好死不如赖活着,然而活着却无法提供正常的服务,只能不断地打印ERROR日志。特别需要注意的是,ERROR和FATAL都属于服务器自己的异常,是需要马上得到人工介入并处理的。而对于用户自己操作不当,如请求参数错误等等,是绝对不应该记为ERROR日志的;

WARN — 该日志表示系统可能出现问题,也可能没有,这种情况如网络的波动等。对于那些目前还不是错误,然而不及时处理也会变为错误的情况,也可以记为WARN日志,例如一个存储系统的磁盘使用量超过阀值,或者系统中某个用户的存储配额快用完等等。对于WARN级别的日志,虽然不需要系统管理员马上处理,也是需要即使查看并处理的。因此此种级别的日志也不应太多,能不打WARN级别的日志,就尽量不要打;

INFO — 该种日志记录系统的正常运行状态,例如某个子系统的初始化,某个请求的成功执行等等。通过查看INFO级别的日志,可以很快地对系统中出现的WARN,ERROR,FATAL错误进行定位。INFO日志不宜过多,通常情况下,INFO级别的日志应该不大于TRACE日志的10%;

DEBUG or TRACE — 这两种日志具体的规范应该由项目组自己定义,该级别日志的主要作用是对系统每一步的运行状态进行精确的记录。通过该种日志,可以查看某一个操作每一步的执行过程,可以准确定位是何种操作,何种参数,何种顺序导致了某种错误的发生。可以保证在不重现错误的情况下,也可以通过DEBUG(或TRACE)级别的日志对问题进行诊断。需要注意的是,DEBUG日志也需要规范日志格式,应该保证除了记录日志的开发人员自己外,其他的如运维,测试人员等也可以通过DEBUG(或TRACE)日志来定位问题;

Rule 1:整个团队(包括运维人员)需要对日志级别有明确的规定,什么日志记入什么级别的日志,什么级别的错误出现要如何处理等。

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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
&lt;?php
/**
 * Log组件使用示例
 */
class LogController extends Controller
{
    //获取基本信息
    public function actionIndex()
    {
        $this-&gt;render('index');
    }
    
    //写trace日志
    public function actionTrace()
    {
        Mod::trace('This is trace log', 'application.controller.log');
    }
    
    //写基本日志
    public function actionLog()
    {
        Mod::log('This is a log', CLogger::LEVEL_INFO, 'application.controller.log');
        Mod::log(array('code'=&gt;205, 'msg'=&gt;'This is a warning'), CLogger::LEVEL_WARNING, 'application.controller.log');
        Mod::log(array('code'=&gt;305, 'msg'=&gt;'This is a error'), CLogger::LEVEL_ERROR, 'application.controller.log');
    }
    
    //写profile日志
    public function actionProfile()
    {
        Mod::beginProfile('loop', 'application.profile');
        for($i=0; $i&lt;3; ++$i)
        {
            Mod::beginProfile('sendData', 'application.profile');
            $this-&gt;sendData();
            Mod::endProfile('sendData', 'application.profile');
        }
        Mod::endProfile('loop', 'application.profile');
    }
    
    private function sendData()
    {
        usleep(100000);
    }
}

PHP编码规范

一、文件格式

1. 对于只含有 php 代码的文件,我们将在文件结尾处忽略掉 “?>” 。这是为了防止多余的空格或者其它字符影响到代码。
2. 缩进应该能够反映出代码的逻辑结果,尽量使用四个空格,禁止使用制表符TAB,因为这样能够保证有跨客户端编程器软件的灵活性。
3. 变量赋值必须保持相等间距和排列。
4. 每行代码长度应控制在80个字符以内,最长不超过120个字符。
(因为 linux 读入文件一般以80列为单位,就是说如果一行代码超过80个字符,那么系统将为此付出额外操作指令。)
5. 每行结尾不允许有多余的空格。

二、命名约定
1. 类文件都是以“.class.php“为后缀,且类文件名只允许字母,使用驼峰法命名,并且首字母大写,例如:DbMysql.class.php 。
2. 配置和函数等其他类库文件之外的文件一般是分别以“.inc.php“和”.php“为后缀,且文件名命名使用小写字母和下划线的方式,多个单词之间以下 划线分隔,例如config.inc.php , common.php,install_function.php 。
3. 确保文件的命名和调用大小写一致,是由于在类Unix系统上面,对大小写是敏感的。
4. 类名和文件名一致(包括上面说的大小写一致),且类名只允许字母,例如 UserAction类的文件命名是UserAction.class.php, InfoModel类的文件名是InfoModel.class.php 。
5. 控制器类以Controller为后缀,例如 UserController、InfoController ,模型类以Model为后缀,例如UserModel、InfoModel ,其他类也分别以相应分类为后缀,例如Service 、Widget。
6. 方法名只允许由字母组成,下划线是不允许的,首字母要小写,其后每个单词首字母要大写,即所谓的 “驼峰法命名” 规则,且越详细越好,应该能够描述清楚该方法的功能,例如switchModel、findPage。
7. 属性的命名只允许由字母组成,下划线是不允许的,首字母要小写,其后每个单词首字母要大写,即所谓的 “驼峰法命名” 规则,例如tablePrefix、tableName 。

三、编码风格
1. php 代码必须以完整的形式来定界( 2. 当一个字符串是纯文本组成的时候(即不含有变量),则必须总是以单引号(’)作为定界符。例如$a = ‘Example String’;
3. 变量替换中的变量只允许用 $+变量名 的形式。例如:
$greeting = “Hello $name, welcome back!”; // 允许
$greeting = “Hello {$name}, welcome back!”; // 允许
$greeting = “Hello ${name}, welcome back!”; // 不允许
当用点号 “.” 连接各字符串的时候,字符串与点号间必须用一个空格隔开,且允许把它分割成多行以增强可读性。在这种情况下,点号 “.” 必须与等于号 “=” 对齐。例如:
$sql = “SELECT `id`, `name` ” . ” FROM `people` “
. “WHERE `name` = ‘Susan’ “
. “ORDER BY `name` ASC “;
当用 array 类型符号来构造数组的时候,必须在每个逗号之后加上一个空格来增强可读性。例如:$sampleArray = array(1, 2, 3, ‘Think’, ‘SNS’);
4. 当使用 array 类型符声明关联数组的时候,我们鼓励把它分成多个行,只是我们必须同时保证每行的键与值的对齐,以保持美观。例如:
$sampleArray = array(
‘firstKey’ => ‘firstValue’,
‘secondKey’ => ‘secondValue’
);
5. 大括号的开始必须在类名的下一行顶格。例如:
class Think
{
// …
}
6. 类中的所有代码都必须用四个空格来进行缩进。
7. 每个 php 文件只允许声明一个类。在类文件里面写其它代码是允许的,但并不鼓励这样做。假如真要附加代码的话,必须用空行来分隔。
8. 任何类变量的声明都必须放在类顶部,先于任何函数的声明。
12. 函数或方法的初始大括号应该在函数声明的下一行顶格。例如:
function get_client_ip()
{
// …
}
13. 在函数或方法名与参数括号之间不允许出现多余的空格。例如:
function get_client_ip()
{
// …
}
14. 引用只允许定义在函数参数中,实时传递引用是禁止的。例如:
// 引用定义在函数参数-允许的
function defineRefInMethod(&$a)
{
$a = ‘a’;
}
defineRefInMethod($b);
echo $b; // ‘a’
// 实时传递引用-禁止的
function callTimePassRef($a)
{
$a = ‘a’;
}
callTimePassRef(&$c);
echo $c; // ‘a’
15. 函数或方法返回值不可以用括号包住,不然会降低可读性,而且假如以后函数修改为返回引用的话,这将会抛出一个异常。
16. 鼓励尽量使用类型提示,特别是在模块设计中。例如:
class Foo
{
public function foo(SomeInterface $object)

{
}
public function bar(array $options)
{
}
}
17. 函数和方法参数必须用逗号+空格来分隔。
18. 对于参数为数组的函数,参数中的数组应该分成多行以增强可读性。例如:
threeArguments(array(1, 2, 3), 2, 3);
threeArguments(array(1, 2, 3, ‘Think’,
‘SNS’, $a, $b, $c,
56.44, $d, 500), 2, 3);
19. 基于”if”, “else”和”else if”的条件控制里,我们必须用空格间隔开语句和括号,大括号的开始 “{” 必须与条件控制语句位于同一行,结束 “}” 必须总是独占一行且顶格,控制流程内容必须用四个空格进行缩进,且不使用”elseif”。
if ($condition) {
// …
} else if ($_condition) {
// …
} else {
// …
}
20. 在条件控制语句的条件括号内,必须用空格将操作符与其它元素隔开。如果遇到很长的逻辑判断,则鼓励用内嵌括号来分割各个逻辑。例如:
if (($a != 2) and ($b == 1)) {
$a = $b;
}
21. “switch” 条件控制语句中,必须用空格将待测参数与其它元素分隔开。例如:
switch ($num) {
// …
}
22. “switch” 语句的内容必须以四个空格缩进,”case” 条件控制的内容必须再加四个空格进行缩进。例如:
switch ($indentedSpaces) {
case 2:
echo “错误”;
break;
case 4:
echo “正确”;
break;
default:
break;
}
23. 在 “switch” 语句中应该总是包括 “default” 控制。
24. 有时候我们需要在 “case” 语境中省略掉 “break” 或 “return” ,这个时候我们必须为这些 “case” 语句加上 “// 此处无break” 注释。例如:
switch ($numPeople) {
case 1: // 此处无break
case 2:
break;
default:
break;
}

《大秦小将》项目经验总结

每个项目的结果如何,都要总结项目为什么失败。

总结无论个人的发展,还是公司的发展来说,在项目结束后对项目进行总结是为了将来完成更好的项目奠定基础。

1、经验:团队开发及管理经验严重不足,其中大多数人都没有游戏行业的从业经历,造成无法明确的游戏上线目标。

2、目标:项目从立项开始都没有制定出到底要做什么的,造成我们站在执行层面不可进行。

3、沟通:项目的管理是多头管理,两地开发的模式,造成需要很大程度上总是花大量的时间进行沟通。

4、执行力:项目从头到尾的情况是说话的人很多,做事的人很少,虽然老板想了很多办法去做,如果中层执行力不足,下面执行的人员更无法适从。

5、人力:人力资源的问题并不是一个项目是否成功的标准,但是确实是一个重要的问题,并且项目由于1,2,3的问题,造成工作大量重复。这样需要大量的人力去弥补,因此人力资源相当短缺。

一个失败的项目总是有各种原因,但是像这样一个基本犯了软件开发中所有问题的项目确实也少见。从某种意义上来讲之所以犯了这么多问题,归根结底的原因是立项草率,管理人员选择的草率,这样纵使下层执行层面执行力越高也只是在错误的方向走的越远。

 

几个iOS中常会用到的库

以下所有框架都经过使用并确认,记录下来做为知识储备

JASidePanels

使用该控件实现类似Path2.0或者Facebook中的菜单

https://github.com/gotosleep/JASidePanels

 

MKNetworkKit

封装HTTP协议的类库,支持ARC

https://github.com/MugunthKumar/MKNetworkKit

 

MBProgressHUD

一个加载等待特效框架

https://github.com/jdg/MBProgressHUD

 

ZBarSDK 

一个支持读取二维码的类库

https://github.com/bmorton/ZBarSDK

 

JSONKit

封装JSON的类库,用来支持低版本的iOS,在arc应用中需加入 -fno-objc-arc,但是效率比较高

https://github.com/johnezang/JSONKit 

SBJson

另一个JSON的类库,支持arc

https://github.com/stig/json-framework

苹果APNS前及后端搭建流程记录

APNS,全称为苹果推送通知服务Apple Push Notification Service)

在iOS开发中消息的推送是利用自身的服务器,通知苹果的apns服务,然后在推送到具体的机器上。网上已有很多的具体配置过程,但是每个方法都不尽相同。以下方法经过自己的测试,完全可行。

首先在appid中申请开通apns的服务,申请过程中需要上传CSR文件,完成后下载push SLL的证书,并导入到本机电脑

紧接着申请provisioning,如果之前已经开通过provisioning,需要重新申请provisioning。并导入电脑以及测试真机。

第三步,也是最重要的就是制作pem文件具体过程如下

1)在Keychain Access.app里选定这个新证书(Apple Development Push Services*),导出到桌面,保存为Certificates.p12.过程中需要输入密码,记录下该密码,后面会用到

  2)然后运行如下命令:

   1.     openssl pkcs12 -clcerts -nokeys -out cert.pem -in Certificates.p12
   2.     openssl pkcs12 -nocerts -out key.pem -in Certificates.p12
   3.     openssl rsa -in key.pem -out key.unencrypted.pem
   4.     cat cert.pem key.unencrypted.pem > ck.pem

<?php

$deviceToken = '46c1015f 0d11cb7a 93680da6 4dfd4f96 a76beb0a 35bdf012 a123d96e 78338dd9'; // masked for security reason
// Passphrase for the private key (ck.pem file)
// $pass = '';
// Get the parameters from http get or from command line
$message = $_GET['message'] or $message = $argv[1] or $message = 'Message received from Robert.si';
$badge = (int)$_GET['badge'] or $badge = (int)$argv[2];
$sound = $_GET['sound'] or $sound = $argv[3];
// Construct the notification payload
$body = array();
$body['aps'] = array('alert' => $message);
if ($badge)
$body['aps']['badge'] = $badge;
if ($sound)
$body['aps']['sound'] = $sound;

/* End of Configurable Items */
$ctx = stream_context_create();
stream_context_set_option($ctx, 'ssl', 'local_cert', 'ck.pem');
// assume the private key passphase was removed.
// stream_context_set_option($ctx, 'ssl', 'passphrase', $pass);
$fp = stream_socket_client('ssl://gateway.sandbox.push.apple.com:2195', $err, $errstr, 60, STREAM_CLIENT_CONNECT, $ctx);
if (!$fp) {
print "Failed to connect $err $errstrn";
return;
}
else {
print "Connection OKn";
}
$payload = json_encode($body);
$msg = chr(0) . pack("n",32) . pack('H*', str_replace(' ', '', $deviceToken)) . pack("n",strlen($payload)) . $payload;
print "sending message :" . $payload . "n";
fwrite($fp, $msg);
fclose($fp);
?>

在app 的delegate中添加如下代码

#import "ApplePushNotificationAppDelegate.h"

#import "ApplePushNotificationViewController.h"

 

@implementation ApplePushNotificationAppDelegate

 

@synthesize window;

@synthesize viewController;

 

- (void)applicationDidFinishLaunching:(UIApplication*)application {   

   [window addSubview:viewController.view];

   [window makeKeyAndVisible];

 

    NSLog(@"Registeringfor push notifications...");   

    [[UIApplication sharedApplication]

       registerForRemoteNotificationTypes:

        (UIRemoteNotificationTypeAlert |

        UIRemoteNotificationTypeBadge |

        UIRemoteNotificationTypeSound)];

}

 

- (void)application:(UIApplication*)appdidRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken {

    NSString *str = [NSString

       stringWithFormat:@"Device Token=%@",deviceToken];

    NSLog(str);

}

 

- (void)application:(UIApplication*)appdidFailToRegisterForRemoteNotificationsWithError:(NSError *)err {

    NSString *str = [NSStringstringWithFormat: @"Error: %@", err];

    NSLog(str);   

 

}

 

- (void)application:(UIApplication*)application didReceiveRemoteNotification:(NSDictionary *)userInfo {

    for (id key in userInfo) {

       NSLog(@"key: %@, value: %@", key, [userInfo objectForKey:key]);

    }   

}

- (void)dealloc {

   [viewController release];

   [window release];

   [super dealloc];

}

@end

iOS程序初探有感

从入门Object-C到现在已有大半年了。

初步掌握了object-c的语法,也已经在App Store上面发布了程序。

虽然误打误撞开始编写编写基于手机的APP,但是也受益良多。开拓了我的很多方面的经验,在手机端的应用环境和产品环境完全不同于Web端,操作丰富,对于后台的交互也与之前完全不同。比如Session不是由浏览器处理,需要自己处理Session_id这样的问题,这些问题如果不是做App的开发,也许将会考虑不到。开发APP以来每天都有一种恍然大悟的感觉

在项目的整体框架上逐渐开始有了自己的感觉。

希望能够下来能够更进一步深入相关程序,尤其对游戏端,程序的动画上面有进一步的了解,如加深对cocos2d的库的了解。

有关’花语’的一些感悟

一个应用起步要必须打通商家和消费者两边

对于卖家:最关切的问题包括如何能够卖出更多的货物,另一个能够在保证质量的前提下更低成本,更好体验的卖货。好的产品至少需要解决两个问题中的一个。

对于买家:根据马斯洛需求在满足生理需求,安全需求,社交需求,尊重需求,自我实现需求中实现第三种社交需求是中间的需求!社交需求中有一个重要原则就是保证社交的私密性,像qq就保证了言论只在一定范围里传播,让人感觉使用社交工具的便宜性!

所以在花语的应用中必须实现两点原则一个就是帮助卖家更好的卖货,其中包括能够方便掌握货物的状态,是新建的订单还是再配货,还是在发货途中,又或者是已经收到了货!如果能更好地提高卖货量那是更加好的事情!当然这是后期的工作了!

另外优化送礼的社交体验方面,必须强调私密性,至少从体验上让用户感到这段话是两人之间的蜜语!这样才能有安全感。能够放心且更多的使用应用!