关于这两个东西的介绍,网上有一大堆的文档,我就不在这里废话了,如何使用呢?这里我先举一个简单的计数器的例子.我选择写一个exe的程序,也就是说程序是以E32Main为入口的.

GLDEF_C TInt E32Main()

{

    CTrapCleanup* cleanup=CTrapCleanup::New();

    TRAPD(error,callInstanceL());

    if (error != KErrNone)

    {

        printf("get error %d\r\n", error);

    }

    delete cleanup;

    return 0;

}

以上的内容是每一个exe文件都应该做的,CTrapCleanup* cleanup=CTrapCleanup::New()建立一个清除堆栈,以便程序在异常退出的时候把清除堆栈里面的资源都释放掉.当然你也可以加上堆检测宏（__UHEAP_MARK,__UHEAP_MARKEND）,这里我就不多说了。TRAPD是symbian里面经常使用的宏,功能类似于try,第一个参数是让定义一个错误返回值变量的名字, 后面就是可能有异常的你写的函数.当这个函数异常时,程序不会crash, 你可以得到异常的原因.可以参考nokia论坛上的一些关于这些使用的文档.

接下来是vcallInstanceL函数,在这个函数里面我来建立ActiveScheduler.

LOCAL_C void callInstanceL()

{

    CActiveScheduler* scheduler = new(ELeave) CActiveScheduler();

    CleanupStack::PushL(scheduler);

    CActiveScheduler::Install(scheduler);

    TRAPD(error,doInstanceL());

    if(error)

    {

        printf("error code=%d\r\n",error);

    }

    else

    {

        printf("OK!\r\n[press any key]");

    }

    CleanupStack::PopAndDestroy(scheduler);

}

这段程序很简单就是创建一个活动规划器,并压入清除栈,然后安装活动规划器,这样就可以用了.再执行真正的实例函数,最后出栈销毁。doinstance(该函数将在最后的代码中给出，主要的功能就是调用我们自己写的活动计数器)我们放到最后来写,现在来构造我们的活动计数器对象。

class TimeCount : public CActive

{

public :

    static TimeCount* NewLC(); // 构造函数

    ~TimeCount();

    void StartL();             // 计数开始

    void ConstructL();

    void RunL();             // 延时事件到达以后的处理函数

    void DoCancel();         // 取消请求提交

    void setDelayTime(int delayTime);

private:

    TimeCount();

    RTimer iTimer;          // 定时器

    int iTimeCount;         // 计数器

     int mTime;            // 计数间隔时间 单位秒

};

TimeCount::TimeCount():CActive(0)  // 这里可以设置活动对象的优先级

{

    // 把自己加入活动规划器

    CActiveScheduler::Add(this);

}

TimeCount* TimeCount::NewLC()

{

    TimeCount* result = new (ELeave) TimeCount();

    CleanupStack::PushL( result );

    result->ConstructL();

    return result;

}

void TimeCount::DoCancel(void)

{

    iTimer.Cancel();

}

void TimeCount::setDelayTime(int mTime)

{

    DelayTime = mTime;

}

TimeCount::~TimeCount()

{

    Cancel();

    iTimer.Close();

}

void TimeCount::StartL()

{

    // 设定定时器状态为每隔mTime秒钟状态完成一次

    iTimer.After(iStatus, 10000 * 100 * mTime);

    // 提交异步请求

    SetActive();

}

void TimeCount::ConstructL()

{

    // 初始化计数器和定时器

    iTimeCount = 0;

    User::LeaveIfError(iTimer.CreateLocal());

}

void TimeCount::RunL()

{

    // 计数器+1以后继续提交延时请求事件

    printf("The Count is ->>%d", iTimeCount++);

    StartL();

}

每一个活动服务对象都有一个iStatus来标识当前对象的状态.在这里我们把iStatus设定为iTimer.After(iStatus, 10000 * 100 * mTime);也就是定时器定时mTime秒钟以后iStatus发生改变,这个时候活动规划器会收到这个状态的改变,从而调用相应活动对象的处理函数,也就是RunL函数.在RunL函数里面进行计数和输出,然后调用startL重新设置定时器和对象状态,再提交给活动规划器。这样mTime秒钟以后活动规划器会再次调用RunL函数.一直这样重复,这样就达到了计数器的效果。

最后我们来写doinstanceL函数

LOCAL_C void doInstanceL()

{

    TimeCount* timeCount = TimeCount::NewLC();

    // 每隔一秒钟打印一次

    TimeCount->setDelayTime(1);

    TimeCount->StartL();

    CActiveScheduler::Start();

    CleanupStack::PopAndDestroy(1);

}

