[转载]《Troubleshooting SQL Server》读书笔记-内存管理 – Joe.TJ – 博客园.

[转载]Android输入法框架分析(1)－三大组件 – 山水含清晖 – 博客园.

转载C#中Trim、TrimStart、TrimEnd的用法 – 猴子哥 – 博客园.

[转载]iOS- 如何集成支付宝 – 清澈Saup – 博客园.

//
//选中商品调用支付宝快捷支付
//
- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
    /*
     *点击获取prodcut实例并初始化订单信息
     */
    Product *product = [_products objectAtIndex:indexPath.row];
    
    /*
     *商户的唯一的parnter和seller。
     *本demo将parnter和seller信息存于（AlixPayDemo-Info.plist）中,外部商户可以考虑存于服务端或本地其他地方。
     *签约后，支付宝会为每个商户分配一个唯一的 parnter 和 seller。
     */
    //如果partner和seller数据存于其他位置,请改写下面两行代码
    NSString *partner = [[NSBundle mainBundle] objectForInfoDictionaryKey:@"Partner"];
    NSString *seller = [[NSBundle mainBundle] objectForInfoDictionaryKey:@"Seller"];
    
    //partner和seller获取失败,提示
    if ([partner length] == 0 || [seller length] == 0)
    {
        UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"提示"
                                                        message:@"缺少partner或者seller。" 
                                                       delegate:self 
                                              cancelButtonTitle:@"确定" 
                                              otherButtonTitles:nil];
        [alert show];
        [alert release];
        return;
    }
    
    /*
     *生成订单信息及签名
     *由于demo的局限性，本demo中的公私钥存放在AlixPayDemo-Info.plist中,外部商户可以存放在服务端或本地其他地方。
     */
    //将商品信息赋予AlixPayOrder的成员变量
    AlixPayOrder *order = [[AlixPayOrder alloc] init];
    order.partner = partner;
    order.seller = seller;
    order.tradeNO = [self generateTradeNO]; //订单ID（由商家自行制定）
    order.productName = product.subject; //商品标题
    order.productDescription = product.body; //商品描述
    order.amount = [NSString stringWithFormat:@"%.2f",product.price]; //商品价格
    order.notifyURL =  @"http://www.xxx.com"; //回调URL
    
    //应用注册scheme,在AlixPayDemo-Info.plist定义URL types,用于快捷支付成功后重新唤起商户应用
    NSString *appScheme = @"AlixPayDemo"; 
    
    //将商品信息拼接成字符串
    NSString *orderSpec = [order description];
    NSLog(@"orderSpec = %@",orderSpec);
    
    //获取私钥并将商户信息签名,外部商户可以根据情况存放私钥和签名,只需要遵循RSA签名规范,并将签名字符串base64编码和UrlEncode
    id<DataSigner> signer = CreateRSADataSigner([[NSBundle mainBundle] objectForInfoDictionaryKey:@"RSA private key"]);
    NSString *signedString = [signer signString:orderSpec];
    
    //将签名成功字符串格式化为订单字符串,请严格按照该格式
    NSString *orderString = nil;
    if (signedString != nil) {
        orderString = [NSString stringWithFormat:@"%@&sign=\"%@\"&sign_type=\"%@\"",
                                 orderSpec, signedString, @"RSA"];
        
        //获取快捷支付单例并调用快捷支付接口
        AlixPay * alixpay = [AlixPay shared];
        int ret = [alixpay pay:orderString applicationScheme:appScheme];
        
        if (ret == kSPErrorAlipayClientNotInstalled) {
            UIAlertView * alertView = [[UIAlertView alloc] initWithTitle:@"提示" 
                                                                 message:@"您还没有安装支付宝快捷支付，请先安装。" 
                                                                delegate:self 
                                                       cancelButtonTitle:@"确定" 
                                                       otherButtonTitles:nil];
            [alertView setTag:123];
            [alertView show];
            [alertView release];
        }
        else if (ret == kSPErrorSignError) {
            NSLog(@"签名错误！");
        }

    }

    [tableView deselectRowAtIndexPath:indexPath animated:YES];
}

