WO2008031070A2

WO2008031070A2 - Software development environment for platform-independent application programs

Info

Publication number: WO2008031070A2
Application number: PCT/US2007/077935
Authority: WO
Inventors: Alexander Block; Carsten Oberwestberg
Original assignee: Jamba!
Priority date: 2006-09-08
Filing date: 2007-09-07
Publication date: 2008-03-13
Also published as: WO2008031070A3

Abstract

In an environment for developing software application programs for use on multiple platforms, a platform-independent application program is provided to multiple platform-specific hosts. Each host provides a runtime environment for execution of the application program on a corresponding target platform. A target environment simulator utilizes profiles to establish features for each target platform such that each target platform emulates the behavior of a particular computing device as defined by the profiles. Thus, the behavior of a large quantity of different target devices may be emulated to remove the necessity of testing applications on actual computing device platforms.

Description

Attorney Docket No.: 26970-131PC

SOFTWARE DEVELOPMENT ENVIRONMENT FOR PLATFORM-INDEPENDENT APPLICATION PROGRAMS

CROSS-REFERENCES TO RELATED APPLICATIONS [0001] The present application claims priority from U.S. Provisional Patent Application No. 60/825,030, filed September 8, 2006; U.S. Provisional Patent Application No. 60/825,054, filed September 8, 2006; U.S. Provisional Patent Application No. 60/842,937, filed September 8, 2006; U.S. Provisional Patent Application No. 60/842,944, filed September 8, 2006; and U.S. Provisional Patent Application No. 60/825,187, filed September 11, 2006, all of which are incorporated by reference herein in their entirety.

TECHNICAL FIELD

[0002] This invention relates to providing a software development environment, and in particular, a software development environment that allows for the development of platform- independent application programs.

BACKGROUND OF THE INVENTION

[0003] One of the problems in developing applications for computing devices, such as cell phones, is that each of the different types of computing device platforms typically has a different hardware and a different operating system. For example, different cell phone manufacturers may produce cell phones having different hardware and different operating systems. Even within the same manufacturer, different cell phone models may have different hardware and operating systems.

[0004] As a result, software applications for mobile device platforms are typically individually developed for each device platform. In order for the application to be useable on another mobile device platform, the application is often redesigned, developed, and certified. Because of the labor involved in this process, an application developed for one mobile device cannot be easily and directly deployed to another mobile device.

[0005] When creating applications for a large set of different platforms, creating platform- specific executables may be prohibitively complex. Each platform may have its own limitations, and achieving acceptable performance may require knowledge and exploitation of features, methods, structure, and limitations specific to each. Application development may include several stages, such as design, concept, project management, development, and testing. In regular applications, more time generally is spent on the first four stages. When the application is designed to run on a large number of configurations and platforms, much time may be spent on testing. The mastering process may also take a relatively long time within the development process. A greater number of platforms generally requires a greater amount of time to produce a master for each platform.

[0006] When developing applications for mobile platforms such as cellular telephones, PDAs, or other mobile devices, hundreds of platforms, each with different features (such as display size) and languages, may be supported. For example, an application may be designed for one hundred platforms and ten languages. This will result in one thousand testing runs, which may require an unacceptably large amount for time for development and testing.

[0007] Thus, there is a need for an improved system and method of developing software applications for use in multiple computing device platforms.

BRIEF SUMMARY OF THE INVENTION

[0008] The present invention provides an environment for developing software application programs for use on multiple platforms. A platform-independent application program is provided to multiple platform-specific hosts. Each host provides a runtime environment for execution of the application program on a corresponding target platform. A target environment simulator utilizes profiles to establish features for each target platform such that each target platform emulates the behavior of a particular computing device as defined by the profiles. Thus, the behavior of a large quantity of different target devices may be emulated to remove the necessity of testing applications on actual computing device platforms.

[0009] In one aspect of the invention, a method of developing a platform-independent application program includes providing a platform-independent application program to a platform-specific host. An application-compatible target platform corresponding to the host is identified. The target platform is associated with hardware and software of a computing device. The application program is processed for execution on the target platform. At least one profile corresponding to the target platform is identified. The at least one profile defines at least one feature of the target platform. The target platform is simulated by processing the at least one corresponding profile. The simulated target platform emulates the behavior of the computing device. The application program is executed on the simulated target platform.

[0010] In another aspect of the invention, a method of developing a platform-independent application program includes providing a platform-independent application program to a plurality of corresponding platform- specific hosts. An application-compatible target platform corresponding to each host is identified. Each target platform is associated with hardware and software of a particular computing device. The application program is processed for individual execution on each target platform. At least one profile corresponding to each target platform is identified. The at least one profile defines at least one feature of the corresponding target platform. Each target platform is simulated by processing the at least one corresponding profile. Each simulated target platform emulates the behavior of the particular computing device. Each processed application program is executed simultaneously on the corresponding simulated target platform.