创建好对象以后,加上CActiveScheduler::Start()程序就开始运行了,这句话告诉活动规划器该等待对象的状态的改变了（正常情况下，一旦CActiveScheduler::Start（）之后，程序直到CActiveScheduler::Stop（）才能终止运行）,在这里就是timeCount的iStatus的改变.等iStatus改变并调用了RunL以后,继续等待iStstus的改变,这样我们使用活动对象的计数器就能够通过消息驱动运行起来了.

这里的CActiveScheduler只管理了一个CActive对象,就是timeCount,可以用类似的方法实现多个CActive,并且都加入CActiveScheduler,CActiveScheduler将会等待所有加入它的CActive的状态的改变,其中有一个的状态改变就会去执行对应的活动对象的处理函数,当状态同时发生的时候,会通过对象的优先级来决定先调用谁的RunL函数.CActiveScheduler也是非抢占式的,当一个RunL函数还没有执行完的时候,如果另一个CActive的状态改变,会等待RunL执行完以后再执行另一个CActive的处理函数（正因为这一点，所以通常RunL函数不能设计为长函数，否则会阻塞活动对象）。

 本文在网上根据网上用人提供的原本阅读学习而成，可算是转载类型的。

Symbian为这种特别需求设计了Active Object (AO)框架。AO框架是运行于一个线程内部的调度框架。其基本思想就是把一个单线程分为多个时间片，来运行不同的任务。

这和多线程有很大区别。多线程之间是可以被抢占的(由操作系统调度)，但是AO框架中的各个任务是不可被抢占的,一个任务必须完成，才能开始下一个任务。

下面是多线程和AO框架的简单比较：

多线程                                       AO框架

可以被抢占                                   不可被抢占

上下文切换耗费CPU时间                       没有上下文切换

由操作系统调度                               由线程自己的AO框架调度

每个线程都有至少4K Stack.                    AO没有单独的Stack.

操作系统还要分配额外的资源记录线程            只是一个Active Object.

Symbian系统本身使用了大量的AO框架来实现一些系统服务。这使得Symbian和其他嵌入式系统相比较，对系统资源的使用更加合理。

AO框架包括CActiveScheduler 和CActive (Active Object)。一个线程的所有的Active Object对象都被安装在该线程的CActiveScheduler对象内.由CActiveScheduler对象监控每个Active Object是否完成了当前任务，如果完成了，就调度下一个Active Object来执行。CActiveScheduler根据优先级来调度各个Active Object.

关于CActiveScheduler的创建和安装，CActive的创建和安装，和CActive的任务处理，可以参看 SDK 文档。理解起来不难。下面要说一个比较容易忽略的地方。这对理解AO框架非常重要。

创建调度器:

CActiveScheduler * scheduler = new (ELeave) CActiveScheduler;

CleanupStack::PushL(scheduler);

CActiveScheduler::Install(scheduler);

运行调度器:

CActiveScheduler::Start();

停止调度器:

CActiveScheduler::Stop();

以上代码都是运行在一个线程中的,一般来讲,一个EXE只有一个主线程.

可是如果真的有2个线程呢?

为什么在当前线程下调用CActiveScheduler::Start(),CActiveScheduler::Stop()运行/停止的就是当前线程的调度器而不是另一个线程的调度器?

每个线程都有自己的CActiveScheduler,那么这个CActiveScheduler类是怎么调用CActiveScheduler::Start(),CActiveScheduler::Stop()来运行/停止当前的调度器的呢?

我们看到Start/Stop并没有参数.

打开CActiveScheduler的类定义：

class CActiveScheduler : public CBase

    {

public:

    IMPORT_C CActiveScheduler();

    IMPORT_C ~CActiveScheduler();

    IMPORT_C static void Install(CActiveScheduler* aScheduler);

    IMPORT_C static CActiveScheduler* Current();

    IMPORT_C static void Add(CActive* anActive);

    IMPORT_C static void Start();

    IMPORT_C static void Stop();

    IMPORT_C static TBool RunIfReady(TInt& aError, TInt aMinimumPriority);

    IMPORT_C static CActiveScheduler* Replace(CActiveScheduler* aNewActiveScheduler);

    IMPORT_C virtual void WaitForAnyRequest();

    IMPORT_C virtual void Error(TInt anError) const;

private:

    void DoStart();

    void OwnedStartLoop(TInt& aRunning);

    IMPORT_C virtual void OnStarting();

    IMPORT_C virtual void OnStopping();

    IMPORT_C virtual void Reserved_1();

    IMPORT_C virtual void Reserved_2();

private:

    // private interface used through by CActiveSchedulerWait objects

    friend class CActiveSchedulerWait;

    static void OwnedStart(CActiveSchedulerWait& aOwner);

protected:

    inline TInt Level() const;

private:

    TInt iLevel;

    TPriQue<CActive> iActiveQ;

    };

