How to detect if phone has 3G enabled.

Some items in you applications you want to do some action only when there is 3G network (like video streaming upload or video calling.) So how to detect that phone has 3G network.

TBool isSupported = CFeatureDiscovery:: IsFeatureSupportedL (KFeatureIdProtocolWcdma);
if (isSupported)
   {
   // activate the service
   }

How to know current editing state of TextEditor.

You can use CAknEnv::EditingStateIndicator() to get then current editing starts.
code below show how to know if T9 is On or OFF.

TBool t9_mode;
MAknEditingStateIndicator* editingindicator = CAknEnv::Static()->EditingStateIndicator();
CAknIndicatorContainer* indicatorcontainer =editingindicator->IndicatorContainer();
if (indicatorcontainer->IndicatorState(TUid::Uid(EAknNaviPaneEditorIndicatorT9)))
  {
  t9_mode = ETrue;
  }
else
  {
  t9_mode = EFalse;
  }

How to fource application to use AGPS instead of GPS.

Solution is you have circle through all the gps modules avaialble and select one with AGPS Support.

RPositionServer iPosServer;
RPositioner iPositioner;

srv.GetNumModules(moduleCount);

for(TInt i = 0 ; i < moduleCount ; i++)
 {
 TPositionModuleInfo modInfo;
 TInt error = iPosServer.GetModuleInfoByIndex( i, modInfo );
 if(modInfo.IsAvailable() && (modInfo.TechnologyType() == TPositionModuleInfo::ETechnologyAssisted))
     {
     iPositioner.Open(iPosServer,modInfo.ModuleId());
     break;
     }
 }

How to get UserAgent for S60 v3.x devices.

use the following code to get the user agent of the device.

iRepository= CRepository::NewLC(TUid::Uid(0x101f8731));
TBuf<255> tmp;
iRepository->Get(7, tmp);
iUserAgent = HBufC8::NewL(tmp.Length());
iUserAgent->Des().Copy(tmp);

How to make old sdk installations foot-print disappear.

Problem: some times the emulator or my sdk [v3.0 MR] installation gets corrupted due to prolonged usage. and i want to reinstall so i uninstall the SDK and reinstall it but the new installation takes S60_3rd_MR_2 as epoc path so how to default it to S60_3rd_MR.

Solution:
1. Uninstall S60_3rd_MR from you PC and delete S60_3rd_MR folder.
2. Open RegEdit
3. Go to HKEY_LOCAL_MACHINE\SOFTWARE\Nokia\com.nokia.s60 and check the counter value
4. if the counter value not "0" then set it to 0.
5. restart PC and install S60_3rd_MR again.

How to observe the flip open and flip close event

If you wanted to observe the flip open and flip close event in case of N93. then you have to use EnableScreenChangeEvents and try capturing events EEventCaseClosed, EEventCaseOpen in RunL()

if(iStatus == KErrNone)
    {
    TWsEvent e;
    ws.GetEvent(e);
    switch(e.Type())
        {
        case EEventCaseClosed:
        case EEventCaseOpen:

        }
    }

Taking ScreenShot in Symbian

Below are steps we have to take ScreenShot and saving it to the file as .jpeg.

1.Create blank bitmap:
iBitmap = new (ELeave)CFbsBitmap;
iBitmap->Create( TSize(176,208),EColor16M ); // Pass the Window Size to capture

2.Create a rectangle of the window you want to capture:
iScreenRect = TRect(TPoint(0,0),TSize(176,208)); // Pass the Window Size to capture

3. Copy Screen To this bitmap and save it into memory.
iScreenDevice->CopyScreenToBitmap(iBitmap,iScreenRect);

4. Now we have to Encode CFbsBitmap to JPEG Format.

TBuf<50> myBuf;
myBuf.Append(KFileName);
myBuf.AppendNum(iCaptureCount);
myBuf.Append(KExtension);

iEncoder = CImageEncoder::FileNewL(iFsSession, myBuf, CImageEncoder::EOptionAlwaysThread, KImageTypeJPGUid);

TRequestStatus status;
iEncoder->Convert(&status,*iBitmap);
SetActive();

5. The conversion process is asynchronous. When it is completed, RunL() is called. Inside RunL()

Indside RunL():
delete iEncoder;
iEncoder = NULL;

How to simplify Symbian Classes using Template.

As you all know we have to have 2-Phase consutsction in heap based classes. And also know that it's repetitive code that we have to write for each and every classes. If you can minimize the coding effort that will help us in long run, for that we can use the Symbian Templates.

Define a class which is base class

// baseclass.h
#ifndef __BASE_CLASS_H__
#define __BASE_CLASS_H__

template <class T>
class CBaseClass : public CBase
   {
public:
   static T* NewL(RWsSession& aWsSession)
       {
       T *self = T::NewLC(aWsSession);
       CleanupStack::Pop(self);
       return self;
       }

   static T* NewLC(RWsSession& aWsSession)
       {
       T *self = new (ELeave) T(aWsSession);
       CleanupStack::PushL(self);
       self->ConstructL();
       return self;
       }

public:
   virtual void ConstructL() = 0;

   };
#endif

Now We can use in any class like below

#ifndef __MYCLASS_H__
#define __MYCLASS_H__

#include "baseclass.h"
class CMyClass;
class CMyClass : public CBaseClass<CMyClass>
   {
public:
   void ConstructL();
public:
   CMyClass()
   {
   }
   ~CMyClass();
   };
#endif

note: you can improve the above implemetaion as per your requirement.

How to Copy BitMap Object to BitMap Object

We can load a bit map using CEikonEnv::CreateBitmapL()

CFbsBitmap* myBitmap = iEikonEnv->CreateBitmapL(KBmpPath,index);

Code below shows how to copy BitMap

CFbsBitmap* aBitmap = new (ELeave)CFbsBitmap;
aBitmap->Create(myBitmap->SizeInPixels(),myBitmap->DisplayMode());
TRect tempRect(TPoint(0,0),myBitmap->SizeInPixels() );
TInt iBufLength = tempRect.Width() * tempRect.Height() * 2;
Mem::Copy(aBitmap->DataAddress(),myBitmap->DataAddress(),iBufLength);

How to choose a mobile platform

When it comes to choosing the target platform and technology for your mobile project the possibilities are numerous. There are several kinds of PDAs and mobile phone platforms to choose from, and they all have somewhat different characteristics. You'll consider very different factors when you develop applications for the Pocket PC versus the Palm OS, even though their target markets are nearly the same. On the other hand, using Mobile Information Device Profile (MIDP) for application development is quite different from doing it using Symbian, even though these two platforms tend to target the same devices.

Project scope and limitations

Before you even begin to consider technology platforms and target devices, you must have a crystal-clear picture of the software you're developing. To begin, ask yourself these questions:

* Who is your target audience? Is your application intended for consumer use, or will it be used more in business or corporate environments? Consumer devices are generally different from business devices, so knowing your target audience will help you narrow down your target device -- quickly. You won't get far developing a children’s game for the Pocket PC.
* Are you developing a game or an application? If it's a game, consider the demographics of the people who will play it (age, gender, economic bracket, and so on). That will give you an idea of which consumer devices to target.
* Are there any pre-existing requirements? If your distributor only handles Symbian applications, for example, then your choice is easy. Likewise if you're developing a business app for a company that already has Symbian phones in place.
* What's your skill-set? Assuming you're doing the coding, if you're a Java™ developer then you probably want to stick with the Java platform (unless you have a good reason for switching to some other technology).
* How quickly do you need the application or prototype? Some technology solutions add complexity, and thus development time, to a project, whereas others limit both.
* How much money do you have? Money is almost always the most important factor to consider.

While not so integral to choosing your development platform, it's also a good idea to know what niche your application will fall into. Is it unique enough to dominate the market on any target device, or will it be one application among many in a given genre? These considerations will help you decide how much time and money to invest in your application, as well as what kind of returns you can anticipate.

Mobile technology options

Mobile development technologies have quite a range -- from the stripped-down server-side scripting of Short Message Service (SMS) to the complete development platforms of Symbian and MIDP. Before I get into comparing the technologies most commonly used for mobile development, I'll briefly describe each one and discuss its pros and cons from both a development and a market perspective.