[0011] In yet another aspect of the invention, a system for developing platform- independent application programs includes an environment manager, a target environment simulator, a compiler and a data store. The environment manager receives a plurality of platform-independent application programs. The target environment simulator is coupled to the environment manager for receiving the plurality of application programs. The target environment simulator includes a plurality of hosts and a plurality of application-compatible target platforms. Each application program is provided to one of the plurality of hosts. Each target platform corresponds to one of the plurality of hosts. Each target platform is associated with hardware and software of a particular computing device. The compiler processes each application program for execution on the corresponding target platform. The data store includes a plurality of profiles. Each profile corresponds to at least one target platform. Each profile defines at least one feature of the corresponding at least one target platform. The target environment simulator is configured to process the profiles to simulate each target platform such that each simulated target platform emulates the behavior of the particular computing device. Each processed application program is executed simultaneously on the corresponding simulated target platform. [0012] These and other advantages of the invention will be apparent to those of ordinary skill in the art by reference to the following detailed description and the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] FIG. 1 is a functional block diagram of a computing device according to one embodiment of the present invention.

[0014] FIG. 2 is a functional block diagram of an integrated software development environment for developing platform-independent application programs, according to one embodiment of the present invention.

[0015] FIG. 3 illustrates multiple profiles mapped to one or more corresponding target platforms, according to one embodiment of the present invention.

[0016] FIG. 4 is a flow diagram illustrating a method for developing platform-independent application programs, according to one embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION [0017] The present invention provides an environment for developing software application programs for use on multiple platforms. A platform-independent application program is provided to multiple platform-specific hosts. Each host provides a runtime environment for execution of the application program on a corresponding target platform. A target environment simulator utilizes profiles to establish features for each target platform such that each target platform emulates the behavior of a particular computing device as defined by the profiles. Thus, the behavior of a large quantity of different target devices may be emulated to remove the necessity of testing applications on actual computing device platforms.

[0018] FIG. 1 is a functional block diagram of a computing device according to one embodiment of the present invention. The computing device may be any of various mobile computing devices, including cell phones. In one embodiment, a mobile device 60 may be represented as a target platform 40 upon which a host 10 resides. A "platform" refers to a specific device and its associated operating system and other software that may be installed on the device, such as a mobile device, a personal computer, or another computing device and the associated software. Exemplary platforms may correspond to a specific brand and model of a cellular telephone, a general purpose computer and the specific operating system version installed on the computer, a specific model of a portable digital assistant (PDA), etc. As shown in FIG. 1, the target platform 40 comprises a native operating system 20 and hardware 30 which represents the physical hardware of the mobile device 60. The host 10 operates in conjunction with and makes use of functions provided by the native operating system 20 and the hardware 30 of the particular target platform 40.

[0019] The host 10 may be compiled for the target platform 40 and may be specific for each target platform upon which it resides. The host 10 may serve as an interface between a platform-independent application program 50 and the underlying target platform 40. The application program 50 may be provided to the host 10 in a platform-independent program structure which includes the program code, data, and other resources that belong to the application program 50. A programmer may build the program structure using an object- oriented scripting language that is platform-independent. In one embodiment, the same program structure may be ported from one target platform to another with little or no modification.

[0020] In one embodiment, the program structure may include a set of script objects built using the object-oriented scripting language. Alternatively, in another embodiment, the program structure may be in the form of an intermediate code. The intermediate code may be in a portable binary format, such as bytecode, and may be obtained by compiling the set of script objects.

[0021] The program structure may be processed by the host 10 for execution on the target platform 40. In one embodiment, where the program structure is provided to the host 10 as a set of script objects, the host 10 may serve as an interpreter of the script-based language for executing the script objects. In one embodiment, where the program structure is provided to the host 10 in the form of an intermediate code, the host 10 may employ a virtual machine that facilitates the matching of different object components, and the matching object components interact with each other via the virtual machine.

[0022] The host 10 may further comprise a runtime environment for the application program 50, providing services to integrate the functionalities of the target platform operating system 20. Such services may include low level services provided by the target platform operating system 20, such as input/output functions or interacting with the controls or display on the target platform 40. Services provided may also include higher level services, such as graphics rendering, sound, physics engine or collision detection, scripting, animation, artificial intelligence, networking, or scene graphs. These services may be carried out by a collection of compiled software modules in a runtime library, such as a class library. For example, the application program may include a script which calls an object for drawing an icon on a display of the target platform 40.

[0023] In one embodiment, the host 10 may provide a cooperative multitasking environment for multi-threaded execution of the program structure. The host 10 may include a multitasking supervisor which serves to accommodate the execution of multiple tasks in a cooperative fashion. Each task may be a stand-alone subprogram that is run as an independent entity. The multitasking supervisor may assign control to a first task with all other tasks being blocked. The first task voluntarily relinquishes control to the multitasking supervisor at programmer-defined points within each task. The multitasking supervisor then assigns control to the next task. In one embodiment, the same code (i.e., shared code) may be executed by more than one task and the same data (i.e., shared data) may be accessed by more than one task.

[0024] In an object-oriented framework, after an object is created by the host 10, several instances of the object may share the same code. Each instance of an object may execute as a single task in the cooperative multitasking environment. The tasks are carried out in a cooperative manner and may be carried out in the order of creation. After the last task is processed, the host 10 updates various components of the runtime environment, such as the display screen, scroll position, and the drawing of sprites and text messages.