主要集成的关键就是下面几步:

//.封装订单模型
AlixPayOrder *order = [[AlixPayOrder alloc] init];
// 生成订单描述
NSString *orderSpec = [order description];

//2.签名
id<DataSigner> signer = CreateRSADataSigner(@“私钥key”);
// 传入订单描述 进行 签名
NSString *signedString = [signer signString:orderSpec];


//3.生成订单字符串
NSString *orderString = [NSString stringWithFormat:@"%@&sign=\"%@\"&sign_type=\"%@\"",
                         orderSpec, signedString, @"RSA"];

//4.调用支付接口
AlixPay * alixpay = [AlixPay shared];
// appScheme：商户自己的协议头
int ret = [alixpay pay:orderString applicationScheme:appScheme];

[转载]跨服务器连接查询（补充） – select left(‘claro’,2)的专栏 – 博客频道 – CSDN.NET.

在 如何方便的建立远程链接服务器   的文章中说明如何在SQL2005环境下方便快捷有效的建立跨服务器查询；

-- 很多朋友问局域网多数据库服务器访问该如何操作？下面简单说明如何配置远程链接访问。

/*********** 环境说明 ***********/

-- 源机器 IP 为 10. 0.0.211 ，在该机器所在数据库建立与目标机器的远程数据库链接。

-- 目标机器 IP 为 10. 0.0.222 。

-- 步骤（一）是指直接用 IP 进行远程链接，个人觉得用 IP 链接虽然麻烦，但是直观而且在多服务器操作时不会出现误链接的情况。

-- 步骤（二）是指直接用别名进行远程链接，较方便；但在高压力，大脑暂时短路情况下容易出现误链接数据库情况发生。

 

/*********** 步骤（一） ***********/

-- 建立连接服务器

EXEC sp_addlinkedserver   '10.0.0.222' , 'SQL Server'

 

/*-- 如果数据库有架构名需要做远程登录之间的映射

-- 创建链接服务器上远程登录之间的映射

EXEC sp_addlinkedsrvlogin '10.0.0.222','false','SA',' 架构名 ',' 登录密码 '

*/

-- 查询数据

-- 含架构名

select top 10 * from [10.0.0.222]. 数据库名 . 架构名 . 表名

-- 不含架构名

select top 10 * from [10.0.0.222]. 数据库名 . dbo. 表名

 

 

-- 查看链接服务器信息

select name , product, provider, data_source, query_timeout, lazy_schema_validation, is_remote_login_enabled, is_rpc_out_enabled

  from sys.servers

where is_linked= 1

 

/*********** 建立步骤（二） ***********/

/*-- 如果用 IP 连接觉得麻烦，可以新建别名

-- 配置链接服务器属性

exec sp_serveroption '222','name','10.0.0.222'

*/

-- 查询数据

-- 含架构名

select top 10 * from 222. 数据库名 . 架构名 . 表名

-- 不含架构名

select top 10 * from 222. 数据库名 . dbo. 表名

 

 

-- 删除链接服务器登录名映射

exec sp_droplinkedsrvlogin '10.0.0.222' ,NULL

 

-- 删除链接服务器属性

exec sp_dropserver '222'

 

--注：如果执行 删除链接服务器时提示如下错误时，

消息 15190，级别 16，状态 1，过程 sp_dropserver，第 56 行
仍有对服务器 'XXXX' 的远程登录或链接登录。

执行

exec sp_dropserver ' 链接服务器 ' , 'droplogins' 

在 SQL2008和SQL2000可以跨服务器连接查询的测试实例   中说明如何在SQL2000和SQL2008环境下跨服务器的查询。

以上跨服务器查询都是在先建立链接服务器的基础上，

如果不建立链接服务器可以直接用SQL查询跨服务器的Table吗？

如果不建立链接服务器可以查询跨服务器的系统表吗？

当然可以！