我们并没有看到静态的成员来表示线程，但是却有一个static函数CActiveScheduler* Current();返回当前线程的调度器.

现在猜想奥秘就在这个函数是怎么实现的。这个静态的函数怎么就能得到当前这个运行线程的调度器,而不是别的线程的调度器。我们可以猜想,肯定是Current()内部实现能取到当前线程的标识信息.用这个标识,静态函数能取到这个线程的CActiveScheduler.这个具体如何实现呢？

答案就是：当前线程的线程ID可以这样得到:

创建一个缺省的线程对象:

RThread thread;

取得当前线程的ID:

TThreadId threadId = thread.Id();

能得到当前线程的threadId,当然可以得到和当前线程关联的CActiveScheduler。因此以上两个问题也就迎刃而解了，在一个线程内调用CActiveScheduler::Start(),CActiveScheduler::Stop()开启的就是当前线程。

既然回复了上面的问题，那么我们自然就能明确，在一个线程内是不能通过Start和Stop函数来开启和停止另一个线程内的活动对象规划器CActiveScheduler。

补充点其他东西：

在Symbian操作系统中，每个进程都有一个或多个线程。线程是执行的基本单位。一个进程的主线程是在进程启动时生成的。Symbian属于抢占式多任务操作系统，这意味着每个线程都有自己的执行时间，直到系统将CPU使用权给予其他线程。当系统调度时，具有最高优先权的线程将首先获得执行。

进程边界是受内存保护的。所有的用户进程都有自己的内存地址空间，同一进程中的所有线程共享这一空间，用户进程不能直接访问其他进程的地址空间。

每个线程都有它自己的stack和heap，这里heap可以是私有的，也可以被其他线程共享。应用程序框架生成并安装了一个active scheduler，并且为主线程准备了清除栈。如果没有使用框架（如编写exe程序）那就要手动生成这些了。

Symbian操作系统专为单线程应用优化，因此强烈推荐使用“活动对象”代替多线程。

对于在往UI框架应用程序发送消息，可以通过Symbian OS的Application Architecture Services可以进行应用程序间的通信，主要用到的类包括：TApaTaskList和TApaTask。

TApaTaskList：用于访问设备中正在运行的任务（假如有些任务隐藏了的话，那么通过这种方法也无法进行访问）。

TApaTask：表示设备中某个运行的任务，通过与程序关联的窗口组（window group）标识。

具体的解决方案：

发送消息端：使用TApaTaskList找到等待接收消息的任务，TApaTaskList::FindApp()提供了两个重载版本，可以使用程序的标题，也可以使用程序的UID进行查找。获得需要发消息的任务后就可以通过TApaTask:: SendMessage()发送消息了，它有两个参数，第一个参数用于标识消息，第二个参数是一个描述符的引用，可以用来提供不同消息时附加的具体信息。

TUid uid( TUid::Uid( 0x0116C9D3 ) );

TApaTaskList taskList( iCoeEnv->WsSession() );

TApaTask task = taskList.FindApp(uid );

if( task.Exists() ) //判断任务是否正在运行

{

    LIT8( KTestMsg, "CustomMessage" );

    TUid msgUid( TUid::Uid( 1 ) );

    task.SendMessage( uid, KTestMsg );

}

接收消息端可以使用如下两种方案：

第一种方案：由于MCoeMessageObserver是处理来自窗口服务器消息的接口类，而CEikAppUi已经继承自MCoeMessageObserver，所以我们只需要在自己的UI类中重现实现MCoeMessageObserver的唯一成员函数HandleMessageL()用来处理接收到的消息即可，代码如下：

MCoeMessageObserver::TMessageResponse CXXXAppUi::HandleMessageL(TUint32 aClientHandleOfTargetWindowGroup, TUid aMessageUid, const TDesC8& aMessageParameters)

{

    _LIT( KFormatStr, "%x" );

    TBuf<32> bufUid;

    TBuf<32> bufPara;

    bufUid.AppendFormat( KFormatStr, aMessageUid.iUid );

    bufPara.Copy( aMessageParameters );

    iEikonEnv->InfoWinL( bufUid, bufPara );

    return MCoeMessageObserver::EMessageHandled;

}

第二种方案：由于TApaTask::SendMessage()发送的消息可以被CEikAppUI的成员函数ProcessMessageL()拦截并处理，不过必须在没有重载HandleMessageL（）函数的前提下，而且函数ProcessMessageL()只负责拦截消息标识为KUidApaMessageSwitchOpenFileValue和KUidApaMessageSwitchCreateFileValue的这两个消息，其它标识值的消息不会被传到ProcessMessageL()中，所以这种方案个人觉得很受限制，不自由，还是采用第一种方案好，具体代码代码如下：