[0025] In one embodiment, the application program 50 may be provided to the host 10 as an archive containing a plurality of program applications, where each application is a version that is directed to a different target platform. In this case, the host 10 may identify the target platform upon which it resides. The host 10 may select and de-archive the appropriate device-compatible application. To assist the host 10 in selecting the appropriate application, the archive may further comprise a description file. The description file includes a description for each of the applications and identifies the target platform to which each of the applications is compatible.

[0026] FIG. 2 is a functional block diagram of an integrated software development environment for developing platform-independent application programs, according to one embodiment of the present invention. A development environment 100 comprises various tools callable through an environment manager 110 to assist the programmer in building an application. A computer system for implementing the development environment 100 may be presented through a general purpose desktop computer. However, one of skill in the art will understand that other types of computer systems, including distributed computer systems, may be used in place of a desktop computer.

[0027] The development environment 100 may be provided in an object-oriented framework and implemented in a custom object-oriented scripting language. The scripting language may include a set of script objects. The script objects are modules that provide instructions, commands, or control structures, along with related code and variables, which may be executed by a corresponding host 142. The script objects may be stored in an object library 120.

[0028] The development environment 100 may be implemented in various ways using various types of user interfaces. For example, the development environment 100 may include a code generator 130 for generating script code. The code generator 130 may be any utility known in the art for generating script code, including a text editor or a graphical user interface adapted to the scripting language. A programmer writes a software application by using object-oriented script code such that the program's functionality is implemented by a set of script objects which may be deployed on or compiled for a particular host 142 on a corresponding target platform 144, as described in detail below.

[0029] In one embodiment, the object library 120 may also include a set of objects in the form of re-useable software modules. In one embodiment, the software modules may be platform-independent and deployable across different target platforms having different architectures and operating systems. In another embodiment, the software modules may be platform-specific or have platform-specific components. For example, the object library 120 may provide a collection of objects providing functionalities that are useful in the development of a game application, including a rendering engine for graphics, a physics engine or collision detection, sound, scripting, animation, artificial intelligence, networking, and a scene graph. For example, a programmer can write a script which calls an object for drawing an icon on the screen of a particular target platform 144. In one embodiment, a set of objects is arranged in one of a plurality of profiles 125. The profiles 125 may be associated with specific target platforms 144, as described below with reference to FIG. 3.

[0030] In one embodiment, the development environment 100 may include a compiler 180. The compiler 180 processes the script code and produces an intermediate code that can be directly executed by the hosts 142. The intermediate code may be in a portable binary format, such as bytecode. The script objects may be compiled to class files that include bytecode representations of the original script code program with references to methods, instances and variables of the script objects. An "instance" refers to an emulation of a specific configuration and/or platform. In one embodiment, the compiler 180 may be a cross- compiler for creating executable codes for one or more hosts 142 on different target platforms 144. For example, the cross-compiler may compile the script objects into a plurality of target versions, each version being executable by a particular host 142 on a specific target platform 144.

[0031] In one embodiment, the development environment 100 may further comprise a target environment simulator 140 which simulates the actual operating environment of one or more of the target platforms 144. The simulator 140 may include the hardware, operating system, runtime environment, and any other aspects of the target platforms 144. For example, the simulator 140 may be structured to emulate the architecture of a mobile device, including its performance characteristics such as processor speed, input and output characteristics, and interfaces/interconnections between the architectural elements of the mobile device. In this manner, the architecture of specific target platforms 144 can be embodied within the desktop computer.

[0032] The target environment simulator 140 may further comprise the target platform- specific hosts 142, as described above. Each host 142 serves as an interface between a platform-independent application program and the corresponding target platform 144. The target environment simulator 140 alleviates a programmer from having to run the application on each of the separate target platforms, which would require downloading the application to each actual device and viewing its operations in situ. Instead, a programmer may use the simulator 140 to run the application simultaneously on target platforms corresponding to a variety of different simulated devices. The programmer can also use the simulator 140 in conjunction with a debugger 150 (described in detail below).

[0033] In one embodiment, the simulator 140 emulates a plurality of target platforms 144. Each target platform 144 may be associated with certain device-dependent specifications, such as CPU speed or drawing speed, as well as a device-dependent host. This information may be stored in the profiles 125 in the object library 120 (as described above) or a database 160 for access by the simulator 140. Using the device-dependent specifications provided by the profiles 125 (described in detail below), the simulator 140 may emulate any particular target platform 144. [0034] The development environment 100 may also include a debugger 150 for inspecting and controlling the execution of the application program. The debugger 150 may operate in conjunction with the simulator 140 to provide debugging operations within the domain of the simulator 140. Some of the debugging support routines may be housed within the simulator 140 and accessed via the environment manager 110. The debugger 150 allows the programmer to gather information about the logical execution of the application program by monitoring the locations of code being executed during the prototyping stages of development. The debugger 150 also provides information about the executing application, showing the lines or statements of source code being executed, or program variables and their values.

[0035] In one embodiment, the debugger 150 provides source-level debugging. A source- level debugger may accept source code as input and perform a symbolic execution, allowing the user to view the source code program through symbolic representations of the program. As such, the source-level debugger may uncover static errors such as syntax errors, range violations, etc. Program symbols are typically the names of subroutines, classes, types, variables, and other program constructs as defined by the scripted programming language.

