The largest Interview Solution Library on the web


Interview Questions
« Previous | 0 | 1 | 2 | 3 | 4 | Next »

41.With no TCP/IP Flush command available in BREW, how can I confirm that a command is sent right away?

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

42.What is the largest packet size supported by BREW?

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

43.When transmitting large files, do we have to break the file up into packets before sending, or does BREW do this for me?

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

44.How many sockets can be opened simultaneously?This

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.

45.Are network callbacks invoked in the context of the main thread, and if so how is the data integrity preserved in the current context?

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

46.When reading from a socket the phone reads whatever it can in one go, while the emulator reads large packets in chunks. Why?

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

47.How can we check the status of my sockets and PPP connection?

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

48.Is it possible to transfer data between two phones?

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.

49.Can a BREW-enabled device be used as a server?

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.

50.Is there any way to tell if a socket is already connected?

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

51.Why does ISOCKET_Release() return one when we are expecting a return value of zero?

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.

52.Why does ISHELL_CreateInstance return ECLASSNOTSUPPORT when I try and create an instance of the net manager (AEECLSID_Net)?

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

53.Can we have a listening TCP socket?

No. You use UDP, specifically, ISOCKET_Bind and ISOCKET_RecvFrom

54.Does BREW support blocking sockets?

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

55.How can we handle the case when we lose cellular coverage?

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

56.When we terminate a data call by closing an open socket, why does the phone still indicate that a data call is in progress?

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

57.Why does connect callback not timeout when service is lost (while attempting to connect) or the server does not respond?

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.

58.What precautions should we take when I invoke INETMGR_GetHostByName() to perform DNS lookup?

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.

59.Are there any restrictions on what value we can set my application's network linger time to?

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.

60.What image formats are supported in BREW?

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

« Previous | 0 | 1 | 2 | 3 | 4 | Next »


copyright © 2014 - all rights riserved by javatechnologycenter.com