//发送:

TUid uid( TUid::Uid( 0x0116C9D3 ) );

TApaTaskList taskList( iCoeEnv->WsSession() );

TApaTask task = taskList.FindApp(uid );

if( task.Exists() ) //判断任务是否正在运行

{

    LIT8( KTestMsg, "CustomMessage" );

    //这里的Uid不能使用自定义的，而且只有系统提供的两个

    TUid msgUid( TUid::Uid(KUidApaMessageSwitchCreateFileValue) );

    task.SendMessage( uid, KTestMsg );

}

//接收:

void CXXXAppUi::ProcessMessageL(TUid aUid,const TDesC8& aParams)

{

    RFileLogger iLog;

    iLog.Connect();

    iLog.CreateLog(_L("tb"), _L("UpdateListener2.txt"), EFileLoggingModeOverwrite);

    iLog.Write(_L("smms appui"));

    if (aUid.iUid == KUidApaMessageSwitchCreateFileValue)

    {

        TBuf<256> buf;

        buf.Copy(aParams);

        iLog.Write(aParams);

        BringMeToFront();

        ShowCreateFile(buf,CFileMonitorEngine::EImageType);

    }

    else

    {

        CAknViewAppUi::ProcessMessageL(aUid,aParams);

    }

    iLog.Close();

}

EasyDgm是一个用于拦截短消息，发送短信的插件代码。用该插件拦截短信没有提示音，发送也不提示用户。但是本身该代码是老外开发的，只是针对8位编码的字符，没有根据我们中文的编码来做成完全Unicode版本的，为此以下改写就是实现Unicode字符串的发送。

1、  修改DatagramService工程中的代码，将其内用到的8位描述符修改为16位，具体修改的描述罗列如下：

//修改前内容

       IMPORT_C static CDatagram* NewL(TDesC8& aBuf);

       IMPORT_C static CDatagram* NewL(const TDesC8& aBuf,const TDesC8& aAddress);              IMPORT_C virtual const TDesC8& GetData();

       IMPORT_C virtual void  SetDataL(const TDesC8& aData);

       void ConstructL(const TDesC8& aBuf);

       HBufC8* iData;

//修改后内容

       IMPORT_C static CDatagram* NewL(TDesC& aBuf);

       IMPORT_C static CDatagram* NewL(const TDesC& aBuf, const TDesC8& aAddress);              IMPORT_C virtual const TDesC& GetData();

       IMPORT_C virtual void  SetDataL(const TDesC& aData);

       void ConstructL(const TDesC& aBuf);

       HBufC* iData;

2、  修改SMSDatagramService工程中CSMSSender类的代码，将其内用到的8位描述符修改为16位，具体修改的描述罗列如下：

//修改前

void CreateSMSMessageL(const TDesC8& aText, const TDesC8& aAddress);

void SendSMSL(const TDesC8& aText, const TDesC8& aAddress, TRequestStatus& aStatus);

//修改后

void CreateSMSMessageL(const TDesC& aText, const TDesC8& aAddress);

void SendSMSL(const TDesC& aText, const TDesC8& aAddress, TRequestStatus& aStatus);

3、  修改SMSDatagramService工程中CSMSSender类内创建短信的函数CreateSMSMessageL内，将原来的代码

smsSettings.SetAlphabet(TSmsDataCodingScheme::ESmsAlphabet7Bit);

改成适合unicode的通道值

smsSettings.SetAlphabet(TSmsDataCodingScheme::ESmsAlphabetUCS2);

4、  删除原有的def，重新为两份工程定稿dll，这个具体参看如何编写dll。

以上操作已经将EasyDgm插件修改成适合Unicode的代码类型了，当然该代码中还有可以进行优化的部分，在这里就不多做赘述。

具体使用的时候，可以参考S60v3_EasyDgmTest的例子，一般都是将里面的两份代码smsdatagramreceiver.cpp和smsdatagramsender.cpp直接拿来用的，但是也要改成16位描述符。

考虑到有些网友问我要修改后的EasyDgm代码，先特给出下载地址 http://www.cppblog.com/Files/franksunny/EasyDgm.rar

DLL（Dynamic Link Library）是一段特殊的代码，它能够被外部程序在程序运行的时候调用。在DLL里面的代码可以同时被许多外部程序共享，而且不会引起手机内存的重复分配。

DLL根据接口的类型Symbian系统支持两种类型的DLL:静态接口DLL和多态接口DLL

