Explore topic-wise InterviewSolutions in .

No. There is no WAY for BREW to ACCESS these and the DISPLAY data is stored as the vendor's PROPRIETARY format.

No. There is no way for BREW to access these and the display data is stored as the vendor's proprietary format.

No. The PALETTES are hard-coded by the VENDOR and will VARY from DEVICE to device.

No. The palettes are hard-coded by the vendor and will vary from device to device.

YES, We can remove it by following the steps outlined below:

• Associate the SOFT key menu with your TEXT CONTROL USING ITEXTCTL_SetSoftKey().
• Call IMENUCTL_DeleteAll() to delete the Multitap item.
• Add items using IMENUCTL_AddItem().

Yes, We can remove it by following the steps outlined below:

We can USE the IMENUCTL_AddItemEx METHOD with CtlAddItem STRUCTURE.

We can use the IMENUCTL_AddItemEx method with CtlAddItem structure.

The screen rectangle in which the menu is to be DRAWN (specified by IMENUCTL_SetRect) MUST exceed the screen HEIGHT by at least the height of a single menu item. Otherwise the menu item will be clipped and no scroll BAR will APPEAR.

The screen rectangle in which the menu is to be drawn (specified by IMENUCTL_SetRect) must exceed the screen height by at least the height of a single menu item. Otherwise the menu item will be clipped and no scroll bar will appear.

Use the BREW Resource Editor to create a dialog. You can also construct the dialog manually by creating data structures in your application to define the contents of the dialog.

Note: If a bmp FILE is being USED, make SURE that the bmp format is supported and that the bmp file is a valid full path, all in lowercase. 

Once the dialog has been created, it will have a resource ID and a resource file (.bar file). Use ISHELL_CreateDialog() to create the dialog:

ISHELL_CreateDialog(pMe->a.pIShell, SAMPLEAPP_RES_FILE,

RESOURCE_ID, NULL);

// SAMPLEAPP_RES_FILE is the resource file (.bar file) and
// RESOURCE_ID is the resource ID specified in the resource
// editor

Process the following events (return TRUE at the very least) in the app handler function:

case EVT_DIALOG_START:
return TRUE;
case EVT_DIALOG_INIT:
return TRUE;
case EVT_DIALOG_END:
return TRUE;

Call ISHELL_EndDialog when the dialog object is no longer needed. ISHELL_EndDialog(pMe->a.pIShell);

Use the BREW Resource Editor to create a dialog. You can also construct the dialog manually by creating data structures in your application to define the contents of the dialog.

Note: If a bmp file is being used, make sure that the bmp format is supported and that the bmp file is a valid full path, all in lowercase. 

Once the dialog has been created, it will have a resource ID and a resource file (.bar file). Use ISHELL_CreateDialog() to create the dialog:

ISHELL_CreateDialog(pMe->a.pIShell, SAMPLEAPP_RES_FILE,

RESOURCE_ID, NULL);

// SAMPLEAPP_RES_FILE is the resource file (.bar file) and
// RESOURCE_ID is the resource ID specified in the resource
// editor

Process the following events (return TRUE at the very least) in the app handler function:

case EVT_DIALOG_START:
return TRUE;
case EVT_DIALOG_INIT:
return TRUE;
case EVT_DIALOG_END:
return TRUE;

Call ISHELL_EndDialog when the dialog object is no longer needed. ISHELL_EndDialog(pMe->a.pIShell);

IDISPLAY_DrawHLine() and IDISPLAY_DrawVLine() always draw lines in black. Therefore setting CLR_USER_LINE to the desired color and then invoking IDISPLAY_DrawHLine() or IDISPLAY_DrawVLine() will not WORK.

The DEFINITIONS of these two IDISPLAY macros are below. To draw a LINE in a color other than black, USE the code contained in the macro definition and change to the desired fill color.

#define IDISPLAY_DrawHLine(p,x,y,len)
{AEERect RC;SETAEERECT(&rc,(x),(y),(len),1); IDISPLAY_FillRect((p),&rc,
RGB_BLACK);}
#define IDISPLAY_DrawVLine(p,x,y,len)
{AEERect rc;SETAEERECT(&rc,(x),(y),1,(len)); IDISPLAY_FillRect((p),&rc,
RGB_BLACK);}

IDISPLAY_DrawHLine() and IDISPLAY_DrawVLine() always draw lines in black. Therefore setting CLR_USER_LINE to the desired color and then invoking IDISPLAY_DrawHLine() or IDISPLAY_DrawVLine() will not work.

The definitions of these two IDISPLAY macros are below. To draw a line in a color other than black, use the code contained in the macro definition and change to the desired fill color.

#define IDISPLAY_DrawHLine(p,x,y,len)
{AEERect rc;SETAEERECT(&rc,(x),(y),(len),1); IDISPLAY_FillRect((p),&rc,
RGB_BLACK);}
#define IDISPLAY_DrawVLine(p,x,y,len)
{AEERect rc;SETAEERECT(&rc,(x),(y),1,(len)); IDISPLAY_FillRect((p),&rc,
RGB_BLACK);}

In Multi-tap mode, a key must be tapped SEVERAL times in order to specify a letter. For example, to specify the letter 'r', tap the number '7' three times. In T9 mode, a key is tapped only once per letter. T9 Text Input determines the most commonly USED word matching the input numeric sequence. If more than once word matches the sequence, the most common word is selected, with the ABILITY to scroll to the next most commonly used word.

The default text ENTRY mode is Multi-tap. T9 text entry mode is not supported on the EMULATOR.

In Multi-tap mode, a key must be tapped several times in order to specify a letter. For example, to specify the letter 'r', tap the number '7' three times. In T9 mode, a key is tapped only once per letter. T9 Text Input determines the most commonly used word matching the input numeric sequence. If more than once word matches the sequence, the most common word is selected, with the ability to scroll to the next most commonly used word.