在SQL2008和SQL2000可以跨服务器连接查询的测试实例 中的各实例对应的sa如何不相同，建立链接服务器后仍无法查询系统表，所以这里强调可以查询跨服务器的系统表并告诉使用它的目的。

当然，我们都熟悉opendatasource的使用，这里也不例外。

环境：

目标服务器SERV1，IP地址10.0.0.250，数据库INTER，架构名DBO 。

目的：

在本地服务器查询目标服务器上的INTER数据库的表logdb。

脚本一：

查询服务器SERV1上INTER数据库的表logdb并返回前十行

select top 10 *

from opendatasource ( ‘SQLOLEDB’

, ‘Data Source=10.0.0.250;User ID=sa;PASSWORD=sa 密码 ;’ )   — 输入目标服务器地址（原因请见《如何方便的建立远程链接服务器》）

— 输入 sa 帐号及密码

. [INTER] . dbo . logdb

  如果结果 集 返回类似如下结果：

链接服务器”(null)”的 OLE DB 访问接口 “SQLNCLI10” 返回了消息 “登录超时已过期”。
链接服务器”(null)”的 OLE DB 访问接口 “SQLNCLI10” 返回了消息 “与 SQL Server 建立连接时发生了与网络相关的或特定于实例的错误。找不到或无法访问服务器。请检查实例名称是否正确以及 SQL Server 是否配置为允许远程连接。有关详细信息，请参阅 SQL Server 联机丛书。”。
消息 53，级别 16，状态 1，第 0 行
命名管道提供程序: 无法打开与 SQL Server 的连接 [53].

  请检查并确认输入的目标服务器地址及SA密码是否正确！

如果结果 集 返回类似如下结果：

消息 7314 ，级别 16 ，状态 1 ，第 1 行

链接服务器 “(null)” 的 OLE DB 访问接口 “SQLNCLI10” 不包含表 “”INTERFACEDATA”.”dbo”.”logdb”” 。该表不存在，或者当前用户没有访问该表的权限。

  请检查并确认输入的表名是否正确！

脚本二：

这里我们假设输入的表名是错的，但不记得正确的表名是什么。此时通常我们会查询sys.objects是否存在该表并确认名称。这里也不例外：

查询服务器SERV1上INTER数据库中是否存在表 db log并返回正确的表名

select NAME

from opendatasource ( ‘SQLOLEDB’

, ‘Data Source=10.0.0.250;User ID=sa;PASSWORD=sa 密码 ;’ )

. [INTER] . [SYS] . [OBJECTS] — 查询目标服务器的系统表

where TYPE = ‘U’ and NAME LIKE ‘%log’ — 查询用户表以 “log” 结尾的表名

ORDER BY 1  — 按 NAME 排序

Posted by: select left(‘claro’,2) @10:27:00

lable: SQL

[转载]android获取web服务器端session并验证登陆 – 云忠飞鸽 – 博客频道 – CSDN.NET.

传统网页实现用户登陆一般采用session或cookie记录用户基本信息又或者两者结合起来使用。android也 可以采用session实现用户登陆验证并记录用户登陆状态时的基本信息，session是在服务器端的;而类似cookie的记录方式，则可以在客户端 采用xml文件记录用户基本信息,重要数据则可以加密存放客户端。Android实现的session登陆功能与网页请求不同的是，网页形式的一次成功的 登陆请求后，再点击其他页面时，session一直是存在的，在一定时间内是有效的；而采用Android客户端请求的一次成功登陆后，再次发送新的请 求，则会产生新的session，而不是原来的。这就需要记录session的id号，并在整个请求过程中都记录并传递这个id号，才能保证 session的一致性。

以获取php session为例，主要思路实现分为客户端与服务器端3个步骤。

附件:  GetWebSession.zip (71.44 KB, 下载次数: 63) 

1.）客户端（Android）

建立一个名为GetWebSession的Android项目，编写GetWebSession.java,LoginSuccessActivity.java,GetUserInfoActivity.java三个activity类。

