Explore topic-wise InterviewSolutions in .

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.

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.

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.

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.

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.

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.

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.

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.

"A "Pref Abort EXCEPTION" usually indicates that memory important to the phone operating system has been trashed. The two most common causes of this exception are DATA CORRUPTION (i.e. RUNNING off the end of an array), and STACK overruns.

"A "Pref Abort Exception" usually indicates that memory important to the phone operating system has been trashed. The two most common causes of this exception are data corruption (i.e. running off the end of an array), and stack overruns.

"The "Re-entrant Data Abort" EXCEPTION is often caused by stack overrun. When an applet is running on the phone the stack size is small, and you are more likely to see stack overrun problems than when running on the emulator. Solutions to this PROBLEM are reducing the size or NUMBER of objects on the stack, and using objects allocated on the heap instead of automatic variables.

NOTE: Version-related incompatibilities between applet code and the BREW image on the phone can also lead to this type of exception.

"The "Re-entrant Data Abort" exception is often caused by stack overrun. When an applet is running on the phone the stack size is small, and you are more likely to see stack overrun problems than when running on the emulator. Solutions to this problem are reducing the size or number of objects on the stack, and using objects allocated on the heap instead of automatic variables.

Note: Version-related incompatibilities between applet code and the BREW image on the phone can also lead to this type of exception.

"Undef Inst Exception" stands for "undefined instruction exception," and means that the program POINTER has JUMPED to a code segment that contains an undefined instruction. This can be the RESULT of memory corruption, a stack overrun, or version-related incompatibilities between applet code and the BREW image on the phone.

Memory is tighter on the phone than when running on the emulator. Therefore, memory and stack overrun problems will be more likely to show up on the phone. You should double check memory related areas of your code, especially auto variable ARRAYS and the maximum total size of allocated memory. To clear the phone, pull the battery out for a few seconds.

"Undef Inst Exception" stands for "undefined instruction exception," and means that the program pointer has jumped to a code segment that contains an undefined instruction. This can be the result of memory corruption, a stack overrun, or version-related incompatibilities between applet code and the BREW image on the phone.

Memory is tighter on the phone than when running on the emulator. Therefore, memory and stack overrun problems will be more likely to show up on the phone. You should double check memory related areas of your code, especially auto variable arrays and the maximum total size of allocated memory. To clear the phone, pull the battery out for a few seconds.

On the Kyocera 3035, you can test your app's handling of SUSPEND/Resume events by enabling automatic Keyguard (Main Menu->SETTINGS->Keyguard) before RUNNING your app. When the Keyguard kicks in, the running app will receive a Suspend Event. The app will receive Resume event when the screen is unlocked.

On the SHARP Z-800, you can test your app's handling of Suspend/Resume events by setting the alarm to go off a few minutes in the future (Main Menu->Setup/Tools->Alarm->Daily Alarm) and then running the BREW app. Please NOTE that in order for the app to be suspended when the alarm goes off, BREW Priority Setting must be off (Main Menu->Setup/Tools->BREW Priority Setting).

On the Kyocera 3035, you can test your app's handling of Suspend/Resume events by enabling automatic Keyguard (Main Menu->Settings->Keyguard) before running your app. When the Keyguard kicks in, the running app will receive a Suspend Event. The app will receive Resume event when the screen is unlocked.

On the Sharp Z-800, you can test your app's handling of Suspend/Resume events by setting the alarm to go off a few minutes in the future (Main Menu->Setup/Tools->Alarm->Daily Alarm) and then running the BREW app. Please note that in order for the app to be suspended when the alarm goes off, BREW Priority Setting must be off (Main Menu->Setup/Tools->BREW Priority Setting).

notifications:

• TAPI (CLASS ID: 0x01001007)
• NMASK_TAPI_STATUS
• 0x0001
• TAPI Status change EVENT
• NMASK_TAPI_SMS_TEXT
• 0x0002
• Incoming SMS
• NMASK_TAPI_SMS_TS
• 0x0004
• SMS message on SPECIFIC Teleservice ID
• INETMGR
• NMASK_OPENED
• 0x0001
• Network layer is available
• NMASK_CLOSED
• 0x0002
• Network layer is closed
• NMASK_IDLE
• 0x0004
• Network layer available and idleNote

notifications:

XML is no way clashes with HTML, SINCE they are for two different purposes.

ISHELL_SendEvent() :

