21.What is an "SWI Exception?"

An "SWI Exception" is usually related to heap memory mismanagement. The most common causes of heap memory corruption are: overwriting the bounds of your allocated arrays, freeing objects more than once, and writing to wild or NULL pointers. 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.

22.Why does the emulator display a blank screen with my application's name when my application exits?

Problem: When an application exits while running on the emulator, instead of returning to the main menu screen, a blank screen is displayed with the application name in the upper left corner.
This behavior is caused by not freeing all allocated memory before exiting the application. Any buffer you allocate using MALLOC or IHEAP_Malloc() must be freed using FREE or IHEAP_Free(). For any instance of a BREW class that you create, you must call the corresponding release function to free that instance.

23.How does the memory architecture in BREW work?

BREW device has Flash RAM and Heap RAM. You can treat Flash RAM as a hard drive. Programs are stored there, but not run from it. You can treat Heap RAM as you would always treat a memory heap. Say you have an application that is 35k in size. This will take 35k from the Flash RAM to store on the device. When the application is run, the 35k will be loaded into Heap RAM in its entirety plus however much Heap RAM it needs to allocate. When the applet is released, this Heap RAM is freed. It will still occupy space on the Flash RAM until it is removed from the device.

24.What is the size limit for an applet?

The size of a BREW applet is limited by the amount of free file system space that is available, and by the amount of available RAM.
BREW applets, when executed, are loaded into RAM; any RAM left over can be used for memory allocation, loading resources, creating controls, etc. How much RAM is available depends on the type of phone, and its configuration. On a QCP-3035, for instance, the available RAM is 90K, 30K of which belongs to BREW and other phone related tasks, leaving 60K available for use by an applet. The memory available on each of the phones running BREW is available here.
Another limiting factor for applet size is heap fragmentation. If the largest available memory block is smaller than the size of the applet, then the applet will not be loaded. Use IHEAP_CheckAvail() to determine whether a memory block of sufficient size can be allocated. IHEAP_GetMemStats() can be used to determine the amount of RAM already used. If you have an applet that is too large for a particular device, a work-around is to split the application into multiple applets. Memory Allocation provides more information on how to avoid heap fragmentation.
Note: In order test a low memory condition on the BREW Emulator reduce the heap size in the Device Configuration file by the appropriate amount. BREW's System Info screen reports the amount of available flash memory, not the amount of available RAM.

25.Why can't an applet be run directly from flash RAM?

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

26.What's the difference between MALLOC() and IHEAP_Malloc() function in BREW-SDK?

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

27.What events must an applet handle?

In addition to the obvious EVT_APP_START and EVT_APP_STOP, your applet must support EVT_APP_SUSPEND and EVT_APP_RESUME in order to pass True BREW Testing.

28.How to test an application on the emulator to determine if it behaves properly under low memory conditions?

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

29.How to send SMS messages from a BREW application?

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

30.Can an SMS message be sent to an inactive applet?

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

31.Can incoming SMS messages be emulated with the SDK?SMS

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

32.What settings are required to allow a running BREW application to be suspended when a non-BREW SMS message is received on the Sharp Z-800?

On the Sharp Z-800 handset, you must set the following in order to receive non-BREW SMS:

33.When making a voice call using ITAPI_MakeVoiceCall, responding No to the Privacy Alert hangs the application. What is the workaround?

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.

34.After making a voice call using ITAPI_MakeVoiceCall, why does my application seem to be restarted when I respond 'No' to the "Return to Application" prompt?

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.

35.What guidelines should follow when making a voice call immediately after a data call?

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.

36.When making a voice call immediately after a data call, why do we see the Privacy Alert again instead of "Return to Application"?

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.

37.How do I obtain the phone number of the device on which my application is running?

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:

38.When will BREW offer HTTP Support?

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.

39.Why does GetHostByName() not work on my phone?

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.

40.Why do we get the value of 0.0.0.0 in dnsresult.addrs when I use GetHostByName()?

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: