Symbian 开发的一些小技巧

核心提示：在ETel第三方API(CTelephony)中使用User::WaitForRequest() 应注意的问题ETel第三方API(即CTelephony)是做为异步模式来设计的，从一个活动对象调用它的方法，Symbian 开发的一些小技巧，然后就等待这个方法的完成，做为活动对象所定义的概念来说，为了进行Symbian

在ETel第三方API(CTelephony)中使用User::WaitForRequest() 应注意的问题

ETel第三方API(即CTelephony)是做为异步模式来设计的，从一个活动对象调用它的方法，然后就等待这个方法的完成。做为活动对象所定义的概念来说，一次只能有个一个active request存在。

Telephony的异步工作模式使得它无论何时检测到一个方法被调用时(这时TRequestStatus 参数被传入该方法)，已经是KRequestPending状态的情况下，都会引发一个异常(Telephony 0)。

一般在Symbian程序员中流传的使异步变同步的方法就是调用User::WaitForRequest来锁定该线程直到方法完成(这个方法是不被提倡的)

这样做主要有两个问题：

1、异步工作模式可能会花费较长的执行时间才能完成，这样线程就一直处于阻塞模式下，这样可能会引发VIEWSERV 11异常(参考Symbian FAQ-0920)

2、该异步方法的完成可能依靠同一个线城中其他活动对象的工作，而如果阻塞线程的话，那这个异步工作将永远无法完结。

我们在一个具体的CTelephony事例中来考虑问题：

CTelephony::TBatteryInfoV1 batterystrength;

CTelephony::TBatteryInfoV1Pckg battery(batterystrength);

CTelephony* tel = CTelephony::NewLC();

TRequestStatus status = KRequestPending; // (1)

tel->GetBatteryInfo(status, battery);

User::WaitForRequest(myStat); // (2)

…

CleanupStack::PopAndDestroy();

这个将意味着：

1、TRequestStatus变量被初始化为KRequestPending(第 (1)行)，这是一个常见的错误，会引发CTelephony报Telephony 0错误(如上所述)，注意一般来说是没有必要对TRequestStatus进行初始化的。

2、如果第(1)行被删除，那代码也永远无法回到第(2)行，因为在线程被阻塞的情况下CTelephony 的异步方法是无法被完成的。

结论就是CTelephony应该一直使用异步工作模式，另外使用User::WaitForRequest 时一定要谨慎。

程序的自启动的动态配置

目前，在S60第三版中，如果一个程序想要自启动，你可以通过启动列表管理API来完成它。具体信息可以在 S60 3rd Edition SDK中找到。

为了进行Symbian Signed criteria的传递，你需要在你的程序中提供对自启动的取消功能。暂时没有公开的API可以帮助你解决这个问题，下面有两个解决方案：