Start-up Sound and Start-up Application

😊

As I have already noted, this might be possible, though is a closely guarded secret...

I will try one of these days.. now that I am back 😉

[quote="talk2sk"]..., this might be possible, though is a closely guarded secret...[/quote]
Not such a big secret. You need to write a recognizer that will launch a file, or a series of files, when launched (instead of recognizing files). Recognizers are loaded within 1 or 2 seconds after installation and at every reboot of the system.

Just be very carefull. Because this file gets loaded automatically everytime the system boots, it can make the system unstable or even put it in a permanently crashed state if there is a bug in the recognizer. For the 9210, this is not such a big problem if the recognizer was installed on the D: drive. For the 7650, this means a trip back to Nokia Service Centre.

cmatthee:does it?
what about backup functionality? simple backup your phone before installing it and use this backup in case of problems...

I am highlighting the extreme here. Not all buggy recognizers will complete crash the system. But, there is at least one documented case on the Nokia forum where a badly coded recognizer totally crashed the system. (If I read that thread correctly, he) Could not even use the backup.

Yeah, One of my concerns, rdls and mdls are the way to do it, but what if something happens 😊... I was wondering whether it could also be done with the font system, but then I read about Muffy's experience and decided not even to experiment 😉

I'm working on a recognizer right now to auto-start an application for the 7650. I have written the recognizer class, but do not quite understand what to do now. Currently, I have two mmp files, one for the application and one for the recognizer. The recognizer mmp file looks like this:

TARGET SwitchMe.mdl
TARGETTYPE MDL
TARGETPATH \system\recogs
UID 0x10003A19

SOURCEPATH ..\src
SOURCE SwitchMeRecognizer.cpp

USERINCLUDE . ..\inc

SYSTEMINCLUDE . \epoc32\include

LIBRARY euser.lib apparc.lib
LIBRARY apmime.lib efsrv.lib apgrfx.lib

A couple questions about this: 1) Is that the correct UID I should be using for the recognizer? 2) Is this correct to have a separate mmp file for the recognizer and one for the application itself?

I then changed the bld.inf file to include both of the mmp files. This seems to work without errors and the build works properly, but when I run on the emulator it doesn't work....the application does not load on startup.

If any of you can provide me with some insight I would really appreciate it. And if you need more of my code just let me know.

Thanks!

switchme,

1. One way to check is to use a hex editor and to open a recognizer from the target device. Look at the first four integers (4 bytes per integer). Is should be something like

79 00 00 10 19 3A 00 10 2F 8A 00 10 76 F3 19 E5

2. It is correct to use a second mmp file. You are creating a second target file.

Just because you have the recognizer, does not mean that your app will start automatically. You must tell it to start. Look at all the functions in the recognizer and pick one that looks like it is called at the start of the recognizer. Put you app launching code in that function.

Cmatthee, thanks for the info. Should the recognizer work properly on the emulator or does it only work on real hardware?

hi guys,

what about incoming calls on a nokia 7650, what is it's mime type(so i can override it?),

so is this possible, the phone is flashing the name of the incoming caller, there's off course two choice for the softkeys, accept and reject, whatever he choses, my app will also be activated as well?

I just noticed that there is a mdl target type and an rdl target type for the mmp file. Which of these is appropriate for the startup recognizer? I am currently using the mdl, but I am wondering if I should be using the rdl type because I'm not really doing anything with MIME recognition. Any thoughts?

It now appears as though the application might be loading upon startup on the emulator because I see the title bar for a split second while the "Nokia" message is still on the phone, but then it goes away and the applications screen appears. Any ideas why this might be happening? A snippet of the code looks like this:

CApaCommandLine* cmdLine = CApaCommandLine::NewLC();
cmdLine->SetLibraryNameL( findFile.File() );
cmdLine->SetCommandL( EApaCommandOpen );

RApaLsSession ls;
User::LeaveIfError(ls.Connect());
CleanupClosePushL(ls);

User::LeaveIfError( ls.StartApp(*cmdLine) );
ls.Close();
CleanupStack::PopAndDestroy(3);

I have tried using EApaCommandOpen and EApaCommandRun, but no better luck with one over the other.