[0036] In one embodiment, the debugger 150 interacts with an executing program to gather dynamic information. The program may be executing within the domain of the target environment simulator 140 and the debugger 150 runs in parallel to the processes being executed by the simulator 140. In one embodiment, the debugger 150 may be a non-intrusive debugger which allows the programmer to analyze the program without controlling its execution. For example, in an object-oriented framework, the debugger 150 can store runtime object data on a frame-by- frame basis for later inspection. Upon termination of the program, the programmer may review the frames to inspect the state of the program at any point during its execution, such as the last few seconds before termination. In one embodiment, the program will terminate abnormally after encountering an error. In another embodiment, the debugger 150 may allow the programmer to terminate the program by interrupting its execution or by setting breakpoints in memory such that the program will terminate at those locations.

[0037] In one embodiment, the debugger 150 may be an intrusive debugger which allows the programmer to inspect and control the execution of the program. The debugger 150 may also allow the programmer to modify the program's state and change the program's execution to a behavior that is different from the original source program, even as the program is being executed. For example, the debugger 150 may allow the programmer to pause the program's execution, change the program's code, recompile the code if necessary, and then resume execution of the program. In some cases, the debugger 150 may allow the programmer to change the target environment simulator 140 as the program is being executed, so that the program continues execution on a different target platform.

[0038] The debugger 150 may also gather other information not available statically, such as the number or frequency of program calls or subroutine calling patterns. The dynamic analysis provided by the debugger 150 allows the programmer to determine memory usage, performance bottlenecks, code coverage, and other data to improve code quality.

[0039] In one embodiment, the development environment 100 can accommodate the development of software simultaneously for multiple target platforms. In this case, multiple target environment simulators may be running simultaneously, one for each target platform being tested, and each of the simulators may be operating in conjunction with the debugger 150. Thus, a tester may perform several test runs at the same time. For example, an application may be tested on multiple emulated devices simultaneously, with the emulated output for each device displayed on a single screen (e.g., graphic interface 115). This may reduce the overall testing time, since multiple physical samples of each device do not need to be obtained, loaded with software, etc.

[0040] While an application is running and being displayed, the tester may observe and modify features of the application using the graphic interface 115. For example, the speed of a game application may be modified during execution by changing a thread period such that the frame rate of the executing application changes accordingly. The developer or tester may also enable game sound while the application is running. Furthermore, a different compiler may also be specified during application execution, for example, a compiler having stricter enforcement of various syntax rules.

[0041] Debug information may be displayed on the graphic interface 115. The debug information may include output originating from an executing application, such as script language outputs; warning and error messages from the environment manager 110 or an instance; and warning and error messages from the compiler 180. The graphic interface 115 may also include options related to the instances. Various options may be set for the instances, such as: • "Run/pause" pauses or resumes a current application.

• "Single step" causes execution of a single command.

• "Step over" causes omission of a code sequence written in brackets " {...}".

• "Restart" restarts an application using lastly compiled code. • "Recompile" recompiles an application to allow for faster development, such as after a modification in the application. Before recompiling, the development environment may wait until every object has finished its frame. After that, every object code position is on a "wait" command. After compiling the changed code, the objects' program counter may be remapped with the new script code according to the old program structure. This may also apply for "Do" commands. In one embodiment,

"data" arrays may not be updated using "Recompile".

[0042] Global variables declared in an application and their current values may be listed on the graphic interface 115. This information may be useful when debugging or for rapid access to information internal to the application to allow a developer or tester to localize improper behavior of the application. Developers may trace executing code step by step when it is processed to quickly locate incorrect conditions, jumps or other irregularities. In one embodiment, a developer may use an editor to set local or global breakpoints. A global breakpoint generally causes an executing application to pause when executing a command identified by a breakpoint. A local break point may be used for a specific object or object type such that when multiple objects use the same module the application is paused. A developer may also manually pause execution of an application.

[0043] In some embodiments, it may be useful to simulate events not related to an application. For example, when an application is developed for use on a mobile platform such as a mobile phone, a phone icon may be used to simulate events such as an incoming phone call or SMS. The use of non-application related events enhances the simulation and testing of an application in conditions similar to real ones.

[0044] The target environment simulator 140 may run a defined set of configurations and/or platforms, while events within an executing application may be synchronized between each instance. Information and values, such as contents of variables or volatile memory, may be displayed to a developer or tester while instances are used to run the application. For example, a mobile application simulator may show the emulated display of several instances at the same time. [0045] Instance synchronization may be preferred for use with a frame-based system. Each frame may be executed in a single instance independent of other instances run at the same time. When an instance has finished its current frame, the instance may wait until all other instances being used have finished the respective frame to allow for synchronization of events across instances.

[0046] State values that may influence the execution of an instance, such as the state of a pseudo random number generator, may be synchronized between multiple instances. For example, one instance may be chosen as the "leader", and the values and states in that instance are then used for each frame. After synchronizing, all instances may then execute the next frame, and synchronization starts again.

[0047] Additional information about the graphics used in an instance may also be displayed on the graphic interface 115, such as object sets which describe graphic files, and the use of objects in the application. Object sets may be sorted by the number of graphics packages to which the files belong. The graphic interface 115 may also show if the relevant package is loaded, how much heap it consumes and, for each file, the name, size, heap and display modes. A developer may set display modes, such as picture size (i.e., default, original size or resized) and transparency (i.e., enabled, on or off).

