ArticlesTutorialsInterview Questions & AnswersCertificationsFree Books & Sample ChaptersTechnical Discussions  Your Account | Advertise with us | Feedback |
BREW Interview Questions
Build a Downloadable BREW Application Languages and Operating Systems
Processor Event Handling
Memory Management TAPI
Networking GUI
Database Sound
Date & Time Class ID's
Backward Compatibility TRUE BREW Testing
Extensions Privileges
Localization Miscellaneous

« Previous | 1 2 3 4 5 |Next »

add to:
Y! MyWeb
1.How to transfer compiled applications to a 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

    - Generated by BREW MIF Editor.

  • /brew/ brewApp/

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

2.How to compile an application to run on a handset?

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.

3.How to upload a device configurator file (.qsc) to a phone

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

4.How to debug output on emulator and phone?

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.

5.What compilers can be used to compile BREW applications

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

6.What guidelines should be followed when compiling an application in Thumb mode?

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

7.What to do if we installed ARM BREW Builder or ARM Development Suite into a path with spaces?

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.

Languages and Operating Systems:

8.What are the Operating System requirements of 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.

9.Does BREW support multi-threading?

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

10.Can we link to Windows DLLs from the SDK?

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.


11.On what devices is BREW supported?

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.

Event Handling:

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

13.What difference is there between using the phone's "End" key to close an applet, and using the "Clear" key to close an applet?

An OEM of a particular device (phone) designates key(s) for the following two activities:

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

14.How do I deal with a Low Battery Warning?

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.

15.What is the difference between ISHELL_SendEvent() and ISHELL_ PostEvent()?

ISHELL_SendEvent() and ISHELL_PostEvent() functions are both used to send an event to a specified class. The difference between the two lies in the manner in which the event is sent.

ISHELL_SendEvent() ISHELL_PostEvent(
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. 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 ISHELL_SendEvent() function allows for control over the destination applet. This function sends the event directly to the destination applet. 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.

Back to top

« Previous | 1 2 3 4 5 |Next »

Add this FAQs to :
Spurl Slashdot
Y! MyWeb


About Us | Our Mission | Terms of use | Author Terms |    Search        | Contact Us | Advertise With Us | Link to Us | Sitemap
Copyright © 2016 developersBOOK.COM. All rights reserved.