静态接口DLL在主调程序启动的时候被系统自动载入到手机内存里面（唯一的例外是如果该DLL是在ROM只读存储器里面，那么可以直接通过它的地址进行调用）。并且如果没有外部程序使用它了，它将被自动的从内存中卸载。静态接口DLL在系统内提供了一系列唯一的函数（例如，两个具有相同导出函数的DLL在系统中也不会混淆）。静态接口DLL具有.dll文件后缀，通常用于在Symbian系统中实现应用程序引擎（例如，与UI无关的代码）。

多态接口DLL是只带一个单独导出函数的普通DLL，一般都是通过调用RLibrary::Load()函数才能被载入到内存中，而且在卸载的时候，也最好通过RLibrary::Close()函数进行卸载。多个多态接口DLL可以为外部程序导出多个相同函数名的函数。所以，这种DLL通常情况下被广泛应用于实现某个应用程序框架功能扩展时候的插件。在Symbian系统中，多态接口DLL可以有多种不同的文件后缀。其中最著名的一个就是.app结尾的（应用程序），.ldd（逻辑设备驱动），.tsy和.csy（电话和通信服务模块）等等。。。

在本文中，我们将只关注静态接口DLL技术，它是你我在开发中最最常用的DLL类型。我们将以通用DLL的继续我们的内容。

静态接口的DLL

从DLL调用者的角度来看，DLL有三个文件组成：

（1）头文件：.h的文件后缀，可以#include到主调程序的代码中去，只有在编译

的时候有用。

（2）导出文件：.lib的文件后缀，可以由主调程序进行链接，这个文件记载了DLL的提供的所有接口函数名称和地址。（在arm版本中应该是dso后缀）

（3）DLL文件本身：.dll的文件后缀包括所有.lib文件记载的接口函数的具体实现，主调函数在运行的时候实际调用和执行的部分。

从DLL编写者的角度来看，DLL可以被看成是一个完整的Symbian项目。它由以下几部分组成：

（1）项目自己的MMP文件（在bld.inf文件中列出的）

（2）一个头文件，指定了该DLL需要导出的接口

（3）源代码文件，具体导出函数的实现

头文件

DLL的头文件与其它类的头文件的头文件非常类似。不同的地方在于使用了IMPORT_C宏来定义所有导出函数：

class CMyEngine : public CBase

{

public:

   // These functions are visible by the

   // clients of the DLL and needs to have

   // the IMPORT_C tag

   IMPORT_C static CMyEngine* NewL();

   IMPORT_C static CMyEngine* NewLC();

   IMPORT_C void MyPublicMethod();

   IMPORT_C void AnotherPublicMethod();

   ...

private:

   // These functions are not visible by the

   // clients of the DLL and then do not need

   // the IMPORT_C tag

   CMyEngine();

   void ConstructL();

   void SomePrivateMethod();

}

实现文件

编写DLL工作本身没有什么需要复杂的地方，但是有两个重要的地方需要留意：

（1）E32Dll()函数必须实现

（2）另外一个特殊的宏，EXPORT_C，应该加在每个导出函数实现的前面。

例如：

// This function is mandatory for all DLLs

EXPORT_C TInt E32Dll(TDllReason)

{

        return KErrNone;

}

// This function is exported: The EXPORT_C tag shall be used.

EXPORT_C void MyPublicMethod()

{

   ...

}

// This one is not: The EXPORT_C tag shall not be used.

void SomePrivateMethod()

{

  // Do Something

}

MMP文件

DLL的MMP文件应该有以下特点

（1）定义项目(project)的类型是dll

（2）使用正确的UID2的值(0x1000008d)

在开发过程中，你也应该通过EXPORTUNFROZEN告诉编译环境，DLL接口还没有定稿，还可以随时修改。

例如：

TARGET        MyEngine.dll

TARGETTYPE    dll

UID           0x1000008d

...

EXPORTUNFROZEN

把DLL接口定稿（Freezing DLL）

一旦你完成了DLL的开发，在你发行你的DLL版本之前，应该把接口定稿（Freezing）这样可以确定将来发行的DLL可以向下兼容。

通过将项目的MMP文件中的EXPORTUNFROZEN关键字去掉，用常规的方法重新建立DLL，来实现DLL库的定稿。这时候会有“.def文件不存在”的编译警告信息出现，不要紧，继续就建立当前项目，在项目编译完毕以后，你可以用如下命令定稿：

abld freeze [platform]

例如

 1、bldmake   bldfiles;  

 2、abld   build  gcce;  

 3、abld   freeze gcce; 

注意:

这里通常有三个定稿的def文件夹：在二版本中编译armi时，用abld freeze armi产生的是BMARM文件夹和对应的Def；在三版本中编译gcce和armV5时会产生EABI文件夹和对应的Def；而用wins时则编译产生BWINS文件夹和对应的Def。（个人总结）