The default text entry mode is Multi-tap. T9 text entry mode is not supported on the emulator.

One way to do this is to USE the IImage interface and SET the rate of animation (IImage_SetParm).

An example in which the animation rate is set to 750ms is shown below:

IIMAGE_SetParm(pMe->m_pIImage, IPARM_RATE, 750, 0);

You can also use a timer to trigger the IMAGE display FUNCTION. Use ISHELL_SetTimer() to set a timer:

ISHELL_SetTimer(pMe->a.m_pIShell, TIMER_RATE, (PFNNOTIFY)(ManipulateBitmap), pMe);

After TIMER_RATE ms expires, ManipulateBitmap function will be triggered, within which you can manipulate your image.

One way to do this is to use the IImage interface and set the rate of animation (IImage_SetParm).

An example in which the animation rate is set to 750ms is shown below:

IIMAGE_SetParm(pMe->m_pIImage, IPARM_RATE, 750, 0);

You can also use a timer to trigger the image display function. Use ISHELL_SetTimer() to set a timer:

ISHELL_SetTimer(pMe->a.m_pIShell, TIMER_RATE, (PFNNOTIFY)(ManipulateBitmap), pMe);

After TIMER_RATE ms expires, ManipulateBitmap function will be triggered, within which you can manipulate your image.

BREW SDK version 1.0 includes support for animated BMP. This is done by PLACING the FRAMES side-by-side and specifying the width of each frame with IIMAGE_SetParm with the IPARM-CXFRAME flag. Please see the IIMAGE example in the Examples directory

BREW SDK Version 1.1 has added support for BREW Compressed Image (BCI) animation. A BCI file contains one or more compressed small graphic image(s), each with a specified duration in milliseconds. The duration represents how long you want each image to be shown before it is replaced by the next image in the SERIES. You can use the BCI AUTHORING Tool included in BREW SDK Version 1.1 to create your BCI file. Please REFER to 'Using the BREW Compressed Image Authoring Tool' document included in the SDK for more information.

BREW SDK version 1.0 includes support for animated BMP. This is done by placing the frames side-by-side and specifying the width of each frame with IIMAGE_SetParm with the IPARM-CXFRAME flag. Please see the IIMAGE example in the Examples directory

BREW SDK Version 1.1 has added support for BREW Compressed Image (BCI) animation. A BCI file contains one or more compressed small graphic image(s), each with a specified duration in milliseconds. The duration represents how long you want each image to be shown before it is replaced by the next image in the series. You can use the BCI Authoring Tool included in BREW SDK Version 1.1 to create your BCI file. Please refer to 'Using the BREW Compressed Image Authoring Tool' document included in the SDK for more information.

Different PHONES have different display characteristics, so there is no unique ANSWER to this question. You can determine whether your application name will fit on the phone's display by COMPARING the WIDTH of the application name to the width of the display.

Use IDISPLAY_MeasureText() to determine the pixel width of your application name string. Use ISHELL_GetDeviceInfo() to determine the pixel width of the screen

Different phones have different display characteristics, so there is no unique answer to this question. You can determine whether your application name will fit on the phone's display by comparing the width of the application name to the width of the display.

Use IDISPLAY_MeasureText() to determine the pixel width of your application name string. Use ISHELL_GetDeviceInfo() to determine the pixel width of the screen

The TITLE area cannot CURRENTLY be suppressed in SDK VERSION 1.0. This has been ADDED in BREW version 1.1.

The title area cannot currently be suppressed in SDK version 1.0. This has been added in BREW version 1.1.

Ensure that you are freeing the MEMORY allocated by CONVERTBMP. Check the LAST Boolean parameter of CONVERTBMP. If True, a REALLOCATION was done and the memory must be freed USING SYSFREE.

For example:

pBmp = CONVERTBMP (pDataBytes, &imageInfo, &bVal);
IDISPLAY_BitBlt (pIDisplay, xDest, yDest, cxDest,
cyDest, pBmp, xSrc, YSRC, dwRopCode);
IDISPLAY_Update (pIDisplay);
if(bVal) //free only if realloc was done
SYSFREE (pBmp);

Ensure that you are freeing the memory allocated by CONVERTBMP. Check the last Boolean parameter of CONVERTBMP. If True, a reallocation was done and the memory must be freed using SYSFREE.

For example:

pBmp = CONVERTBMP (pDataBytes, &imageInfo, &bVal);
IDISPLAY_BitBlt (pIDisplay, xDest, yDest, cxDest,
cyDest, pBmp, xSrc, ySrc, dwRopCode);
IDISPLAY_Update (pIDisplay);
if(bVal) //free only if realloc was done
SYSFREE (pBmp);

If the text is LARGER than the Text Control SIZE, then a vertical or horizontal scrollbar will appear and you can NAVIGATE through the text using the DIRECTIONAL keys.

If the text is larger than the Text Control size, then a vertical or horizontal scrollbar will appear and you can navigate through the text using the directional keys.

The cursor can be moved to the end of the string by continuously invoking ITEXTCTL_HandleEvent() METHOD n times on the string, where n is the LENGTH of the string.
For example:

while(len) {
ITEXTCTL_HandleEvent(pMe->m_pIText, EVT_KEY,
AVK_RIGHT, dwParam);
len--;
}

NOTE: This does not currently work on the Kyocera 3035, unless dwParam is set to 10 (corresponds to AVK_RIGHT). Kyocera is working on fixing this issue such that dwParam will not need to be explicitly set. Setting dwParam = 10 will not have any adverse affect on the Sharp Z-800 handset.