SMS and MMS
SMS (Short Message Service) and MMS (Multimedia Service) are by far the simplest technologies to use for mobile development. Both build on the basic functions of mobile phones, with the SMS/MMS development happening on the server side. The simplest way to make an SMS application (for example one that receives a message and sends a joke) is to sign a contract with a mobile service operator and write a simple PHP script that communicates with the operator's interface. MMS applications are the same but a bit more complicated, because you're handling different kinds of content.
MIDP
The Mobile Information Device Profile (better known as mobile Java) launched the mobile application revolution. Sadly, the technology fell flat of many developer's expectations when it turned out that its applications weren’t really write-once, run-everywhere. MIDP 2.0 fixed many of the problems inherent in the first version, but some developers still have doubts about MIDP. On the upside, MIDP development can be very fast, allowing you to make a working application or prototype in just a few days.
Symbian
Symbian is an increasingly popular operating system for smart phones. Symbian has a number of user interface platforms, including Nokia’s Series 40, Series 60, Series 80, and Series 90, and the UIQ, which is used by Sony Ericsson and Motorola among others. Symbian is a lot more complicated to work with than MIDP, but Symbian applications are designed and targeted for a particular UI and platform, making them more reliable. Symbian applications are written mainly in C++.
Pocket PC
Windows™ CE, Pocket PC Edition (aka Pocket PC or Windows mobile) is Microsoft’s operating system for PDAs. The Pocket PC platform resembles other Windows operating systems, which makes it quite easy to learn. A Pocket PC device also contains all the basic applications for word processing, personal information management, e-mail, and so on, making it a popular choice among consumers. On the other hand, Pocket PC devices don’t necessarily have network connections or phone functions. Pocket PC apps are typically written in C++, Visual Basic, or the Java language.
Smartphone
Smartphone is the smartphone version of Windows CE or Windows Mobile. It is aimed at smartphones and mainly competes in the same category as the Symbian OS. Smartphone development is similar to Pocket PC development. Because Smartphone is a mobile phone platform it is guaranteed to have phone functions and connectivity.
Palm OS
Palm OS is the operating system behind Palm devices, which were among the first practical handheld devices. These days there are Palm OS phones and PDAs. Palm devices have a loyal user base, which ensures a good market for Palm applications. Palm OS Garnet and Palm OS Cobalt are the two versions of the Palm platform, Cobalt being the newer version. Most Palm OS applications are written in C, but there are development environments that will let you create Palm OS applications in other languages including C++, Visual Basic, or Java programming.
Others.
iPhone, Android, Linux etc

Now you have a clear sense of your application and the mobile technologies you could use to build it, but you're probably not sure yet which is the best one. Asking more questions (and answering them) will help you narrow the decision down even further.

What can you afford?

Money is the bottom line in application development. Knowing what you have to spend lets you determine how much time you have to develop your application and how many developers you can assign to the project. Symbian is probably the slowest and, thus, most expensive mobile development technology, while MIDP, Pocket PC (with Visual Basic), and SMS can be quite fast and cheap. Table below summarizes the budgeting considerations for each of the mobile development technologies profiled.

Budget factors compared

Technology	Budgeting considerations
SMS and MMS	You can use standard Web development tools, like Java programming or PHP, and you'll find plenty of experienced developers. It's also easy to learn these technologies yourself. You'll need a Web host for your scripts and a contract with your local mobile operator.
MIDP	Development tools are free, although some of the commercial tools can make development faster and easier. The MIDP APIs are quite easy to learn and use. You can build a good application with a small team.
Symbian	Probably the most difficult to master, and thus expensive, but also rewarding. The software is reliable and has a solid reputation. Consumers are willing to pay more for Symbian. You will need a commercial development tool, which adds to the cost. Further, some distributors only accept tested applications, so you’ll have to use a third-party testing company to do the testing. And in the latest version of Symbian, you have to get your applications signed.
Pocket PC	Free tools let you start a development project with a small budget. Developing an application with a reasonable amount of features requires experience and time, however, as with any other Windows application.
Smartphone	Development is pretty straightforward if you’re familiar with Microsoft’s technologies and are fluent with Visual C++. You'll find a large community of experienced developers for Microsoft’s technologies, so the size of the team will depend on the size of your project.
Palm OS	You can download free development tools from Palmsource and get support for a small fee. Palm OS development is about as demanding as Windows Mobile (Pocket PC and Smartphone) development, with the same benefits and constraints.

How much time do you have?
Table below shows the factors that affect development time for each mobile technology, then categorizes them by speed. (Of course, a lot depends on the experience of the development team.)

Development time factors compared

Technology	Factors that affect development time	Speed
SMS and MMS	Getting the contracts with a mobile operator can take some time, but the development itself should go quickly if you're an experienced Web developer.	Fast
MIDP	Prototypes can be made very quickly. A simple application can be designed, implemented, and tested in a month.	Fast
Symbian	While this is the most time-consuming choice, it significantly increases the credibility of your application. You most likely need a development team that is experienced with Symbian. If you plan to learn the technology yourself make sure you reserve enough time.	Slow
Pocket PC	Visual Basic development is quite fast even for the beginner, but C++ development takes time. You can also use the Java platform, but doing so presents limitations for running the application easily in the device.	Medium
Smartphone	Quite like the Pocket PC.	Medium
Palm OS	Developing with C is slow compared to MIDP. Other options are faster.	Slow

What's the ROI?

Not all people who own certain devices are potential buyers. Some don’t even know that their mobile phone is Java-enabled -- or even know what "Java-enabled" means. Knowing what to expect in returns will help you decide how much time and money to put into your application up front; this is an important consideration for some mobile platforms. Table 3 describes the potential market for different platforms and explains some of the variables that will affect your application's return on investment.

ROI and target consumers compared

Technology	Market
SMS and MMS	Nearly everyone with a mobile phone is a potential user of SMS or MMS services, although you'll find more users in some demographics than others. Stock market applications are strictly for business people, whereas almost anyone could want to vote for their favorite reality television series candidate.
MIDP	Most mobile phones now include MIDP 2.0, but that doesn’t mean that consumers know what to do with it. As a test, ask all your friends and family if their phones are Java-enabled. How many of them know that they have Java-enabled phones? How many of them have used a mobile Java application?
Symbian	At the moment there are two market segments for Symbian: young people for games and business people for business apps. More users will tune into Symbian soon, but for now these are the early adopters who are willing to pay for applications.
Pocket PC	These devices are mostly owned by business people, which guides the applications built for them. Think PIM applications, travel applications, and the like.
Smartphone	Smartphone is relatively new (compared to Palm OS, for example) and so its market is quite fresh. There are not very many devices out yet, but the number is growing. The phones are quite large, so, at the moment it's unlikely to woo the masses.
Palm OS	The PDA's target audience is mainly business people or people with a high demand for contact and memo data. The phones could appeal to anyone, but their size and price suggests that they're targeted to business people or early adopters.

In conclusion

I've focused in this column on considerations to help you choose the right mobile platform, starting with some questions to help you define your software project. Knowing the scope and limitations of your application -- from both a development and a market perspective -- is paramount in choosing the right technology to build it. From there, you'll want to consider market factors such as whether your application falls into a niche that is already dominated by a given technology or range of devices and the anticipated return on investment from your app. Finally, think about the development itself.

Developing MIDP apps is relatively simple and takes place entirely on the Java platform. If you're building a lightweight consumer app and you know Java already, then MIDP is a good choice for you. If you want to build your application using Symbian -- a good choice for more robust applications that will compete for marketshare -- then you or your team must be proficient in C++ programming. An SMS application is easy to build and can target a wide audience, but offers a fairly limited user interface.

The key to choosing the right technology for your projects is to think from multiple perspectives. Here, I've introduced the most commonly used mobile technologies and compared them based on the three essential considerations for any project: budget, development time, and ROI.

Why Should we use Resource Files in defining UIs ?

Symbian (and its Licensees S60 and UIQ) provides a lot of the infrastructure for an application in Symbian.C++ that is already prebuilt[like MFC] so it is not really practical to reinvent the wheel with more code to rebuild the controls.

Additionally to provide a consistent framework across devices, the underlying OS uses a framework calls LAF which dictates how controls should look and where they should be on the screen so that there is a common style to all applications.

Also Keeping source code and resource files separate, which gives lots of advantages
1. easy localization,
2. developer only need to recompile resource files if there are any changes in the UI elements.