所有的ARM平台共享一个.def文件，但是对于wins模拟器和winscw CodeWarrior环境来说，他们有不同的.def文件。

一旦项目已经定稿，重新生成makefile，这时候导入的lib会直接通过定稿的.def文件生成。

BYTE hidden = KAppNotHidden;

我们要实现图标隐藏，只需将其值赋为KAppIsHidden即可。具体示例代码如下：

RESOURCE APP_REGISTRATION_INFO

{

       app_file="Hello_Hide_app_0xEC12F4E3";

       localisable_resource_file =  qtn_loc_resource_file_1;

       localisable_resource_id = R_LOCALISABLE_APP_INFO;

       hidden = KAppIsHidden;

       embeddability=KAppNotEmbeddable;

       newfile=KAppDoesNotSupportNewFile;

}

在2nd版本中显得略微复杂些，具体实现如下（本人尚未测试过）：

I installed the application without name (.app only) or in a folder out of \system\apps\<myapp>\, for example, c:\system\data. In that way the app was not in the list.

假设你的应用ID为：ef37946b

1)在data下新建一个文件， [ef37946b].rss（注意加上[]）文件具体代码如下

#include <startupitem.rh>

RESOURCE STARTUP_ITEM_INFO dispatcher

{

    executable_name = "!:\\sys\\bin\\AutoStart.exe";

    recovery = EStartupItemExPolicyNone;

}

此处的AutoStart.exe是你的应用程序文件名。

注：笔者试图通过修改此处为其他应用程序名从而启动指定其他程序，但是没有成功。

2)在mmp文件中增加以下代码

START RESOURCE [ef37946b].rss

TARGETPATH                 \private\101f875a\import

HEADER                                  

END

确保：

LANG              SC

CAPABILITY         ReadUserData

注意“\private\101f875a\import”不能够变。

3)在pkg文件中增加以下代码

"$(EPOCROOT)epoc32\data\z\private\101f875a\import[ef37946b].rSC"-"!:\private\101f875a\import\[ef37946a].rSC"

如果是采用carbide c++编译，那么使用上述代码就可以了。

如果是使用makesis命令行打包或者使用.Net编译，那么你需要修改成绝对路径，路径名视你的安装目录而定。

例如：

"C:\Symbian\9.1\S60_3rd_MR\Epoc32\Data\z\private\101f875a\import[ef37946b].rSC"-"!:\private\101f875a\import\[ef37946a].rSC"

其次，在获知焦点变化的同时，改变应用程序的焦点，通过TApaTask::SendToBackground()和TApaTask::BringToForeground()两个函数来实现。由于这里用到的TApaTask类，需要包含APGTASK.H和apgrfx.lib。

再次，因为需要在调用其上函数时，必须用我们的应用程序的窗口组id(window  group  id)初始化(Initialise) TApaTask这个对象，这个实现需要用到，获取当前应用程序窗口组id的函数CEikonEnv::Static()->RootWin().Identifier()。刚好以上函数又要包含w32std.h和w32.lib。

l         具体实现代码如下：

void CHelloUIAppUi::HandleForegroundEventL(TBool  aForeground)

{

       if(aForeground)

       {

              TApaTask task ( CEikonEnv::Static()->WsSession() );

              task.SetWgId( CEikonEnv::Static()->RootWin().Identifier() );

              //Foreground run

              task.BringToForeground();

              ActivateLocalViewL(iHelloUIContainerView->Id());

       }

       else

       {

              TApaTask task ( CEikonEnv::Static()->WsSession() );

              task.SetWgId( CEikonEnv::Static()->RootWin().Identifier() );

              //background run

              task.SendToBackground();

       }

}

如何设置S60模拟器的网络参数

在调试使用Socket进行数据通讯的Symbian S60程序过程中，需要编写客户端与服务器的数据交互代码，如果S60的模拟器可以直接访问网络中的服务器程序，调试就会非常方便。S60的模拟器提供了这些功能，不过需要对网络参数进行一些设置，下面将讨论这一问题。

首先是网络参数的设置，在Symbian安装目录的..\Epoc32\tools目录下有一个网络参数设置程序network_config.bat，对于不同的开发包，这个名字可能会有一些不同(可以选择开始菜单下SDK目录tools下的Ethernet Support Configuration)。执行该程序，将显示参数设置界面。其实参数的设置和对局域网中的PC设置一样，你就把它当成是在设置PC的网络配置就可以了。分配一个没有使用的IP（注意绝对不能与本机IP相同），填写好子网掩码，设置好局域网的网关。唯一的不同是要选择所使用的网卡。当你点OK关闭该设置对话框的时候(或着点那个Adapters按钮)，会显示一个命令行界面，列出了当前机器上可以使用的网卡的信息，你需要输入一个数字选择一个网卡，注意，应该选择你的PC所使用的那个真实的网卡，也就是标识你机器在局域网内IP地址的那个网卡。