[0048] For example, level sets, tile sets, base sets, base set bottom layers and tile palette bottom layers may be displayed. The various components may be displayed as pictures. Tile sets are pictures which store tiles used in level creation; base sets store the basic tiles for the level while using additional sets; bottom layers are background images; and tile palettes store color palette, which can be used to ink the background. Specific information about each picture or image used in the application may also be displayed.

[0049] Objects used in a current instance may be shown with relevant parameters, such as: • "Creator" provides a parent identifier for an object.

• "Other" provides an object identifier currently saved in another pointer of the object.

• "x, y" provides the position of the object.

• "Runs" provides the number of commands executed in a single frame by the object.

[0050] In some embodiments, it may be useful for a developer to have information regarding the heap usage for a particular resource. Such information may include:

• "Script" provides the total size of a currently loaded script module. • "Objectset, Tileset, Baseset, Botlay" provide heap consumption of the graphical resource files.

• "Text" provides heap consumption of a text resource in use.

• "Background" provides heap consumption of a buffer image for a background. • "Level Data" provides heap consumption of the botlaymap, tilemap and floormap.

• "Sprite Buffer" provides heap consumption of the sprite buffer usage.

• "Objects" provides heap consumption of all script objects.

• "Deco Sprites" provides heap consumption of all decosprite objects.

• "Global Variables" provides heap consumption of the used global variables in scripts.

• "Commands" provides heap consumption of the engine caused by the used script commands.

• "External Images" provides heap consumption of the external graphic files.

• "Used Heap" provides the amount of used heap. • "Total" provides the total amount of used heap.

• "Free" provides the amount of heap that is not used.

[0051] The development environment 100 may further comprise an archiver 170 which constructs and saves an archive of one or more applications that have been built using the development environment. The one or more applications may be different versions of the same application, where each version is directed to a different target platform 144. The archive may also include a description file. The description file includes a description for each of the applications and identifies the target platform 144 to which each of the applications is compatible.

[0052] The development environment 100 may further comprise a variety of other development tools. For example, the development environment may include source code formatting aids, built-in editing facilities, tools for source code control, subprogram libraries in a variety of application areas, browsers, reverse engineering tools, and the like.

[0053] The development environment 100 provides a way to manage platforms for which applications will be developed. Profiling patterns and simultaneous development may simplify and/or accelerate the process of developing applications for multiple platforms. For example, project management may be simplified by specifying groups into which certain platforms may be included; setting parameters such as a project's version, name, output file format, etc.; and defining the profiles 125 to be linked to the target platforms 144. Actions related to platform management (e.g., creation, modification and deletion of the target platforms 144) may be performed via the graphic interface 115 included in the environment manager 110.

[0054] FIG. 3 illustrates multiple profiles mapped to one or more corresponding target platforms, according to one embodiment of the present invention. The profiles 125 may be stored in the object library 120 for retrieval by the environment manager 110. The profiles 125 are defined by a user to describe and associate limitations and features of each target platform 144. A developer may then assign one or more of the profiles 125 to the relevant target platforms 144. For example, as shown in FIG. 3, Resource Profile A may be assigned to Platforms A, B, D and F. Specific profiles 125 may be provided to the target environment simulator 140 such that a corresponding target platform 144 is properly configured to emulate a computing device for an application executing on the simulator 140. The profile 125 may then be stored in the database 160 for subsequent retrieval if the profile 125 is to be reused.

[0055] When a profile 125 is linked into a platform- specific executable, it may be necessary that different parts of code are executed. After creating profiles representing different device features (e.g. different resources for devices with low/high heap, small/large displays, different sound formats, slow/fast devices, or other criteria) a program developer may create executables for different kinds of devices by combining the corresponding profiles 125. This may reduce development time and improve security. Example profiles include resource profiles, loading bar profiles, settings profiles, sound profiles, language profiles and icons profiles. For example, as shown in FIG. 3, Platform D may include the device features defined in Resource Profile A, Loading Bar Profile, Settings Profile C, and Language Profile B.

[0056] Resource profiles may be used to create profiles with resources (e.g., object sets, level sets, icons, splash screens, etc.) which could be used in the target platforms 144. Resources may be applied to the profiles 125 in consideration of device specifications such as icon size, display size, heap size or jar size. Resources may be added and/or removed from the profiles 125 as files or folders. The program developer may also set values of various attributes used with a resource profile.

[0057] Loading bar profiles may allow a user to set different profiles regarding the look of a loading bar. The developer may change frame, bar, and background colors, as well as the height, gap and offsets of the loading bar. The appearance of the loading bar may then be stored in the profile 125 and used with platforms 144 to which the profile 125 is linked.

[0058] The program developer may select a settings profile and define settings for the profile 125 for use in the development environment 100. Example types of settings profiles include game (or application) settings, defines and remarks. Application settings may be used, for example, to set the maximum amount of decoration sprites ("decosprites"), objects and/or sprite buffer size; to set game speed or scroll "y" offset; to set record store size; or to set graphics capabilities and/or features. Application- specific settings may apply to special- use cases, such as a device that has an especially slow processing speed and requires the omission of some animations when the application is run on the device. Code changes that may result from use of the profile may also be defined and/or modified.