A new API - ITEXTCTL_SetCursorPos(), will be added in BREW SDK version 1.2 to set the Text Control's cursor position.

The cursor can be moved to the end of the string by continuously invoking ITEXTCTL_HandleEvent() method n times on the string, where n is the length of the string.
For example:

while(len) {
ITEXTCTL_HandleEvent(pMe->m_pIText, EVT_KEY,
AVK_RIGHT, dwParam);
len--;
}

Note: This does not currently work on the Kyocera 3035, unless dwParam is set to 10 (corresponds to AVK_RIGHT). Kyocera is working on fixing this issue such that dwParam will not need to be explicitly set. Setting dwParam = 10 will not have any adverse affect on the Sharp Z-800 handset.

A new API - ITEXTCTL_SetCursorPos(), will be added in BREW SDK version 1.2 to set the Text Control's cursor position.

Magenta is the TRANSPARENT COLOR for color DEVICES. WHITE is the transparent color on MONOCHROME and 4-level gray-scale devices.

Magenta is the transparent color for color devices. White is the transparent color on monochrome and 4-level gray-scale devices.

BREW supports any BMP FILE with a color depth up to that which is provided on the device it is running on. BREW does not YET SUPPORT GIF and JPEG images. For now, you need to convert GIF and JPEG images into BMP images. PNG format and BREW Compressed Image (BCI) format will be supported in BREW SDK version 1.1.

In SDK versions prior to 1.1, the emulator is capable of emulating only 1, 4, and 8 bit color depth BMPS. In version 1.1, the emulator can also display 2 bit color depth BMPs

BREW supports any BMP file with a color depth up to that which is provided on the device it is running on. BREW does not yet support GIF and JPEG images. For now, you need to convert GIF and JPEG images into BMP images. PNG format and BREW Compressed Image (BCI) format will be supported in BREW SDK version 1.1.

In SDK versions prior to 1.1, the emulator is capable of emulating only 1, 4, and 8 bit color depth BMPs. In version 1.1, the emulator can also display 2 bit color depth BMPs

The INETMGR_SetLinger() function is provided to give DEVELOPERS FLEXIBILITY in designing their application. HOWEVER, it is not recommended that you alter the OEM's chosen default linger TIME (usually 30 SECONDS), unless your application has a compelling reason to do so. Altering the default linger time in either direction may cause your application to fail TRUE BREW Testing, or carrier rejection of your application.

The INETMGR_SetLinger() function is provided to give developers flexibility in designing their application. However, it is not recommended that you alter the OEM's chosen default linger time (usually 30 seconds), unless your application has a compelling reason to do so. Altering the default linger time in either direction may cause your application to fail TRUE BREW Testing, or carrier rejection of your application.

You must ensure that your app cancels its pending DNS callback, if any, using CALLBACK_Cancel() in all exit routes. This includes when the app is suspended and when the app is STOPPED (both via the End key and the Clear key).

For example, if you used the FOLLOWING code to lookup a DNS address:

CALLBACK_Init(&pMe->cbkLookup, GetHostByNameCB, pMe);
INETMGR_GetHostByName(pINetMgr,&pMe->dnsresult, hostName,
&pMe->cbkLookup);
You should use the following code to cancel the callback in all exit routes:
// CHECK if the callback can be cancelled. If NULL it has
// ALREADY happened and cannot be cancelled.
if(pMe->cbkLookup.pfnCancel != NULL) {
CALLBACK_Cancel(&pMe->cbkLookup);
}

The callback cancel code should be incorporated in the Suspend event handler code ( EVT_APP_SUSPEND), the app's FreeAppData function (which is called when the app is stopped, i.e. receives EVT_APP_STOP event), and in the Clear key event handler code (EVT_KEY and keycode AVK_CLR).

Note: Please note that your app will not pass TRUE BREW TESTING if it does not properly cancel its pending DNS callback. Some symptoms that might indicate that your app is not canceling its p ending DNS callback are:,/p>

• hone crashes upon starting up app
• Phone displays "Please Re-insert Battery" error upon starting up app

Both might imply that the previously running app did not cancel its pending DNS callback.

You must ensure that your app cancels its pending DNS callback, if any, using CALLBACK_Cancel() in all exit routes. This includes when the app is suspended and when the app is stopped (both via the End key and the Clear key).

For example, if you used the following code to lookup a DNS address:

CALLBACK_Init(&pMe->cbkLookup, GetHostByNameCB, pMe);
INETMGR_GetHostByName(pINetMgr,&pMe->dnsresult, hostName,
&pMe->cbkLookup);
You should use the following code to cancel the callback in all exit routes:
// Check if the callback can be cancelled. If NULL it has
// already happened and cannot be cancelled.
if(pMe->cbkLookup.pfnCancel != NULL) {
CALLBACK_Cancel(&pMe->cbkLookup);
}

The callback cancel code should be incorporated in the Suspend event handler code ( EVT_APP_SUSPEND), the app's FreeAppData function (which is called when the app is stopped, i.e. receives EVT_APP_STOP event), and in the Clear key event handler code (EVT_KEY and keycode AVK_CLR).

Note: Please note that your app will not pass TRUE BREW Testing if it does not properly cancel its pending DNS callback. Some symptoms that might indicate that your app is not canceling its p ending DNS callback are:,/p>

Both might imply that the previously running app did not cancel its pending DNS callback.

This is due to a bug in the BREW version 1.0.1 SDK - connect callback is not invoked under the following circumstances:

• Service is lost while connect is being attempted
• SERVER does not respond

As a workaround, you should implement a timer in association with the callback. If the connect callback does not occur in 30 seconds, you should timeout the connection.

For example:

// initialize pMe->connectCBInvoked = FALSE;
// Set timer for 30 seconds before invoking ISOCKET_Connect()
ISHELL_SetTimer(pMe->a.m_pIShell, 30000, ConnectTimeout_CB, (void *)pMe);
ISOCKET_Connect(pMe->m_pISocket, nodeINAddr, AEE_htons(USAGE_TEST_PORT),
SampleApp_ConnectCB, pMe);
// Set flag indicating connect CB was called
void SampleApp_ConnectCB(void *cxt, int err) {
SampleApp *pMe = (SampleApp*)cxt;
// Set flag indicating connect CB was called
pMe->connectCbInvoked = TRUE;
if (err) {
DisplayOutput((IApplet*)pMe, 3, "Connect failed!");
return;
}
DisplayOutput((IApplet*)pMe, 3, "Connected!");
}
// When timer expires, check if connect CB was invoked
static void ConnectTimeout_CB(void* cxt) {
SampleApp *pMe = (SampleApp *)cxt;
if(pMe->connectCbInvoked == FALSE) {
// Callback was not invoked within 30seconds - cancel connect callback
ISOCKET_Cancel(pMe->m_pISocket, 0, 0);
DisplayOutput((IApplet*) pMe, 3, "Connection TIMED out");
}
else {
// Callback invoked. Set flag to default value FALSE
pMe->connectCbInvoked = FALSE;
}
}

NOTE: Multiple TCP SOCKETS are not supported on the Kyocera 3035. It allows one TCP socket and one UDP socket at a given time.

This is due to a bug in the BREW version 1.0.1 SDK - connect callback is not invoked under the following circumstances:

As a workaround, you should implement a timer in association with the callback. If the connect callback does not occur in 30 seconds, you should timeout the connection.

For example:

// initialize pMe->connectCBInvoked = FALSE;
// Set timer for 30 seconds before invoking ISOCKET_Connect()
ISHELL_SetTimer(pMe->a.m_pIShell, 30000, ConnectTimeout_CB, (void *)pMe);
ISOCKET_Connect(pMe->m_pISocket, nodeINAddr, AEE_htons(USAGE_TEST_PORT),
SampleApp_ConnectCB, pMe);
// Set flag indicating connect CB was called
void SampleApp_ConnectCB(void *cxt, int err) {
SampleApp *pMe = (SampleApp*)cxt;
// Set flag indicating connect CB was called
pMe->connectCbInvoked = TRUE;
if (err) {
DisplayOutput((IApplet*)pMe, 3, "Connect failed!");
return;
}
DisplayOutput((IApplet*)pMe, 3, "Connected!");
}
// When timer expires, check if connect CB was invoked
static void ConnectTimeout_CB(void* cxt) {
SampleApp *pMe = (SampleApp *)cxt;
if(pMe->connectCbInvoked == FALSE) {
// Callback was not invoked within 30seconds - cancel connect callback
ISOCKET_Cancel(pMe->m_pISocket, 0, 0);
DisplayOutput((IApplet*) pMe, 3, "Connection timed out");
}
else {
// Callback invoked. Set flag to default value FALSE
pMe->connectCbInvoked = FALSE;
}
}

Note: Multiple TCP sockets are not supported on the Kyocera 3035. It allows one TCP socket and one UDP socket at a given time.

After the last connected SOCKET is closed, BREW waits for a CERTAIN linger time before TERMINATING the PPP CONNECTION. Hence the lingering call-in-progress indication.

The default linger time is 30 SECONDS. To change the linger time, use INETMGR_SetLinger().

After the last connected socket is closed, BREW waits for a certain linger time before terminating the PPP connection. Hence the lingering call-in-progress indication.

The default linger time is 30 seconds. To change the linger time, use INETMGR_SetLinger().

BREW uses asynchronous sockets. You can USE ISOCKET_Readable or ISOCKET_Writeable to be NOTIFIED when it is SAFE to read/write.

BREW uses asynchronous sockets. You can use ISOCKET_Readable or ISOCKET_Writeable to be notified when it is safe to read/write.

No. You USE UDP, SPECIFICALLY, ISOCKET_Bind and ISOCKET_RecvFrom

No. You use UDP, specifically, ISOCKET_Bind and ISOCKET_RecvFrom

This is because of the permissions on the MIF FILE for your applet. Please open your MIF file in the MIF editor and CHECK the CHECKBOX for NETWORK privileges, then save

This is because of the permissions on the MIF file for your applet. Please open your MIF file in the MIF editor and check the checkbox for Network privileges, then save

When an application CALLS ISOCKET_Release(), the internal state of the ISocket object CHANGES to "CLOSING," and BREW begins waiting for the asynchronous "closed" EVENT. Since the closed event is received in a callback, the reference count of the ISocket object is incremented to PREVENT it from being released before its internal state changes to closed.

When an application calls ISOCKET_Release(), the internal state of the ISocket object changes to "closing," and BREW begins waiting for the asynchronous "closed" event. Since the closed event is received in a callback, the reference count of the ISocket object is incremented to prevent it from being released before its internal state changes to closed.

There are two ways to DETERMINE if a socket is connected. The easiest is to check the return value of ISOCKET_Connect(). When a socket is ALREADY connected, ISOCKET_Connect() will return EISCONN.

It is also possible to monitor the state of a socket connection by registering for the socket status change events NE_SO_CLOSING, and NE_SO_CLOSED with INETMGR_OnEvent(). Using this method, your application can avoid trying to connect an already connected socket.

For more information about network and socket events, including NE_SO_CLOSING and NE_SO_CLOSED, please refer to the following include file: AEENet.h

For Example:

// Register to receive Network and Socket events
INETMGR_OnEvent(piNet, (PFNNETMGREVENT)CheckNetStatus,
(void*)pMe, TRUE);
//Callback INVOKED when Network/Socket event is received
static void CheckNetStatus(void* cxt, NetMgrEvent evt,
uint32 dwData)
{
SampleApp *pMe = (SampleApp*)cxt;
if(evt == NE_SO_CLOSING || evt == NE_SO_CLOSED) {
// FLAG set to false to indicate socket is disconnected
pMe->m_SocketConnected = FALSE;
ReleaseNetAndSocket(pMe);
}
if(evt == NE_SO_CONNECTED) {
// flag set to true to indicate socket is connected
pMe->m_SocketConnected = TRUE;
}
return;
}

There are two ways to determine if a socket is connected. The easiest is to check the return value of ISOCKET_Connect(). When a socket is already connected, ISOCKET_Connect() will return EISCONN.

It is also possible to monitor the state of a socket connection by registering for the socket status change events NE_SO_CLOSING, and NE_SO_CLOSED with INETMGR_OnEvent(). Using this method, your application can avoid trying to connect an already connected socket.

For more information about network and socket events, including NE_SO_CLOSING and NE_SO_CLOSED, please refer to the following include file: AEENet.h

For Example:

// Register to receive Network and Socket events
INETMGR_OnEvent(piNet, (PFNNETMGREVENT)CheckNetStatus,
(void*)pMe, TRUE);
//Callback invoked when Network/Socket event is received
static void CheckNetStatus(void* cxt, NetMgrEvent evt,
uint32 dwData)
{
SampleApp *pMe = (SampleApp*)cxt;
if(evt == NE_SO_CLOSING || evt == NE_SO_CLOSED) {
// flag set to false to indicate socket is disconnected
pMe->m_SocketConnected = FALSE;
ReleaseNetAndSocket(pMe);
}
if(evt == NE_SO_CONNECTED) {
// flag set to true to indicate socket is connected
pMe->m_SocketConnected = TRUE;
}
return;
}

In addition to the OBVIOUS memory and PERFORMANCE LIMITATIONS, it is not POSSIBLE to listen on a socket CONNECTION when a BREW application is running on a phone. These factors make implementing a server on BREW difficult at best.

In addition to the obvious memory and performance limitations, it is not possible to listen on a socket connection when a BREW application is running on a phone. These factors make implementing a server on BREW difficult at best.

PEER to peer CONNECTIONS between two PHONES have been found to be unreliable, FAILING when the phones are on the same subnet. It is best therefore to use a proxy server, transferring data between the phones USING the server as a go between.

Peer to peer connections between two phones have been found to be unreliable, failing when the phones are on the same subnet. It is best therefore to use a proxy server, transferring data between the phones using the server as a go between.

We can CHECK on the status of the PPP connection (active, inactive, opening or closing) using INETMGR_NetStatus().

NetState netState = NET_INVALID_STATE;
AEENetStats netStats;
netState = INETMGR_NetStatus (pINetMgr, &netStats);
We can use INETMGR_OnEvent() to MONITOR both the status of the PPP connection and socket connections. REFER to NetMgrEvent enum in AEENet.h for a list of all network and socket EVENTS.
// Register to receive Network and Socket events
INETMGR_OnEvent(piNet, (PFNNETMGREVENT)CheckNetStatus,
(void*)pMe, TRUE);
//Callback INVOKED when Network/Socket event is received
static void CheckNetStatus(void* cxt,
NetMgrEvent evt, uint32 dwData) {
SampleApp *pMe = (SampleApp*)cxt;
if(evt == NE_PPP) { 
// network event. dwData = NetState enum value
// refer NetState data structure in BREW API Reference doc
}
if(evt == NE_SO_CLOSING || evt == NE_SO_CLOSED) {
// socket event - closing or closed. 
// DwData is pointer to socket
}
… …
return;
}

We can check on the status of the PPP connection (active, inactive, opening or closing) using INETMGR_NetStatus().

NetState netState = NET_INVALID_STATE;
AEENetStats netStats;
netState = INETMGR_NetStatus (pINetMgr, &netStats);
We can use INETMGR_OnEvent() to monitor both the status of the PPP connection and socket connections. Refer to NetMgrEvent enum in AEENet.h for a list of all network and socket events.
// Register to receive Network and Socket events
INETMGR_OnEvent(piNet, (PFNNETMGREVENT)CheckNetStatus,
(void*)pMe, TRUE);
//Callback invoked when Network/Socket event is received
static void CheckNetStatus(void* cxt,
NetMgrEvent evt, uint32 dwData) {
SampleApp *pMe = (SampleApp*)cxt;
if(evt == NE_PPP) { 
// network event. dwData = NetState enum value
// refer NetState data structure in BREW API Reference doc
}
if(evt == NE_SO_CLOSING || evt == NE_SO_CLOSED) {
// socket event - closing or closed. 
// DwData is pointer to socket
}
… …
return;
}

This is a LIMITATION of the phone.

Program should call ISOCKET_Readable() to be informed when more data can be read from the stream. The callback routine registered by ISOCKET_Readable() will be invoked whenever data becomes available---you can usually call ISOCKET_Read() at this point. Continue calling ISOCKET_Readable() for as long as your program EXPECTS more data.

rv = ISOCKET_Read(piSock, (byte *)szBuf, sizeof(szBuf));
if (rv == AEE_NET_WOULDBLOCK) {
// WOULDBLOCK => no more data available at the moment
// Register the callback to read the data later.
ISOCKET_Readable(piSock, CommonReadCB, (void*)pMe);
return;
}
else if (rv == AEE_NET_ERROR) {
// error reading from socket
ReleaseNetAndSocket (pMe);
}
else if (rv > 0) { 
// rv bytes of data has been read from the socket into
// szBuf
// Read REMAINING data
ISOCKET_Readable(piSock, CommonReadCB, (void*)pMe); 
}
else { // rv == 0
// There is no more data to be received.
// The PEER has shut down the connection.
ReleaseNetAndSocket (pMe);
}