QT - Windows CE Application Framework

Qt for Windows® CE enables developers to write rich and high performance applications using an intuitive API available for a wide range of devices. Qt for Windows CE allows rapid application development, translation to numerous languages, and unparalleled ease of platform migration to Windows, Mac®, Linux®, embedded Linux® and Unix®. Enjoy efficient cross-platform development across multiple device types.

Qt Cross-Platform Application Framework

Qt is a cross-platform application framework for desktop and embedded development. It includes an intuitive API and a rich C++ class library, integrated tools for GUI development and internationalization, and support for Java™ and C++ development.

Innovate & Differentiate

Proven Technology

Qt for Windows CE inherits the power and advantages of Qt, Trolltech's leading C++ cross-platform application framework. Trolltech has always demonstrated both commitment and ability to remain ahead of the technology curve, freeing customers to focus on front-end value-adding innovation rather than maintaining the software infrastructure.

Power to Differentiate

With full source code and documentation provided, Qt for Windows CE offers the freedom to create and innovate. Device and application developers using Qt can efficiently differentiate their products by taking control of the user experience.

Independence
Qt for Windows CE has minimal hardware dependencies and supports most existing Windows CE configurations. Qt for Windows CE is easy to build even for custom hardware configurations.

High Productivity

Whether you are developing for the desktop or Windows CE, Qt comes with a rich toolset enabling rapid application development, seamlessly integrated with Visual Studio®.

High Quality API

Qt for Windows® CE supports the same API as Qt on the desktop: a growing library of over 600 C++ classes, which encapsulates a complete infrastructure for end-to-end application development. Qt for Windows CE benefits from Qt 4's leading technologies including high-quality rendering engine, concurrency abstraction, text rendering and multi-threading. Unused features can be excluded when compiling Qt for Windows CE in order to minimize software footprint.

Enhanced Graphics Capabilities

Speed optimization and visual quality, a primary focus for Qt, has even more impact on embedded devices. The Qt for Windows CE API allows for the capabilities of the hardware's accelerated graphics to be utilized. Qt integrates Scalable Vector Graphics (SVG 1.1/1.2 Tiny) drawings and animations on embedded with full support for multiple displays. OpenGL ES is supported including an OpenGL paint engine for accelerated 3D graphics.

Powerful 2D Graphics Canvas

Qt Graphics View – a powerful 2D graphics canvas – enables the creation of interactive applications that responsively handle thousands of 2D graphics objects. Graphics View provides support for collision detection, optimized level-of-detail rendering, affine item transformations, enhanced control over animations and enhanced drag-and-drop features.

Native and Customizable Look and Feel

Qt for Windows CE adds two new native styles to Qt: the Windows Mobile and Windows CE style. At runtime, Qt applications will detect which style to use. The look and feel of Qt applications can be easily customized further with its unique widget stylesheets. Qt Style Sheets are a powerful mechanism that allows customization of widget appearance. The concepts, terminology, and syntax of Qt Style Sheets are inspired by HTML Cascading Style Sheets (CSS), but adapted to the world of widgets. With Qt Style Sheets, complex styles can be defined by anyone familiar with CSS techniques, in a fraction of the time and lines of code required for traditional UI styling.

Multimedia Framework*

Qt 4.4 incorporates Phonon: a straightforward, high-level, open-source media playback API. Phonon provides cross-platform support for video and audio playback using native media facilities.

Qt WebKit Integration*

Qt's integration with WebKit – a powerful open source web rendering engine – allows you to display and integrate dynamic web content and functionality in your local application. Applications can incorporate real-time web content and services, and utilize HTML and application scripting skills enabling new ways of creating and delivering user interfaces.

Advanced Text Layout Engine

Qt for Windows CE supports TrueType® and raster fonts. Targeting the global market is easier with Qt for Windows CE, with its extended Unicode support and right-to-left languages. Qt's rich text engine adds capabilities for complex text layouts including tables, path tracing and text which flows around shapes. Using Qt, it's has never been this easy to create rich text content in your embedded application.

Invaluable Tools

Regardless of what platform you are targeting, Qt includes tools, which enable rapid and optimal development. All tools are seamlessly integrated with Visual Studio, making it possible to target multiple platforms from within the popular Windows IDE. Tools include automatic code completion and syntax highlighting, powerful GUI layout and forms design through an integrated Qt Designer, templates for the most common application types, and Qt documentation integrate with Visual Studio online help. Also included are a set of tools designed to smooth the internationalization workflow.

How to retrieve a list of the languages supported by the phone.

    CPtiEngine* eng = CPtiEngine::NewL( ETrue );
 CleanupStack::PushL( eng );
 if ( eng->NumberOfLanguages() )
     {
     RArray<TInt> languages;
     CleanupClosePushL( languages );
     eng->GetAvailableLanguagesL( languages );
     ........
     CleanupStack::PopAndDestroy( &languages );
     }
 CleanupStack::Pop (eng);

Naming convention used in Symbian

Why we require special "Naming convention" for symbian.

* provide common syntax for Symbian OS C++
* help reinforce Symbian OS programming idioms
* help communicate Symbian OS C++ class design for APIs
* serve as checklist for coding
* act as reference during code inspection/review
* helps produce efficient and reliable code for ROM-based devices

Fundamental data types in Symbian
* typedefs of built-in types for integer, floating-point, character, and pointer types (e32def.h), compiler-independent.
* TInt, TUint signed and unsigned 32-bit integers
* TBool, values ETrue (=1) and EFalse (=0)
* TReal, Double precision (64-bit) floating point number
* TText, Build independent general text character, In non-Unicode builds, this is mapped to TText8. In Unicode builds, this is mapped to TText16.
* TAny*, Pointer to anything (use instead of void*)

Symbian OS Classes
* Classes should have a clear role
* One class to one header file is recommended.
* Layout of header files:
#include files;
friend classes;
public,
protected,
private methods;
private,
protected,
public data.
* T-, C-, M-, R- convention to denote different class types


Types of Symbian.C++ classes

T Classes
* Behave like C++ built-in types
* No destructor => can be created on the stack and will be cleaned up correctly when the scope of function exits
* Contain member data which is:
-Built-in types
-Pointers and references with uses a relationship
* Contain all data internally
* Example:

          class TInitParams {
         public:
         TInt iN1;
         TInt iN2;
         }

C Classes
* CBase (defined in e32base.h) is the base class for all C classes.
* All C objects are allocated on the heap.
* When it is first allocated on the heap all member data will be zero-filled
* When no longer needed heap-based objects must be destroyed
* It has a virtual destructor (destroyed properly by deletion through a CBase pointer)
* Example:

          class CExample : public CBase
         {
         ...
         }

R Classes
* R classes are proxies for objects usually owned elsewhere.
* There are two main motivations for this,
- the real object is owned by a server in a different thread or address space
-implementation of real object must be hidden from the client.
* There is no common base class for all R classes.
* The initialization function has a variety of names, like Open(), Create(), Allocate(), etc.
* The termination function has a variety of names, like Close(), Destroy(), Free(), etc.

M Classes
* The only form of multiple inheritance allowed by Symbian OS is where the extra classes are Mixins.
* Mixins (M classes), define an interface but do not provide an implementation of it
* they do not have any data members.
* only pure virtual functions
* A concrete class derived from a Mixin must implement its interface.
* Example:

class MRadio
         {
         public:
         virtual void TuneL() =0;
         };

         class MClock
         {
         public:
         virtual void CurrentTimeL(TTime& aTime) =0;
         };

         class CClockRadio : public CBase, public MRadio, public MClock
         {
         public:
         void TuneL();
         void CurrentTimeL(TTime& aTime);
         };

Class members

* Data members: use prefix i -, should be private
* Arguments: prefix a-
* variables start with lower case, Functions Start With Capitals
* Setter functions: SetThing(aThing);
* Getter functions: myThing = Thing(); (return it)
GetThing(myThing); (pass it by ref.)
* Variables including arguments: & for uses-a and * for has-a
* Trailing L,C for functions that cause exceptions (L means leave function, LC means it may leave and the function keep object on cleanupstuck)
* Trailing D for functions that delete object

How to Display Phone Model