[0059] Example application settings that may be used in a settings profile include:

• "Game Speed" may cause an application to slowdown to a given frame rate when a platform is faster than a given value. • "Max Deco Sprites" may be used to define a maximum number of decosprites that may be used in a game.

• "Max Objects" may be used to define a maximum number of objects that may be used in a game. Since, in general, more objects consume more memory, such a setting may be preferred to allow for saving heap memory. In general, a developer may assign such a setting to as low a value as is possible.

• "Scroll Y Offset" may be used to correct the scroll offset for a platform with especially small or large displays.

• "RMS Size" is an amount of non- volatile memory, which may depend on how much information, such as high scores or custom settings, a developer wants to be stored with the application when it is run.

• "Use Botlay" may be used to specify that bottom layer functionality is used.

• "No Save Functionality" may be used to reduce the memory size of an application by not allocating any memory to store data on the heap memory. The value of a saved memory is related to the RMS size parameter. • "No Baseset Inking" may prevent replacement of a baseset palette with a tileset color palette. By avoiding use of the baseset inking a developer may save, for example, about 800 bytes of the heap memory. • "Use Key Buffer" may cause the development system to include a buffer of key events, which may be required for slower platforms. This may prevent loss of events when the platform is too slow to respond to user actions.

• "Pixel Double" may be used to double the pixels on the display. • "Use Old Font Format" may be used to specify old or outdated sets of fonts, characters, etc. For example, in many mobile devices there exist two font formats: one with 6 rows and 192 characters, and one with 7 rows and 224 characters. Such a setting may be useful to allow for compatibility with older platforms.

[0060] Other application settings may be related to a display window (e.g., the graphic interface 115) that simulates the display of a specified real mobile phone, where outputs generated by the running game are displayed. An area of the display window that provides graphic output is scaled to match the display size of the mobile phone being simulated. Thus, portions of the display window may not be used when displaying the graphic output of the executing application. A variety of options related to the display window may be set in a settings profile, such as:

• "Modem Instance Setting" allows a change of dimension, width, height, maximum heap value and speed of a selected instance.

• "Double Display Size" doubles the size of the display area.

• "Show Current Object Sprites" marks a selected object of the currently displayed scene. This option may simplify tracing the processed code and is useful in the debug process.

• "Show Sprite Object Numbers" is similar to the previous option but instead of showing a white frame around the marked sprite, it shows sprite numbers.

• "Show Protected Area" marks an area which is not repainted by other objects and will not be constantly refreshed.

• "Show Tile Grid" displays a grid that shows tile positioning in the display area.

• "Show Floormap Values" displays the value of a floor map for the appropriate tiles.

• "Simulate Vibration" simulates some vibrations by "shaking" the display area.

[0061] Defines in a settings profile may include script defines and engine defines, both of which are set forth by developers using the development platform. Script defines are used in script source files. Engine defines may be restricted to specific uses. Developers using a platform 144 may also have access to engine defines. [0062] Remarks in a settings profile may be used by developers to write comments or notes which can help in management processes. Example remarks may include "to do"; "missing graphics"; "incorrect menu positioning"; and "known bugs and problems." Other notes may be used; typically the remarks allow for free-text entry.

[0063] Sound profiles allow a developer to store features of a sound system and a set of sound files in a profile 125. Sounds may be grouped by file type. The default sounds that are available in the development system may be used, or a path to sound resources may be specified. In a specific profile 125, available sound files may be displayed for user selection. The sound profile may then be associated with any of the various platforms 144.

[0064] Different platforms 144 may support different sound APIs, which may play only some specific sounds formats. To be able to specify the correct sound API for a certain platform, a developer may coordinate the supported sound format(s) of the platform 144 with those in the development system. For example, a development system may support the following sound formats and/or APIs:

Sound API Sound format

SOUND BEN mmf

SOUND LG mid

SOUND MMAPI mid, amr, wav, mp3

SOUND MOTO mid

SOUND NOKIA Ott

SOUND SAMSUNG mmf

SOUND SIEMENS mid

SOUND V 10 spf [0065] Language profiles may allow a developer to define a language list and language specific sets. Rules may be defined for consistency between languages. Generally languages could be added as separate files. Thus, one platform could have multiple languages such as English, German, French, Turkish and so on. For example, as shown in FIG. 3, Platform F is associated with Language Profile A and Language Profile B. In one embodiment, languages could be associated with a platform as a multi-language profile so for one application all languages are available.

[0066] While creating a multi-language platform, it may be desirable to create a file ("multi.rtx") with language defines. It may be preferred that each language file have the same number of lines. Resource file and define lists may be used to add language-specific resources and defines. For example, resources that should be used only with a specific language and small-loading text graphics in each language may be defined. Language profiles may also store the application name for each language.

[0067] Icons profiles may be used to store icons in different sizes or types for particular profiles 125. Depending on the platform 144, a variety of icons could be used for applications or games. For example, in a Java application, an icon resource may be added to a "Medium Icon" field, but for BREW-enabled devices all fields (e.g., Small Icon, Medium Icon and Large Icon) may be populated with paths to icons resources.

