Tuesday, August 26, 2008

Nokia N85 - The definitive entertainment package

Espoo, Finland - Nokia today unveiled the Nokia N85, the latest Nokia Nseries multimedia computer made to set new standards for mobile entertainment, gaming and sharing. Along with an eye-catching 2.6" OLED screen and smooth, sleek finish, the Nokia N85 redefines the mobile experience. It boasts N-Gage gaming, music with in-built FM transmitter, 5 megapixel camera with Carl Zeiss optics and geotagging capabilities, three month integrated license for turn-by-turn voice navigation and high-speed connectivity, all in one device. The Nokia N85 is expected to begin shipping in October 2008 with an estimated retail price of EUR 450, before taxes and subsidies.




"The Nokia N85 was created to be more than the sum of its parts, offering a complete mobile entertainment package designed for connecting, sharing and discovering," said Juha-Pekka Sipponen, Director, Nokia Nseries. "The iconic Nokia Nseries dual slider design has evolved to become smaller and sleeker while integrating the newest features and services to deliver the best mobile experience to date."




With a strong lineup of multimedia features, the Nokia N85 is taking the world of mobile convergence to the next level. Gaming, photos, navigation and music blend together with the newest Ovi and third party services via 3.5G HSDPA and Wi-Fi connectivity to make discovering and sharing experiences quick and seamless.









A demo of the Nokia N85, showing off some of the features.






Engage and interact
The Nokia N85 is pre-loaded with at least 10 made-for-mobile N-Gage gaming titles that jump off of the screen thanks to the dazzling OLED display and a voucher to activate one full game license. Dedicated gaming keys light up when the device is in landscape gaming mode to further enhance the action-packed experience.



A state-of-the-art 5 megapixel camera with Carl Zeiss optics and bright dual LED flash captures clear, sharp images as well as DVD-quality videos at 30 frames per second. Combined with A-GPS it is possible to geotag favorite pictures to see where each photo was taken using the Nokia Maps application or online sites such as Share on Ovi or Flickr.



Each Nokia N85 comes with an 8 GB microSD card, up to 30 hours of music playback time and its high-fidelity sound means favorite tracks can be enjoyed virtually anywhere. Build a personal music collection from the millions of tracks and playlists available from the Nokia Music Store or other online music vendors, or synchronize PC and mobile music libraries via USB cable. Alternatively, consumers can enjoy RDS radio or a wide selection of stations via the internet. The 3.5 mm audio jack makes connecting a top-quality headset simple and an in-built FM transmitter lets the Nokia N85 play wirelessly through a car or home stereo to really crank up the sound.



While it comes out of the box with a multitude of powerful functionality, the pre-loaded Nokia Download! application makes the Nokia N85 truly customizable by offering a wide range of bespoke content. This includes an outstanding selection of world-class branded entertainment content, the latest in mobile gaming and dynamic applications so users can really make their device their own.

Read More......

Nokia N79 - Powerful fusion of technology and style

Aug 26, 2008 Espoo, Finland - Nokia today unveiled the Nokia N79, the latest addition to the Nokia Nseries range that combines intelligent and customizable design with a fully-loaded multimedia computer. Behind its sleek exterior, the Nokia N79 is a technology powerhouse. It offers a full range of multimedia experiences including integrated navigation, music with FM transmitter, high-speed connectivity, superior web browsing, at least 10 pre-loaded N-Gage games and an advanced 5 megapixel camera with Carl Zeiss optics. The Nokia N79 is expected to begin shipping in October 2008, with an estimated retail price of EUR 350, before taxes and subsidies.




"The Nokia N79 packs cutting-edge technology into a compact design - a characteristic of the iconic Nseries - that allows people to discover, create and share their passions with others," said Juha Kokkonen, Director, Nokia Nseries. "It has been designed for those who want a device that is as appealing as it is powerful and comes with interchangeable covers that have automatically matching screen themes. This balance of performance and style means that it is a powerful and defining step forward from the popular and very successful Nokia N72 and Nokia N73."



Perfect for the style conscious, the Nokia N79 comes with Xpress-on smart covers that are available in five cool colors: Light Sea Blue, Espresso Brown, Olive Green, White and Coral Red. A combination of three of these comes with each Nokia N79.



