Project Summary: Movieticketing

Booking the tickets of famous movies, concerts and plays was not so easy until the development of movie ticketing application.

A kind of mobile application that would be installed on the mobile and enables the users to book the movie tickets in the various cinema halls in a particular listed city. The application enables its user to select a particular city from the listed cities. Moreover the user is given option of selecting the subregions in the particular city. Then the user is provided the list of cinema halls in the subregion. Then list of movies, plays or concerts.

When the user tries to book a movie or plays or concerts tickets, he would be prompted to fill his credit card details through which he wants to make the payments. All the credit card details and the data which is needed to be sent to server is sent in an encrypted form so that details can't be determined.

Rest I 'll tell you tommorrow...

BREW UI Widgets: An Introduction

IWidget is the interface for describing user interface elements of a wide variety of types and capabilities including containers, forms, controls such as checkboxes and radio button, static and editable text, decorators and many other UI objects. The IWidget interface provides many common controls, and can used as a base class for new custom widgets and UI objects. Widgets, in general, possess characteristics of both display and behavior.

Creating Sig files on brew

SIG files

SIG files are device-specific signature files that are required for each device you are using for your application development. These files must be obtained from QUALCOMM and are good for 90 days. After 90 days, the signature file expires and QUALCOMM must issue a new signature file.

Only one SIG file is required per device. However, because each individual application requires its own corresponding SIG file, you make a copy of the original SIG file and rename it to match the name of the application you have created. Remember that the SIG file must reside in the same folder as the MOD file, the application file for the BREW device.

You must be an authenticated BREW developer to access the signature generation utility on the BREW website.

NOTE

SIG files are required for testing applications on devices, but they are not required for testing using the BREW Simulator.

To obtain a SIG file:

1. Go to the BREW website and navigate to the page that contains the link to the QUALCOMM web-based test signature generator.
2. Select BREW Testing Generator.
3. Enter your BREW developer user name and password.
4. In the ESN field, type 0x where the ESN number is the number you find under the device battery when you lift it up.
5. Click Generate and wait for the Download Signature link to appear.
6. Download the signature and save the file; it will be required for all testing on the device.

Why carriers choose Brew Platform for developing applications.

There are two main reasons for doing so

1. Decreasing ARPU
2. Increasing Subscriber demand

The mobile market share is growing. For the existence of a operator / carrier in the market it is neccesarry for it to keep the prices competitive. Every day the no. of telephone users are increasing . Hence increase in subscribers base makes the operators to upgrade their infrastructure so as to meet the demands of increasing subscribers. But as a matter of fact the cost of upgradation of infrasturcture couldn't be met by the revenue generated by a user. Hence to increase ARPU VAS comes in picture. Operators want to increase ARPU through VAS. VAS applications on CDMA handsets will definitely be a boom.

Running your brew application on a device is entirely different than that on a simulator. Memory stack plays a prominent role in it.

Stack Usage



With BREW™, each running program has a call stack and a heap. Each has a finite maximum amount of space. If the heap cannot be expanded without exceeding the maximum space for it, memory allocation attempts fail; an application should detect this and deal with it as gracefully as possible. However, if the stack expands past its maximum (called "smashing the stack") data is overwritten. This can cause seemingly random and often strange bugs or crashes. Smashing the stack can be a very difficult problem to debug, because it may be data-dependent, won't occur in the emulator, and the code may look fine.

Be sure to keep your stack size below 500 bytes.

To reduce your stack size, try to keep the calling depth short (avoid recursion or deeply nested function calls). Also, except for simple items such as ints, pointers, and other scaler types, consider allocating memory dynamically instead of on the stack. For example, to avoid declaring a buffer inside a function, declare a pointer and dynamically allocate the buffer. (To further reduce memory usage and object code size, you may want to use a global buffer instead of local buffers in multiple functions.)

One method of reducing call depths is to manually unroll your code (taking the code from functions that would otherwise be called and inserting it into a function that would otherwise call it).

Another is to use the INLINE specification with function declarations. However, be aware that compilers may not honor an INLINE directive. For example, as of this writing, the ARM C compiler is reported to ignore INLINE. Use the ARM C++ compiler instead (even if you are writing normal C code). Also, many compilers do not inline functions that are called from outside the file in which they are declared.

The following examples show how to prevent smashing of the stack due to String variables , large structures, and recursion.

Using ITextCtl

A text control enables the device user to enter a string of text using the keys on the device. The text control consists of an optional title and a rectangular window containing one or more lines in which the entered text is displayed to the device user. The text control handles the translation of device user key presses into characters. Your application only needs to pass keypress events to the text control while it is active and retrieve the text from the control when device user text entry has completed. The translation process depends on the text entry modes the device supports (for example, the standard multi-tap mode in which the device user selects from the characters mapped to each key, and Tegic's T9 predictive text input mode). If more than one text entry mode is supported, your application makes it possible for the device user to select the specified mode while the text control is active. The text control allows you to specify a Soft Key menu that is used for this purpose.

While the text control is active, your application must send all keypress events to it by calling ITEXTCTL_HandleEvent(). The input mode menu control is managed by the underlying text control. If the input mode menu is activated by pressing the associated softkey, then the underlying text control will be deactivated until the input mode menu is dismissed.

To use a text control in your application

1. Call ISHELL_CreateInstance() to create an instance of the text control.

2. Call ITEXTCTL_SetRect() to specify the screen rectangle that contains the text control.

3. If specified, call ITEXTCTL_SetTitle() or ITEXTCTL_SetText() to specify the control's title and the initial value of its text string.

4. Call ITEXTCTL_SetProperties() to set any text control properties.

5. Call ITEXTCTL_SetSoftKeyMenu() to specify the Soft Key menu that is associated with the text control, if any.

6. Call ITEXTCTL_SetActive() to activate the text control and draw its contents on the screen.

7. While the text control is active, call ITEXTCTL_HandleEvent() to pass it any key events generated by the user.

8. When the device user has completed entering text, call ITEXTCTL_GetText() or ITEXTCTL_GetTextPtr() to retrieve the text the device user has entered. (If you are using a Soft Key menu, the device user may signal the completion of text entry with a "Done" item in the menu, or by pressing the SELECT or other key if no Soft Key menu is present).

9. Call ITEXTCTL_Release() to free the text control when you no longer need it.

The following header file is required for ITextCtl

AEEText.h

Required Header File

AEEText.h

Intangible gains of SCJP

have been preparing for SCJP 1.4 examination for 3months. Now i can score more than 80% in simulation examinations by Whizlabs and others. Next month i am going to take that examination and i belive on myself that i can score more than 90% in real examination but What i have realized that clearing SCJP exam with a high percentage is less about declaring that you are technically sound but more about declaring that you are mentally sound. The ability to work hard in adverse conditions is the first advantage that i have received by working hard for SCJP, rather i should say working hard for me. High degree of Patience is the next ability what makes SCJP different from other Programmers. (When you start preparation for SCJP it happens in most of the cases that the you don't get good percentage of marks in practice exam. Every time it is not the case that you are not technically sound, but certainly if you look at the same questions with more concentration so will see a rise in your marks.) The ability to concentrate for a longer period is what we achieve for patience. Clearing SCJP with a good percentage of marks or rather i would say other similar exams requires a definitive strategy. By practising hard a person masters the art to make good strategy to crack the particular exam. And this art of analysis and making good strategy to go about solving a problem is the most important advantage what i have been learining by endeavouring to become a successful SCJP.Thanks for paying attention to post! If you liked it reply to me your opinion.