[0068] In addition to the profiles described above, as one having ordinary skill in the art would appreciate, various other platforms and configurations may be used. For example, a profile may include information that is set by the game developer, such as version, vendor, information URL, install notify, first solid tile, and name format. For example, the version number of a project may be listed in the format "x.x.xx" and to identify different project states. Pre-master versions generally are given a number less than 1.0.0, and the first master submission is generally number 1.0.0. As one having ordinary skill in the art would appreciate, other formats may be used.

[0069] Computing device platforms may be managed using computing device names and related devices; i.e., a "handset" may have several specific models which share common development platforms with only minor differences in the platform which are of little concern to developers. A developer may compare a selected handset with the handsets stored in the development system by, for example, speed, display, heap or jar compatibility. Compatible devices may be displayed on the graphic interface 115 differently from incompatible devices to assist the developer in identifying compatibility.

[0070] In one embodiment, an information list may display information about a selected device including compatibility information. The information list may allow for a more detailed and more readily-available comparison of different platforms. A developer may also use the information list to modify script and engine defines associated with a selected platform.

[0071] The development system 100 may also allow a developer to establish the profiles 125 with various options to be used during compilation. The compiler options may include Java obfuscation information, which platform should be compiled, which language should be used, and the like. [0072] The development environment 100 may display the various projects incorporating the profiles 125 and corresponding platforms 144 in a main window (e.g., graphic interface 115). Exemplary menu bar sections may include several options, such as:

• "New Project" creates a new project. • "Load Project" loads an existing project.

• "Save Project" saves the content of the project.

• "Last Project" loads an existing project from the project history, as selected by the user.

• "Exit" closes the environment. • "Delete Recordstore" forces the environment to delete all record stores created during runtime of the project.

[0073] FIG. 4 is a flow diagram illustrating a method for developing platform-independent application programs, according to one embodiment of the present invention. Platform- independent application programs are provided to platform-specific hosts (step 400). Each host may serve as an interface between at least one application program and a corresponding target platform such that the host provides a runtime environment for execution of the application program on the corresponding target platform. In one embodiment, the application program is provided to a host from an archive containing different versions of the same application program. Each version of the application program may correspond to a different target platform.

[0074] Application-compatible target platforms corresponding to each host are identified (step 410). Each platform may be associated with a specific computing device including the hardware and the software (e.g., the operating system) that may be installed on the device. In one embodiment, a developer may define the target platforms corresponding to the host.

[0075] The host processes the application program for execution on the corresponding target platform (step 420). In one embodiment, the host includes a multitasking supervisor for executing multiple tasks in a cooperative manner. In another embodiment, the application program may be processed by a compiler and then submitted to the host. The compiler may process the application for multiple hosts on different target platforms.

[0076] At least one profile corresponding to each target platform is identified (step 430). Each profile is configured to define features for the target platforms. For example, a profile may store information associated with device-dependent specifications such as operating system characteristics, CPU characteristics, input/output functions, and networking configurations. One profile may be associated with multiple target platforms, and multiple profiles may be associated with one target platform. Thus, a target platform may be configured to emulate a computing device by associating the profiles that define the device characteristics with the target platform. Example profiles include resource profiles, loading bar profiles, sound profiles, language profiles and icons profiles.

[0077] Each target platform is simulated by processing the corresponding profiles (step 440). A target environment simulator processes the profiles to establish multiple features for a specific target platform such that the target platform emulates the behavior of a particular computing device. The simulator may include the hardware, operating system, runtime environment, and any other aspects of the target platforms. Thus, the architecture of specific target platforms can be embodied by the target environment simulator within, for example, a desktop computer. In one embodiment, multiple target environment simulators execute simultaneously (e.g., one for each target platform being tested).

[0078] Applications are executed simultaneously on each simulated target platform (step 450). Since each target platform corresponds to different simulated computing device characteristics, a program developer need not execute each application program separately on individual target platforms. In other words, the differently configured target platforms allow an application to be tested for many different devices at the same time thereby reducing the overall testing time.

[0079] Events and/or values are synchronized within an instance or between multiple instances of at least one executing application (optional step 460). For example, a frame may be executed in a single instance independent of other instances run at the same time. When an instance has finished its current frame, the instance may wait until all other instances being used have finished the respective frame to allow for synchronization of events across all instances.

[0080] Information associated with each executing application is provided by a debugger (step 470). The debugger allows a developer/tester to analyze, inspect or control the execution of the application program. The information provided by the debugger may include static data (e.g., syntax errors) or dynamic data (e.g., instantiated values, program calling patterns). [0081] A modification may be received to at least one application feature (optional step 480). In the case of an intrusive debugger, a programmer may be allowed to pause execution of the application program, modify the program code, recompile the code (if necessary), and then resume program execution. In one embodiment, the programmer may modify the target environment simulator as the application program executes so that the program continues execution on a different emulated target platform.