Any ideas? Is there anyway to tell if my application is in fact running, just maybe in the background?

Thanks!

Recognizers are loaded fairly early in the boot process. Maybe you should put a User::After instruction before starting your app. This will give the system enough time to boot fully.

There is a program available called Spy. Search on Symbian and Nokia web sites. I don't remember if this is only for the target device itself, or only for the emulator, or for both. If you can get the program to run on the emulator, then it will give you all the running threads. If your app runs in the background, then the thread will be there.

OK, that seems to work just perfect! On the emulator, 5 seconds seems to be enough time. I wonder if it will be the same on the real device or if that will need to be adjusted a little bit. I post what I figure out, so everyone else knows.

One more thing I would like to implement....I'd like to let the user determine whether the autostart functionality should be used or not. I am not sure where to even begin with this problem. Any ideas to get me started?

Store it as an option in a ini file. Either with your app of with the recognizer. This way, when the recognizer starts, it queries the ini file and either starts the app or not.

OK, I'll see if I can give that a try. So, the ini file would replace my use of store streams? I have two settings which are either on or off that I need to save the state of for the next time the application is loaded.

Thanks.

Here is an interesting comment from the discussion.epoc.C++ news group on publicnews.epocworld.com related to this topic. (Message-ID: <xZNH8ns5CHA.1596@extapps30>😉

[quote]i've used Eduard Frank's code to start an app in the recognizer, however, there is a big problem with this.

when you start charing your nokia 7650, i think the phone boots too or something, therefore the recognizers are being read and offcourse my app gets loaded as well, so my app will appear, but in a hang condition after a few seconds(depends on the time i place to start the thread)

Solution is to wait (using timer) until some system app will start.
Here is psevdocode I use to solve the problem:

[code:1]TBool CheckPhoneOn()
{ // checks for sdp thread startup
TFullName fn;

TFindThread tt(_L("sdp*"));
return (tt.Next(fn) == KErrNone)
}

void timerexpired()
{
if (CheckPhoneOn())
{
request_start(); // start app
}
else
{
request_timeout(1 sec); // wait 1 sec more
}
}[/code:1][/quote]

Hi all,
Here is what I succeeded in making with the whole information collected in the forum. 😃

autostart.mmp
=========
TARGET autostart.mdl
TARGETTYPE MDL
UID 0x10003A19 0x10008A2F
TARGETPATH \system\recogs

SOURCEPATH ..\src
SOURCE autostart.cpp

USERINCLUDE . ..\inc

SYSTEMINCLUDE . \epoc32\include

LIBRARY euser.lib apparc.lib
LIBRARY apmime.lib efsrv.lib apgrfx.lib

autostart.cpp
========

// INCLUDE FILES
#include "autostart.h"

// ================= MEMBER FUNCTIONS =======================
CMyRecognizer::CMyRecognizer()
:CApaDataRecognizerType(KUidemAMRec, CApaDataRecognizerType::ENormal)
{
iCountDataTypes = 1;
}

TUint CMyRecognizer::PreferredBufSize()
{ // no buffer recognition yet
return 0;
}

TDataType CMyRecognizer::SupportedDataTypeL(TInt /*aIndex*/) const
{
return TDataType();
}

void CMyRecognizer:😃oRecognizeL(const TDesC& /*aName*/, const TDesC8& /*aBuffer*/)
{ // this function is never called
}

void CMyRecognizer::StartThread()
{
TInt res = KErrNone;

//create a new thread for starting our application
RThread * startAppThread;
startAppThread = new RThread();

User::LeaveIfError( res = startAppThread->Create(
_L("MyThreadName"😉,
CMyRecognizer::StartAppThreadFunction,
KDefaultStackSize,
KMinHeapSize,
KMinHeapSize,
NULL,
EOwnerThread) );

startAppThread->SetPriority(EPriorityNormal/*EPriorityLess*/);

startAppThread->Resume();

startAppThread->Close();
}

TInt CMyRecognizer::StartAppThreadFunction(TAny* /*aParam*/)
{

User::After(2000000);

// create an active scheduler
CActiveScheduler * scheduler = new CActiveScheduler();
if( scheduler == NULL )
return KErrNoMemory;

CActiveScheduler::Install(scheduler);
// create a TRAP cleanup
CTrapCleanup * cleanup = CTrapCleanup::New();
TInt err;
if( cleanup == NULL )
{
err = KErrNoMemory;
}
else
{
TRAP( err, StartAppThreadFunctionL() );
}
delete cleanup;
delete CActiveScheduler::Current();

return err;
}

// thread function to start our application
void CMyRecognizer::StartAppThreadFunctionL()
{
// absolute file path to our application to be launched automatically
TFileName fnAppPath = _L("\\system\\apps\\someapp\\somefile.app"😉;

RFs fsSession; //file server session
User::LeaveIfError(fsSession.Connect());
CleanupClosePushL(fsSession);
TFindFile findFile( fsSession );

User::LeaveIfError( findFile.FindByDir(fnAppPath, KNullDesC) );

CApaCommandLine* cmdLine = CApaCommandLine::NewLC();
cmdLine->SetLibraryNameL( findFile.File() );
cmdLine->SetCommandL( EApaCommandOpen );

RApaLsSession ls;
User::LeaveIfError(ls.Connect());
CleanupClosePushL(ls);

User::LeaveIfError( ls.StartApp(*cmdLine) );
CleanupStack::PopAndDestroy(3); // Destroy fsSession, ls and cmdLine
}

// The gate function - ordinal 1
EXPORT_C CApaDataRecognizerType* CreateRecognizer()
{
CApaDataRecognizerType* thing = new CMyRecognizer();

//start thread for our application
CMyRecognizer::StartThread();

return thing;
}

// DLL entry point
GLDEF_C TInt E32Dll(TDllReason /*aReason*/)
{
return KErrNone;
}

Then :
launch autostart.dsw (environment)
insert somefile.dsp (project)
define dependencies on autostart
select autostart as active project, build and launch :P

This runs on emulator but I don't know wether it works on real hardware.
I'm not sure on Uid3 value 0x10008A2F. I took it from cmatthee. 😮ops:

I'm not sure if that you were looking for.

In return could you indicate to me how to rock an application in background task (i.e for waiting some event) ? I will really appreciate. :P

barmal

[quote="barmal"]This runs on emulator but I don't know wether it works on real hardware.
I'm not sure on Uid3 value 0x10008A2F. I took it from cmatthee[/quote]
The Uid3 must be UNIQUE to each project. You can not use the uid from the example earlier in this thread. That uid belongs to one of the build-in recognizers of the 9210.

To get your own unique uid number, contact Symbiam. The documentation contains more information and the email address to use.

Gday people. I'm a complete newbie to the Symbian development scene, and I can't say I know much C++ either (I usually do backend Java stuff in the telco business).
I'm trying to write an app that auto starts when a Series 60 phone (I'm guessing Nokia 3650/7650 at this point) is powered up, after everything else has been initialised.
Admittedly, I haven't tried Barmal's solution because I'm not sure what the .dsw and .dsp files are - I'm guessing they are IDE specific files (I'm using Borland C++ Mobile Edition), and also things about defining dependencies.

However, I found Mika Raento's code here, which, according to the description, does what we want in this thread. Im having some problems even importing the app into Borland C++, complaining that there are no valid mmp files found, and no target specified, even after i manually added the mmp file into the project (basically none of the source and mmp files were picked up while attempting to import it).
Colleague of mine attempted to fix it by creating a new app using the IDE, then moving the project and source files across. They looked like they were compiling, with usual warnings and stuff, but at the very end, it said that the build failed. I'm kinda lost at the moment :P

Any ideas?

Sorry for the amateurish question, but I really am one at the moment!

Thanks.

Hmm, looks like the problem is solved - in the MMP file, the targettype was set as "MDL". I changed it to DLL and it seems to be working fine now. Is MDL meant to work? Perhaps in a newer SDK or something? I'm using 6.1.

[quote="Anonymous"]Hmm, looks like the problem is solved - in the MMP file, the targettype was set as "MDL". I changed it to DLL and it seems to be working fine now. Is MDL meant to work? Perhaps in a newer SDK or something? I'm using 6.1.[/quote]
Ick sorry that was me... forgot to log in.