Objective C Vs C++

1. Declaration changes:Class declaration-in C++ each class is structure and variables, methods are in that structure.In Objective C variables are in one section and methods are in another section.Objective C uses + & - to differentiate between factory and instance methods,C++ uses static to specify a factory method.Method declaration varies,Objective C uses small talk approach.Method calls syntax varies,C++ uses arrow operator and objective C uses square operator.
2. In objective C same name for method and variable is allowed but in C++ it is not.
3. Objective C does not respect public and private(it knows about them but doesn't really use them) as it does in C++.
4. Objective C does not have constructor and destructor.Instead it has init and free methods,which must be called explicitly.
5. C++ uses strong typing and Objective C uses weak typing(run time binding).
6. Objective C does not allow stack based objects,C++ these are allowed.
7. Operator overloading is not supported in Objective C,C++ these are supported.
8. Templates are not allowed in Objective C,C++ these are allowed.
9. abstract objects when instantiated,Objective C generates runtime errors,C++ generates compile errors. 

Create a OpenGL ES project without using Interface Builder

In this section I will explain you how to create a OpenGL ES project without using Interface Builder.


Step 1 : First create a OpenGL ES project from template available in Xcode.
Step 2 : Delete nib dependency in project:

1. Delete nib file from Resources.
2. Delete "main nib" key entry in info.plist.

Step 3 : Update the main method which is in main.m as follows:

we have to change 4th parameter of UIApplicationMain method call to @"ProjectNameAppDelegate" from nil.

Step 4 : In appDelegate method we need to create window, view manually, earlier Interface builder use to do this for us.In header file we need to remove IBOutlet from window, glView declaration(as we are not using Interface Builder).

Now we need to update applicationDidFinishLaunching to create window, glView manually:

1. Create the window.
2. Create EAGLView.
3. Add the EAGLView to window.
4. make window visible.

//Create the window.

window = [[UIWindow alloc] initWithFrame:[UIScreen mainScreen].bounds];

//Create EAGLView.

glView = [[EAGLView alloc] initWithFrame:window.bounds];

//Add the EAGLView to window.

[Window addSubview:glView];

//make window visible.

[window makeKeyAndVisible];

Step 5: Now we need to replace following code in EAGLView.m:

- (id)initWithCoder:(NSCoder*)coder {

    if ((self = [super initWithCoder:coder])) {

with

- (id)initWithFrame:(CGRect)frame {

    if ((self = [super initWithFrame:frame])) {

following is the video that illustrates this tutorial:

Developing application using OpenGL ES.

OpenGL(Open Graphics Library): It is a cross platform C based interface used for visualizing 2D and 3D. This allows to specify models as points, lines or polygons to which an infinite no. of shading technique can be applied to provide desired rendering effect.


OpenGL ES(OpenGL for Embedded systems): This is a version of OpenGL designed for mobile devices.


OpenGL ES on iPhone: OpenGL ES allows your application to configure a traditional 3D graphics pipeline and submit vertex data to OpenGL, where they are transformed and lit, assembled into primitives, and rasterized to create a 2D image.There are 2 versions of OpenGLES are available.
OpenGL ES 1.1: This implements the standard graphics pipeline with a well-defined fixed-function pipeline.The fixed function pipeline implements a traditional lighting and rasterization model that allows various parts of the pipeline to be enabled and configured to perform specific tasks, or disabled to improve performance.
OpenGL ES 2.0: It is same as OpenGL ES 1.1,but removes all functions that act on a fixed function pipeline, replacing it with a general purpose shader-based pipeline.
OpenGL ES provides a procedural API for substituting geometry to a hardware accelerated rendering pipeline, OpenGL ES commands are submitted to a rendering context , where they are consumed to generate images that can be displayed to the user.


Any OpenGL ES implementation provides a platform-specific library that includes functions to create and manipulate rendering context.The rendering context maintains a copy of all OpenG ES state variables and accepts and executes all OpenGL ES commands.In iPhone OS, EAGL is the library that provides this functionality.An EAGLContext is rendering context, executing OpenGL ES commands and interacting with Core Animation to present the final images to the user.


iPhone OS Classes:
All implementations of OpenGL ES require platform specific code to create a rendering context and use it to draw to the screen.iPhone OS does this through EAGL, an Objective C interface.
EAGLContext: The EAGLContext class defines the rendering context that is target of all OpenGLES commands.
Steps:

1. Create and initialize an EAGLContext object and make it the current target of commands.
2. Store all the commands issued by OpenGL ES in queue that is maintained by the context.
3. Execute all the commands to render the final image.

EAGL Sharegroup: Every EAGLContext object contains a reference to an EAGL Sharegroup object.When an object is allocated by OpenGL ES for that context, that object is actually allocated and maintained by the share group.This division of responsibility is useful because it is possible to create two or more contexts that use the same sharegroup. Finally using sharegroup allows two or more contexts to share OpenGL resources without duplicating that data for each context.
By sharing textures, shaders and other objects , your object makes better use of available resources.
EAGLDrawable: iPhone OS objects that implement the EAGLDrawable protocol can be used as a rendering surface and displayed to the screen by an EAGLContext object.And you can configure the drawable surface with Drawable Properties(A dictionary of values that specify the desired characteristics of the drawable surface).



OpenGL ES Objects:
OpenGL ES offers a number of objects that can be created and configured to help creating you screens.

1. Texture: A texture is a image that can be sampled by graphics pipeline. This is typically used to map a color image onto your geometry.
2. Buffer: A buffer is a set of memory owned by OpenGL ES that your application can read and write data into(normally to hold vertex data). Using buffers to manage your vertex data can significantly boost the performance of your application because the buffer is owned by the OpenGL ES implementation, it can optimize the placement and format of the data in this buffer in order to more efficiently process vertices,particularly when data does not change from frame to frame.
3. Shaders: An OpenGL ES 2.0 application creates a shader, compiles and links code into it, and assigns it to process vertex and fragment data.
4. Render Buffer: A render buffer is a simple 2D graphics image in a specified format.This format may be defined as color data, but it could also be depth or stencil information.Render buffers are not usually used alone, but are instead collected and used as part of a frame buffer.
5. Frame buffer: Frame buffers are the ultimate destination of the graphics pipeline.A frame buffer object is really just a container that attaches texture and render buffer to itself to create a complete destination for rendering.

Note: OpenGL ES 2.0 has frame buffer support.OpenGL ES 1.1 also supports this with OES_framebuffer_object extension.


Standard model that all OpenGL ES objects should share:

1. Generate an object identifier: To generate/create object, you should generate an identifier.An identifier is analogous to a pointer.Whenever your application wants to operate on an object,you use this identifier to specify which object to work on. Creating an object identifier does not actually allocate an object. It simply allocate a reference to it.
2. Bind your object to OpenGL ES context: Each object type in OpenGL ES has a method to bind an object to the context. You can only work on one object of each type at a time, and you select that object by binding to it. The first time you bind to an object identifier, OpenGL ES allocates memory and initializes that object.
3. Modify the state of your object: Commands implicitly operate on the currently bound object.After binding the object, you application makes one or more OpenGL ES calls to configure it.Ex:After binding the texture, your application actually makes an additional call to actually load the texture image.
4. Use your object for rendering: once you have created and configured, you can start drawing your geometry.
5. Delete your object.

Actions that most of commands in OpenGL ES do:

1. Reading the current state of an OpenGL ES context.This is most typically used to determine the capabilities of an OpenGL ES implementation.
2. Changing state variables in an OpenGL ES context.This is typically used to configure the pipeline for some future operations,
3. Creating, modifying or destroying OpenGL ES objects.
4. Submitting geometry to be rendered.Vertex data is submitted to the pipeline, processed, assembled and then rasterized to a frame buffer.

Creating an EAGLContext:

Before your application can execute any OpenGL ES commands, it must first create and initialize an EAGLContext and make it the current context.

EAGLContext* myContext = [[EAGLContext alloc] initWithAPI:kEAGLRenderingAPIOpenGLES1];

[EAGLContext setCurrentContext:myContext];

Creating FrameBuffers:
FrameBuffer objects are the target of all rendering commands.Traditionally in OpenGL ES, frame buffers are created using a platform-defined interface.Each platform would provide its own functions to create a frame buffer that can be drawn to the screen.
FrameBuffer Object provides storage for color, depth and/or stencil data by allocating images to the frame buffer.
Although an EAGL context receives commands, it is not the ultimate target of those commands. Your application provides a destination to render the pixels into.In iPhone Os all images are rendered to frame buffer objects.frame buffer object allows your application to precisely control the creation of color, depth and stencil targets.

About Interface Builder.

Interface Builder:
This is a visual design tool you use to create the user interface of your iPhone OS and Mac OS X apps.
Responsibility:

1. Arrange items that are required(choose from library).
2. Set their attributes.
3. Establish connections between them.
4. Save then in special type of resource files(nib files).

NIB / XIB:
NIB : NextSTEP Interface Builder(in binary format).
XIB : XCode Interface Builder(in XML format).
A nib / xib file stores your objects, including their configuration and layout information, in a format that at runtime they can be used to recreate the actual objects.
Difference between XIB and NIB : Both formats store the same information but do so in different ways.
Xib files: These are intermediate XML-based files that are intended for use only during the development of your project.Because they are text based, you can save them in your source code management system and perform diff on them.
NIB files: During deployment, xib files are converted into nib files, which contain a binary version of the document data and are what your application actually loads at runtime.


Windows in Interface Builder:
Interface builder provides several windows to allow you to display and modify the objects in your user interface.

1. Document Window.
2. Library Window.
3. Inspector Window.
4. Connection Panel.

Document Window: Each Interface builder document stores information about one or more objects you want to create at runtime in your application. 
Library Window: This contains the object that you can add to your Interface Builder documents.

It has three modes

1. Object Mode: When this mode selected, the window displays the objects you use to build your user interface.Ex:Windows, menus, views, controls etc.
2. Classes Mode: This window displays the classes you can use to build the user interface in your object. Ex: Custom classes.
3. Media Mode: This window displays the image and sound resources you can refer to from your object. 

Inspector Window: This makes it easy to display and adjust the settings for the currently selected objects.This is divided into panes:
Attributes: Displays the object specific configuration attributes.For Cocoa and Cocoa touch objects, the sections in this pane reflect the classes in the inheritance hierarchy of the selected object.
Effects: Displays the core animation based and Core Graphics based attributes associated with the object.
Size: Displays information about the size and position of the object and also displays  alignment controls and autosizing attributes.
Bindings: DIsplays the available bindings for an object and provides an interface for binding those objects to one or more controllers.
Connections: Displays the outlets and actions of the objects along with information about which ones are currently connected to other objects.
Identity: Displays information that helps identify the objects either at design time or runtime.
Connection Panel: A connection is a way to associate interface elements with source code.There are few sections their description goes as follows
Outlets: Lists the outlets exposed by the object. An outlet is a member variable of the class that has the IBOutlet keyword associated with it. Outlets let you create inter-object reference from within Interface builder.
Sent Actions: Shows the target of a control's action message. An action is a message that is sent by a control in response to a user action.
Received Actions: Lists  the incoming actions that the current object is capable of handling.
Accessibility: Lists standerd outlets for storing accessibility related information. These outlets are present for all visual elements.
Accessibility Reference: Lists the source objects that refer directly to the selected object through an accessibility connections.
Reference Outlets: Lists the source objects that currently refer to this object through an outlet.


iPhone OS interface objects:
windows: A typical iPhone application has only one window, which provides the backdrop for all of the applications content.
Views and Controls: In iPhone OS, everything that appears onscreen descends from the UIView class. In practical terms, views and controls are rectangular regions that display data and are capable of handling events.
Custom View: Interface builder is aware of any custom views declared in your source code. You can find your custom views listed in the classes tab of the library window.
Toolbars: Toolbar contains a collection of buttons representing frequently used commands in an application.
Controller Objects: In addition to visual objects, Cocoa touch nib files can include any type of custom object needed by application. This is to facilitate MVC design pattern used by iPhone application. The non visual objects in a nib files acts as controllers for the visual objects
Controls and custom objects in Cocoa touch nib files:

1. NSObject.
2. ViewControllers.
3. Proxy Object.

Developing application using Cocoa Touch.

Cocoa Touch comprises of the UIKit and Foundation framework.
Design Patterns:
The main patterns that you will use in simple cocoa touch based application are:

1. Delegation
2. Model View Controller
3. Target Action

Delegation : Delegation is pattern where one object periodically sends messages to another object specified as its delegate, to notify the delegate that an event is occurring.
Example : In a normal application, application object tells its delegate(which is AppDelegate class) that the main start-up routine have finished and that the custom configuration can begin(to create an instance of a controller to set up and manage the view).
Model View Controller : MVC sets out 3 roles for objects in an application
Model : Model object represents data.
Example : 

1. Space ship and rockets in a game.
2. Todo items in a productive application.
3. Circle and squares in a drawing application.

View : View answers for the question "How to display the data?", may allow the user to edit the data.
Controller : Controller object mediates between models and views.
Target Action :
The target-action mechanism enables a control object - that is, an object such as a button or slider - in response to a user event (such as a click or a tap), sends a message(the action) to another object (the target) that can interpret the message and handle it as an application specific instructions.


Xcode : Apple's IDE(Integrated development Environment).


Info.plist : Info.plist is a dictionary that contains information about the application such as its name and icon.


Bundle : 
A Bundle is an abstraction of a location in the file system that groups code and resources that can be used in an application.


Forward declaration in Objective C:
This is a promise to the compiler that class will be defined some where else and that it needn't waste time checking for it now.
Forward declaration in Objective C : @class MyViewController.


Nib files : Nib files contains an archive of user interface elements (file extension will be .xib).Clicking on it opens the xib file in Interface builder.
NIB : NextStep Interface Builder


Interface Builder : 
This application is used to create user interfaces. It does not create/generate source code, instead it allows you to manipulate object directly and then save those objects in an archive called nib files.
At runtime, when nib is loaded the objects are unarchived and restored to the state they were in when you saved the file including connection between them.
The Interface Builder document contains 4 items:

1. File's owner proxy object.
2. File's responder proxy object.
3. AppDelegate.
4. A Window.

Files Owner Proxy Object : The files owner object is not created when the nib file is loaded, instead it is the object that loads the nib file.You have to mention the class of object that loads the nib in the identity inspector.It will automatically set the class name if you create the together with the view controller class.
The View Outlet : An outlet is just an attribute (typically an instance variable) that happens to connect to an item in a nib file.The outlet connection means that when the nib file is loaded and the UIView instance is unarchived, the view controller view instance variable is set to that view.
Note : You can look at - and make and break - an object's connection using an inspector panel.In interface builder document-click on files owner to display a translucent panel showing file's owner connections.


Application Bootstrapping:
If you create a project using template provided by Xcode already sets up the basic application environment.
It creates:

1. Application object.
2. Connects to the window server.
3. Establishes the run loop and so on.

Note : Most of the work is done by UIApplicationMain function.
main function which is normally available in main.m is the starting point to iPhone application.
When user taps on the application then UIApplication looks at info.plist and loads the main lib file(file name that is associated with NSMainNibFile key in that plist). And following things will happen

1. STEP 1 : Delegate creates view controller object and initializes it.
2. STEP 2 : The Delegate asks its view controller for its view.
3. STEP 3 : Finally delegate adds that view as a subview of the window.

Note : Xcode template provides an application delegate class and an instance is created in the nib file.Finally our responsibility is to implement a view controller class and create an instance of it.

Example code for each step:

STEP 1 : Delegate creates view controller object and initializes it:
view controller will be initialized with intWithNibName:bundle: method.

MyViewController* aViewController = [[MyViewController alloc] initWithNibName:@"MyViewController" bundle:[NSBundle mainBundle]];

[self setMyViewController:aViewController];

[aViewController release];

STEP 2 : The Delegate asks its view controller for its view.

UIView* controllerView = [myViewController view];

STEP 3 : Delegate adds that view as a subview of the window.

[window addSubView : controllerView];

View Controller Class:
View controller object plays a central role in most iPhone applications.This is responsible for managing a view.
UIKit provides a special class - UIViewController - that encapsulates most of the default behavior you want from a view controller.You have to create a subclass to customize your behavior for your application.
Note : The View controller lasts for the life time of the application, so it is good practice to add it as an instance variable of the application delegate.


Disabling Status bar:

Added "Status bar is initially hidden" check box to info.plist and check the check box this will disables the status bar.

IBOutlet : IBOutlet is a special keyword that is used only to tell Interface Builder to treat an instance variable or property as an outlet. It’s actually defined as nothing so it has no effect at compile time.
Example:

UILabel *label;

@property (monatomic, retain) IBOutlet UILable* label;

IBAction  : IBAction is a special keyword that is used only to tell Interface Builder to treat a method as an action for target/action connections. It’s defined to void.
Example:

- (IBAction)changeGreeting:(id)sender;

Getting access to AppDelegate instance :
Use following code to get access to AppDelegate:

[[UIApplication sharedApplication] delegate]

iPhone OS Graphics Overview:
      Core Animation is fundamental to the iPhone graphics sub-system.
      Every UIView object in your application is backed by a Core Animation layer.As various layers update their contents, they are animated and composited by Core Animation and presented to the display.
      OpenGL ES is also a client of Core Animation.To use OpenGL ES to draw to the screen, your application creates a UIView class backed by a special Core Animation layer, CAEAGLLayer object.
      CAEAGLLayer : A CAEAGLLayer object is aware of OpenGL ES and can be used to create rendering targets that acts as part of CoreAnimation.
Note: In your application you can create screens using both OpenGL ES layer and non-OpenGL ES layer drawing , but this hits performance.

iPhone OS Overview.

iPhone OS:

iPhone OS comprises the operating system and technologies that you use to run applications natively on iPhone and iPod touch devices.New technologies that are added to iPhone that are not available in Mac OS are - Multi-touch interface and accelerometer support.

iPhone OS technologies Layers:

In iPhone OS, the underlying system architecture, and many of the technologies, are similar to those found in Mac OS X.

High level over view of these layers:

       Layer 4             Cocoa Touch

       Layer 3                   Media

       Layer 2             Core Services 

       Layer 1                 Core OS

Here,

Core OS and Core Services layers : Core OS and Core Services layers contain the fundamental interfaces for iPhone OS(mostly C based), example :- 

1. Accessing files,
2. Low level data types
3. Bonjour services
4. network sockets and so on

Technologies that come to this category:

1. Core Foundation
2. CFNetwork
3. SQLite
4. Access to POSIX threads and
5. UNIX sockets etc.

Media Layer : It is mixture of C - based and Objective-C based interfaces.It supports 2D and 3D drawing, audio, and video.

This layer includes 

C-based technologies 

1. OpenGL ES.
2. QuartZ.
3. Core Audio.
4. Core Graphics.

Objective-C based technologies:

1. Core Animation(animation engine).

Others:

1. Audio Toolbox.
2. Audio Unit.
3. AV Foundation.
4. Media Player

Cocoa Touch Layer:

This is has most of Objective-C based technologies.

Cocoa Touch is the application development environment for iPhone OS,includes Objective-C runtime and two core frameworks namely - Foundation and UIKit frameworks.

Foundation Framework : Publishes a procedural(ANSI C) interface.This implements the root class, NSObject, which defines basic object behavior.

It implements classes that represent 

1. primitives types
2. collections

Provides facilities for

1. internationalization
2. object persistance
3. file management
4. XML parsing

Access underlying system entities and services :- ports, threads, locks, and processes etc.

UIKit : For developing an application's user interface.

Includes classes for :

1. Event handling
2. Drawing
3. Image-handling
4. Text processing
5. Typography and
6. Inter-application data transfer.

Also includes UI elements such as :- views, sliders, buttons, text fields, and alert dialogs.

Other frameworks at this level give you access to the user’s contact, photo information, the accelerometers and other hardware features of the device.

Core Animation:
Core animation is a Objective-C framework that supports animations.Core animation is not a drawing technology itself, in the sense that it does not provide primitive routines for creating shapes, images, or other types of content. Instead, it is a technology for manipulating and displaying content that you created using other technologies.


Core Graphics and Quartz 2D:
The Core graphics framework is a C based API.Quartz 2D API is part of the Core graphics framework, so you may see Quartz referred to as Core Graphics or simply CG.Quartz 2D is an advanced, 2D drawing engine available for iPhone application development outside of the kernel.
It provides low-level,light weight 2D rendering with unmatched output fidelity regardless of the display or printing device.
Quartz 2D is resolution and device independent. you do not need to think about the final destination when you use the Quartz 2D API for drawing.
In iPhone OS Quartz works with all available graphics and animation technologies, such as Core animation, OpenGL ES and the UIKit classes. 

BREW Overview

Hello all,


Some Acronyms:

1. BREW - Binary Runtime Environment For Wireless.
2. AEE - Application Execution Environment.
3. MIF - Module Information File.
4. BRI - Binary Resource Intermediate.
5. BAR - BREW Applet Resources.
6. BAM - BREW Application Manager.
7. BCI - Binary Compressed Image.
8. DLL - Dynamic Link Libraries. 
9. BID - BREW ClassID.

Some important header files usage:

1. AEEAppGen.h : Contains declerations that AEEClsCreateInstance() needs in order to instantiate our module and applet.
2. AEEShell.h : Contains support for the IShell services that the application will need throught out its life cycle.
3. AEEFile.h : To provide file support.

About BREW:
BREW - Binary Runtime Environment For Wireless.Qualcomm's BREW is hardware platform, originally intended as internal library for developing software on their own custom handsets.


Components that are available in BREW SDK:

1. BREW Application Execution Environment : Provides the foundation for BREW applications.
2. Set of tools : MIF editor, Resource Editor, Emulator, and Device Configurator.
3. BREW header files.
4. BREW Utilities : PureVoice Converter,2Bit Tool,NMEA Logger.
5. Add-ins to microsoft Visual Studio : Application Wizard, Automated ARM compiling, BREW Integrated Help.
6. Some example apps.
7. Online help.

Contents of BREW Tools:

1. Resource Editor.
2. MIF editor.
3. BCI Authoring Tool.
4. AppLoader.
5. AppLogger.
6. AppSigner.

BREW simulator:
It simulates a selected hand held device.


BREW application wizard:

It is included in 1.1 on and this does not exists in 1.0.This application wizard sets most of the applicable project options and produces the minimal skeliton code for a BREW application, assuming you are intended to develop in C.
Brew Application Wizard is an add on to Microsoft Visual Studio which creates following file:

1. Project File(appname.dsp).
2. Workspace File(appname.dsw).
3. Application source file(appname.c).
4. AEEAppGen.c and AEEModGen.c that are included with the BREW SDK.

About MIF:
MIF(Module Information File) that is created with MIF editor.
It contains information about the contents of the module:

1. Supported classes.
2. Supported applications.
3. Application privileges.
4. Application details.
5. Author of the application

Note : Without MIF, BREW will act like your application does not exists.


About resource editor:

The resource editor is made up of two integrated parts : The Resource Editor, Resource Compiler.Serves as a repository for the application's strings, images and dialog resources.The resource editor stores all of the entered resources in BREW Resource Intermediate(.bri) file.BRI is resource editors native format.

The Resource editor compiles the resource contained in the .bri into a binary BREW Applet Resource(.bar) file.The application will programatically load resources at runtime.
Usage : Resources files are useful for storing language-specific strings, dialogs, and bitmaps.If you need to localize your application for use in a target device in a different language, you simply need to translate the resources in the resource file.It is not necessary to recompile the MOD or DLL file.

Development Environment:
Any development environment  which can generate window's compliant dynamic link libraries is suitable for developing BREW applications which will execute on the simulator.

About BREW application:
In BREW, an application is a class that can only have one instance(singleton). BREW loads and creats a module only once - regardless how many times it required, because loading a module is expensive process.
Loading a module requires  

1. Updates to system tables about "what classes are available".
2. Brings executable from disk and allocates ancillary support structures.

BREW Applications are entirely event driven.

The basic elements of BREW application are :-

1. BREW classes.
2. BREW shell.
3. Module.
4. Applet.
5. Event handler.
6. Class IDs.
7. Resources.
8. Module Information Files(MIF).

BREW API:

Represents a group of interface classes with their own set of functions to use in your applications.BREW interface are initialized and memory is allocated only when the interface is needed.Each inteface has a unique ClassID, and the name of each interface in the BREW API begins with the letter I.

Application Execution Environment (AEE):

AEE foundation of BREW,which is responsible to load and execute BREW applications.

BREW Shell (IShell):

The BREW shell(IShell) is an interface,whcih is loaded when your application first runs.IShell permits access to a wide variety of lower-level services provided by the device.

About BREW Module:
A BREW  Module is a container for all of the applications functionality.
A BREW Module is a binary file containing the code for applications or extensions.
A BREW Module - as applications and extentions - are the fundamental units of code loading / contains implementation of multiple classes. It is a unique instance of IModule interface, to create a module one have to implement IModule interface.
This is accompanied by a module information file.This provides info regarding the classes your module contain.
But normally we dont do this, because Qualcomm provides a helper file AEEModGen.c. Which does this for us.

The module is loaded by the BREW shell.Fundamentally this module exports single entry point so that the BREW shell can call into your application's CreateInstance function.
CreateInstance - creates an event handler, allocates application memory and creates an instance of the IDisplay interface etc.

Event Handler:

Since BREW application model is event-driven programming model,this must contain an event handling  function.After application is loaded , the BREW layer passes all input to this function as events.In BREW, substantial delays in processing events may result in the application being shutdown to safeguard the device.

BREW Class IDs:

Class IDs are a unique 32-bit ID identidying BREW applications, BREW extensions, privilege levels, or BREW interfaces.This ClassID is stored in a BREW ClassID(BID) file.

About Applet:
Terms "Application" and "Applet" are interchangeable.
An "Applet" is a discrete unit of functionality that the module loads and the AEE executes.

About AEEApplet:

AEEApplet is a typedef for a struct.This structure contains key information about the applet.

1. m_pIShell : IShell pointer that provides access to the applet with shell services. 
2. m_pIModule : IModule pointer that keeps track of the module that "owns" the applet.
3. m_pIDisplay : IDisplay pointerthat gives the applet the ability to write to the screen.
4. pAppHandleEvent : A pointer to the applet's event handling function.
5. pFreeData : A pointer to a function that frees all of the applets dynamically allocated data  

Difference between Applet and Module:

A module may consists more than one applet, but only one applet can be active at a time(because BREW is single - threaded ). For example single module can have two applets in it with different class ids.

BREW Application entry points:
When the user selects the application icon in the BREW Application Manager, the AEE kicks off the entire process by calling AEEMod_Load() and AEEMod_CreateInstance().

NOTE:

1. In the emulator, AEEMod_Load is exported from the modules DLL.
2. In some production environments internal to QUALCOMM, the entry point is module_main.
3. In all other cases, for OTA configuration, the entry point is AEEMod_Load, and its declared the enttry point during the link process.

About  AEEModGen.c file provided by Qualcomm:

AEEModGen.c contains reference source code for modules.

AEEModGen.c also implements four methods of IModule interface.

1. CreateInstance : BREWinvokes this method when it needs an instance of a class provided by the module.From here we will call AEEClsCreateInstance method.
2. FreeResources : This method frees additional resources consumed by the module prior to its destruction.
3. AddRef : This method increments modules ref count.
4. Release : This method decrements ref count and when it reaches to 0 it frees the module.

In AEEModGen.c AEEMod_Load is really just wrapper function for AEEStaticMod_New, which is the function static builds invoke when creating static modules.This function is much like AEEClsCreateInstance for any class, with two key differences - it must accept pointers to creation and destruction functions when invoked during static builds.

About  AEEModGen.c file provided by Qualcomm:

In our code after the class ID check is done then AEEApplet_New() method will be called, whcih is defined in AEEAppGen.c. Its main function is to allocate memory for, and populate, the AEEApplet instance and then add it to the module by calling AEEMod_ListAdd().

Creating sub class of IModule:

The data structure that represents the IModule subclass instance:
typedef struct _SSingletonModule
{
//Declaring the virtual table for this class,whcih implements IModule.
DECLARE_VTABL(IModule)
//Ref count
uint32      nRefs;
//Pointr to the system shell.
IShell      *pIShell;
//Required for static extentions and are unused for OTA applications.
PFNMODCREATEINST  pfnModCrInst;
PFNFREEMODDATA    pfnModFreeData;
//Our singleton pointer.
SSingletonModule *pInstance;
}SSingletonModule;


Diff between static application and dynamic application:
Static applications:
1. Built into the OEM software build.
2. Can not be deleted but can be upgraded.

Dynamic applications:
1. Downloaded OTA or preloaded at the factory.
2. Have dynamically loaded MOD file.
3. Can be upgraded, deleted, recalled.