This is a limitation of the phone.

Program should call ISOCKET_Readable() to be informed when more data can be read from the stream. The callback routine registered by ISOCKET_Readable() will be invoked whenever data becomes available---you can usually call ISOCKET_Read() at this point. Continue calling ISOCKET_Readable() for as long as your program expects more data.

rv = ISOCKET_Read(piSock, (byte *)szBuf, sizeof(szBuf));
if (rv == AEE_NET_WOULDBLOCK) {
// WOULDBLOCK => no more data available at the moment
// Register the callback to read the data later.
ISOCKET_Readable(piSock, CommonReadCB, (void*)pMe);
return;
}
else if (rv == AEE_NET_ERROR) {
// error reading from socket
ReleaseNetAndSocket (pMe);
}
else if (rv > 0) { 
// rv bytes of data has been read from the socket into
// szBuf
// Read remaining data
ISOCKET_Readable(piSock, CommonReadCB, (void*)pMe); 
}
else { // rv == 0
// There is no more data to be received.
// The peer has shut down the connection.
ReleaseNetAndSocket (pMe);
}

All NETWORK callbacks OCCUR within the same thread context, at some point in time after the caller RETURNS CONTROL to the AEE event loop. If your application is busy doing something, callbacks will be queued, then invoked once your application returns control to the AEE event loop, ensuring DATA integrity..

All network callbacks occur within the same thread context, at some point in time after the caller returns control to the AEE event loop. If your application is busy doing something, callbacks will be queued, then invoked once your application returns control to the AEE event loop, ensuring data integrity..

This limit is OEM specific, and will vary depending on the DEVICE that your applet is running on---it is not SET by BREW.

Note: Multiple TCP SOCKETS are not supported on the Kyocera 3035. It allows one TCP SOCKET and one UDP socket at a given time.

This limit is OEM specific, and will vary depending on the device that your applet is running on---it is not set by BREW.

Note: Multiple TCP sockets are not supported on the Kyocera 3035. It allows one TCP socket and one UDP socket at a given time.

You should simply send what you can, and ISOCKET_Write() will tell you how much DATA was actually sent. If there is data remaining to be sent, simply offset your data pointer by the amount indicated by your last call to ISOCKET_Write().

For Example:
void CommonWriteCB (void *pUser) {
char *psz = NULL;
int cbWrite;
… … …
SampleApp * pMe = (SampleApp*)pUser;
// pszData is the data to be written
psz = pszData;
cbWrite = STRLEN (pszData);
// Loop till all the bytes are written.
while (cbWrite > 0) {
rv = ISOCKET_Write(pMe->m_pISocket, (byte *)psz,
(uint16)cbWrite);
if (rv == AEE_NET_WOULDBLOCK) {
// No byte were written SUCCESSFULLY. Register
// callback to try again later.
ISOCKET_Writeable(pMe->m_pISocket,
CommonWriteCB, (void *)pMe);
return;
} ELSE if (rv == AEE_NET_ERROR) {
// Write Error.
ReleaseNetAndSocket(pMe);
return;
}
// In case of parital write, loop and write the rest
cbWrite -= rv;
psz += rv;
}
… … …
}

You should simply send what you can, and ISOCKET_Write() will tell you how much data was actually sent. If there is data remaining to be sent, simply offset your data pointer by the amount indicated by your last call to ISOCKET_Write().

For Example:
void CommonWriteCB (void *pUser) {
char *psz = NULL;
int cbWrite;
… … …
SampleApp * pMe = (SampleApp*)pUser;
// pszData is the data to be written
psz = pszData;
cbWrite = STRLEN (pszData);
// Loop till all the bytes are written.
while (cbWrite > 0) {
rv = ISOCKET_Write(pMe->m_pISocket, (byte *)psz,
(uint16)cbWrite);
if (rv == AEE_NET_WOULDBLOCK) {
// No byte were written successfully. Register
// callback to try again later.
ISOCKET_Writeable(pMe->m_pISocket,
CommonWriteCB, (void *)pMe);
return;
} else if (rv == AEE_NET_ERROR) {
// Write Error.
ReleaseNetAndSocket(pMe);
return;
}
// In case of parital write, loop and write the rest
cbWrite -= rv;
psz += rv;
}
… … …
}

The maximum packet SIZE is OEM dependant, and may VARY from ONE manufacturer's PHONE to another. BREW has no control over this limitation.

The maximum packet size is OEM dependant, and may vary from one manufacturer's phone to another. BREW has no control over this limitation.

It is not possible to DETERMINE when a TCP/IP command is sent; BREW does not PROVIDE this capability.

It is not possible to determine when a TCP/IP command is sent; BREW does not provide this capability.

This may be due to INCORRECT implementation of error HANDLING in the GetHostByName() callback function. The error handling implementation in the GetHostByName() callback of the NetSocket EXAMPLE is incorrect. You can use the following sample implementation:

if(pMe->dnsresult.nResult > 0 && pMe->dnsresult.nResult
<= AEEDNSMAXADDRS) {
// DNS lookup success
// Process dnsresult.addrs
for(i = 0; i < pMe->dnsresult.nResult; i++) {
SPRINTF(szMsg,"Addr=: %x",pMe->dnsresult.addrs[i]);
DisplayOutput(pMe,i+4,szMsg);
}
} else {
// DNS Failure - error code is dnsresult.nResult
SPRINTF(szMsg, "DNS: error %d", pMe->dnsresult.nResult);
DisplayOutput(pMe, 2, szMsg);
}