1. GetWebSession.java主要是实现布局界面以及发送用户名和密码到php服务器端验证，如果验证成功则跳转到 LoginSuccessActivity.java类。GetWebSession.java主要涉及到与服务器端连接请求，对从服务器端返回的 json数据(如用户id,session等)进行解析，并存入HashMap,传递到LoginSuccessActivity.java

代码如下:

2. LoginSuccessActivity.java主要获取php的session唯一的标识id以及用户的一些基本信息，session id则作为本次用户登录状态在服务器的唯一标识，即确定用户的唯一状态进行相关操作。LoginSuccessActivity.java类的方法与 GetWebSession.java类似。其主要功能是获取session id后再次发送session id到服务器进行验证，根据封装的session数据验证用户操作权限等。

代码如下：

3.GetUserInfoActivity.java类是根据用户登录后产生唯一session 标识进行操作获取用户详细信息的类。

代码如下:

4.三个布局的xml文件

(1.)main.xml

(2.)login_success.xml

(3.)get_info.xml

2.）服务器端（php）

php服务器端主要有三个文件,conn.php,login.php和getinfo.php。

1. conn.php是连接数据库的配置文件。

2. login.php主要是用来验证android客户端发送的请求,请求成功则返回flag=’success’的状态标识,采用数组记录用户基本信息， 存储用户数据到session，并且记录本次产生的session id。用户基本数据及本次session产生的id均封装成json格式(json_encode($arr)),发送android客户端。产生本次 session id的方法

$sessionid=session_id();//注意没有参数

具体代码如下：

3. getinfo.php文件主要是用户再次查询信息验证session，而不是重新产生session，以记录用户状态。通过验证flag是否为empty判断数据是否显示。最后封装成json发送到客户端

获取本次session的方法：

$sessionid=$_POST[“sess_sessionid”];//获取android客户端的sessionid

session_id($sessionid);//有参数

session_start();//启动session

具体代码如下:

3.）数据库端（mysql）

采用mysql建立数据库，建立两个简单的数据表：user和info。

运行效果如图：

图 -1 GetWebSession.java类的布局

图 -2 LoginSuccessActivity.java类获取的session id以及用户基本信息

[转载]通过Android View的两种事件响应方法比较inheritance和composition – 山水含清晖 – 博客园.

Android view有两种主要的处理事件的方式，

1. 在View的子类中覆盖onXXX方法。因为这是在子类中通过覆盖的方式来响应事件，我称之为基于继承（inheritance）的响应方式。
2. 调用View.setXXXListener，参数会实现View.OnXXXListener接口。因为View对象和Listner组合起来完成工作，我称之为基于组合（composition）的响应方式。

例如对于touch事件而言，View.dispatchTouchEvent接收到touch事件对象，然后：

1. 调用通过View.setOnTouchListener注册的listener。
2. 调用可以被子类覆盖的onTouchEvent方法。

举个简单例子，一个Activity中有一个edit框（EditText对象）。EditText是通过代码添加的到Activity中的。我希望在点击它时，自动把该框的底色设置为红色。

如果采用第一种方式，其EditText的子类是：

public class TouchChangeBackgroundColorEditText extends EditText {

    public MyEditText(Context context, AttributeSet attrs) {
        super(context, attrs);
    }

    @Override
    public boolean onTouchEvent(MotionEvent event) {
        this.setBackgroundColor(Color.RED);
        return super.onTouchEvent(event);
    }
}

然后我们在Activity中使用该EditText的子类。

如果采用第二种方法，则需要创建一个对touch事件的listener：

public class TouchChangeBackgroundColorListener implements View.OnTouchListener {

    @Override
    public boolean onTouch(View v, MotionEvent event) {
        v.setBackgroundColor(Color.RED);
        return false;
    }
}

然后在Activity中使用普通EditText，并对该EditText调用setOnTouchListener(new TouchChangeBackgroundColorListener)。

然后用户又想对某些EditText使用Key event来改变背景颜色，那如果采用基于继承的方式，用户需要创建KeyChangeBackGroundColorEditText的子类，在其中覆盖onKeyDown方法；如果采用组合的方式，则需要实现OnKeyListener并添加到EditText中。