• In the case of ISHELL_SendEvent(), the event is IMMEDIATELY sent to the application of the specified CLASS ID. If an instance of that class is not currently present, the AEE Shell creates one, and then invokes its IAPPLET_HandleEvent() function with the specified event code and data parameters. Unless it chooses to start itself, the application terminates after it completes processing of the event.
• The ISHELL_SendEvent() function allows for control over the destination applet. This function sends the event DIRECTLY to the destination applet.

ISHELL_PostEvent() :

• ISHELL_PostEvent() is similar, except that the destination class's IAPPLET_HandleEvent() function is not called immediately. The event is placed in a queue and is sent at a later time, which allows the calling application to CONTINUE its processing without interruption.
• The processing of events posted using ISHELL_PostEvent() is deferred until the next iteration of the event loop. This is useful in providing continued execution while allowing other events to be processed.

XML is no way clashes with HTML, since they are for two different purposes.

ISHELL_SendEvent() :

ISHELL_PostEvent() :

BREW sends the running application an EVT_APP_SUSPEND event in the case of a LOW BATTERY Warning. In ORDER to handle low battery condition, you must CORRECTLY handle EVT_APP_SUSPEND and EVT_APP_RESUME events.

BREW sends the running application an EVT_APP_SUSPEND event in the case of a Low Battery Warning. In order to handle low battery condition, you must correctly handle EVT_APP_SUSPEND and EVT_APP_RESUME events.

A key, that when pressed, will CLOSE the current application. Most OEMs designate this to be the AVK_CLR key.

• A key, that when pressed, will close all applications. Most OEMs designate this to be the AVK_END key.
• When AVK_END is pressed, BREW will immediately send EVT_APP_STOP to the active APPLET without first SENDING the AVK_END key. In addition, the FreeAppData() callback routine provided to AEEApplet_New() will be called prior to unloading the applet; no other events or callbacks will occur.
• When AVK_CLR is pressed, BREW will first send this event to the applet. If the applet does not handle the event (i.e. RETURNS FALSE in HandleEvent), only then BREW will close the application. In the implementation of your AVK_CLR handler, remember to also call FreeAppData as follows:

case AVK_CLR:

if (pMe->OnMainMenu == TRUE) {
// App is on main menu. THEREFORE pressing CLR key should cause app to exit
HelloWorld_FreeAppData(pi); //clean up
return FALSE; //return FALSE so that BREW will now close application
}
else { // Not on main menu.
// Therefore pressing CLR key should cause app to undo one level of menu
// nesting. Show previous menu in menu hierarchy
return TRUE;
}
Make sure that your FreeAppletData() properly cleans up all allocated memory and resources. All objects and interfaces created by CreateInstance, CreateDialog, MALLOC, etc., must have an associated call to Release or FREE.

A key, that when pressed, will close the current application. Most OEMs designate this to be the AVK_CLR key.

case AVK_CLR:

if (pMe->OnMainMenu == TRUE) {
// App is on main menu. Therefore pressing CLR key should cause app to exit
HelloWorld_FreeAppData(pi); //clean up
return FALSE; //return FALSE so that BREW will now close application
}
else { // Not on main menu.
// Therefore pressing CLR key should cause app to undo one level of menu
// nesting. Show previous menu in menu hierarchy
return TRUE;
}
Make sure that your FreeAppletData() properly cleans up all allocated memory and resources. All objects and interfaces created by CreateInstance, CreateDialog, MALLOC, etc., must have an associated call to Release or FREE.

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.

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.

Currently, support for BREW is only available for DEVICES based on the following QUALCOMM chipsets: MSM3100, MSM3300, MSM5000, MSM5100, and MSM5105. In ADDITION, for a particular phone or other device to support BREW, it must be "BREW enabled" with a version of the BREW runtime provided by the device's manufacturer.

Currently, support for BREW is only available for devices based on the following QUALCOMM chipsets: MSM3100, MSM3300, MSM5000, MSM5100, and MSM5105. In addition, for a particular phone or other device to support BREW, it must be "BREW enabled" with a version of the BREW runtime provided by the device's manufacturer.

No. You should treat the SDK as a fully integrated stand-alone PLATFORM, which includes avoiding the C STANDARD Libraries. BREW has PROVIDED a port of the most COMMON FUNCTIONS.

No. You should treat the SDK as a fully integrated stand-alone platform, which includes avoiding the C Standard Libraries. BREW has provided a port of the most common functions.

BREW does not SUPPORT multi-threading. BREW does have support for COOPERATIVE multi-tasking.