This may be due to incorrect implementation of error handling in the GetHostByName() callback function. The error handling implementation in the GetHostByName() callback of the NetSocket example is incorrect. You can use the following sample implementation:

if(pMe->dnsresult.nResult > 0 && pMe->dnsresult.nResult
<= AEEDNSMAXADDRS) {
// DNS lookup success
// Process dnsresult.addrs
for(i = 0; i < pMe->dnsresult.nResult; i++) {
SPRINTF(szMsg,"Addr=: %x",pMe->dnsresult.addrs[i]);
DisplayOutput(pMe,i+4,szMsg);
}
} else {
// DNS Failure - error code is dnsresult.nResult
SPRINTF(szMsg, "DNS: error %d", pMe->dnsresult.nResult);
DisplayOutput(pMe, 2, szMsg);
}

For INETMGR_GetHostByName() to function CORRECTLY, the phone's DOMAIN Name Server (DNS) settings must be properly configured. This is GENERALLY TAKEN care of by the Service Provider, in which case the phone should be returned to the place of purchase, or an authorized service CENTER so that its DNS settings can be properly configured.

For INETMGR_GetHostByName() to function correctly, the phone's Domain Name Server (DNS) settings must be properly configured. This is generally taken care of by the Service Provider, in which case the phone should be returned to the place of purchase, or an authorized service center so that its DNS settings can be properly configured.

HTTP Support is available through the AEEWeb INTERFACE in VERSION 1.1 of the BREW SDK and above. With earlier versions of the SDK, use the ISocket interface to connect to a SERVER's HTTP port, and SEND HTTP "get" and "post" requests.

HTTP Support is available through the AEEWeb interface in version 1.1 of the BREW SDK and above. With earlier versions of the SDK, use the ISocket interface to connect to a server's HTTP port, and send HTTP "get" and "post" requests.

An application can obtain the phone NUMBER of the DEVICE on which it is running by CALLING ITAPI_GetStatus(). The phone number is in TAPIStatus.szMobileID.
For example:
TAPIStatus tapiStat;
if (ITAPI_GetStatus(pMe->p_tapi, &tapiStat) == EBADPARM) {
DisplayOutput((IApplet*)pMe, 6, "TAPI Status fetch failed");
}
DisplayOutput((IApplet*)pMe, 4, "MOBILE ID:");
DisplayOutput((IApplet*)pMe, 5, tapiStat.szMobileID);

An application can obtain the phone number of the device on which it is running by calling ITAPI_GetStatus(). The phone number is in TAPIStatus.szMobileID.
For example:
TAPIStatus tapiStat;
if (ITAPI_GetStatus(pMe->p_tapi, &tapiStat) == EBADPARM) {
DisplayOutput((IApplet*)pMe, 6, "TAPI Status fetch failed");
}
DisplayOutput((IApplet*)pMe, 4, "Mobile ID:");
DisplayOutput((IApplet*)pMe, 5, tapiStat.szMobileID);

Refer to above FAQ In addition to the more common causes, stack OVERRUN can ALSO lead to SWI Exceptions.

Note: It is RECOMMENDED that large buffers be allocated on the heap RATHER than on the stack as automatic variables.

Refer to above FAQ In addition to the more common causes, stack overrun can also lead to SWI Exceptions.

Note: It is recommended that large buffers be allocated on the heap rather than on the stack as automatic variables.

After the last socket is released, BREW waits for the network LINGER time (default linger time is 30s) to expire before terminating the PPP connection. The actual tearing down of the PPP connection takes about 3s. Therefore, (linger time + 3 seconds) must elapse between releasing the last socket and invoking ITAPI_MakeVoiceCall(). You should introduce a (linger time + 3 seconds) TIMER between releasing the last socket and making the voice call.

For example:

ReleaseNetAndSocket(pMe);
//LINGER_TIME below is in seconds
ISHELL_SetTimer(pMe->a.m_pIShell, (LINGER_TIME +3) * 1000,
Timer_CB, (void *)pMe);

In the timer callback code, you can make the voice call using ITAPI_MakeVoiceCall().
NOTE: In BREW SDK version 2.0, this 3-second lag is BUILT into BREW. The application will not need to implement the additional 3 seconds in its timer.

After the last socket is released, BREW waits for the network linger time (default linger time is 30s) to expire before terminating the PPP connection. The actual tearing down of the PPP connection takes about 3s. Therefore, (linger time + 3 seconds) must elapse between releasing the last socket and invoking ITAPI_MakeVoiceCall(). You should introduce a (linger time + 3 seconds) timer between releasing the last socket and making the voice call.

For example:

ReleaseNetAndSocket(pMe);
//LINGER_TIME below is in seconds
ISHELL_SetTimer(pMe->a.m_pIShell, (LINGER_TIME +3) * 1000,
Timer_CB, (void *)pMe);

In the timer callback code, you can make the voice call using ITAPI_MakeVoiceCall().
Note: In BREW SDK version 2.0, this 3-second lag is built into BREW. The application will not need to implement the additional 3 seconds in its timer.

MAKE sure that the parameter clsReturn (application to start when the call ends) in the call to ITAPI_MakeVoiceCall is 0 (zero). If you specify clsReturn as your APP's Class ID, then BREW TRIES to create ANOTHER instance of your app, rather than resume your app.

Make sure that the parameter clsReturn (application to start when the call ends) in the call to ITAPI_MakeVoiceCall is 0 (zero). If you specify clsReturn as your app's Class ID, then BREW tries to create another instance of your app, rather than resume your app.

This is a BUG in BREW SDK version 1.0.1, and will be fixed in an upcoming release.

The recommended workaround for BREW SDK Version 1.0.1 is for the user to PRESS 'No' twice (i.e. press Select Key twice). When the Privacy Alert Yes/No dialog is displayed, all key EVENTS up until the first Select key press GO to the Dialog. After the first Select key (for the dialog), subsequent key events go to the application.