按照官方文档来说，这样就可以，但实际上不是所有的机器都可以，我没有测试过，不知道别人的机器如何，反正我使用的机器不可以。后来我在一本书里看到，还需要运行另外一个程序，才可以达到我们的目的。这个程序与上面的设置程序在同一个目录下，叫做npacketadmin.exe。执行它，会显示一个程序，并跳出一个设置对话框，首先在下拉列表框里选择你刚才选定的那个网卡，然后点击下面的Start按钮，这样就可以了。这时你就可以使用模拟器调试你的Symbian S60通讯程序了。（我实际测试中发现不用启动npacketadmin.exe也是可以的）

测试是否连通的方法是，执行模拟器中的“网络”应用程序，然后输入一个网址，比如www.sina.com.cn,如果设置正确，将显示该页面，注意也许是乱码，不过不要紧，因为我们只想知道网络是否已经可用了。（强烈建议使用非中文网站做测试，比如www.google.com）

如果以上的过程中，不启动npacketadmin.exe就不能连接的用户，必须注意下面几个问题：

1.在调试期间可以关闭npacketadmin.exe的那个设置对话框，但是不能关闭该程序。如果关闭了，网络将不通。

2.如果不小心关闭了该程序，需要重新启动，并重新做上面的第二步的操作。

3.应该在启动模拟器之前就启动该程序，不然模拟器可能会异常退出。

本人刚开始调试时，犯了以下一些问题：

首先用msconfig工具将S60的Ethernet Packet Service这个服务停掉了，后来每一次模拟器试图用Socket连接时都弹出“Error：1058 无法启动服务……”的报错。该错误在npacketadmin.exe启动时也会出现。

其次没有注意IP的问题，用跟本机同一个IP，结果怎么连都连不上，后来改成我同事的，害得他一个下午都因为网络上有同名IP而半天没得上网。

Symbian 应用程序框架浅析

S60应用程序的运行依赖于大量的OS组件，例如屏幕绘图和应用程序数据持久性等，可以直接使用OS的窗口服务器或者文件服务器即可。

应用程序核心框架类

应用程序框架由一套核心类组成，这些类是所有应用程序框架的基础。这些类封装了应用程序和所需OS服务器之间的相互作用。

应用程序核心框架类

第一层：CBase和CActive两个基类，其中CActive也是派生于CBase，而CActive又被第二层的CConEnv派生

第二层：包含两个基本组件：AppArc和CONE。AppArc代表“应用程序架构”，这些类提供了基本的应用程序结构、将系统信息提交到应用程序的机制，以及使用文件服务器持久化数据。其中的类在命名时都带有前缀“*Apa”。CONE是控制环境的缩写，在这个组件中的类提供用于处理用户输入并创建用户界面的机制－－这些类主要用于和窗口服务器进行交互，其中的类在命名时都带有前缀“*Coe”。这一层中的许多类都是抽象类，仅仅定义了一个API的接口。

第三层：Uikon组件。这是具有丰富功能、非抽象框架类的一般性设备无关实现，并且提供了一个在所有symbian OS上公用的UI库层。一些具体的UI控件（比如列表框和滚动条等）都可以在该层创建，这些控件有时也被称为Eikon控件。UIkon组件中的类在命名时都带有前缀“*Eik”。添加了一个公共的symbian OS实现，和其他Symbian OS UI平台共享。

第四层：由Avkon类组成，这些类提供了核心的S60 UI功能，例如菜单支持。Avkon控件的类在命名时都带有前缀“*Akn”。在框架上添加S60特有的实现。

第五层：针对应用程序的层，设计自己的应用程序，添加自定义应用程序实现。

以上提到的这些类简单来说就是：视图（View）、文档（Document）、应用程序（Application）、应用程序UI（Application UI）。那么一个S60 UI应用程序是如何用这些类来实现其有机程序呢，这个就涉及到一个应用程序框架的初始化问题。

应用程序框架初始化

必须创建下面的每个方法，才能提供最小的S60应用程序：

a、 框架入口：所有S60 UI都实现一个全局函数E32DLL()（非UI类的全局入口函数为E32Main），当应用程序启动时，框架将首先调用该函数，该函数也称为DLL入口点，应用程序必须存在该函数。每个S60 UI 应用程序都是一个多态DLL。

b、新建应用程序实例：让框架调用NewApplication()，该函数是由DLL导出的唯一函数，负责创建应用程序类的一个实例，并返回它的指针，以后框架使用该指针完成应用程序的创建。这里在堆上创建应用程序实例使用的是“new”方法而不是Symbian OS常见的“new (ELeave)”方法，这是因为TRAP harness(陷阱捕捉)这时还没有创立。如果系统不能为新的实例分配内存，那返回的指针就是NULL，应用程序框架能够检查到并处理这个问题。