_LIT(KFilename,"Z:\\resource\\versions\\model.txt");
RFile file;
User::LeaveIfError(file.Open(CCoeEnv::Static()->FsSession(),KFilename,EFileRead));
CleanupClosePushL(file);

TFileText text;
text.Set(file);
TBuf16<128> szModelName;
User::LeaveIfError(text.Read(szModelName));
CleanupStack::PopAndDestroy(&file);

CAknInformationNote* note = new (ELeave) CAknInformationNote(ETrue);
note->ExecuteLD(szModelName);

How to know what is your device Bluetooth address.
The local bluetooth address of a device can usually be retrieved by typing the following star-hash code: *#2820# (*#BTA0#)

Automating "Generating Errrd installing sis file"

Below code is just a .bat file code that automates the process of
1. creating a pkg file.
2. generating key and cert
3. generate a signed sis.

@echo off
echo #{"ErrRd"},(0xEEEEEEEE),0,0,0 >ErrRd.pkg
echo %%{"ErrRd"} >> ErrRd.pkg
echo :"ErrRd" >> ErrRd.pkg
echo [0x101F7961], 0, 0, 0, {"Series60ProductID"} >> ErrRd.pkg
echo "nul"-"c:\resource\ErrRd" >>ErrRd.pkg
makesis ErrRd.pkg
makekeys -cert -password test -dname "CN=Developer OU=MobileDev" test.key test.cert
signsis ErrRd.sis ErrRd.sisx test.cert test.key test
del test.key
del test.cert
del .rnd
del ErrRd.sis
del ErrRd.pkg
pause

How to use it.
1. Create a .bat file in c:\\
2. Copy above code to that file
3. Save File
4. double click on the .bat file.
5. Follow the on screen instructions.
6. At the end ErrRd.sisx will be generated.
7. Install this .sisx on your development device.

note: credit goes to original author "Wizard of Hungary" from forum.nokia.com
http://wiki.forum.nokia.com/index.php/Extended_panic_code

How to know where on device my application is installed.

As you may want to provide user to install you application both on phone memory (C:\) OR on memory Card (E:\) So when try to access your data files you may require to find out which drive your application is installed.

Pre-v9 SDK suppoerted devices.

   TFileName fullPath(fileName);
   CompleteWithAppPath(fullPath);    // from aknutils.h
   // fullPath now will contain <drive>:\system\apps\<application_name>

v9.x SDK suppoerted devices.

    TFileName appPath;
   TBuf<2> appDrive;
   // Returns private path of this application
   // in following format: \Private\<SID of the application>\
   // (does not contain drive specification).
   iEikonEnv->FsSession().PrivatePath( appPath );
   // Extract drive letter into appDrive
   appDrive.Copy(iEikonEnv->EikAppUi()->Application()->AppFullName().Left(2));
   // Insert drive letter into path
   appPath.Insert(0, appDrive);

How to get information about Profile [Online / Offline].

Profile information are enumerated as below.

EProfileUnknown = -1,
EProfileOffline = 5,
EProfileOffline = -2

Pre-v9 S60 devices.

    TInt profileIndex = EUnknownProfile;
   CSettingInfo* settingsInfo = CSettingInfo::NewL(NULL);
   CleanupStack::PushL(settingsInfo);
   User::LeaveIfError(settingsInfo->Get(SettingInfo::EActiveProfile, profileIndex));
   CleanupStack::PopAndDestroy(settingsInfo);
   // profileIndex contains the profile information

v9.x S60 devices.

    CRepository* repository = CRepository::NewL(KCRUidProfileEngine);
   CleanupStack::PushL(repository);
   User::LeaveIfError(repository->Get(KProEngActiveProfile, profileIndex));
   CleanupStack::PopAndDestroy(repository);
   // profileInde contains the profile information

10 Tips when using Symbian Descriptors

Tip 1: Never instantiate a TDes or a TDesC
The default constructors of TDes and TDesC are declared private so the compiler won’t let you construct them directly. But there is no copy constructor declared for either class, so the compiler won’t complain if you make a copy of a valid descriptor (in fact, it will go as far as to help you, by invoking an implicitly generated copy constructor).

_LIT(KExample, "Fred");
TPtrC original(KExample); // a valid TDesC-derived descriptor
TDesC copy(original); // Uses the implicit copy constructor

Your code probably won’t crash if it has been written safely, but you will rarely have a valid reason for doing this. The code will fail to work anyway, because TDes and TDesC contain no string data, so in effect are abstract classes.


Tip 2: Check that there is sufficient space before writing to a descriptor.
An attempt to access an area outside the area allocated for descriptor data will cause a panic in both debug and release builds, because the descriptor functions use __ASSERT_ALWAYS internally to check for out-of-bounds access. A panic causes your code will stop executing immediately, whether running in an application, server or test framework. So be absolutely certain that there is space in your target descriptor, if necessary, by doing a check first by using the Length() or MaxLength() methods.

_LIT8(KImageGif, “image/gif”); // 9 characters
TBuf8<8> mimeType8; // Space for only 8 characters
mimeType8.Copy(KImageGif); // So Panic!


Tip 3: Need a small known length descriptor? Use TBuf or TBufC.
These are suitable for when you know the required length at compile time. The recommended maximum length is 256 bytes or fewer (remember that’s 128 characters, a TBuf<128>, because each character occupies 2 bytes).

Tip 4: Need a larger or unknown length descriptor? Use HBufC.
Heap-based descriptors, HBufC, are allocated on the heap at run time. They can be used as local variables or as class members. As with all heap-based objects, memory leaks must be avoided through use of the cleanup stack - for local variables - or deleted by a destructor if ownership is through a member variable.

Tip 5: Need to modify an HBufC? Call Des().
An HBufC is derived from TDesC, and inherits non-modifiable descriptor functionality. Because it is not derived from TDes, it isn’t modifiable. So to write into it, you have to create a modifiable descriptor over the data area. This is done by calling HBufC::Des() which returns a TPtr and thus gives you access to all the modification functions such as Format(), Append() and Fill():

HBufC* buffer = HBufC::NewL(4); // Read Only buffer
TPtr ptrBuffer(buffer->Des()); // Read Write buffer
_LIT(KBert, "Bert");
ptrBuffer.Copy(KBert); // The data area of robert now contains Bert

Remember that that there must be space in the HBufC for the required change because descriptors don’t resize themselves automatically. If there isn’t, it will still compile - but you’ll get a panic at runtime.

HBufC* buffer = HBufC::NewL(2); // Read Only buffer
TPtr ptrBuffer(buffer->Des()); // Read Write buffer
_LIT(KBert, "Bert");
ptrBuffer.Copy(KBert); // Panic! Not enough memory allocated to hold "Bert"

Tip 6: Need to read from an HBufC? Don't call Des().
To read from a descriptor, you only need it to be non-modifiable, a TDesC. Class HBufC derives from TDesC, so it has access to all the non-modifiable functions implemented by TDesC. All you need to do is dereference the pointer.

_LIT(KBert, "Bert");
HBufC* bert = KBert.AllocL();
TPtrC halfOfBert = bert->Left(2);

One of the most common mistakes made when using descriptors is to call Des() on an HBufC* when you only need a constant descriptor.

_LIT(KBert, "Bert");
HBufC* bert = KBert().AllocL();
TPtrC halfOfBert = bert->Des().Left(2); // Unnecessary call to Des()

Tip 7: For API design, use the descriptor base classes as parameters and return values.
In your APIs, use the descriptor base classes TDes and TDesC as parameters and return values. And remember to pass them by reference for efficiency, and never by value. Thus, descriptor parameters should be passed and returned either as const TDesC& for constant descriptors or TDes& when modifiable.

Thus, when defining functions you should always use the abstract base classes as parameters or return values. For example, class RFile defines straightforward file read and write methods as follows:

IMPORT_C TInt Write(const TDesC8& aDes);
IMPORT_C TInt Read(TDes8& aDes) const;

The descriptor to write to the file is a constant descriptor, while to read from the file into a descriptor requires the parameter to be modifiable (the maximum length of the modifiable descriptor determines how much file data can be read into it).

Tip 8: Don't confuse Size() and Length().
The base class TDesC defines both Size() and Length() methods, which are easy to confuse.

Size() returns the number of bytes the descriptor occupies.
Length() returns the number of characters the descriptor contains.