现在问题来了，用户希望某些EditText是不响应touch和key事件的，有些只响应一种，有些两种都响应。那么如果采用继承的方式，那需要四种对象，一个基本都EditText和三种针对only touch，only key和both touch and key的子类。

但如果采用组合的方式，我们仍然只需要两个listener，只需对不同的EditText添加不同的listener即可。

如果更复杂，我们还想针对trackball改变颜色，那如果采用继承，则可能有3×3=9种类。但采用组合，只需要三种listener，然后EditText根据需要添加即可。

所以说，在可能有多种因素导致变化的时候，继承可能导致对象种类（即类）爆炸式增长；而组合可以用不同的对象封装不同的变化，减少类的个数。

但这里减少的只是编码中类的个数，而在运行时如果采用继承，那对象的个数是EditText的个数；但如果采用组合，那每个EditText都对应着一个Listener，所以有更多的对象个数。所以说，组合一般较继承产生更多的运行时对象，这需要更多的内存（对象存储）和运算时间（对象间相互调用）。

现在假设app的界面上已经有一个EditText控件，我们又想在app中通过选项来控制该EditText的行为，例如我们有三个选项，分别对应touch，key和trackball事件发生时是否改变该EditText的背景颜色。那么如果采用组合，可以先创建好三个listener，然后根据选择添加listener到现有的的EditText中。但如果使用继承，根本是无法动态改变其行为了。所以说，组合可以动态改变对象的行为，而继承只能在静态改变。

再回到前面继承的onTouchEvent方法，在最后一行，我需要调用super.onTouchEvent。事实上，我开始实现时忘记调用这行了，结果点击edit框时，可以改变颜色，但无法切出输入法。在现实中覆盖父类的方法时，有的父类方法是需要在子类中被调用的，但有的却不需要。覆盖的时候要详细查看父类文档和代码。但如果采用组合的方式，我只需要关系listener自己的视线即可，并不需要调用view中跟touch处理相关的代码。所以说，继承是一种白盒复用，在覆盖父类的方法时，需要关心父类方法的实现；但组合是黑盒测试，我只需要实现接口即可，而不需要关心该接口如何被调用。

故而Design pattern中所有模式的两大基石之一就是：Favor object composition over class inheritance。

[转载]iOS- 显示数据列表最常用的一个控件UITableView – 清澈Saup – 博客园.

相信做过iOS的程序员，最熟悉的控件一定少不了UITableView，最常用的控件也一定少不了UITableView！

今天分享一下自己对UITableView的实现大体思路，和整理出来的学习笔记！

1.UITableView里的结构图　　　　　　　　　　　　　　　　　　　　　　　

2.UITableView数据展示的条件　　　　　　　　　　　　　　　　　　　　　　

1> UITableView的所有数据都是由数据源（dataSource）提供的，所以要想在UITableView展示数据，必须设置UITableView的dataSource数据源对象

2> 要想当UITableView的dataSource对象，必须遵守UITableViewDataSource协议，实现相应的数据源方法

3> 当UITableView想要展示数据的时候，就会给数据源发送消息（调用数据源方法），UITableView会根据方法返回值决定展示怎样的数据

3.数据展示的过程　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

数据显示，三步走

1> 先调用数据源的