The convergence of photos, music and navigation in the Nokia N79 combines with high-speed 3.5G HSDPA and Wi-Fi to make it quick and easy to share experiences on websites, blogs or online communities.



A demo of the Nokia N79, showing off some features.




Experience new discoveries
The innovative technology packed into this colorful offering means that accessing a rich pool of services to further enhance individual experiences is seamless. Log on to online communities like Friendster, Flickr or YouTube or click through to Nokia services such as the Nokia Music Store, N-Gage, Nokia Maps and Share on Ovi, an online service that enables consumers to share personal pictures and videos from their mobile devices.



The 5 megapixel camera with Carl Zeiss optics, dual LED flash and video light captures sharp, clear images and video that can be edited immediately, without the need for a PC. Images can also be geotagged to specific locations. What's more, the Nokia N79 comes packaged with a 4 GB microSD memory card that makes it possible to store around 3,000 songs, approximately 2,500 pictures and up to four hours of DVD-quality video clips that can be organized by albums or tags and uploaded directly to Share on Ovi or third party services. The addition of a sliding lens cover helps protect the top-quality lens when not in use.



Nokia Maps makes it easy to explore and navigate new surroundings by accessing more than 15 million points of interest (POI). In-built A-GPS providing turn-by-turn navigation - for walking or driving - comes with a three month integrated license on the Nokia N79.



A Friendster widget will also be made available for the Nokia N79 via the WidSets service. This will allow people to browse Friendster friends' profiles, view and post shoutouts, upload pictures taken with their handset, and browse their own and friends' photo albums. All this enables more effective communication with friends while away from a computer using the Nokia N79. New users can even register for Friendster directly on their device via a link to Friendster's mobile site (m.friendster.com), create an account, and instantly begin participating in the Friendster global community.



To ensure each device is as distinctive as its user, customizable features are available at the Nokia Download! store, a one stop personalization shop, already embedded in Nokia Nseries devices. It lets consumers create a unique experience for themselves by offering easy access to a multitude of popular ringtones, branded entertainment content, the latest in mobile gaming and dynamic applications for personalizing mobile devices to the user's own preferences.

Read More......

LG KC910

LG has announced the LG KC910, the successor to the LG KU990 Viewty, and competition to the newly announced Sony Ericsson C905 and Samsung INNOV8. This GSM Quadband phone has an 8-megapixel camera that supports auto focus and has a Xenon flash module.



With a 3-inch touch screen at 240 x 400 resolution and three buttons below the screen, this phone is designed for both form and function. It also supports video recording with 30 fps in VGA resolution. Or, you can crank it up a notch for 120 fps in QVGA resolution.

Other features are thought to be GPS, Bluetooth, WiFi, multiple codec support and more. The device is only 14 mm thick and will be released sometime in October.

Read More......

Friday, July 25, 2008

OO Design Principles and Patterns

Principle 1: “Encapsulate what varies”


Identify the aspects of yours application that vary and separate them from what stays the same. This principle helps to make the future changes without affecting the code that doesn’t vary.





Principle 2: “Program to an Interface, not an Implementation”


This will decouple the class implementation from the class that uses them. So, the clients may not need to know the complete implementation.





Principle 3: “Favour Composition over Inheritance”


This principle lets you change behaviour at runtime.





Principle 4: “Strive for loosely coupled designs between objects that interact”


Loosely coupled designs allow us to build flexible OO systems that can handle change because they minimize the interdependency between objects.





Principle 5: “Classes should be open for extension, but closed for modification


Modifying existing code will always lead to introduce new bugs. Design your classes in such a way that they would be easily extended to incorporate new behaviour without modifying the existing code.





Principle 6: “Dependency Inversion Principle – Depend upon Abstractions. Do not depend upon Concrete classes”


This principle suggests that high-level components should not depend on our low-level components. Rather both should depend on abstractions.





Principle 7: “Principle of least knowledge – talk only to your immediate friends”


It means when you are designing a system, for any object, be careful of the number o f classes it interacts with and also how it comes to interact with those classes. This principle prevents us from creating designs that have a large number of classes coupled together so that changes in one part of the system cascade to other parts.