[0082] As is apparent from the above description, the development environment provides tools for the creation and testing of platform-independent applications. The development environment may emulate the behavior of a large quantity of different target devices. Emulation settings may be changed at runtime which may further simplify the development process. Embodiments of the invention may therefore reduce or remove the necessity of testing applications on actual platforms, such as a specific physical device. Furthermore, the invention may allow developers lacking experience in special problems of the various platforms to develop applications by automatically adjusting for various platforms. The use of profiles may also allow users without programming or design skills to create device- specific executables. The user may combine existing profiles using knowledge of the limitations of a device. Embodiments of the invention may further allow for new techniques of simultaneous or synchronized development of multiple device-specific executables. It may also reduce the probability of errors during the process of executable creation. This is because when new executables are created, the various profiles (which have been previously tested) are combined.

[0083] The foregoing description and examples have been set forth merely to illustrate the invention and are not intended to be limiting. Each of the disclosed aspects and embodiments of the present invention may be considered individually or in combination with other aspects, embodiments, and variations of the invention. As will be understood by those skilled in the art, the embodiments illustrated above may be modified, altered, and changed without departing from the scope of the present invention. The scope of the present invention is defined by the appended claims.

Claims

WHAT IS CLAIMED IS:

1. A method of developing a platform-independent application program, the method comprising: providing a platform-independent application program to a platform-specific host; identifying an application-compatible target platform corresponding to the host, wherein the target platform is associated with hardware and software of a computing device; processing the application program for execution on the target platform; identifying at least one profile corresponding to the target platform, wherein the at least one profile defines at least one feature of the target platform; simulating the target platform by processing the at least one corresponding profile, wherein the simulated target platform emulates the behavior of the computing device; and executing the application program on the simulated target platform.

2. The method of claim 1, further comprising providing debugging information associated with the executing application program.

3. The method of claim 1 , further comprising receiving a modification to the application program.

4. The method of claim 3, further comprising, in response to receiving the modification: processing the modified application program for execution on a different target platform; and executing the modified application program on the different simulated target platform.

5. The method of claim 1, further comprising synchronizing events or values within at least one instance of the executing application program.

6. The method of claim 1, wherein the at least one profile comprises at least one of: a resource profile, a loading bar profile, a settings profile, a sound profile, a language profile and an icons profile.

7. A method of developing a platform-independent application program, the method comprising: providing a platform-independent application program to a plurality of corresponding platform-specific hosts; identifying an application-compatible target platform corresponding to each host, wherein each target platform is associated with hardware and software of a particular computing device; processing the application program for individual execution on each target platform; identifying at least one profile corresponding to each target platform, wherein the at least one profile defines at least one feature of the corresponding target platform; simulating each target platform by processing the at least one corresponding profile, wherein each simulated target platform emulates the behavior of the particular computing device; and executing each processed application program simultaneously on the corresponding simulated target platform.

8. The method of claim 7, further comprising providing debugging information associated with the executing application program.

9. The method of claim 7, further comprising receiving a modification to the application program.

10. The method of claim 7, further comprising synchronizing events or values within at least one instance of the executing application program.

11. The method of claim 7, wherein the at least one profile comprises at least one of: a resource profile, a loading bar profile, a settings profile, a sound profile, a language profile and an icons profile.

12. The method of claim 7, wherein one profile corresponds to multiple target platforms.

13. A system for developing platform-independent application programs, the system comprising: an environment manager configured to receive a plurality of platform- independent application programs; a target environment simulator coupled to the environment manager for receiving the plurality of application programs, the target environment simulator comprising: a plurality of hosts, wherein each application program is provided to one of the plurality of hosts, and a plurality of application-compatible target platforms, wherein each target platform corresponds to one of the plurality of hosts, each target platform being associated with hardware and software of a particular computing device; a compiler for processing each application program for execution on the corresponding target platform; and a data store comprising a plurality of profiles, wherein each profile corresponds to at least one target platform, each profile defining at least one feature of the corresponding at least one target platform, wherein the target environment simulator is configured to process the profiles to simulate each target platform such that each simulated target platform emulates the behavior of the particular computing device, each processed application program being executed simultaneously on the corresponding simulated target platform.

14. The system of claim 13, further comprising a debugger configured to provide debugging information associated with the executing application program, wherein the debugging information is provided to the environment manager.

15. The system of claim 13, wherein the debugger is further configured to receive a modification to one of the application programs.

16. The system of claim 15, wherein the target environment simulator is further configured to: process the modified application program for execution on a target platform; and execute the modified application program on the different simulated target platform.

17. The system of claim 13, further comprising a code generator configured to provide the plurality of platform-independent application programs to the environment manager.

18. The system of claim 13 , wherein the target environment simulator is further configured to synchronize events or values within at least one instance of at least one of the executing application programs.

19. The system of claim 13, wherein the profiles comprises at least one of: a resource profile, a loading bar profile, a settings profile, a sound profile, a language profile and an icons profile.

20. The system of claim 13, wherein one profile corresponds to multiple target platforms.

21. The system of claim 13 , wherein multiple profiles correspond to one target platform.

22. The system of claim 13, further comprising an archiver configured to provide a plurality of different versions of the same application program to the environment manager, wherein each version of the application program corresponds to a different target platform.

23. The method of claim 13, further comprising an additional target environment simulator coupled to the environment manager, wherein the additional target environment simulator is configured to process and execute the application programs such that at least one application program is executed simultaneously on more than one of the corresponding simulated target platforms.