c、返回UID：由框架调用AppDllUid（）返回应用程序的UID。该函数必须返回在.mmp文件中指定的UID值，该值可用于确定应用程序的实例是否正在运行。如果一个应用程序正在运行，而要启动这个程序的另一个实例，这时该运行的程序就会被切换到前台，而不是重新生成一个。

d、新建文档实例：框架通过框架调用应用程序类实例的CreateDocumentL（）函数获取指向新创建的Document类实例的指针。通过文档实例指针，框架就可以调用文档实例的某些功能，同时文档实例也通过调用自身的NewL（）和NewLC（）双重静态构造函数（为什么是双重构造，这跟Symbian的异常处理机制有关，而之所以设计成静态函数我现在也还不是很清楚）来创建自己。

e、是否装入文件：框架重新调用AppDllUid（）来观察是否要从文件系统中装入一个文件。（似乎这里跟某些永久存储信息有关，目前项目还没用到这个功能，我也不知道这个该怎么用）

f、 新建AppUi和View实例：框架通过调用文档对象的CreateAppUiL（）方法生成了一个AppUi实例并获取指向它的指针。此处AppUi实例创建自身时使用的是C++的默认构造函数并返回实例的指针，之后框架通过这个指针调用AppUi实例的ConstructL（）函数来完成构造。而在这个ConstructL（）函数中首先调用的是AppUi基类的BaseContructL（）函数，处理了读入与该程序相关的资源的事宜，其次是新建需要加载的View类的实例（通过双重构造），如果不止一个View的情况下需要调用AddViewL（）函数将新建的View实例加载进来，最后如果是多个View时通过SetDefaultViewL（）函数设置缺省的默认视图。如读入一个与该程序相关的资源文件AppUi调用了AppView类的NewL函数来生成其实例，这里也是用的双重构造

g、 View的重绘：通过以上的创建过程，框架已经拥有了View的无限调度权利，此时如果有一般的system事件框架就可以通过窗口服务器调用View的Draw（）函数，至于这些System事件一般指程序启动、应用程序获得焦点或者选项菜单消失等等。在这里需要注意的是编程开发者并不能直接调用Draw，它要求在调用前系统的graphics context处于激活状态，如果编程开发者希望进行屏幕的重绘，则只能调用DrawNow（）方法。还有就是Draw函数是不能异常退出的，这是因为该函数能被框架直接调用，而框架是不知道如何处理可能发生的异常的。因此Draw自己需要捕捉和处理可能发生的错误。

h、 处理命令：完成以上步骤后，用户可以通过比如菜单选项之类的交互UI使框架调用HandleCommandL（）函数，并传递一个参数aCommand，它指明了用户所选择的命令，HandleCommandL（）会据此来判断不同的命令以分别调度执行。在此处还有一个必须注意的地方是如果要程序的View实例也回应用户的按键，则必须将View实例通过AppUi的AddToStackL（）函数加入到AppUi实例的控件堆栈（control stack）中。具体的调用方式实现以按键来解释如下流程所示：

对于上面的调用方式实现说明，个人觉得有必要再将AppUi的几个重要事件处理方法罗列一下：

HandleWsEventL（）用于处理窗口服务器传递的事件，它的作用使框架调用下面这些具体事件处理方法；

HandKeyEvent（）用于处理用户按键事件（此函数在控件堆栈为空时调用，否则框架将会调用OfferKeyEventL（）函数）；

HandleForegroundEventL（）当应用程序切换到前台或从前台切换到后台时调用该函数，默认的实现可以处理键盘焦点的改变；

HandleSystemEventL（）用于处理由窗口服务器生成的事件；

HandleApplicationSpecificEventL（）用于处理自己定义的自定义事件。默认的实现可以处理颜色方案改变的通知；

HandleCommandL（）用于处理用户选择的菜单项；

HandleSwitchOnEventL()用于处理像设备切换之类的特定切换事件；

HandleMessageReadyL()用于处理窗口服务器产生的消息事件。

在以上各函数处理事件中，除了第一个HandleWsEventL（）函数外，其它函数默认都是纯虚函数，需要重载才能用。

通过以上对应用程序框架初始化步骤后，一个完整的框架就创建完毕了，其具体过程可以由一个图来形象做结。

本文中参考了网络上的一些文章链接如下：

Symbian程序框架研究http://www.sf.org.cn/Article/lumen/200607/18837.html

Symbian开发初级手册http://www.sf.org.cn/Article/lumen/200508/34.html