Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Quote:
From NSTL:

Error(s) that cause the application to fail testing:

Error #1: If the user receives an SMS event during startup the application does not suspend and the user is not alerted to the new message. (Test Case 3.3.1.9)

Steps to reproduce the error:

1. Send SMS event to the handset.
2. Start the application.
3. Note error.

Error #2: If user downloads the demo application (5 Uses) the number of uses is never decremented and use of the program is unlimited. (Test Case 3.4.1.3, 3.4.1.4)

Steps to reproduce the error:

1. Download demo application from test server (or cable load.)
2. Start and end the application.
3. Repeat step 2 five times.
4. Note error.

Error #3: The application could not be disabled. If the user tries to download an additional application while memory is low the application refuses to disable and the handset displays a message saying "File Space Full: Your phone does not have enough file space to download this app. Unlock or remove apps and try again." (Test Case 3.7.1.2, 3.7.1.3, 3.7.1.4)

Steps to reproduce the error:

1. Start the application manager.
2. Lock all applications except for Boricua Al Dia.
3. Fill the handset by downloading applications until handset is full.
4. Attempt to download additional application to force Boricua Al Dia to be disabled.
5. Note error.

#1: i don't know what to do with it. i mean, while on a data call the phone doesn't go into suspend (read 'i never saw the EVT_APP_SUSPEND event arrive'). The app is a web portal, so it almost always keeps a live connection. Linger time is standard, 30 secs. After setting up the most basic objects needed to run, a web call is started. I don't think is humanly possible to catch it from start up to call init.
Nevermind shooting the handset with a sms AT THE EXACT MOMENT BEFORE the data call is started, which would send the app into suspend correctly. Has anyone been through this before and give me a hint on how to get a workaround on this?

#2: I wish i knew what they are doing, because with the exact same files, both the dll and mods i get the correct behavior. With the correct settings, Licesetype: uses, PriceType: demo, Number of Uses: 3, my app does what i designed it should do as a demo. It works, and it will prevent access after the 3rd use. :confused: Has anyone been through this one? Does anyone know how NSTL goes about testing this?

#3: How could i verify this, pray? I mean is not like we have access to the ADS. And even if we did, not locking out the application to free space is the HANDSET'S JOB, one that, to my knowledge, we can not interfere with or modify it. :confused: :mad: :eek: :(
Has anyone been through this? Could it be argued that such a thing is the handset's os job and not ours?

This is frustrating, still no word from NSTL or Qualcomm.

Saludos,

A very disapointed and frustrated Albert