– (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView

得知一共有多少组

2> 然后调用数据源的

– (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section

得知第section组一共有多少行

3> 然后调用数据源的

– (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath

得知第indexPath.section组 第indexPath.row 行显示怎样的cell（显示什么内容）

4.开发中经常用到的UITableView数据源方法　　　　　　　　　　　　　　　

1> 一共有多少组

– (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView

2> 第section组一共有多少行

– (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section

3> 第indexPath.section组 第indexPath.row行显示怎样的cell（显示什么内容）

– (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath

4> 第section组显示怎样的头部标题

– (NSString *)tableView:(UITableView *)tableView titleForHeaderInSection:(NSInteger)section;

5> 第section组显示怎样的尾部标题

– (NSString *)tableView:(UITableView *)tableView titleForFooterInSection:(NSInteger)section;

5.开发中经常用到的UITableView代理方法　　　　　　　　　　　　　　　

选中了UITableView的某一行

某一行的高度

第section分区头部的高度

第section分区尾部的高度

5.- (UIView *)tableView:(UITableView *)tableView viewForHeaderInSection:(NSInteger)section

第section分区头部显示的视图

第section分区尾部显示的视图

设置每一行的等级缩进(数字越小，等级越高)

6.tableView刷新数据的方式　　　　　　　　　　　　　　　　　　　　　　

 1> 修改模型数据

2> 刷新表格

– reloadData

整体刷新（每一行都会刷新）

– (void)reloadRowsAtIndexPaths:(NSArray *)indexPaths withRowAnimation:(UITableViewRowAnimation)animation

局部刷新

[转载]iOS- iOS 和 Android 的后台推送原理各是什么？有什么区别？ – 清澈Saup – 博客园.

iOS 的推送
iOS 在系统级别有一个推送服务程序使用 5223 端口。使用这个端口的协议源于 Jabber 后来发展为 XMPP ，被用于 Gtalk 等 IM 软件中。

所以， iOS 的推送，可以不严谨的理解为：
苹果服务器朝手机后台挂的一个 IM 服务程序发送的消息。
然后，系统根据该 IM 消息识别告诉哪个 Apps 具体发生了什么事。
然后，系统分别通知这些 Apps 。

这个消息的内容是这样的：
应该说，苹果这种方式在技术上没有什么创新。但是，整个架构是很了不起的。 因为：
1 
使用久经考验的协议，技术风险小。

2 
苹果勇于承担责任：
他需要维护一个代价不小的服务器集群，而且要为服务器的 down 机负责。

选择低风险的技术方案 Bug 更少，减轻了用户的痛苦，这是构架师的功劳。
苹果承担责任，尽可能的减少了不可控的意外，保证了用户体验。
这，只能说是公司决策者的功劳。
（从侧面说明有个懂技术的 VP 是多重要。。。而 Scott 走人了。。）

他们带给用户的好处也是实实在在的。
1 安全。
只有登录过的开发者可以通过苹果的服务器推送。

2 快速，稳定，可靠。
苹果掌控推送服务器和 OS 。

3 更省电。

4 让整个系统的体验更统一和简单。
不会出现杀后台这种脑残事。（不用大量 Apps / Apps 的服务为了推送挂后台）。
也不会出现 Apps 被杀就收不到推送这种脑残事（早一点的新浪微博 Android 版仍然如此）。

5 开发容易。
当然，开发者还是要做些事情，比如维护个服务器什么的： http://www.ifanr.com/3979。但是复杂度无疑降低很多了。

Android 的推送
Apps 挂后台一直是 Android 引以为豪的特性（虽然我真的不知道是好处多还是坏处多。。）。。。大家挂后台等待推送就成为技术选择。

当然， Google 事后也提供类似苹果的推送方式了。倒也谈不上抄袭，毕竟苹果的整个技术实现也没有什么特别创新之处。

用户的电池？ 

Apps 的开发者不会站在系统层面考虑的。他会假设其他 Apps 没有那么“不自觉”。而 Google 不强制的结果就是：没人真正为用户的电池负责。

但是， Google 的方案也并非全是悲剧：
也因为整个技术方案非强制， Android 的 Apps 在接收到推送后的表现更为灵活。
像 Line 的 Android 版本可以在推送通知的 Popup 上直接回复， iOS 就需要越狱才能做到了。

最后的话
强制和封闭，有时候并非坏事。他意味着做出这个决定的人，要为此负责。

所以，如果说苹果的推送方案有何创新？

我以为是超越技术，不惜让公司承担更多风险和责任的解决方案。（类似的还有 BB 的专用网络， Kindle 的全球 3G ）

个人相信，担负起这些“额外”的责任，是值得的。。。

只要是为了用户。

[转载]如何打一手好Log – luguo3000 – 博客园.