Brew Interview Preparation Guide

Download PDF

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.

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

No. You use UDP, specifically, ISOCKET_Bind and ISOCKET_RecvFrom

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

When the phone goes out of a coverage area, the data call will drop. When this happens, BREW cleans up the underlying OEM sockets that are in use. The ISocket(s) used by an app continue to exist, and the app will get appropriate error responses when it tries to use them.

For synchronous (TCP/IP) data communication, there are two ways to handle the potentially bad sockets:


Check the return value from all Socket operations

Writing or reading from the socket will cause AEE_NET_ERROR to be returned. In your code, you should check the return value from the Socket connect, read, write and take appropriate action.

// Connect callback
static void SampleApp_ConnectCB(void *cxt, int err) {
SampleApp *pMe = (SampleAppApp*)cxt;

if (err) {
// connect failed
SampleApp_CleanUp(pMe);
//Clean up net manager and
// sockets
ShowMainMenu(pMe);
return;
}

}

// Writing
iRet = ISOCKET_Write(pMe->m_piSock, (byte*)Request,
(uint16)STRLEN(Request));
if (iRet == AEE_NET_ERROR) {
// Write error
SampleApp_CleanUp(pMe);
// Clean up net manager and sockets
ShowMainMenu(pMe);
return;
}


// Reading
iRet = ISOCKET_Read(pMe->m_piSock, (byte*)buf,
sizeof(buf));
if (iRet == AEE_NET_ERROR) {
// Read error
SampleApp_CleanUp(pMe);
// Clean up net manager and sockets
ShowMainMenu(pMe);
return;
}



Register for change in network/socket state

Another way to handle the phone going out of coverage while a data call is in progress is to register for Network and Socket events using INETMGR_OnEvent() and take appropriate action when notified of change in network/socket status. In the example below, a flag is set to indicate that the socket is bad. The socket state is checked before it is used.

For more information on Network and Socket events, please refer to NetMgrEvent and NetState enums in aeenet.h include file.

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_PPP) {
if(dwData == NET_PPP_CLOSING || dwData ==
NET_PPP_CLOSED) {
// flag set to false to indicate socket is bad
pMe->m_SocketState = FALSE;

// clean up network and socket
ReleaseNetAndSocket(pMe);
}
}

if(evt == NE_SO_CLOSING || evt == NE_SO_CLOSED) {
pMe->m_SocketState = FALSE;
ReleaseNetAndSocket(pMe);
}

if(evt == NE_SO_CONNECTED) {
pMe->m_SocketState = TRUE;
}

return;
}

// Check socket state before using it
static void RoadWarriorApp_ReadCB(void *cxt) {
int rc;
SampleApp *pMe = (SampleApp *)cxt;

if(pMe->m_SocketState == FALSE) { //socket is bad
ReleaseNetAndSocket(pMe);
ShowMainMenu(pMe);
return;
}

rc = ISOCKET_Read(piSock, (byte*)buf, sizeof(buf));

}



When registering for network and socket events using INETMGR_InEvent(), you must de- register before terminating the application by using INETMGR_OnEvent() with bRegister = FALSE.

Note: After the phone goes out of coverage, the sockets are unusable. You must release your ISocket(s) and reinstantiate them when next required. The INetMgr does not need to be released and re-instantiated before using it for the next network operation, however there is no harm in doing so.

To handle potentially bad sockets for asynchronous(UDP) data communication, register for change in network/socket state (described in number 2 above).

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().

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.

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>

Phone 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.

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.

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.

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;
}

Certain limited symbol entry is available by pressing a certain key (usually 1) multiple times. This set of symbols is OEM dependent. On the Kyocera 3035, the following symbols are available by pressing the '1' key multiple times: .&@,-':;?/"(). On the Sharp Z- 800, the following symbols are available by pressing the 1 key multiple times: .,@:!?/.

To allow a greater breadth of symbol entry in your text control, you must associate your text control to a soft key menu using ITEXTCTL_SetSoftKeyMenu(). The set of symbols available using this method are:
-.&'()_!?*#%":+<>=¿¡""/\@,~{}$[]^;.

ITEXTCTL_SetSoftKeyMenu() adds an item to the Soft Key menu that allows the user to change the text entry mode (the text string for this item is the currently selected mode - for example, MultiTap). When it receives this command, the text control displays a menu allowing the user to select the new text entry mode. After the user selects the new mode, the text control is reactivated and the user may continue to enter text. When entering text, the user may press the Select Key to leave text-edit mode and activate the SoftKey Menu. While the Soft Key menu is active, the user may press the UP key to return to edit mode without making a menu selection.

The following is an example of how to allow multiple input modes in your text control:

// Create text control
ISHELL_CreateInstance(pMe->a.m_pIShell, AEECLSID_TEXTCTL,
(void **)&pMe->m_pIText);

if (pMe->m_pIText) {
// Create soft key menu
ISHELL_CreateInstance(pMe->a.m_pIShell, AEECLSID_SOFTKEYCTL,
(void **)&pMe->m_pISoftKey);
if (!pMe->m_pISoftKey) {
ITEXTCTL_Release (pMe->m_pIText);
pMe->m_pIText = NULL;
return FALSE;
}
}
else {
return FALSE;
}

// Set the soft key menu rectangle
IMENUCTL_SetRect(pMe->m_pISoftKey, &softKeyRect);

// Set text control title, size, properties, rectangle
ITEXTCTL_SetTitle(pMe->m_pIText, NULL, NULL, titleString);
ITEXTCTL_SetMaxSize(pMe->m_pIText, 100);
ITEXTCTL_SetProperties(pMe->m_pIText, TP_FRAME | TP_MULTILINE );
ITEXTCTL_SetRect(pMe->m_pIText, &rect);

// Initialize the softkey menu of the text control.
ITEXTCTL_SetSoftKeyMenu (pMe->m_pIText, pMe->m_pISoftKey);

// Set both the soft key and text control active.
IMENUCTL_SetActive(pMe->m_pISoftKey,TRUE);
ITEXTCTL_SetActive (pMe->m_pIText, TRUE);


In the app's HandleEvent function, you must handle the EVT_KEY and EVT_COMMAND

events as follows:

case EVT_COMMAND:
// Process EVT_COMMAND event - change of input mode
if((pMe->m_pIText != NULL) && ITEXTCTL_HandleEvent(pMe->m_pIText,
eCode, wParam, dwParam)) {
return TRUE;
}
return FALSE;

case EVT_KEY:
if ((pMe->m_pIText != NULL) && ITEXTCTL_HandleEvent(pMe->m_pIText,
EVT_KEY, wParam, dwParam)) {
//Event handled by text control
return TRUE;
}

if(pMe->m_pISoftKey != NULL && IMENUCTL_HandleEvent(
pMe->m_pISoftKey, EVT_KEY, wParam, dwParam)) {
//Event handled by menu control
return TRUE;
}
return FALSE;

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.

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().

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.

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);}

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.

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