Principle 8: “A class should have only one reason to change”


This principle guides us to assign each responsibility to one class, and only one class.





Please get the details about various design patterns here

Read More......

Friday, May 30, 2008

Symbian Developer Network C++ Code Clinic

Jo Stichbury opens the code clinic to dispense more advice about Symbian C++.



A new Code Clinic will be published on the first Friday of every month.



In this month’s clinic she examines the cause of two panics that occur when the cleanup stack is used with classes that use mixin inheritance.



Got a Symbian C++ problem? Send it to the Code Doctor at sdn@symbian.com.



Problems used will receive a complementary copy of the Symbian Press book Developing Software for Symbian OS, Second Edition.



visit http://developer.symbian.com/main/learning/code_clinic/

Read More......

Friday, May 23, 2008

Interfacing UART in Symbian

Accessing any port in symbian needs the following steps

  1. Load physical DD
  2. Load logical DD
  3. Connect to RCommServer
  4. Connect RComm client to Server
  5. Load the specific port module (.CSY file)
  6. Configure and Open
  7. Do the operation

Here is a piece of code explains how to interface with UART in symbian





TInt err = User::LoadPhysicalDevice(PDD_NAME);




if (err != KErrNone && err != KErrAlreadyExists)


{


RDebug::Printf("Loading of Physical drive failed\n");


User::Leave(err);


}





// Load the logical device driver.


err = User::LoadLogicalDevice(LDD_NAME);


if (err != KErrNone && err != KErrAlreadyExists)


{


RDebug::Printf("Loading of Logical drive failed\n");


User::Leave(err);


}








#if 1 //!defined (__WINS__)


// Start the comms server process


err = StartC32();


if (err != KErrNone && err != KErrAlreadyExists)


{


RDebug::Printf("StartC32 failed\n");


User::Leave(err);


}


#endif



// Connect to the Serial comms server.


User::LeaveIfError(iCommServer.Connect());


RDebug::Printf("Success: CommServer connect\n");


// Load the CSY module.


User::LeaveIfError(iCommServer.LoadCommModule(RS232));


RDebug::Printf("Success: CommServer RS232 Loading\n");





TInt numPorts;


User::LeaveIfError(iCommServer.NumPorts (numPorts));


RDebug::Printf("Success: CommServer returned number of ports & the number of ports = %d", numPorts);



//we are really only interested in using the CSY that we've


// just loaded up ourselves. We could find out its portInfo by


// comparing the moduleName returned by the version of GetPortInfo we


// just used to the name of the CSY we loaded, but there's a better


// version of GetPortInfo we can use, which just takes the name of a CSY


// as a parameter. We'd expect to find this informtion is an exact


// duplicate of the indexed portInfo for the last loaded CSY


// Our example code will use the lowest possible port (why not?)



TSerialInfo portInfo;





TBuf16 <> moduleName;