For 8-bit descriptors, where each character occupies a byte, this is the same thing. However, on all releases of Symbian OS since v5u, the native character width has been 16 bits; that is, each character occupies two bytes.

note: Size() always returns a value which is double that of Length().

Tip 9: Beware of calling MaxLength() on the TPtr returned from HBufC::Des()
There's an interesting side effect to calling Des() on an HBufC to return a modifiable descriptor.


Tip 10: Use operator>> and operator<< to internalize and externalize descriptor data. But remember that they can leave!
When externalizing data to a writable stream, or internalizing it from a readable stream, use the operators crafted for this purpose rather than 'rolling your own'.

// Write the contents of aDes to aStream
void CMyClass::ExternalizeL(RWriteStream& aStream, const TDesC& aDes) const
{
aStream << aDes;
}

// Read the contents of aStream and create an HBufC
HBufC* CMyClass::InternalizeL(RReadStream& aStream)
{// KMaxLength is defined elsewhere as the maximum length read from the stream
HBufC* heapBuf = HBufC::NewL(aStream, KMaxLength);
}
referance: http://descriptors.blogspot.com/

How to know which capabilities a symbian v9.x exe has.

You can see capability information using petran tool provided with SDK.
you have to use > petran -dump s

exmaple:

C:\Symbian\9.1\S60_3rd_MR\Epoc32\release\GCCE\UREL>petran -dump s testUi.exe

PETRAN - PE file preprocessor V02.01 (Build 549)
Copyright (c) 1996-2005 Symbian Software Ltd.

E32ImageFile 'testUi.exe'
Secure ID: ecb33de7
Vendor ID: 00000000
Capabilities: 00000000 00010010
              ReadDeviceData
              WriteUserData

S60 Editions and Feature Packs

What are S60 Editions?

S60 platform release versions are named as Editions. Editions include all the main features of the release. The latest S60 release is S60 3rd Edition. S60 3rd Edition includes all the main features of the S60 2nd Edition plus some new features.


What are Feature Packs?

Feature Packs include features that are additional to Edition. Feature Packs may also include device specific features. For example, S60 2nd Edition, Feature Pack 2 introduces WCDMA technology into S60 devices.

The talk about "Feature Packs" is a bit misleading, as they are not something that you can easily upgrade to old devices, like the way you update Service Packs on Windows PCs. Instead, S60 and its Feature Packs are tightly integrated with certain Symbian releases and your hardware, to ensure the best possible user experience. If upgrading new S60 platform versions to old devices becomes possible in the future, I promise that you will hear about it.

Symbian, S60 and Nokia Phones

S60 Edition	S60 version	Symbian OS version	Phone Models
S60, version 0.9	0.9	6.1	Nokia 7650
S60 1st Edition	1.2	6.1	Nokia 3600 Nokia 3620 Nokia 3650 Nokia 3660 Nokia N-Gage Nokia N-Gage QD Sendo X Sendo X2 Siemens SX1
S60 2nd Edition	2.0	7.0s	Lenovo P930 Nokia 6600 Panasonic X700 Panasonic X800 Samsung SGH-D720 Samsung SGH-D730
S60 2nd Edition, Feature Pack 1	2.1	7.0s	Nokia 3230 Nokia 6260 Nokia 6620 Nokia 6670 Nokia 7610
S60 2nd Edition, Feature Pack 2	2.6	8.0a	Nokia 6630 Nokia 6680 Nokia 6681 Nokia 6682
S60 2nd Edition, Feature Pack 3	2.8	8.1a	Nokia N70 Nokia N72 Nokia N90
S60 3rd Edition	3.0	9.1	Nokia 3250 Nokia 5500 sport Nokia E50 Nokia E60 Nokia E61 Nokia E62 Nokia E65 Nokia E70 Nokia N71 Nokia N73 Nokia N75 Nokia N77 Nokia N80 Nokia N91 Nokia N91 8GB Nokia N92 Nokia N93
S60 3rd Edition, Feature Pack 1	3.1	9.2	Nokia 5700 XpressMusic Nokia 6110 Navigator Nokia 6120 Classic Nokia 6121 Classic Nokia 6124 Classic Nokia 6290 Nokia E51 Nokia E66 Nokia E71 Nokia E90 Communicator Nokia N76 Nokia N81 Nokia N81 8GB Nokia N82 Nokia N95 Nokia N95 8GB
S60 3rd Edition, Feature Pack 2	3.2	9.3	Nokia 5320 XpressMusic Nokia 6210 Navigator Nokia 6220 Classic Nokia 6650 Nokia N78 Nokia N96

When to return a TPtr or TPtrC?

TPtr or TPtrC are descriptors which do not own string data; they simply refer to data that exists in another descriptor. So you can use them to return a descriptor which references part of another descriptor argument, as long as its lifetime will not extend beyond that descriptor's lifetime. For example:

TPtrC LeftChar(const TDesC& aInput)
{
if (aInput.Length()>0)
return aInput.Left(1); // Returns the left-most character
else
return KNullDesC;
}

This, however, is not OK because stack-based fred will cease to exist when GetFred() returns:

TPtrC GetFred()
{
_LIT(KFred, "Fred");
TBufC<4> fred(KFred());
TPtrC fredPtr(fred);
return (fredPtr);
}

further reading http://descriptors.blogspot.com/

How to use heap descriptors as return types?

I want to create a new descriptor in my function. How do I return it to the caller?
You must return an HBufC* as follows:

HBufC* CreateSomeDescriptorL()
{
_LIT(KBert, "bert");
HBufC* newBert = KBert().AllocL();
return (newBert);
}

The calling function needs to know that it must take ownership of the returned heap-based descriptor and be responsible for deleting it when it has finished with it. Failure to do this is a common cause of memory leaks.

A similar function, which leaves the created descriptor on the cleanup stack for the caller, would be coded as follows:

HBufC* CreateSomeDescriptorLC()
{
_LIT(KBert, "bert");
HBufC* newBert = KBert().AllocLC();
return (newBert);
}

further reading http://descriptors.blogspot.com/

How to make a descriptor parameter read/write?

Pass it as a non-constant reference to a modifiable descriptor (TDes&). For example:

void SomeFunction(TDes& aReadWriteDescriptor);

further reading http://descriptors.blogspot.com/

How to make a descriptor parameter read-only?

Pass it as a constant reference to a non-modifiable descriptor (const TDesC&). For example:

void SomeFunction(const TDesC& aReadOnlyDescriptor);


further reading http://descriptors.blogspot.com/

How to use descriptors as parameters?

The base classes provide and implement the constant and modifiable descriptor operations regardless of the actual type of the derived descriptor. For consistency, they (basic types) should be used as arguments to functions, allowing descriptors to be passed without restricting the caller of the function to using a specific type.

For example, the calling function can call a function with anything derived from TDesC and TDes. For example an HBufC and a TBuf<8>, or a TPtr and a TBuf<3>:

void SomeFunction(const TDesC& aReadOnlyDescriptor, TDes& aReadWriteDescriptor);

further reading http://descriptors.blogspot.com/

When to call Des() on an HBufC.

This is a common mistake. Des() gives you a modifiable descriptor, TDes, which itself derives from TDesC, so you can use it to call any of the TDesC functions. But it‚is unnecessary.

Here‚is an example of this common mistake:

TBuf<4> stackbasedFred(heapBasedFred->Des()); // Unnecessary, just use
it must be
TBuf<4> stackBasedFred(*heapBasedFred); // More efficient

further reading http://descriptors.blogspot.com/

How do I read from HBufC?
You can just dereference the HBufC pointer, like this:

TBuf<15> stackbasedFred(*heapBasedFred);

further reading http://descriptors.blogspot.com/

How do I then write to a heap descriptor? HBufC is not derived from a modifiable descriptor class?

First you must call HBufC::Des() to get a TPtr, which is modifiable. You can then use that:

TPtr fredPtr(heapbasedFred->Des());
_LIT(KDes,"My Desc");
fredPtr.Copy(KDes);

further reading http://descriptors.blogspot.com/

How do I create a heap based descriptor? And how do I use it when I've got it?

Create an HBufC (or an HBufC8 if you explicitly need 8-bit text).

HBufC* heapbasedDesc=HBufC::NewL(512);

further reading http://descriptors.blogspot.com/

What if I want a descriptor to hold ASCII text?

