苹果的证书那叫一个多啊~~~ –_–!

这里不仅仅讲到证书，还讲到provision。

为了能正确使用Push功能，需要对App进行相应的设置，服务器也需要相应设置，因此这里牵扯到两方面的证书/provision：

1. 用于App的mobileprovision配置文件
2. 用于服务器和APNS验证的SSL证书

整个推送流程分为三步骤：

1. 收集用户身份识别码
2. 向用户发送推送信息
3. 从苹果获取卸载用户

在iOS下UIWebview中的代码和Objective C代码交互比较蛋疼，其过程可以用下面一段描述：

1. 制造一个点击，链接为自己定义的格式，比如protocol://control/action?key1=value1
2. UIWebview的delegate收到webView:shouldStartLoadWithRequest:navigationType:分析链接，并处理
3. 如果要返回结果则调用[webView stringByEvaluatingJavaScriptFromString:]

要是这种交互接口不多，随便按照上面步骤写写就够用了。如果这些接口不少，我们可以利用performSelector来解放一下生产力。

今天准备把一个SVN的项目迁移到Git上，看了一下网络上的迁移方法

git svn clone svn://192.168.1.108:9999/ --no-metadata -A user.txt --trunk=trunk --tags=tags --branches=branches myProject

，看上去好像不难，试了一下，发现一个很悲剧的事情：SVN的结构不是标准结构-_–#

- branches
    - A1
    - A2
    - B1
    - B2
- trunkA
- trunkB
- tagsA

居然将两个项目放在了一起，就不能使用标准的方法了 T^T

这几天和中间层同事们对接接口， 常常需要生成个链接然后发过去，超级麻烦。于是想能不能让他们在设备上自己复制个链接来测试。

因为这些链接都是有上下文的， 不能说生成就生成. 想来想去最简单的获取方法是在请求链接之前NSLog出来。

为了减少将来的重复劳动，我决定把NSLog出来的东西也在APP的一个TableView里显示一份。

要获得Log，需要用到 asl.h ，通过它可以查询符合特定条件的Log

我的查询条件比较简单： 1. 当前APP的Log 2. APP启动后的Log

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

- (void)updateLogs {
    aslmsg query = NULL, message = NULL;
    aslresponse response = NULL;

    query = asl_new(ASL_TYPE_QUERY);
    constchar *time = [[NSStringstringWithFormat:@"%d", _lastTime] UTF8String];
    asl_set_query(query, ASL_KEY_TIME, time, ASL_QUERY_OP_GREATER | ASL_QUERY_OP_NUMERIC);
    asl_set_query(query, ASL_KEY_FACILITY, [[[NSBundlemainBundle] bundleIdentifier] UTF8String], ASL_QUERY_OP_EQUAL);

    response = asl_search(NULL, query);
    while (NULL != (message = aslresponse_next(response))) {
        const char *content = asl_get(message, ASL_KEY_MSG);
        NSString *contentString = [[[NSStringalloc] initWithUTF8String:content] autorelease];
        [((NSMutableArray *)self.logs) addObject:contentString];

        const char *time = asl_get(message, ASL_KEY_TIME);
        _lastTime = atoi(time);
    }

    aslresponse_free(response);
    asl_free(query);
}

多线程访问数据库本身就存在分险，容易形成脏数据。幸好FMDB这个第三方库支持了多线程访问，从而解决了脏数据问题。然而也带来了死锁问题……

先看看FMDB的多线程机制的原理。

看了它的代码，发现其实很简单的一个思路，但是实现起来还真不容易，难怪花了好长时间才支持多线程！！它是生成一个请求队列，将一次事务进行封装放在队列中，只有一个事务完成了，才会进行下一个事务。这就出现了一种现象：如果某一个请求耗时过大，将会导致所有请求堵塞！！同时也要求：同一个线程中，在一个事务完成之前，不能进行下一个事务。

GB18030

变长, 1, 2, 4 字节

1
2
3

单字节，其值从0到0x7F。
双字节，第一个字节的值从0x81到0xFE，第二个字节的值从0x40到0xFE（不包括0x7F）。
四字节，第一个字节的值从0x81到0xFE，第二个字节的值从0x30到0x39，第三个字节从0x81到0xFE，第四个字节从0x30到0x39。

• kCFStringEncodingGB_18030_2000

兼容 GB2312

GB2312 变长，1，2字节

1
2

“高位字节”使用了0xA1-0xF7（把01-87区的区号加上0xA0）
“低位字节”使用了0xA1-0xFE（把01-94加上0xA0）。