for (TInt index=0 ; index <>
{


User::LeaveIfError(iCommServer.GetPortInfo (index, moduleName, portInfo));


RDebug::Print(_L("module name = %S"), &moduleName);


RDebug::Print(_L("Port name = %S"), &(portInfo.iName));


RDebug::Print(_L("Port Description = %S"), &(portInfo.iDescription));


RDebug::Printf("Port high unit = %d", portInfo.iHighUnit);


RDebug::Printf("Port Low unit = %d", portInfo.iLowUnit);


}




User::LeaveIfError(iCommServer.GetPortInfo (RS232, portInfo));


RDebug::Printf("Success: CommServer returned port information \n");





RDebug::Print(_L("Port name = %S"), &(portInfo.iName));


RDebug::Print(_L("Port Description = %S"), &(portInfo.iDescription));


RDebug::Printf("Port high unit = %d", portInfo.iHighUnit);


RDebug::Printf("Port Low unit = %d", portInfo.iLowUnit);








// Now let's use a few Symbian OS functions to construct a descriptor for the


// name of the lowest port our CSY supports -


// The name can be as long as a TSerialInfo.iName plus a


// couple of colons and digits



TBuf16 <> portName; // declare an empty descriptor buffer


portName.Num (portInfo.iLowUnit); // put in the port number in ASCII


portName.Insert (0, KColons); // stick in a couple of colons


portName.Insert (0, portInfo.iName); // and lead off with the iName



// and at last we can open the first serial port,which we do here in exclusive mode



RComm commPort;


User::LeaveIfError(commPort.Open (iCommServer, portName, ECommExclusive));


RDebug::Printf("Success: Commport Open\n");



// Now we can configure our serial port


// we want to run it at 115200 bps 8 bits no parity (why not?)


// so maybe we ought to get of its capabilities and check it can


// do what we want before going ahead



TCommCaps ourCapabilities;


commPort.Caps (ourCapabilities);



if (((ourCapabilities ().iRate & KCapsBps115200) == 0) ||


((ourCapabilities ().iDataBits & KCapsData8) == 0) ||


((ourCapabilities ().iStopBits & KCapsStop1) == 0) ||


((ourCapabilities ().iParity & KCapsParityNone) == 0))


User::Leave (KErrNotSupported);




TCommConfig portSettings;


commPort.Config (portSettings);


portSettings ().iRate = EBps115200;


portSettings ().iParity = EParityNone;


portSettings ().iDataBits = EData8;


portSettings ().iStopBits = EStop1;



// as well as the physical characteristics, we need to set various logical ones


// to do with handshaking, behaviour of reads and writes and so so



portSettings ().iFifo = EFifoEnable;





//portSettings ().iHandshake = (KConfigObeyCTS | KConfigFreeRTS); // for cts/rts





portSettings ().iHandshake = (KConfigObeyXoff | KConfigSendXoff); // for xon/xoff





// portSettings ().iHandshake = KConfigFailDSR;





portSettings ().iTerminator[0] = 10;


portSettings ().iTerminatorCount = 1; // so that we terminate a read on each line feed arrives



User::LeaveIfError(commPort.SetConfig (portSettings));


RDebug::Printf("Success: Commport Config\n");



// now turn on DTR and RTS, and set our buffer size



commPort.SetSignals (KSignalDTR, 0);


commPort.SetSignals (KSignalRTS, 0);


TInt curlenth = commPort.ReceiveBufferLength ();


commPort.SetReceiveBufferLength (4096);


curlenth = commPort.ReceiveBufferLength ();





const TTimeIntervalMicroSeconds32 KTimeOut(4000000);


TRequestStatus stat;


commPort.Write (stat, KTimeOut, (TDesC8&)KFileName);


User::WaitForRequest (stat);


err = stat.Int ();


if (err != KErrNone) // Write has failed for some reason


{


RDebug::Printf("Failure: Commport Write and the reason is %d\n", err);


//Failed


}





RDebug::Printf("Success: Commport Write\n");



TBuf8 <> localInputBuffer;


localInputBuffer.FillZ();


TRequestStatus readStat;



//Reading the written buffer


commPort.Read (readStat, localInputBuffer, 20);


User::WaitForRequest(readStat);


User::LeaveIfError (readStat.Int ());


RDebug::Printf("Success: Commport Read\n");





RDebug::Print(_L("Read buffer is %S"), &localInputBuffer);



commPort.Close ();


iCommServer.Close ();



Read More......

Wednesday, May 21, 2008

Enabling Logs for Emulator

Quite Simple !!!

  1. Open \epoc32\data\epoc.ini
  2. make LogToDebugger to 1 & save
  3. You can find your log file epocwind.out in windows temproary directory
  4. you can type %temp% in the address bar of explorer to reach the temproary directory.

Read More......

Tuesday, May 20, 2008

Self signing your symbian application

Target Apps:

Application doesn't require other than basic capabilities, include LocalServices, NetworkServices, ReadUserData, UserEnvironment and WriteUserData



Creating Certificates:

"makekeys -cert -password World123 -len 1024 -dname "CN=World User OU=Development OR=WorldCompany CO=FI EM=World@test.com" WorldKey.key WorldCert.cer" - Execute this command in windows command prompt from sis directory



Signing Application

signsis HelloWorld_unsigned.sis HelloWorld_signed.sis WorldCert.cer WorldKey.key World123

Read More......

Friday, May 16, 2008

Symbian OS Stacks

Symbian OS stacks are fixed in size. They are allocated during the creation of a thread and they do not grow. Once the stack is exhausted there is no dynamic capability for extension

Symbian OS stacks exist both User and Kernel side.

User-side stack:
They are used as temporary scratch storage inside functions or methods. The stack typically grows and shrinks wildly as the thread executes instructions.

Kernal-side Stack:

In EKA2, each thread also has a kernel-side stack, called the supervisor stack. This stack is used for:

a)executive calls