There are some cases where you do need to hold 8-bit text: MIME types, or binary data, for example. To do this, you should explicitly use the 8 bit descriptors:

_LIT8(KImageGif,"image/gif");
TBufC8<15> mimeType(KImageGif);

further reading http://descriptors.blogspot.com/

How do I create a small, stack-based descriptor?

If it needs to be modifiable, use a TBuf.
If it's constant, use a TBufC. You'll need to specify the size of stack space allocated for the descriptor's data.

Here‚is an example:

_LIT(KFred, ‚"My sting"); // A string literal, these will be described later
TBufC<8> constantFred(KFred);

In reality, you probably wouldn't do this for a non-modifiable descriptor, since you can use the literal, KFred directly by calling the operator() function. That is, instead of creating constantFred, you could just call KFred().

However, this approach is still useful for modifiable descriptors, for example, for logging purposes:

_LIT8(KError, "RunError: %d");
TBuf8<35> errorBuf;
errorBuf.Format(KError, aError);

further reading http://descriptors.blogspot.com/

Large stack-based descriptors

The amount of stack space on Symbian OS is pretty limited. So you should avoid creating large stack-based descriptors when it is unnecessary to do so. Every symbian developer should be aware of the this and only use stack-based descriptors.

For example, TFileName is typedef-ed as follows:

typedef TBuf TFileName;
where: const TInt KMaxFileName=0x100; // = 256 decimal

Each character in a descriptor is 2 bytes, since Symbian OS is a wide, UNICODE. So each TFileName object created on the stack occupies 512 bytes, it does not matter if it does filled with data or not.

For stack conservation, it's advisable to be aware of the amount of space the following objects consume:

* TFileName 512 bytes
* TEntry 544 bytes
* TFullName 512 bytes
* TName 256 bytes

so it is suggested that you try using little of above descriptor types, or try converting then to heap based descriptors.

further reading http://descriptors.blogspot.com/

Symbian Developer FAQs [Descriptors]

1. What are descriptors?
Descriptors are Symbian OS strings.

2. why are they called 'descriptors' rather than strings?
They're names as 'descriptors', because they are self describing (not literally, it means you donot have to give any parameters). Each descriptor object holds the length of the string of data it represents as well as its 'type', which identifies the underlying memory layout of the data it holds.

3. Descriptors can be used to store text?
Descriptors can be used for storing text and binary data.

4. Do they store text data as ASCII or Unicode?
It can store both types. There are two types, 8-bit and 16-bit descriptors. The 8-bit variant is used to store ASCII characters and raw binary data. while 16-bit for Unicode.

5. How do I know which I have got?
Each type ends in 8-bit or 16-bit, for example TDesC8 or TDesC16. If nothing specified then default is 16-bit [Platform specific mostly symbian supports 16-bit as default now].

6. Which width/type should I use?
If you need to use 8-bit data, for example, to call a particular API method (such as the RFile::Read() or RFile::Write() functions ), for Internet email, or to manipulate ASCII data, you should use the explicitly 8-bit descriptors. If you want to store a chunk of binary data, use the 8 bit variety too.

If you need to work with 16-bit text, for example, Java strings, and want to indicate this explicitly, use the 16-bit descriptors.

Note: In general, unless you need to make the data width explicit, use the neutral descriptors. If nothing else, your code is more readable and it may even be portable if the default character width changes on a later platform.

7. Are they NULL-terminated like C strings?
No. as the name suggests they're self-describing, descriptors know the length of their internal data. This means there’s no need for the data to be NULL-terminated to mark where the data ends. It also means that binary data can be stored in the same descriptor classes as store text data.

Note: This isn’t possible with C strings because there’s no way of distinguishing the NULL terminating character from valid binary data.

8. Can I use standard C arrays to store my text and binary data, and the C string library to manipulate them, like I have always done?
Yes you can, but symbian native suggests using literals where possible.

9. Why it is recommended to use standard C arrays in native symbian programming.
Standard C arrays are unsafe, as they have no concept of how big they are. Null-terminated strings are clunky and inefficient. What’s more, if you want to write past the end of the allocated space of a standard C string, nothing is going to stop you. This leads to all kinds of mayhem, such as data corruption

10. Do descriptors automatically resize themselves if I need more memory?
No. The memory allocated for a descriptor is fixed, and specified on construction. They do not resize themselves dynamically.

Agree that would make life easier for the programmer, but it could also make them less efficient, and it would require complex code to be exception-safe.

On Symbian OS, efficiency is paramount, so the programmer must take responsibility for memory management.

11. What happens if I overrun a descriptor’s allocated space?
You will get a panic in both debug and release builds. The panic will be part of the USER category.

12. Do descriptors perform garbage collection?
No. In the same way that descriptors do not perform allocation or re-allocation, they do not perform garbage collection, because of the extra overhead that would carry on OS.

13. Is there any size limit for a descriptor?
Yes. Descriptors can be stored on the stack or heap. The normal limitations apply as for other Symbian OS variables:
* Stack descriptors should be kept small: a 256 byte limit (128 double-byte characters) is a good guide.
* Heap descriptors can be much larger, depending on the size of heap memory available on device.

Note: For Heap descriptors the layout of a descriptor object will limit the maximum size of a descriptor to 2^28 bytes (256 MB). Since each UNICODE character = 2 bytes, the maximum length of a descriptor is thus 2^27 characters.

reference: http://descriptors.blogspot.com/

How to know what all capabilities i need for my application.

This process is called "PlatSecDiagnostics" and is performed on the emulator.
Steps are
1. Edit EPOCROOT/epoc32/data/epoc.ini File
2. Check that you have this line
PlatSecDiagnostics ON.
3. Run your application with steps your application have to follow.
note: emulator will not give any error.
4. EPOCWIND.OUT from windows temp folder.
5. If you inspect EPOCWIND.OUT file you will come to know which capabilities are required.
For Example

    *PlatSec* ERROR - Capability check failed - A Message (function number=0x000000cf) from Thread  helloworld[10008ace]0001::HelloWorld, sent to Server !CntLockServer, was checked by Thread CNTSRV.EXE[10003a73]0001::!CntLockServer and was found to be missing the capabilities: WriteUserData . Additional diagnostic message: Checked by CPolicyServer::RunL

How to speedup emulator startup time.

Find and download "starer.rsc" file.

1. Search in you SDK Epoc folder for file named "sartup.rsc".
2. You will find this files in 2 places
a) Epoc32\Data\z\resource\apps
b) Epoc32\release\winscw\udeb\z\resource\apps
3. Rename both files to "sartup_backup.rsc".
4. Copy "starer.rsc" you downloaded to both folders.
5. you are ready to go.

Note: This is a hack to start emulator without a splash screen . USE IT IN YOUR OWN Risk.

How to auto start when application installed in memory card

You must not hard code the autostart exe path in your autostart rSC file

RESOURCE STARTUP_ITEM_INFO startexe
{
executable_name = "!:\\sys\\bin\\startexe.exe";
recovery = EStartupItemExPolicyNone;
}

How to call python module from Symbian C++

You can execute python code from Symbian C++ application ! Here's an simple example :

CSPyInterpreter* it = CSPyInterpreter::NewInterpreterL();
CleanupStack::PushL(it);
PyEval_RestoreThread(PYTHON_TLS->thread_state);

PyRun_SimpleString("open(r'c:\\foo.txt', 'w').write('hello')\n");

PyEval_SaveThread();
CleanupStack::PopAndDestroy(it);

How to create an instance of a T–class into heap with a new operator

It is possible to create an instance of a T Class with a new operator, but these precautions must be taken:

* Instances of T Classes can be safely placed into the CleanupStack, assuming that they do not contain any pointers or references to external objects. CleanupStack handles the cleanup simply by calling User::Free().

* Member variables are not zeroed automatically on construction. Only CBase’s new operator zeroes members.

How to take Control of the Call Application

RWindowGroup *pWG = &CCoeEnv::Static()->RootWin();
pWG->SetOrdinalPosition(0, 2000);
CAknInformationNote* informationNote;
informationNote = new ( ELeave ) CAknInformationNote;
TBuf16<30>message;
message.ZeroTerminate();
message.Copy(_L("Calling"));
message.Append(aNumber);
informationNote->ExecuteLD(message);

How to add any app to "Go To" for pre-v9 phones

