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

Developer

Forums

Forums:

I have a couple of apps that use the network to upload data to a server, but the upload isn't crucial so the app should continue running even if the upload fails.

I have included code to ignore the data upload if any of the various IWEB calls fail, so if the user is out of range there shouldn't be a problem. IWEB_GetResponse will succeed but the callback will never happen, which is exactly what I've planned for.

There is a problem, however, if the phone is not network enabled. One of the calls (I haven't located which one yet, but presumably either the CreateInstance for the IWEB object or the IWEB_GetResponse) is causing the phone to reboot. In this case the phone is an LG VX4400.

One possible way that this could occur would be if a user bought a new phone with the web enabled, downloaded my app, and then cancelled the add-on web access. (I have a friend who did just that - he figured he'd buy a couple of games and then cancel web access to save the $15/month.)

In a case like that, I need to be able to determine whether or not the network is enabled from within my app. Is there a simple way to do this that I've missed?

There is no way to do this from within your application other than attempting to use the network. Your app should not however be crashing. Can you please use DBGPRINTF statements to check where you are crashing. Also check your code to verify the return from the calls. Most likely you are accessing a pointer that is not available. Please let me know your findings.
--Kevin Warmerdam
BREW Support

There is no way to do this from within your application other than attempting to use the network. Your app should not however be crashing. Can you please use DBGPRINTF statements to check where you are crashing. Also check your code to verify the return from the calls. Most likely you are accessing a pointer that is not available. Please let me know your findings.
--Kevin Warmerdam
BREW Support

I don't have a lot of luck with DBGPRINTF().
The messages in the following log file are created with statements like this:
DBGPRINTF( "%d:message", counter++ );
There are two counters... one starts at 0 and the other starts at 100. This is so that I can keep the two functions that are printing messages separated.
So, obviously, you should never see the same counter number twice and the counter numbers should always be in increasing order except for where the 0 series and the 100 series are interleaved.
As you can see from this log file, I'm getting repeats of messages and they're not even all showing up. (Where is message 5, for example?) I presume this is caused by the nature of the crash, but it certainly makes it difficult to track down the problem as I cannot be certain where, exactly, the program is getting to before it crashes.
Does it matter that this phone is not live? (I.e. it has neither voice nor network capability - it displays "Initial Programming Needed!" on its splash screen.)
--- LOG FILE FOLLOWS ---
BREW Logger Version 2.1.0.5 FileLogging Thread Started
TimeStamp Message FileName Line # Sev. Qty Drop Count Total Messages
05/30/03 10:49:03.148166 #*gST=16809984 AEEShell.c 5571 4 1 0 21888832
05/30/03 10:49:06.457249 #*gSU=16809984 AEEShell.c 5573 4 4 0 21888832
05/30/03 10:49:06.458166 #*gCL=16809984 AEEShell.c 5571 4 3 0 21888832
05/30/03 10:49:06.966333 0:IDisplay interface successfully creat AEEShell.c 5573 4 1 0 21888832
05/30/03 10:49:07.224083 1:ILicense object created AEEShell.c 5571 4 3 0 21888832
05/30/03 10:49:07.322249 2:PT_DEMO == FALSE, m_Uses == -1 AEEShell.c 5573 4 3 0 21888832
05/30/03 10:49:07.427249 3:ITAPI object successfully created AEEShell.c 5571 4 3 0 21888832
05/30/03 10:49:07.527249 2:PT_DEMO == FALSE, m_Uses == -1 AEEShell.c 5573 4 2 0 21888832
05/30/03 10:49:07.632249 3:ITAPI object successfully created AEEShell.c 5571 4 2 0 21888832
05/30/03 10:49:07.766315 4:MIN=<310000000003424> AEEShell.c 5573 4 1 0 21888832
05/30/03 10:49:07.871333 101:create the URL AEEShell.c 5571 4 4 0 21888832
05/30/03 10:49:07.971333 102:Contacting server... AEEShell.c 5573 4 4 0 21888832
05/30/03 10:49:08.071333 7:use count == 11 AEEShell.c 5571 4 5 0 21888832
05/30/03 10:49:08.173166 6:ISound object successfully created AEEShell.c 5573 4 4 0 21888832
05/30/03 10:49:08.292249 7:use count == 11 AEEShell.c 5571 4 3 0 21888832
05/30/03 10:49:08.409083 6:ISound object successfully created AEEShell.c 5573 4 2 0 21888832
05/30/03 10:49:08.411333 7:use count == 11 AEEShell.c 5571 4 2 0 21888832
05/30/03 10:49:08.648166 #*gST=570425344 AEEShell.c 5573 4 1 0 21888832
05/30/03 10:49:08.771333 #*gDC AEEShell.c 5571 4 3 0 21888832

I don't have a lot of luck with DBGPRINTF().
The messages in the following log file are created with statements like this:
DBGPRINTF( "%d:message", counter++ );
There are two counters... one starts at 0 and the other starts at 100. This is so that I can keep the two functions that are printing messages separated.
So, obviously, you should never see the same counter number twice and the counter numbers should always be in increasing order except for where the 0 series and the 100 series are interleaved.
As you can see from this log file, I'm getting repeats of messages and they're not even all showing up. (Where is message 5, for example?) I presume this is caused by the nature of the crash, but it certainly makes it difficult to track down the problem as I cannot be certain where, exactly, the program is getting to before it crashes.
Does it matter that this phone is not live? (I.e. it has neither voice nor network capability - it displays "Initial Programming Needed!" on its splash screen.)
--- LOG FILE FOLLOWS ---
BREW Logger Version 2.1.0.5 FileLogging Thread Started
TimeStamp Message FileName Line # Sev. Qty Drop Count Total Messages
05/30/03 10:49:03.148166 #*gST=16809984 AEEShell.c 5571 4 1 0 21888832
05/30/03 10:49:06.457249 #*gSU=16809984 AEEShell.c 5573 4 4 0 21888832
05/30/03 10:49:06.458166 #*gCL=16809984 AEEShell.c 5571 4 3 0 21888832
05/30/03 10:49:06.966333 0:IDisplay interface successfully creat AEEShell.c 5573 4 1 0 21888832
05/30/03 10:49:07.224083 1:ILicense object created AEEShell.c 5571 4 3 0 21888832
05/30/03 10:49:07.322249 2:PT_DEMO == FALSE, m_Uses == -1 AEEShell.c 5573 4 3 0 21888832
05/30/03 10:49:07.427249 3:ITAPI object successfully created AEEShell.c 5571 4 3 0 21888832
05/30/03 10:49:07.527249 2:PT_DEMO == FALSE, m_Uses == -1 AEEShell.c 5573 4 2 0 21888832
05/30/03 10:49:07.632249 3:ITAPI object successfully created AEEShell.c 5571 4 2 0 21888832
05/30/03 10:49:07.766315 4:MIN=<310000000003424> AEEShell.c 5573 4 1 0 21888832
05/30/03 10:49:07.871333 101:create the URL AEEShell.c 5571 4 4 0 21888832
05/30/03 10:49:07.971333 102:Contacting server... AEEShell.c 5573 4 4 0 21888832
05/30/03 10:49:08.071333 7:use count == 11 AEEShell.c 5571 4 5 0 21888832
05/30/03 10:49:08.173166 6:ISound object successfully created AEEShell.c 5573 4 4 0 21888832
05/30/03 10:49:08.292249 7:use count == 11 AEEShell.c 5571 4 3 0 21888832
05/30/03 10:49:08.409083 6:ISound object successfully created AEEShell.c 5573 4 2 0 21888832
05/30/03 10:49:08.411333 7:use count == 11 AEEShell.c 5571 4 2 0 21888832
05/30/03 10:49:08.648166 #*gST=570425344 AEEShell.c 5573 4 1 0 21888832
05/30/03 10:49:08.771333 #*gDC AEEShell.c 5571 4 3 0 21888832

You should check the DDS for known issues on the 4400. A 64 message buffer exists as well, but you are not hitting that.
The crash is most likely related to not having service, and you are relying on a return value or not checking for the one returned. Service should have little impact on DBGPRINTF statements (mainly priority tasking)

You should check the DDS for known issues on the 4400. A 64 message buffer exists as well, but you are not hitting that.
The crash is most likely related to not having service, and you are relying on a return value or not checking for the one returned. Service should have little impact on DBGPRINTF statements (mainly priority tasking)

Well, we enabled the phone that I was seeing the problem on and the problem is now gone.
The only thing I can think of is that one of the IWEB or ITAPI calls causes an unregistered phone to reboot, but works just fine on a registered phone that does not have network availability (either due to the user being out of range or the user not having a data network calling plan).

Well, we enabled the phone that I was seeing the problem on and the problem is now gone.
The only thing I can think of is that one of the IWEB or ITAPI calls causes an unregistered phone to reboot, but works just fine on a registered phone that does not have network availability (either due to the user being out of range or the user not having a data network calling plan).