b)if a hardware interrupt occurs whilst the thread is running and the interrupt queues IDFCs and/or DFCs

c)rescheduling. A reschedule always occurs as a result of the current thread calling the scheduler. Inside the scheduler, the current thread’s register state is saved on its supervisor stack and the final stack pointer value is saved in the thread control block. Then the stack pointer is loaded using the new thread’s saved stack pointer value and its register state is restored from the stack (which is now the new thread’s supervisor stack).


Chunk Size:

The minimum amount of RAM required by a stack for a given thread is one page (4kb)

Currently, the default amount of RAM allocated for the thread’s stack is 8kb. Can be changed using EPOCSTACKSIZE keyword in mmp file

But the maximum size for a thread is 64 KB

And maximum size for a process is 2 MB

stacks are seperated using guard with in a chunck

Read More......

Symbian OS Heaps

Each Symbian application the default Symbian OS RHeap implementation.



Symbian OS heaps are implemented using a chunk. A chunk is a wrapper around a collection of pages of memory. The minimum size for a chunk is one page of RAM and this is typically 4 KB.



When a process is created, a default heap is created for the main thread of execution within that process. And this heap has maximum size that a process is allowed to grow in the usage of RAM. If it goes beyond that upper limit, memory allocation will fail with KErrNoMemory.



Process Startup:


When the main thread starts
, Symbian OS E32 Process startup framework creates a chunk in which the heap for the process will live.



if your process is called “ProA”, your thread is called “Thr1”, then full name associated with your heap chunk is “ProA::Thr1::$HEAP.”



Once the chunk is created by the kernel and is mapped into the process , an RHeap object is then allocated in-place at the start of the chunk. Then the heap object is configured with the sizing information from the E32 image header. This object is used to find out the sizes of allocated and unallocated in a chunk / Heap.

Symbian OS process heaps can be extended using some slack spaces by adding some free cells at the end of the chunk.



Read More......

Thursday, May 15, 2008

TTL ( Time-To-Live)

Time-to-live (TTL) is a value in an Internet Protocol (IP) packet that tells a network router whether or not the packet has been in the network too long and should be discarded.


For a number of reasons, packets may not get delivered to their destination in a reasonable length of time. For example, a combination of incorrect routing tables could cause a packet to loop endlessly. A solution is to discard the packet after a certain time and send a message to the originator, who can decide whether to resend the packet.

The initial TTL value is set, usually by a system default, in an 8-binary digit field of the packet header. The original idea of TTL was that it would specify a certain time span in seconds that, when exhausted, would cause the packet to be discarded. Since each router is required to subtract at least one count from the TTL field, the count is usually used to mean the number of router hops the packet is allowed before it must be discarded. Each router that receives a packet subtracts one from the count in the TTL field. When the count reaches zero, the router detecting it discards the packet and sends an Internet Control Message Protocol (ICMP) message back to the originating host.

The default Windows 95/98 TTL value is 32 hops. Some users recommend changing this to 128 if you have difficulty reaching certain sites.

The ping and the traceroute utilities both make use of the TTL value to attempt to reach a given host computer or to trace a route to that host. Traceroute intentionally sends a packet with a low TTL value so that it will be discarded by each successive router in the destination path. The time between sending the packet and receiving back the ICMP message that it was discarded is used to calculate each successive hop travel time.