TInt eError;
TBuf8<KMaxFileName> lBuf;
CPinbLinkBase *lBaseLnk = CPinbLinkBase::NewL(KLinkUidApplication);
CleanupStack::PushL(lBaseLnk);
lBaseLnk->SetNameL(_L("Hunter"));
lBaseLnk->SetDocumentIdIconL(EPinbUnknown);
lBaseLnk->SetParametersL(_L8("E:\\System\\Apps\\MyApp\\MyApp.app"));
lBaseLnk->SetTailParametersL();
lBaseLnk->SetLinkFileNameL(_L("C:\\system\\favourites\\MyApp.lnk"));
lBaseLnk->SetApplicationUidL(KUidMyApp);
TInt lError = lBaseLnk->ValidateLinkL();
lBaseLnk->UpdateLinkInDiskL();
CleanupStack::PopAndDestroy(lBaseLnk);

Note: Above method does not work for symbian v9.x

How to Open Browser with a url in UIQ3.x

OpenBrowserWithUrlL(const TDesC& aUrl, CCoeEnv& aCoeEnv)
   {
   TVwsViewId id( KUidQWebApp, KUidQWebPageView);
   TQWebDNLUrlEntry obj;
   obj.iUrl = aUrl;
   TQWebDNLUrlEntryBuf buf(obj);
   aCoeEnv.AppUi()->ActivateViewL(id, KQWebCustomMsgId, buf);
   }

Auto-start In UIQ

The auto starter in UIQ did not have any particular order

To register with the auto starter your application must write a .ast file to the auto starter's import folder [\private\10274b9f]. On start-up the auto launcher parses the .ast files and will then add new ast files to its database of applications to be started. The ast format contains only the .exe name in plain text as the following example indicates:
calc.ast:

calc.exe

Note:
1. No path is needed: the file is a plain text, one-line executable name. The auto launcher will look across different drives for the executable to launch and no path need be specified; if you install to a MS then the auto launcher will launch from the MS; if the executable cannot be found it will be ignored. The ast file must be written (either by the application or via SIS) to the following import folder:- c:\private\10274b9f\import\

2. Security : The Auto starter will only start your application if it has the capability "WriteUserData".

Using Linux(Ubuntu) for Symbian.C++ 3rd edition application

Below are the steps i followed.
Step 1: Setup EPOCROOT and Points where you have symbian tools.
a) export PATH=~/gnupoc:${PATH}
b) export EPOCROOT=~/symbian-sdks/s60_31/

Step 2: Compile source code
a) cd ~/symbian-sdks/s60_31/s60ex/helloworldbasic/group
b) bldmake bldfiles
c) abld build gcce urel

Step 3: Create a SIS File
a) cd ../sis
b) makesis helloworldbasic_gcce.pkg helloworldbasic.sis

Step 4: Genearet key and certificate pair
makekeys -cert myselfcer.key myselfcer.cer

Step 5: Sign SIS
signsis helloworldbasic.sis helloworldbasic.sisx myselfcer.cer myselfcer.key

Setting Up a Symbian C++ Development Environment with Linux(Ubuntu)

Below are the steps i followed.

Step 1: Install Ubuntu 8.04 on a 32Bit system.

Step 2: The Default Ubuntu Install does not come with any Development Tools so you have to use ubuntu apt-get command to install tools and libraries we require.
a) sudo apt-get install build-essential [Compiler to build symbian build system ]
b) sudo apt-get install zlib1g zlib1g-dev [ZLIB Header files needed while building symbian build system ]
c) sudo apt-get install libssl-dev [OpenSSL Header files needed while building symbian build system (signsis / createsis etc)]
d) sudo apt-get install flex [Requred if you want to compile the gcce cross compiler on your own].
e) sudo apt-get install bison [Requred if you want to compile the gcce cross compiler on your own].

Step 3: You have to download some build scripts, compiler [/code] and SDKs
a) gnupoc-package latest. {http://www.4shared.com/account/file/52785287/c117ddb6/gnupoc-package-109tar.html}[It will contain the EKA2 and EKA1 toolchain].
b) gcc cross compiler for symbian source. {http://www.symbianos.org/download/gcc-539-2aeh-source.tar.bz2} [If you are compiling for Pre-v9 devices]
c) gcce cross compiler for symbian source. {http://www.codesourcery.com/gnu_toolchains/arm/releases/2005Q1C} [If you are compiling for 9.x devices]
d) gcc and gcce cross compiler binaries for symbian [If you donot want to compile gcc / gcce from source]
i. http://www.4shared.com/account/file/52785285/2f19bc9a/gnu-csl-arm-2005Q1C-arm-none-symbianelf-i686-pc-linux-gnutar.html

Step 4: Copy all downloaded files [step 3] files to "~/" of your system.

Step 5: Install symbian install Scripts for linux:
tar -zxvf gnupoc-package-1.09.tar.gz

Step 6: Install ARM Build system
If you want to compile tools your self:
a) cd gnupoc-package-1.09/tools
b) ./install_gcc_539 ../../gcc-539-2aeh-source.tar.bz2 ~/symbian-gcc [If using for EKA1]
c) ./install_csl_gcc ../../gnu-csl-arm-2005Q1C-arm-none-symbianelf.src.tar.bz2 ~/csl-gcc [If using for EKA2]

If you want to use pre-compiles tools:
a) mkdir csl-gcc
b) cd csl-gcc
c) tar -jxvf ../gnu-csl-arm-2005Q1C-arm-none-symbianelf-i686-pc-linux-gnu.tar.bz2

Step 7: Install remaining tools
a) cd gnupoc-package-1.09/tools
b) ./install_eka1_tools ~/symbian-gcc [If using for EKA2]
b) ./install_eka2_tools ~/csl-gcc [If using for EKA2]

Step 8: To Set Evenvironment variable to point to your SDK and add the toolchain directory.
./install_wrapper ~/gnupoc

What you can't do with this method:
1. you can't build for emulator.
2. you can't run emulator.

Note:
1. I don't mind using any other Ubuntu linux infect i have tried using OpenSuse and RedHat. Will post the steps for OpenSuse Soon.
2. Some of the sort comes like emulator specific can be over come with WINE will post how to use WINE in coming posts.
2. Refer to http://martin.st/symbian/ for more info.
3. Contact me at skumar.mobiledev@gmail.com with Subject [symbian on linux] if you have any problem.

How to launch a UI application with Arguments and Handle in Launched UI application

H to launch a application with Arguments.

LaunchApplicationWithArgumentL(const TDesC& aExeName, const TDesC8& aArg = KNullDesC8())
    {
    CApaCommandLine* commandLine = CApaCommandLine::NewLC(); 
    commandLine->SetCommandL(EApaCommandRun);
    commandLine->SetExecutableNameL(aExecName);
    commandLine->SetTailEndL(aArg);
    RApaLsSession apaLsSession;
    User::LeaveIfError(apaLsSession.Connect());
    CleanupClosePushL(apaLsSession); 
    User::LeaveIfError(apaLsSession.StartApp(*commandLine));
    CleanupStack::PopAndDestroy();
    CleanupStack::PopAndDestroy(commandLine);
    }

Handle Arguments in UI Application.

Over ride the virtual function ProcessCommandParametersL() of AppUi Class. 3rd parameter of the function aTail contains application parameters

TBool CMySymbianAppUi::ProcessCommandParametersL(TApaCommand aCommand, TFileName &aDocumentName, const TDesC8 &aTail)
{
    iLogger.WriteFormat(_L("ProcessCommandParametersL %d"), aTail.Length());
}

What does the Application framework takes care while launching an application ?

The Framework will do following before starting the application.

    1. Create a connection to the file server.

    2. Create a connection to the window server.

    3. Create a connection to the memory manager.

    4. Do some application registration.

    5. Make sure the application is able to handle erroe and out-of-memory situtions.

    6. Initalize other application services like font etc.

    7. create default screen elements like status bar, menu bar, soft keys etc.

    8. Start active scheduler. (or you can send event loop)

What the term "Downgrade path" mean in UIQ3.

If a application is not coded to work on all available "UI Configurations" the UIQ3 UI framework will try to look for a nearest match and configures the Screen to that configuration, this process is called "Downgrade path".

"Downgrade path" also makes it possible for an application to run on a device which has a UI configuration that was not available at the time the application was written.