BREW does not support multi-threading. BREW does have support for cooperative multi-tasking.

DUE to the requirement for Unicode support, the SDK runs only on the MICROSOFT WINDOWS NT™ 4.0, Windows 2000™ and Windows XP™ PLATFORMS. Windows 98 is not supported by the BREW SDK.

Due to the requirement for Unicode support, the SDK runs only on the Microsoft Windows NT™ 4.0, Windows 2000™ and Windows XP™ platforms. Windows 98 is not supported by the BREW SDK.

The solution is to modify your makefile in the following FASHION:

• COMMENT out the ARMBIN, ARMINC, and ARMLIB declaration.
• Add the full PATH to the ARMCC, LD, and HEXTOOL variables. Make sure you double quote the path.

The solution is to modify your makefile in the following fashion:

function AEEMod_Load() MUST be moved to a DIFFERENT source file and this file must be compiled in ARM mode. AEEMod_Load() must always be compiled in ARM mode.

All files that are compiled in thumb mode MUST have the INTERWORK compiler option turned on. If this option is NOT turned on in the MAKE file, the app will very LIKELY crash.

function AEEMod_Load() must be moved to a different source file and this file must be compiled in ARM mode. AEEMod_Load() must always be compiled in ARM mode.

All files that are compiled in thumb mode MUST have the INTERWORK compiler option turned on. If this option is NOT turned on in the make file, the app will very likely crash.

The ARM BREW Builder can be USED to COMPILE BREW APPLICATIONS.

The ARM BREW Builder can be used to compile BREW applications.

When an application is running on the BREW Emulator, DBGPRINTF outputs messages to the Visual C++ Debug Window. Currently, DBGPRINTF messages are not available while running on a phone. SUPPORT for outputting debug messages to a HOST PC via serial connection is under development.

When an application is running on the BREW Emulator, DBGPRINTF outputs messages to the Visual C++ Debug Window. Currently, DBGPRINTF messages are not available while running on a phone. Support for outputting debug messages to a host PC via serial connection is under development.

The device configurator FILE (.qsc) is used by the BREW Emulator APPLICATION, and is not required to run applications on the PHONE.

The device configurator file (.qsc) is used by the BREW Emulator application, and is not required to run applications on the phone.

To build applications for the PHONE requires the ARM Developer Suite of tools, which are used to compile and link a project that has been developed using the PC-based BREW SDK, and related tools. RUNNING an application built using the ARM tools requires a BREW-enabled phone, a data cable for establishing a SERIAL connection to the phone, and file copying SOFTWARE such as QUALCOMM's BREW AppLoader application. See How to Build a Downloadable BREW Application for more details.

To build applications for the phone requires the ARM Developer Suite of tools, which are used to compile and link a project that has been developed using the PC-based BREW SDK, and related tools. Running an application built using the ARM tools requires a BREW-enabled phone, a data cable for establishing a serial connection to the phone, and file copying software such as QUALCOMM's BREW AppLoader application. See How to Build a Downloadable BREW Application for more details.

Use BREW AppLoader to upload applications to the phone. The following EXAMPLE shows files and locations for an application with the name " brewApp."

/brew/ brewApp.mif

• GENERATED by BREW MIF Editor.

/brew/ brewApp/ brewApp.bar

• Generated by BREW RESOURCE Editor.

/brew/ brewApp/ brewApp.mod

• COMPILED and linked with ARM BREW Builder.

/brew/ brewApp/ brewApp.sig

• Digital Signature.

All directory and file NAMES on the phone must be in lower case. Any additional files specific to your application may also be copied to the application directory, or subdirectories of the application directory.

The Digital Signature file is generated using the BREW TestSig Generator, then renamed with the name of the application. The first part of the .sig filename must be the same as the first part of the .mod filename.

After uploading files, reset the phone.

Use BREW AppLoader to upload applications to the phone. The following example shows files and locations for an application with the name " brewApp."

/brew/ brewApp.mif

/brew/ brewApp/ brewApp.bar

/brew/ brewApp/ brewApp.mod

/brew/ brewApp/ brewApp.sig

All directory and file names on the phone must be in lower case. Any additional files specific to your application may also be copied to the application directory, or subdirectories of the application directory.

The Digital Signature file is generated using the BREW TestSig Generator, then renamed with the name of the application. The first part of the .sig filename must be the same as the first part of the .mod filename.

After uploading files, reset the phone.