Using the multicast IP protocol, the TTL value indicates the scope or range in which a packet may be forwarded. By convention:


  • 0 is restricted to the same host
  • 1 is restricted to the same subnet
  • 32 is restricted to the same site
  • 64 is restricted to the same region
  • 128 is restricted to the same continent
  • 255 is unrestricted
  • Courtesy: searchnetworking.techtarget.com

    Read More......

    RFC's

    SDP: Session Description Protocol
    http://www.faqs.org/rfcs/rfc4566.html

    Read More......

    Friday, May 2, 2008

    APP_REGISTRATION_INFO

    The registration file

    All applications must provide a registration file.

    A registration file is a standard Symbian OS compiled resource file (.rsc). The .rss file used to build the registration file should be named AppName_reg.rss and contain at least the following lines:

    #include appinfo.rh
    UID2 KUidAppRegistrationResourceFile
    UID3 0x01000000 // application UID
    RESOURCE APP_REGISTRATION_INFO
    {
    app_file="AppName"; // filename of application binary (minus extension)
    }

    To build the registration file, add the following lines to the application's MMP file:

    START RESOURCE AppName_reg.rss
    TARGETPATH \private\10003a3f\apps //Dont think 10003a3f is the uid of the app.
    END

    The _reg filename suffix is used as a naming convention only and is not mandatory.

    Note that any lines in the MMP file that are used to build an AIF file should be removed.

    Read More......

    Tuesday, March 4, 2008

    Implementing Active backup

    Yeah.. Its would be really good if you understood the idea / concept behind the backup & Restore.

    If not please refer to my previous post on "Backup & Restore"

    Now its time to code your application / process to interact with Symbian Backup Engine (SBE). That is implementing active backup for your application.

    Before that let me explain few more things.

    Backup Listener:
    You must have a listener class which listens to the events from SBE. It should be an Active Obeject and it should implement MActiveBackupDataClient
    class CMyBackupListener : public CActive, public conn::MActiveBackupDataClient

    Signaling from SBE to Listener:
    The signalling method provided to inform processes that a backup or restore is taking place is via the publish-and-subscribe API. The publish-and-subscribe server maintains a list of subscribers expressing an interest in the backup and restore flag. Any published changes to this flag by the backup and restore engine results in all subscribers being notified. The flag provides information on whether a backup or restore operation is in progress, whether a backup is base or incremental and whether the operation is full or partial. Subscribing to the flag is done via RProperty, which must be used in conjunction with an active object to be notified when the value changes.
    The following key and category values should be used (these are defined in epoc32\include\connect\sbdefs.h):

    Category : KUidSystemCategoryValue

    Key : KUidBackupRestoreKey

    The following code fragment demonstrates this:

    #include RProperty iProperty;
    iProperty.Attach(KUidSystemCategory, KUidBackupRestoreKey);
    CActiveScheduler::Add(this);
    iStatus = KRequestPending;
    iProperty.Subscribe(iStatus);
    SetActive(); // In CMyBackupListener::RunL, you will get the notification

    Yep. You got a notification from SBE that its going to backup the data. How to make connection with SBE then?

    Connecting to SBE:
    Once you got the notification from SBE, then make a connection as follows

    iConn = conn::CActiveBackupClient::NewL(this); // Listener is again the observer for this
    iConn ->ConfirmReadyForBURL(KErrNone);

    yes.. we initimated SBE that we are ready for backup.


    Hereafter you will start getting events from SBE to backup and restore. Its up to the application writer, what data to be backed up and what not to be. Because its active backup method 

    If its passive, it would have been already mentioned in the backup registration file and the fact is that the data owning process need not to be run at that time.

    As you know the active backup expects the data owning processes need to be run. So, a question should flash in your mind here.

    “Where did we mention which process to be expected to run?”

    Yeah.. Here is the answer

    It should be mentioned in the backup registration file. The following is the syntax of that.

    xml version="1.0" standalone="yes"?
    backup_registration
    active_backup process_name = "Myprocess" requires_delay_to_prepare_data = "yes"
    backup_registration

    Conclusion:

    When your phone is connected to PC, the SBE from backup software signals all the processes that are registered for the backup process. (obviously by referring the backup registration files )

    On receiving those events, the process creates a connection (CActiveBackupClient)

    Then Processes receive events from SBE and they backups the data they wish. The same way as restore.

    Read More......

    Monday, March 3, 2008

    "Backup & Restore" for symbian OS applications

    Do you want to upgrade your phone? Then what about your existing application data? Ok. Lets take a backup of them and upgrade your phone.

    Symbian OS includes software to carry out backup and restore operations to and from a connected PC. In order to do this, the applications should be made aware of backup and restore.

    Make your application "Intelligent"
    Before making your application aware of the backup and restore, Determine the following:
    1. What are the contents to be backed up?
    Private data? yes. ok. Do you wish to backup the complete private directory or specific files?
    Public data? yes. Then where its located?
    Do you want to backup system directory?
    2. Do you want to use Active backup or passive method?
    Have you got the answers for this? If yes, then write them up in a file. Yes that is called "backup registration file"

    Wait... wait.. Tell me onething.. Are you clear with the concept of backup and restore?? Nope?? Then read the below paragraphs :)

    Backup Operation
    Hi dudes (processes in the phone) I am Mr.backup. I want to store all of your data's safely. Could you please let me do my job?
    Ok Mr.Backup... we are all releasing our resources for the time being, you copy our data into PC :)
    Yes.. A backup operation needs to read files so processes must relinquish exclusive-locks on files but can retain read-locks (although in practice many processes just relinquish all locks for the sake of safety and simplicity). In order for a backup operation to take place, applications and servers must flush any pending updates to files and allow all files to be read (but cached data can be retained as backup will not alter data files). When the backup has taken place, servers and applications can re-take file locks and carry on.

    Restore Operation
    A restore operation requires exclusive access to files so processes must relinquish all locks on files. In order for a restore operation to take place, applications and servers must discard all cached data and allow files to be written or overwritten. When the restore has taken place, servers and applications must reload their data from files that can be expected to have changed.
    Hopefully it better explained about the resposibilities of the application / process, when backup & restore takes place.

    Now lets see what is active and passive ways of backup.

    There are two ways of backing up private data:
    1. Active backup of private data. In this model, the process which owns the data, registers with the secure backup engine using a registration file. The secure backup engine will start any process registered for active backup if not already started. The data owning process then responds to a central signal when a backup or restore operation takes place and actively provides its private data to or receives it from the secure backup engine. This requires that the data-owning process include specific code to take part in backup and restore operations, and that it must be running when a backup or restore takes place. In this model the data-owning process registers with the secure backup engine but exercises complete control of which data is backed up and restored.

    2. Passive backup of private data. In this model, the process which owns the data, registers with the secure backup engine using a registration file and records whether executables, private files or directories of private files should be backed up. The data-owning process then releases file locks for private files in the same way as for public files (described above) and the files are backed up by the secure backup engine (which has the required capability to access private data files belonging to other processes).

    Now lets concentrate on Backup_registration.xml file format

    Basic application backup
    The following represent the minimum you have to do for the backup of your application. Write a backup_registration.xml file as shown below
    xml version="1.0" standalone="yes"
    backup_registration
    system_backup
    restore requires_reboot="no"
    backup_registration


    add it into your pkg file:
    "backup_registration.xml"-"!:\private\\backup_registration.xml"

    Adding private data into the backup
    Another common requirement would be to save the content of your private directory (located in \private\). This is done by adding the following declaration in your backup_registration.xml file
    passive_backup
    include_directory name="\"
    passive_backup

    You can also decide to save all your private directory but a 'nobackup' subdirectory:
    passive_backup
    include_directory name="\"
    exclude name = "\nobackup\"
    include_directory
    passive_backup


    You may also prefer to specify files instead of directories:
    include_file name="important.dat"
    include_file name="me_too.dat"


    Adding public data into the backup
    In the paragraph above, the "\" directory is referring to your application private directory. So how to save data when they are located outside of your private area ? This is done by simply using another xml tag. Replace by and the path will be relative to the root directory of the phone file system (you don't need to specify the drive):
    public_backup
    include_directory name="C:\MyData"
    public_backup


    Okay.. The blog is increasing in length. I will stop here. Hope its somewhat useful to understand the idea behind the backup & Restore. I will give the complete details, how to use symbian backup engine in your code to make your application aware of backup & Restore.

    Bye for now. Comments are welcome. That will help me to put my points correctly as this is my first ever blog :)

    Read More......
     
    Template design by Amanda @ Blogger Buster