Application is rejected by Symbian Signing, due to a couple of issues: Please help

[mpurna]

Hi All,

Couple of days ago, when I submitted my application for Symbian Signing, my application has been reject saying that the following issues need to be addressed before it is signed.
Issues are:
1) UNI-01 : Installation, Normal and Stressed Usage
2) UNI-10 : Scalable UI Compliance

Before I ask for any clarification, I would like to give an overview of my application.
1. Earlier, my application was successfully signed
2. Now I have made a little variation, such as adding two list items to CAknSettingItemList object
3. No new capabilities are added/removed
4. With developer certificate it is successfully tested the existing as well as new functionality.
5. All the development is done for S60 3rd Edition MR/FP1 devices

Now, the above two issues are reported by Symbian Signing. I need your guidance to figure out the root cause of the problem. Please help.

1) Issue UNI-01:
When tried to exit the my application using menu item "Exit" the application is not getting exited.

"Exit" function implementation as below:

HBufC* szExitQuery;
szExitQuery =CCoeEnv::Static()->AllocReadResourceL(R_EXIT_APP_QUERY);
CleanupStack::PushL(szExitQuery) ;
m_pQueryDialog = CAknQueryDialog::NewL( );
if ( m_pQueryDialog->ExecuteLD( R_EXITAPPLICATION_QUERY, szExitQuery->Des()) )
{
if(IsPinForExitEnabled())
{
if(!VerifyPin(R_ENTER_PIN))
{
m_pQueryDialog = NULL;
CleanupStack::PopAndDestroy(szExitQuery);
break;
}
}

m_pQueryDialog = NULL;
CleanupStack::PopAndDestroy(szExitQuery) ;

TInt nAutoStart =m_ptSettingsData->AutoStartFlag();;
if(nAutoStart == -1)
m_ptSettingsData->m_nAutoStart = KAutoNotConfiured;

ExternalizeSettingsDataL();
Exit();
break;
}
m_pQueryDialog = NULL;
CleanupStack::PopAndDestroy(szExitQuery) ;

Question:
1) Is there anything wrong in the above piece of code?
2) Is there any chance that "m_pQueryDialog = CAknQueryDialog::NewL( )" would return NULL?
2.1)If it returns NULL then is it safe to call (in general not) m_pQueryDialog->ExecuteLD() in Symbian?

2) on UNI-10 : Scalable UI Compliance:
Q1) When is this issue arises?
Q2) As I mentioned, two list items are added to CAknSettingItemList object, will this causing the UNI-10 issue?

Looking forward for your valuable suggestions.

Thanks in advance.
Purna.

[kiran10182]

You should debug and test your application thoroughly before sending for SymbianSigning. Which is the option you chose for signing? Expressed Sign or Certified sign? You can always ask for more detail about the failure case and I believe Test house will help you.

As far as Scalable UI compliance is concerned, it has been there for a long time. Read more about it and see if it breaks anything on any device. http://developer.symbian.org/wiki/in...Test_UNI-10%29

[ltomuta]

Presumably your application cannot exit (for example when the user tries to close it from the task list) if you are prompting the user for a PIN when the exit command is received. What is the purpose of that PIN prompt? why don't you just close the app, as expected?

As for the Scalable UI thing, you should know best what issue you're talking about and how it really impacts your application.

[mpurna]

Thanks for your inputs.

For security reason, we provide the password protection for "Exit". It PIN for exit is enabled then user need to enter the valid PIN to exit the application. This functionality had been working and successfully signed earlier.

Kiran, We have used Certified signing.

[ltomuta]

Sounds to me that this requires a waiver as it certainly contradicts the testing criteria. Or at least you can implement it a bit smarter, such as an attempt to exit while in the foreground will prompt for the PIN while an attempt to exit while in the background (i.e. from the task list) would simply remove the applications from the task list until next time you are in foreground again. Better yet, go for both the "clevel" technical solution and the waiver.

[kiran10182]

I reckon I read about this particular issue somewhere but I cannot find the source. It was said that you have to allow user to exit from the application at his wish.

Anyways as said, you can follow up with the Test house and apply for a waiver if that is the required behavior of your application.

[mpurna]

Thanks for your suggestions.

The same behavior (not able to exit the application) is also observed even without prompting for PIN to enter.

I have a question: Is there any chance (such as low memory for the application) where the call to "Exit()" will fail to execute?

- Purna

[symbianyucca]

I have a question: Is there any chance (such as low memory for the application) where the call to "Exit()" will fail to execute?

Never seen that happening really..

[mpurna]

Now, I have got few more details about my application Exit issue. The details are as follow:

1. While try to exit the application, It invoked the destructor of the class
2. Successfully wrote the log "[CAppUi: ~CUi] Uninitializing Application" into the log file
3. After that, the application is goes to background, but the status is still showing running (application crashes).

The functionality of the Destructor as follow:
-- Write a log into log file
-- Deallocate the memory, if any allocated (valid pointer).

Question: The below piece of code is working fine with on certain devices. Sometimes, if fails on Nokia E61.
Could please tell me, is there any chance where the application would crash while deleting the allocated memory?

CAppUi::~CAppUi()
{
_LIT(KBegFormat , "[CAppUi: ~CUi] Uninitializing Application");
m_ptLogFile->Write(KBegFormat);

// Reset and delete the created arrays.
if(m_arrEmergencyNumbers)
{
m_arrEmergencyNumbers->Reset();
delete m_arrEmergencyNumbers;
m_arrEmergencyNumbers = NULL;
}
if(m_ptLogFile)
{
delete m_ptLogFile;
m_ptLogFile = NULL;
}
if(m_ptSettingsData)
{
delete m_ptSettingsData;
m_ptSettingsData = NULL;
}
}

Thanks,
Purna

[ltomuta]

If an application "crashes" (or rather it panics) it is terminated by the system and therefore no longer running. What you seem to describe is a hanging application, one that still runs but it is no longer responsive.

I am not aware of any conditions under which an application would fail to exit once the destructor of *AppUI is invoked. Of course one can hardly ever judge an application by looking at a destructor only, without even knowing the data types of the members being destroyed there ...

[wizard_hu_]

Note that waiting dialogs start a nested scheduler in their ExecuteLD. If you invoke AppUi::Exit from that nested scheduler loop (e.g. when the dialog is still open), that can cause this kind of "partial exiting" effect.