Steps are outlined below:

• Added a boolean 'madeVoiceCall' in the Applet structure
• If ITAPI_MakeVoiceCall() returns Success, set madeVoiceCall to TRUE

retValue = ITAPI_MakeVoiceCall(pMe->p_tapi, PHONE_NUM,
AEECLSID_SAMPLEAPP);
ITAPI_Release(pMe->p_tapi);
if(retValue == SUCCESS) {
pMe->madeTapiCall = TRUE;
}

• Handle EVT_KEY in the app handler function. If the Select key was pressed and madeVoiceCall is TRUE, the user has selected No in response to the Privacy Alert. Set madeVoiceCall = FALSE and redraw screen.

case EVT_KEY:

if (wParam == AVK_SELECT && pMe->madeTapiCall ==
TRUE) {
// Redraw screen
pMe->madeTapiCall = FALSE;
}
return TRUE;

• If the user selected 'Yes' to the Privacy Alert, the application would have been SUSPENDED. When resumed, the madeVoiceCall flag must be cleared.

case EVT_APP_RESUME:
if(pMe->madeTapiCall == TRUE) {
pMe->madeTapiCall = FALSE;
}
… … …
… … …
return TRUE;

This is a bug in BREW SDK version 1.0.1, and will be fixed in an upcoming release.

The recommended workaround for BREW SDK Version 1.0.1 is for the user to press 'No' twice (i.e. press Select Key twice). When the Privacy Alert Yes/No dialog is displayed, all key events up until the first Select key press go to the Dialog. After the first Select key (for the dialog), subsequent key events go to the application.

Steps are outlined below:

retValue = ITAPI_MakeVoiceCall(pMe->p_tapi, PHONE_NUM,
AEECLSID_SAMPLEAPP);
ITAPI_Release(pMe->p_tapi);
if(retValue == SUCCESS) {
pMe->madeTapiCall = TRUE;
}

case EVT_KEY:

if (wParam == AVK_SELECT && pMe->madeTapiCall ==
TRUE) {
// Redraw screen
pMe->madeTapiCall = FALSE;
}
return TRUE;

case EVT_APP_RESUME:
if(pMe->madeTapiCall == TRUE) {
pMe->madeTapiCall = FALSE;
}
… … …
… … …
return TRUE;

On the SHARP Z-800 handset, you must set the FOLLOWING in ORDER to receive non-BREW SMS:
MAIN Menu -> Setup/Tool -> BREW Setting -> OFF.

On the Sharp Z-800 handset, you must set the following in order to receive non-BREW SMS:
Main Menu -> Setup/Tool -> BREW Setting -> OFF.

SMS :SMS emulation will be AVAILABLE in version 1.1 of the BREW SDK.

SMS :SMS emulation will be available in version 1.1 of the BREW SDK.

Yes, SMS NOTIFICATION events can be DELIVERED to an application, even if it is not currently ACTIVE. To do so, BREW first loads the APPLET, and then sends the EVT_APP_MESSAGE event to it. The application may start itself by calling ISHELL_StartApplet(), or can "silently" PROCESS the event without calling ISHELL_StartApplet().

Yes, SMS notification events can be delivered to an application, even if it is not currently active. To do so, BREW first loads the applet, and then sends the EVT_APP_MESSAGE event to it. The application may start itself by calling ISHELL_StartApplet(), or can "silently" process the event without calling ISHELL_StartApplet().

Currently, BREW does not EXPOSE a MEANS to SEND SMS messages from WITHIN a BREW applet. BREW applications can only receive SMS messages.

Currently, BREW does not expose a means to send SMS messages from within a BREW applet. BREW applications can only receive SMS messages.

This can be achieved by reducing the heap size in the device configurator FILE (.qsc file) to almost the size of the .mod file. Any RUN time allocations by the applications should fail and you can test if your application deals with those FAILURES correctly.

• SINCE the size of the mod file a is a lot less then the dll that runs in the emulator, the emulator approximates the size of the mod file to be 10% of dll.
• To PROPERLY run this test, create a separate directory that contains only the MIF of the application under test and have emulator point to this new directory (File->Change MIF Dir).

This can be achieved by reducing the heap size in the device configurator file (.qsc file) to almost the size of the .mod file. Any run time allocations by the applications should fail and you can test if your application deals with those failures correctly.

MALLOC and IHEAP_Malloc() are identical, just as FREE and IHEAP_Free() are identical. In earlier versions of the BREW SDK, malloc was part of the IHEAP INTERFACE, and was later made into a helper function for ease of use. Both are still available for backward compatibility, but it is recommended that, use MALLOC and FREE RATHER than IHEAP_Malloc() and IHEAP_Free().

An APP needs to CREATE IHeap interface only when it wants to get current memory usage statistics (IHEAP_GetMemStats()) or check if a memory block of a certain size can be ALLOCATED (IHEAP_CheckAvail()).

MALLOC and IHEAP_Malloc() are identical, just as FREE and IHEAP_Free() are identical. In earlier versions of the BREW SDK, malloc was part of the IHEAP Interface, and was later made into a helper function for ease of use. Both are still available for backward compatibility, but it is recommended that, use MALLOC and FREE rather than IHEAP_Malloc() and IHEAP_Free().

An app needs to create IHeap interface only when it wants to get current memory usage statistics (IHEAP_GetMemStats()) or check if a memory block of a certain size can be allocated (IHEAP_CheckAvail()).

BREW LOADS the apps into Heap RAM because FILES on EFS are stored as non- contiguous BLOCKS.

BREW loads the apps into Heap RAM because files on EFS are stored as non- contiguous blocks.