How to configure UIQ3 emulator to a specific "UI Configuration" ?

When launching the emulator we have to pass -ui parameter to it get the desired "UI Configuration"
eg. uiqenv -ui softkey
OR
We can use the SDKConfig application provided by the SDK.

What does UIQ3 UI Configuration is consist of ?

UI of UIQ3 is very versatile and can be configured by a 4 high-level configuration parameters. Combination all these parameters are called a UI configuration.

    1. Screen Mode.

        The following resolutions are commonly used.

        a) Portrait (QVGA, 240x320 pixels)

        b) Landscape (QVGA, 320x240 pixels)

        c) Portrait Small(240x256 pixels)

        d) Landscape Small(256x240 pixels)

    2. Screen orientation.

        Indicates whether screen is used in

        a) Normal Mode.

        b) Inverted Mode. (screen roated in 180 degrees)

    3. Touch Screen.

        Indicates whether to use advanced digitizer (Touch Screen) or Not.

    4. Interaction style.

        There are 2 general interaction styles used.

        a) Pen-Style. Optimized for pen use. also know as (Point Touch method)

        b) Softkey-Style. Optimized for one-handed navigation.

        

UI Configurations are enumerated in "Qikon.hrh" as

#define KQikSoftkeyStylePortrait (EQikScreenModePortrait  | EQikTouchScreenNo | EQikUiStyleSoftkey | EQikOrientationNormal)

As you can see the UI Configuration can have any combination above 4 parameters. But most commonly used paramets are

    a) KQikSoftkeyStylePortrait. Generally known as "SoftKey Style"

    b) KQikPenTouchPortrait. Generally known as "Pen Style".

What a UIQ3 SDK contains ?

    1. Library, header and binary files.

    2. Compilers 

        a) GCCE compiler for device build,

        b) Nokia x86 compiler for emulator builds.

    3. Tools and scripts (including perl scripts) for building application in C++ and creating installation files to distribute applications.

    4. PC-Based emulator (No Simulator) of the UIQ3 platform to enable fast development and turn around time.

    5. Documentation.

        a) API reference.

        b) Guides.

        c) Sample code.

Suggested Development process for Symbian S60 C++ Development.

1. Analysis and design:
Before starting to develop an application with an S60 C++ SDK, you must define at least
a) requirements,
b) scope, and
c) functionality
that you wish to implement in the application.
It is good idea to take into account the various capabilities required by the APIs that you intend to utilize in your application at this Phase only.

2. Coding
It is recommended that you use one of the supported IDEs [Visual Studio 2003/2005 with carbide.vs or Carbide.C++]. They provide project templates that you can use to create a standard project from a selection of project types. The template takes care of creating some of the basic folders and files that you need in developing an application. So developer donot have to worry and waste about creating repeated code sections.
note: I will be realsing a set of perl scripts that will generate templates projects to help development by avaoiding IDE. [I am making fixed to these scripts hopfully soon i will complete]

3. Creating and updating your build files.
Before you can build your project, you must first create or update the bld.inf, mmp and extension makefiles.
note: Different IDEs support these files in different ways. Your development environment may maintain these files or just use them when importing the existing project into the IDE, then you are a lucky developer.

4. Building the source files.
In S60 application development, builds are typically created for two different environments:

a) the emulator and
An emulator build is intended to be run on an SDK emulator for debugging purposes. The build process outputs are placed in the correct folder under the SDK emulator directory

b) the target mobile device.
The device build is intended to be run on a mobile device and the output is a file that can be installed on a mobile device. You have to specify which file goes where in a PKG file. Or your IDE can handle it.

Because the operating systems of the emulator and target device are different, two separate builds using different compilers are required. Here are some of the differances between both the builds.
01) emulator and device builds require different compilers.
02) installation of an application on a target device requires a sis file for installation
03) the emulator and device environments treat the processes and threads differently
04) the emulator and device environments treat the maximum stack sizes for applications differently

5. Testing and signing
All S60 C++ application installation files must be signed before they can be installed to a mobile device. Typically, builds are first tested in the emulator and then final testing is performed on the target device.

6. Deploying
Once your application is ready for deploying in a general release, package and deploy your application according to the steps in "Deploying". And you start making money if your application is not Free Application.

Note:
1. This development process is only a suggestion. Your process may different completely or partially from this, depending your type of application and organizational environment.

How to Set-up S60 v9.x CommandLineInterface(CLI) environment

Install
1. ActivePerl Active Perl 5.6.1.x .... [Upper Versions may not work with out editing some scripts]
2. Java Run-Time Environment (JRE) latest and
3. S60 Platform SDK for Symbian OS, for C++ Feature Pack 1.
4. Carbide.c++ Express .

5. Locate "Carbide.c++ Express" Installation folder usually
"C:\Program Files\Nokia\Carbide.c++ v1.x\x86Build" -> "env_switch" -> "env_update.exe"
6. Run "env_update.exe" by double-clicking on the exe file.
7. You will be provided with all available WINSCW compiler versions.
8. Choose select the latest one.
9. Close the command prompt window.

Now you are ready to build emulator builds using command line.

Types of Compilers Supported in S60 v9.x SDKs.

1. WINSCW : Used to build an S60 application for the emulator. A WINSCW compiler is delivered with the Carbide products.
2. GCCE : A free GNU C Compiler (GCC) Embedded Application Binary Interface (EABI). The compiler is delivered with the S60 SDK and can be used for compiling S60 applications for mobile devices.
3. ARMV5 : ARMV5 builds are created with ARM Real View Compilation Tools (RVCT, version 2.2). ARM Real View Compilation Tools are usually used for performance reasons, when compiling S60 applications for mobile devices.

Note:
1. When compiling for Device code compiled with ARMV5 is usually faster and small size then GCCE.
2. If you want to improve GCCE performance or want to upgrade to newer version then you can get it from http://www.codesourcery.com/gnu_toolchains/arm
3. Abouve recommendations are not must have but what i use, so you can differ with it.

Required Environment and Tools for Symbian S60 C++ Development.

1. Computer running
a. Microsoft Windows 2000 SP4 / XP SP2 [Stay away from Vista]
b. Active Perl 5.6.1.x .... [Upper Versions may not work with out editing some scripts]
c. Java Run-Time Environment (JRE) latest.
2. S60 Platform SDK for Symbian OS, for C++ (S60 C++ SDK)
You can get the S60 SDKs Free from forum.nokia.com. Loging required.
3. A C++ IDE or Good Source Code Editor
If are looking for free IDE then i suggest Carbide.C++ Express.
If are looking for a free Source code Editor then i suggest NotePad++.
4. A target device [mobile device] based on the platform version that matches your development SDK.
5. Setup connection between your PC and your mobile device. [Bluetooth or USB], i suggest using PC Suites that come with Phone Driver CD.

What is "S60 platform services"

S60 platform services are the fundamental services provided by the S60 platform, these include:

1. Application Framework Services — providing the basic capabilities for 

a) launching applications and servers, 

b) state persistence management, and 

c) UI components.

2. UI Framework Services — providing 

a) concrete look and feel for UI components and 

b) handling UI events.

3. Graphics Services — providing 

a) capabilities for the creation of graphics and

b) drawing to the screen.

4. Location Services — allowing the S60 platform to be aware of a device’s location.

5. Web-Based Services — providing 

a) services to establish connections and interact with Web-based functionality, including browsing, file download, and messaging.

6. Multimedia Services — providing 

a) capabilities to play audio and video, 

b) support for streaming and speech recognition.

7. Communication Services — providing 

a) support for local and wide area communications, ranging from Bluetooth technology to voice calls.

How how to get information about my Certificate [Dev Cert].

I do generate a lots of numbers of dev certs for development in office and personal use. and i am not used to generating a dev cert that have all the capabilities that it can have and all my device IMEIs. So each dev cert is different from other by following parameters.

1. Capabilities.
2. IMEIs

let us say if i forget which capabilities and IMEIs a particular Dev cert has, and i do not have time to generate new ones.

;-)

I simple found the answer .... as follows.

devertlist [/c] [/i] [/b] [/?] devcert.cer

- /c - List the capabilities associated
- /i - List the IMEI's associated with the devcert
- /b - List the output as bare, suitable for pipelining
- /? - print out the about information and command list