Visual generation of mobile applications based on data models

Systems, methods and computer program products for mobile device application design are described herein. The method accesses a data model corresponding to a selected mobile platform. The data model is used by a device application designer to generate, model, and debug a mobile application. The data model is used to take into consideration characteristics of the selected platform and a selected mobile device as the application is designed. The application is structured and generated for a selected platform that is independent of the data model, but is cognizant of the selected platform. A simulator models the application user interface (UI) as it will appear on the selected platform. The method performs platform-specific validation and allows for correction of various aspects of a generated application including platform-specific features. The tool generates a graphical image that can guide a developer to either generated code or help files corresponding to framework libraries.

FIELD OF THE INVENTION

The present invention is generally related to mobile applications, and more specifically to tools for developing applications for mobile platforms.

BACKGROUND OF THE INVENTION

Mobile devices with the ability to run software applications continue to become prevalent in the field. Due to differences between mobile device hardware and operating systems, many mobile applications must be tailored to and customized for specific types of mobile devices. Thus, multiple versions of mobile applications must be developed to run on disparate mobile operating platforms, operating systems, and mobile devices. Mobile applications must be designed and developed in light of mobile device hardware capabilities, enterprise software, wireless network capabilities, and the target mobile device platform. Mobile application development represents a rapidly growing business segment.

Due to the broad range of mobile device capabilities and characteristics, mobile application development often entails designing, developing, and debugging software code using platform-specific development environments and tools for each specific device type. There are many flaws with this approach. For example, using this approach, it is difficult, if not impossible, to readily visualize and debug applications to ensure consistency of mobile applications across different mobile device platforms. As a result, it is difficult to efficiently test and debug mobile applications to be deployed to multiple mobile platforms.

This approach also does not afford efficient platform-neutral code generation. As a result, mobile application development costs increase and software releases are delayed.

Accordingly, what is needed is an improved platform-neutral approach for developing and debugging mobile applications for a multiple platforms.

BRIEF SUMMARY OF THE INVENTION

The present invention is directed to systems, methods and computer program products for developing device applications. A device application is a software application that runs on a mobile device. Briefly stated, according to an embodiment, a developer can create device applications using a device application designer tool. In an alternative embodiment, a developer can use an application programming interface (API) framework to develop device applications. In an embodiment, a data model corresponding to a selected mobile platform and device is accessed to enable visual device application design so that device application code corresponding to a selected platform and device is generated. In an embodiment, the device application designer tool is accessed via an interactive user interface in order to simulate or model the operation of generated device applications for testing and debugging purposes.

The systems, methods, and computer program products are used to develop mobile applications for a plurality of diverse mobile devices running a plurality of operating systems. In an embodiment, the device application designer tool takes into consideration characteristics of the diverse mobile devices and platforms and generates applications for a plurality of device types independent of the data model but cognizant of the device and appropriately structuring the application. The mobile applications that are built using the data model are provisioned on to the devices in a secure way across various devices.

The features and advantages of the present invention will become more apparent from the detailed description set forth below when taken in conjunction with the drawings. In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. Generally, the drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number.

DETAILED DESCRIPTION OF THE INVENTION

Overview of the Invention

The present invention is directed to embodiments for visual development of mobile applications. A mobile application is any application that can run on a mobile device, including those presently known and those developed in the future. A mobile device may be one of many devices, such as, but not limited to, personal digital assistants (“PDAs”), IPHONEs, IPOD touch devices, devices operating according to the Microsoft Pocket PC specification with the MICROSOFT Windows CE operating system (OS), devices running the MICROSOFT Windows Mobile Standard OS, devices running the MICROSOFT Windows Mobile Professional OS, devices running the Android OS, devices running the Symbian OS, devices running the PALM OS, mobile phones, BLACKBERRY devices, smart phones, hand held computers, palmtop computers, laptop computers, ultra-mobile PCs, and other wireless mobile devices capable of running mobile applications.

As used herein, an application is any software program or web service that can be executed or run on a server, computer, or mobile client device. An application includes at least a rendering component, execution logic, and Input/Output (I/O) parameters. An application's execution logic may be in the form of binary executable code or scripting programming/markup languages such as WinMobile C#, Objective-C, Java, JavaScript, HyperText Markup Language (HTML), Extensible HTML (XHTML), or AJAX (Asynchronous JavaScript and XML). One of skill in the relevant arts will appreciate that other programming languages and technologies can be used for an application's execution logic.

Unless specifically stated differently, a developer is interchangeably used herein to identify a human user, a software agent, or a group of users and/or software agents. Besides a human developer who needs to design and debug mobile applications, a software application or agent sometimes generates and validates mobile applications. Accordingly, unless specifically stated, the term “developer” as used herein does not necessarily pertain or refer to a human being.

In one embodiment, the device application designer tool employs a code generation pattern for building platform-specific applications based on a data model corresponding to a selected target platform. The data model represents operational characteristics of a mobile platform, pre-defined application screens for the platform, mobile devices supported by the platform; and default input controls for mobile devices supported by the selected platform. In an embodiment, respective data models for a plurality of mobile device platforms are defined as a respective plurality of extensible markup language (XML) files. For example, a data model corresponding to the data model for the BLACKBERRY/Research in Motion (RIM) platform can include XML code indicating, operational characteristics of the BLACKBERRY/RIM platform, pre-defined application screens for the BLACKBERRY/RIM platform, specific BLACKBERRY devices supported by the BLACKBERRY/RIM; and default input controls for each of the BLACKBERRY devices supported by the BLACKBERRY/RIM platform.

In an exemplary embodiment, if a BLACKBERRY/RIM platform is selected, the device application designer tool generates RIM-specific Java code for a BLACKBERRY device. In an alternative embodiment, if a Windows Mobile operating system is selected as the platform, WinMobile C# code is generated by the tool for smart phones and mobile devices running a Windows Mobile operating system (OS). In another embodiment, if an IPHONE platform is selected, Objective-C code is generated for applications running in an IPHONE OS developed by Apple Inc. for an IPHONE or IPOD touch mobile device.

As some mobile applications may not be completely implemented using the device application designer tool, the tool includes an interface that enables developers to modify generated code. For example, the tool may include a source code editing interface enabling a developer to insert additional code into the generated code in order to implement additional logic.

In an embodiment, the device application designer tool is part of the SYBASE Unwired Platform (SUP), formerly the Unwired Enterprise Platform (UEP). The UEP is described in greater detail in U.S. patent application Ser. No. 11/882,749, entitled “Unwired Enterprise Platform,” filed Aug. 3, 2007, which is herein incorporated by reference in its entirety.

The invention enables a developer to visualize and test applications developed for multiple devices and platforms before they are deployed to and installed on the actual mobile devices. Mobile devices160may be any existing or future mobile device, and may be operating from any location.

Systems for Visual Generation of Mobile Applications

In the exemplary mobile application design systems100and200depicted inFIGS. 1 and 2, a mobile application which has been designed and generated using device application designer124for platform164is deployed to mobile device160.

FIG. 1depicts a system100for visually designing, developing, and debugging applications for a selected mobile device160and platform164, in accordance with an embodiment of the present invention. The device application design system100includes a device application designer124with a generation wizard114, debugger116, user interface (UI) simulator118, device modeler128, and data store130. In an embodiment, device application designer124is a software tool or application hosted on server122as depicted inFIG. 2. In an alternative embodiment, device application designer124is hosted by a remote server (not shown) from a desktop client machine. Similarly, components of the device application designer124such as generation wizard114, debugger116, UI simulator118, device modeler128, and data store130; may be hosted locally on server122or may be distributed amongst one or more remote servers (not shown).

Although a single mobile device160is depicted in systems100and200, it is understood that device application designer124can be used to design, generate, and test applications for a plurality of disparate mobile devices160and platforms164.

In an embodiment, device application designer124is configured to access a plurality of data models corresponding to mobile devices160and platforms164. In another embodiment, platform plug-ins indicating platform-specific properties for platforms164are accessed from data store130. These platform plug-ins contribute platform-specific properties to the mobile application168and the mobile application168screen controls and stock screens. In other embodiments, stock images, stock screens, stock styles, and system variables for platforms164and mobile devices160are stored in data store130for use by device application designer124. In one embodiment system styles corresponding to platforms164are also stored in data store130so that the pre-defined styles are available to designers.

In an embodiment, generation wizard114is a multi-page wizard, which allows a developer to select a platform164and a target mobile device160. The selection of a platform164and a mobile device160causes the generation wizard114to map the current selected device160to the correct UI simulator118and device modeler128. This mapping is described below with reference toFIG. 5. In one embodiment, the first page of generation wizard114allows a developer to pick the platform164to generate mobile application code126for mobile application168. According to an embodiment, a default platform is mapped based upon the mobile device160picked in a screen design interface. An exemplary screen design user interface (UI) is described below with reference toFIG. 6. Other details of generation wizard114are described below with reference toFIGS. 12 and 13.

Mobile application168comprising mobile application code126is deployed to mobile devices160via connectivity to multiple diverse and disparate wired and wireless networks, including but not limited to WiFi, 2G/2.5G, WiMAX, Wired, and 3G. Other wired and wireless mediums will be apparent to persons skilled in the relevant art(s), and fall within the scope of the present invention.

As illustrated inFIG. 1, mobile device160may comprise a local data store166. In an embodiment, mobile application168comprising mobile application code126is deployed to device160is stored in local data store166.

As depicted inFIG. 2, mobile device160may further comprise a display262and an input device264. According to embodiments of the present invention, input device264can be, but is not limited to, for example, a touch screen, a keyboard, a pointing device, a track ball, a touch pad, a joy stick, a voice activated control system, or other input devices used to provide interaction between a user and mobile device application168. Input device264can be used by a user of mobile device160to launch newly-deployed and installed mobile applications168.

Additionally, existing mobile applications168that have previously been deployed to mobile device160can be executed and displayed on display262.

Accordingly, mobile applications168operate on mobile devices with varying levels of hardware and platform capabilities and in a heterogeneous network environment with varying degrees of reliability, bandwidth, latency, connectivity, etc. According to embodiments of the invention, device application designer124takes into consideration the characteristics of the diverse mobile devices160and their respective platforms164. Features of generation wizard114, debugger116, UI simulator118, and device modeler128are described below with reference toFIGS. 3-5.

The device application designer124allows applications for a variety of devices160and platforms164to be visually designed, debugged, and modified in a single tool. By doing so, the device application designer124provides a single context hides the complexities of implementing mobile applications168across an increasing range of mobile devices160and platforms164.

Mobile Application Generation Methods

FIG. 3is a flowchart300illustrating steps by which an application design method is used to design and generate an application for a mobile device, in accordance with an embodiment of the present invention.

More particularly, flowchart300illustrates the steps by which an application is designed and developed for a selected mobile platform and device, according to an embodiment of the present invention.

FIG. 3is described with continued reference to the embodiments illustrated inFIGS. 1 and 2. However,FIG. 3is not limited to those embodiments. Note that the steps in the flowchart do not necessarily have to occur in the order shown.

The method begins at step302when a device application designer tool is invoked. In an embodiment, device application designer124depicted inFIGS. 1 and 2is accessed by a developer in step302. According to an embodiment of the invention, the device application designer tool makes automatic entries in some data fields in the generation wizard114, such as a parent folder for generation wizard114. In one embodiment, the parent folder is a directory within data store130under which generated mobile device application code126associated with a mobile application168is saved.

After the tool is invoked, a user interface for the device application designer is launched and method proceeds to step304.

In step304, selections of mobile application168screen creation preferences are received from a preferences interface. In this step, a file name for the mobile application can be entered. In step304, a developer can link the mobile application code126being generated to one or more files in data store130. In this step, a platform164for which the mobile application168is being created is selected. These selections determine which application features are available to be generated in subsequent steps in the method illustrated in flowchart300. In an embodiment, the selection of a platform164causes device application designer124to access a data model associated with the platform. In an embodiment, the data model is accessed from data store130. The default device160is set based upon the selected164. Once the selections of the target platform164and screen creation preferences are made, the method proceeds to step306.

In step306, a flow design interface in the device application designer is used to create a flow design for custom and pre-defined mobile application screens. An exemplary flow design interface is described below with reference toFIGS. 18 and 19. In an embodiment, a flow design is selected, which allows selection of a mobile application screen from a set or ‘palette’ of pre-defined screens in a menu. The pre-defined screens presented in the menu are based upon the data model accessed in step304. The flow design can be visually generated in this step. For example, pre-defined screens can be dragged and dropped from the palette onto a flow design ‘canvas’ within device application designer124. In step306, additional screens can be added to mobile device application168, as needed. In this step, connections between the screens can also be selected. In step306, in a UI in device application designer124, a developer can add controls and actions to the screens of mobile application168. In an embodiment, a flow design UI of device application designer124is used in this step to create a flow design for custom mobile application168screens. In step306, the flow design UI can also be used to add and connect screens, as well as customized stock screens. Once the initial flow design of mobile application168is complete, the method proceeds to step308.

In step308, additional connections are created between screens within mobile application168. In one embodiment, in a flow design page within device application designer124, a selection of a connection type from a set or palette of connection types is made. In this step, a developer can, using an input device, select a source screen and drag to connect it to a target screen. In an embodiment, this step can be performed using an interactive interface which allows a designer to hide details of connections to other screens within the flow design by collapsing screens to icons and expand the screen views to show both the screens and any connections to other screens. Connections between screens created in step306will not work until they are used in an action attached to a menu, button, or until another control is selected. The selection of controls occurs is described below with reference to step312. In an embodiment, a UI displays a connection line between screens that are connected in this step. Once the additional connections are created, the method proceeds to step310.

In step310a mobile device160is selected. The properties of display262of the selected mobile device160are used to format a screen designer UI specifically for the selected mobile device160. In an embodiment, once a mobile device160is selected, an empty canvas is displayed in a screen design UI, wherein the empty canvas is formatted for the selected device160. According to one embodiment, a mobile device160is selected from a drop-down list. In this step, if a specific mobile device, an orientation icon is activated so a developer can select the orientation for the selected device160. For example, if a BLACKBERRY STORM™ is selected, horizontal and vertical orientations are available in the canvas. If a specific mobile device160is not selected in step310, the default device set in step304is used, but the default device screen is displayed as a much larger canvas in the screen design UI. This makes it easier to add additional controls to screens that have containers that occupy most of the screen design UI display. Once the mobile device160is selected, the method proceeds to step312.

In step312, controls and their corresponding control events are added to the application screens added in step306. In an embodiment, a screen design palette is used to add controls to mobile device application screens. In this step, a menu, button, or other controls for the connections between screens are selected. A properties page for can be used to configure the controls added in this step. In an embodiment, the types of controls available in the screen design palette varies depending the platform164and device160selected in steps304and310, respectively. For example, if the selected device160is an IPHONE or IPOD touch device, a ‘wheel’ control is available for selection. Similarly if the selected platform164and device160supports a touch screen UI, touch screen controls can be selected in step312. In an embodiment of the invention, control events are selected for one or more of the controls added in this step. Control events, or event hooks include, but are not limited to, those shown in Table 1.

TABLE 1Control Events for Controls Applied to a Mobile Device ApplicationEvent NameDescriptiononLoadEvent is called in response to loading the control is loaded. Forexample in, in an email/PIM mobile application, an inbox buttonmay be edited to show the button as an envelope icon with anumber indicating the number of unread mail before the buttonis displayedonClickEvent is called in response to detecting that a control has beenacted upon. This may be used for showing tool tip (i.e.,interactive, context-aware help), or expanding a table cell/row toshow additional information for the cell/row (i.e., to showadditional contact information when a user navigates to a contactrecord in an address book).onValueChangeEvent is called in response to detected a value change of an inputcontrol. This could be handy for linked parameters in that thevalues of a control change based on the selected value of anothercontrol.onSelectionChangeEvent called when a selection of a table or list detail is detected.This event can be used for enabling or disabling menu items,activating phone actions, etc.onOrientationChangeEvent code is called in response to detecting an orientationchange of the mobile device (i.e., landscape versus portrait,horizontal versus vertical). May trigger a redraw of the mobileapplication screen/UI.onDrawEvent called when the control or container is called to paint theobject.

In an embodiment, control events can be supported in two different levels. For the first level, an “Events” property page may be displayed which allows developers to provide the location and method name of any platform-specific source for the control events for specific platforms164for each control added in step312. During the code generation described below with reference to step318, the provided source can be linked into a device client corresponding to the mobile device160selected in step310. According to an embodiment, a second level, event scripting, abstracts controls and persistence layers into JavaScript objects. In this way, JavaScript can be generated for manipulating controls and data on a display262of mobile device160. The JavaScript can be converted into mobile application code126when the client for device160is generated. For example, when an IPHONE client is generated, the script may be converted into Objective-C code. In this way, the same JavaScript can work on multiple platforms164. After controls are added and their corresponding control events (i.e., event hooks) are selected, the method proceeds to step314.

In step314, the design of the mobile device application168to be generated is verified. In an embodiment, platform specific problem checking is performed in this step based upon the platform164selected in step304. For example, if a RIM/BLACKBERRY platform has been selected, step314will perform personal information manager (PIM)-type checks on the PIM actions that are supported by the RIM/BLACKBERRY platform. The validation in this step may result in detection of configuration problems with platform-specific actions. In an embodiment, developers can also contribute or add problem checks for a given platform164by returning implemented problems in the platform's getPlatformProblems( ) method. In this way, any new problem checks for a platform164can be added into the device application designer124. These problems will automatically be added into the preferences system for platform problems so that the severity of the problem can be configured. In one embodiment, depicted in the code sample below, problems can only be added for checking and the actions performed by content assist are not extensible. The problems detected in step314are automatically placed under the platform name corresponding to platform164in the problems preferences for setting default values.

The following code is an embodiment for adding problem checks for a platform. In this embodiment (from a device application design tool entitled ‘Bob’), a problem can be added for actions including editing or removing. As would be appreciated by one of skill in the relevant arts, other programming languages and technologies can be used to implement the problem checking in the programming language code sample below.

/*** Platforms can add problem checks. These problems will automaticallybe added* into the preferences system for platform problems for configurationof the severity.** NOTE: problems can only be added for checking, the actions performedby content assist* are not extensible. However, in most cases this is not necessary.** For extensible objects like actions, If the problem is for youraction,* you would assign the problem to the check type for a“CHECK_TYPE_MENUITEM_PLATFORM_ACTION” or* “CHECK_TYPE_PLATFORM_ACTION” (widgets). This will givethe contentassist for edit, remove the action.* On edit, the action is opened with the problem check type and shouldfix the problem.**/public interface IBobProblem{/*** Get the id to use for this marker. This is used as the key forthe preference.* @return*/public String getId( );/*** Get the type of marker this should be added in to for checking.This is one of the* marker types defined in IBobMarkerConstants. i.e.FLOW_DESIGN_PROBLEM, SCREEN_DESIGN_PROBLEM, etc.* @return marker type* @see IBobMarkerConstants*/public String getMarkerType( );/*** Get the message to display without arguments. This is used in thepreference settings* so the user can figure out what severity to set. This would bethe resource, string without* message format, i.e.* com.sybase.uep.bob.flowdesignmarker.screen=Screen {0} is notvalid.* The id would be: com.sybase.uep.bob.flowdesignmarker.screen* The message would be: Screen {0} is not valid.** @return*/public String getMessage( );/*** Get the default severity assigned for this problem id. This willbe used with the preference* system to assign defaults.* @return*/public int getDefaultSeverity( );/*** Check the bob document using the given checker (checker assignedwill be type returned from* getMarkerType( )). The problem should be added into the checkervia the reportCheckResult( )* @param checker checker to use.* @param bob editor* @see getMarkerType( )* @see BaseBobChecker.reportCheckResult( )*/public void checkProblem(BaseBobChecker checker, BobEditor bob);/*** Check the bob document using the given checker (checker assignedwill be type returned from* getMarkerType( )). The problem should be added into the checkervia the reportCheckResult( )* @param checker* @param bob* @param localePath locale to check if the problem is extending thelocale checker.* @see getMarkerType( )* @see BaseBobChecker.reportCheckResult( )*/public void checkProblem (BaseBobChecker checker, BobEditor bob,IPath localePath);}

In an embodiment, a modeling tool is used in step314to provide platform and device specific validation and allows for correction of various aspects of the mobile application code126, including device specific features, and errors in connections between screens created in step308. After the design is validated, control is passed to step316.

In step316, an evaluation is made regarding whether there are errors in the mobile device application168to be generated. This step is performed by verifying the mobile application code126associated with the mobile device application168to be generated. If it is determined that there are no errors, control is passed to step318where the mobile device application168is generated. If it is determined that there are errors in the mobile device application, control is passed to step320where the application is debugged.

In step318, a mobile device application168is generated. In an embodiment, in this step, generation wizard114generates mobile application code126based upon the selections made in steps302-312. For example a multi-page generation wizard114may be invoked to generate mobile device application168. The first page of generation wizard114may allow the developer to pick the platform164to generate the application for. If no selection is made in the wizard, a default platform164will be mapped based upon the device160picked in step310. In this step, a locale may also be selected in the wizard. The locale section contains the locales defined for the selected platform164and device160. The locale section of generation wizard114is disabled if localization capability is not supported by the selected platform164. Another section of generation wizard114contains areas of checking that are generic to all platforms164. When a platform164is selected the next button will bring up that platform's specific generation wizard114page(s). After completion of the generation wizard114pages, mobile device application168is generated and control passes to step324.

In step320, a ‘mind map’ of mobile device application168is generated so that a developer can readily navigate to different pieces of mobile application code126where errors were detected in step316. In an embodiment, in this step, functional components of mobile device application168are depicted as an interactive mind map so that a developer can select one or more functional components in order to inspect the underlying source code and help files. In the mind map generated in step320, functional components of mobile device application168are linked to corresponding mobile application code126. The mind map can be used in conjunction with a debugger in step322to link to portions of generated mobile application code126that needs to be fixed. Step320is described in greater detail below with reference toFIG. 4. After the mind map is generated and displayed, control is passed to step322.

In step322, a debugger is invoked to fix and test errors detected during step314. In an embodiment, debugging is performed in a platform neutral way by using an agent based approach to integrate platform simulators with debugger116in device application designer124. In an embodiment, platform simulators comprise a UI simulator118and device modeler128corresponding to the selected device160and platform164. In an embodiment, the debugging of the mobile application code126is performed by debugger116in conjunction with a simulator configured to simulate the behavior of the combination of the selected device160and platform164. However, as an agent is used by the platform simulator, the debugging performed in this step is independent of the device type being debugged because of the abstraction between debugger116and the simulator. The debugging performed by debugger116is described in greater detail below with reference toFIG. 5. After the mobile application code126is debugged and errors are fixed, control is passed to step318where the mobile application168is generated.

In step324, the generated mobile device application168is ready to be deployed to a mobile device160. In step324, the developer may identify additional software components that are required on device160to properly execute the generated mobile device application168. For example, the developer may identify an operating system upgrade, patch, library, plug-in, etc., that is required to be installed on device160so that the application168will properly execute on the device160. The listing or identity of such required components is considered to be metadata associated with the application designed and developed in steps302-322. In step324, such metadata may be stored in data store130so that it can be deployed with the application168. In an embodiment, the developer provides the metadata to an administrator who stores the metadata in a metadata repository within data store130. In one embodiment step324is performed at some later time, when device160that is connected to a network and requests that the application168be installed. Once the application168is deployed and installed, the process ends.

Friendly Code Generation with Inspection and Assistance

This section describes embodiments of the invention for a tool to generate and graphical image that can guide the developer to either the code generated or the help files corresponding to the framework libraries that are leveraged by the device application designer to generate the application. In an embodiment, the tool generates and displays an interactive visual representation, or ‘mind map’, that enables developers to navigate to generated code and/or help documents corresponding to various aspects of a mobile application previously generated by the device application designer.

In an embodiment, device application designer124employs a code generation pattern for building device-specific applications168based on a selected target device160. As many of the applications168are not completely implemented using the visual design process300described above, the generated code often needs to be modified so that code can be inserted to implement additional logic or to fix errors in an application168. Due to the large amounts of code that is generated, it is difficult for a developer to parse through all the mobile application code126to determine how the mobile device application168modeled in the device application designer124matches up with particular subsets of code so that code can be modified at correct place (i.e., in the correct functional component) without causing side effects.

FIG. 4depicts an interactive mind map410for navigating to different pieces of the mobile application source code126.FIG. 4is described with continued reference to the embodiments illustrated inFIGS. 1-3. However,FIG. 4is not limited to those embodiments. Mind map410is useful, for example, as a tool for debugging step322illustrated in flowchart300described above. Mind map410is a tool used to allow a user of system100and200, such as a developer, to quickly drill down from functional components of mobile device application168to corresponding generated and custom mobile application code126. In short, mind map410provides a way for developers to select portions of source code related to components, such as mobile business objects (MBOs), functions, procedures, libraries, or frameworks of a mobile device application168. MBOs are described in greater detail in U.S. patent application Ser. No. 12/503,573, filed on Jul. 15, 2009, entitled “Metadata Driven Mobile Business Objects,” which is incorporated by reference herein in its entirety.

In the example mind map410depicted inFIG. 4, the mobile device application168being analyzed is sales application412. Using an input device similar to input device264described above with reference toFIG. 2, a developer can select the About Screen component414to link to the code sample provided below.

By selecting the top-level Sales MBO component416, mind map410links to the generated mobile business office (MBO) code for sales application412.

More particularly, by selecting a specific MBO such as Customer MBO418, Sales MBO420, or Sales Order MBO422, mind map410navigates to Java documents or code for the selected MBO. For example, by selecting Customer MBO418, a developer can link to the code sample provided below.

Selecting UI Frameworks424takes a developer to Java documents for the user interface frameworks.

In an embodiment, an interactive mind map410is generated by device application designer124for all platforms164supported by systems100and200, including, but not limited to, Windows Mobile, the IPHONE OS, RIM, the Android mobile operating system, and other platforms164.

FIG. 5depicts a modular view500of an agent-based tool for platform-neutral debugging of mobile device applications168.FIG. 5is described with continued reference to the embodiments illustrated inFIGS. 1-3. However,FIG. 5is not limited to those embodiments. In an embodiment, the tool depicted inFIG. 5can be used in the debugging step322of the method illustrated in flowchart300. For example, debugger116may comprise the tool depicted inFIG. 5. In an embodiment, debugging of mobile application code126is performed on desktop510for device application designer124using desktop agent512. Desktop agent512communicates information about the mobile device application168to one of a plurality of platform simulators via links518. Each platform simulator comprises an agent, a UI simulator118, and a device modeler128. The platform simulator that is launched depends on the target platform164. For example, BLACKBERRY simulator514is launched if the RIM/BLACKBERRY platform164was selected in step304as part of the method depicted in flowchart300. Each platform simulator comprises a respective agent used to launch mobile device application168. For example, as shown inFIG. 5, BLACKBERRY simulator514includes agent516to launch application168. BLACKBERRY simulator514models the behavior the application168as it would appear on the target device160. In an embodiment, each platform simulator's agent reflects device specific features for the combination of the selected device160and platform164. For example, agent516is configured to enable BLACKBERRY simulator514to model behavior of application168on a specific BLACKBERRY device160selected in step310in flowchart300in combination with a RIM platform164selected in step304. For example, if a BLACKBERRY STORM™ was selected in step310, the device-specific behaviors of the selected BLACKBERRY STORM™ device160are modeled by BLACKBERRY simulator514. These behaviors include, but are not limited to, display characteristics for the BLACKBERRY STORM touch screen display262, modeling the use of the BLACKBERRY STORM input device264, comprising buttons and a touch screen.

As shown in the embodiment depicted inFIG. 5, Android simulator520comprising agent522can be used for debugging when the Android OS platform164has been selected as the target platform164for application168. Similarly, in another embodiment, IPHONE simulator526comprising agent528can be used to debug applications168when the IPHONE OS platform164was selected in step304in the method depicted in flowchart300. In the example embodiment depicted inFIG. 5, only three platform simulators,514,520, and526are depicted for three exemplary platforms164(e.g., RIM′ Android, and IPHONE, respectively). However, as would be appreciated by one of skill in the relevant arts, other platforms164can be simulated using platform simulators comprising a UI simulator118and device modeler128configured to model the operational characteristics of other mobile platforms and operating systems not depicted inFIG. 5.

As desktop agent512agent communicates with agents running within each respective simulator, platform-neutral debugging can be performed independent of the selected device160and platform164. This is because of the abstraction from the actual devices/platforms being simulated and the additional level of abstraction between the simulator agents516,522, and528and desktop agent512.

Device/Platform Specific View of User Interface Controls

This section describes functionality within the device application designer124to display various control ‘widgets’ as they would appear on the selected device/platform combination. In an embodiment, device application designer124can provide a developer with a device and platform-specific view of a UI control based on the device160and platform164chosen. The developer can dynamically change the view of that UI control based on selecting a different device160and/or platform164. This embodiment enables developers to have a realistic view of the UI of an application168being designed without having to first execute it on a simulator. In an embodiment, the device application designer124provides default views for all controls, regardless of which platform164the figure is designed for. Additionally, a platform-specific figure interface is provided for each control widget. Each platform164implements an interface to create its own version of views in order to model the look and feel of a selected platform164and device160. Not all platforms164support the same widgets. For example, a screen designed for a BLACKBERRY platform might look dramatically different on an IPHONE device. A toggle widget, for example, can be displayed as a checkbox on a BLACKBERRY device, but may be displayed as an on-off switch on devices running an IPHONE OS. The device application designer124updates an application editor to show the figure corresponding to the currently-selected platform164. A default figure may be used if a platform-specific figure is not available for a selected platform164.FIG. 6depicts exemplary control widgets for BLACKBERRY STORM controls610and IPHONE controls620. The code sample below provides an example platform-specific interface view for radio button controls.

/*** This interface contains methods that need to be implemented by radiobutton views.**/public interface IRadioButtonFigure extends IBaseFigure, IWidgetFigure{/*** Sets the RadioButton item.* @param bIsSelectedWhether the radio button is checked.* @param bReadOnlyWhether the item is read only.*/public void setSelectedState(boolean bIsSelected, booleanbReadOnly);/*** Sets the value of the radio button.* @param radioValue The display of the radio.*/public void setRadioValue(String radioValue);}
Example Graphical User Interface

FIGS. 7-19illustrate a graphical user interface (GUI), according to an embodiment of the present invention. The GUI depicted inFIGS. 7-19is described with reference to the embodiments ofFIGS. 1-5. However, the GUI is not limited to those example embodiments, and the embodiments ofFIGS. 1-5are not limited to the example GUI ofFIGS. 7-19. For example, the GUI may be interface used for visual design and generation of mobile applications, as described in steps302-324above with reference toFIG. 3. The GUI may also be used to generate the mind map410with reference toFIG. 4. In an embodiment of the invention, the GUI illustrated inFIGS. 7-19is displayed on server122having a display for device application designer124.

Although in the exemplary embodiments depicted inFIGS. 7-19the GUI is shown for designing and generating mobile device applications168for BLACKBERRY devices, it is understood that the GUI can be readily adapted to create applications other mobile device platforms and operating systems.

ThroughoutFIGS. 7-19, displays are shown with various icons, command regions, buttons, menus, links, and data entry fields, which are used to initiate action, invoke routines, launch displays, enter data, view data, or invoke other functionality. The initiated actions include, but are not limited to selecting platforms, selecting devices, selecting device orientation, completing generation wizard114, and designing screens. For brevity, only the differences occurring within the figures, as compared to previous or subsequent ones of the figures, are described below.

FIG. 7illustrates an exemplary device preference interface700for selecting preferences for a device160. Device preference interface700contains only a default device when no platform164has been selected. For example, if no platform was selected in step304, device preference interface700will have a default device and list the default device configuration. In the exemplary interface provided inFIG. 7, device preference interface700for BLACKBERRY displays simulator configuration mappings710for generation wizard114to map the current selected device160to the correct platform simulator. The platform simulators are identified in mappings710by their location within data store130and by file name. As discussed above, the platform simulator comprises a device modeler128, UI simulator118, and a platform-specific agent. For example, BLACKBERRY simulator514will be mapped when a configuration mapping corresponding to a BLACKBERRY device is selected in device preference interface700.

FIG. 8illustrates a device selection interface800for currently selected device type for the screen design as a toolbar entry in toolbar810. The device160is can also be selected under a “Device” property tab (not shown) within device application designer124. Selection of a device160in device selection interface800resets the icon812in the toolbar810to be the platform icon selected. Each platform164has its own grouping. The last item, item814, is for no platform specific tooling (None). The platform icons816and device list818are used in device selection interface800to select both a platform164and a corresponding device160running a selected platform. When a device type is selected in device selection interface800, the screen designer is rebuilt with the device skin corresponding to the platform164.

FIGS. 9 and 10illustrate the orientation toolbar interface900. If the selected device160supports multiple orientations (i.e., vertical and horizontal), applications168being designed can be viewed in different modes by selecting the desired orientation in orientation toolbar interface900.FIG. 9depicts the vertical orientation view andFIG. 10depicts the horizontal orientation view. In an embodiment of the invention, Orientation information for each device is defined in an extensible markup language (XML) file within data store130.

FIG. 11depicts the menu selection interface1100. As shown in the exemplary embodiment ofFIG. 11, the menu selection has 2 natural groupings. The device context menu area is where device-specific context is added by the selected device160. For example, the device-specific context may comprise the ways a device performs copy, cut, and paste operations. A developer can add menus between this section and the “Unwired Platform Context Menu” for context menus (i.e., menus that only appear in the context of something being selected). In another embodiment (not shown), the menu system is abstracted on a per-platform basis. That is, menus for each platform164can be selected in menu selection interface1100.

FIGS. 12 and 13illustrate the generation wizard114interface. In the embodiment depicted inFIGS. 12 and 13, generation wizard114is a multi-page wizard. The first page, interface1200, allows a developer to pick the “platform” to generate. The default platform164will be mapped based upon the device160picked in the screen design.

The locale section1210of the interface contains the locales defined for the data model corresponding to the selected platform164. This section is disabled if localization capability is not supported by the selected platform. The advanced section1220contains areas of checking that are generic to all platforms. When a platform164is selected, the next button122will bring up that platform's wizard page(s). The details of the flow of generation will be described in the wizard page interface.FIG. 13provides an exemplary BLACKBERRY generation wizard page1300.

FIGS. 14 and 15depict an interface for selecting platform-specific properties. As shown inFIG. 14, the height and width properties for a control for a selected platform164can be selected in interface1400.FIG. 15illustrates a dialog interface1500for setting screen properties for a stock screen. Once the desired properties have been set in window1510, create screen class button1520can be selected to create the corresponding screen class.

FIG. 16illustrates flow design palette1600that can be used add pre-built ‘stock’ screens into the list of stock screens available to developers. In one embodiment, the device application designer124comes with certain stock screens, which were defined using menu1600for many functionally needed screens. Each platform164should support all existing stock screens1610. Stock screens1610are grouped under the stock screen folder in the flow design palette1600.

FIG. 17depicts a create screen class interface1700. In interface1700, a properties page1710can be used to set properties for a newly-created screen within mobile device application168.

FIGS. 18 and 19depict a flow design interface1800.FIGS. 18 and 19are described with continued to the embodiment illustrated inFIG. 16. As illustrated inFIG. 18, palette1600of screens can be used to select application screens from a set of default, stock screens1610, and custom screens1820. For example, pre-defined stock screens1610can be dragged and dropped from palette1600onto flow design ‘canvas’1840within flow design interface1800. In an embodiment, flow design interface1800can be used to visually design the flow for application168. Flow design interface1800can be used to receive developer selections of properties for newly-created screens1820within mobile device application168. Flow design interface1800can also be used to select connections1810between stock screens1610and custom screens1820by receiving, via an input device (not shown), selection of one or more connections1810between one or more selected screens1820. Using flow design interface1800, additional custom mobile screens1820can be added to mobile device application168, as needed. Connections1810between the screens can also be selected in order to create a flow design for custom mobile application168screens. In this way, flow design interface1800can also be used to add and connect screens, as well as customized stock screens1820.

Additional connections1810can be created between screens1610and1820within mobile application168using flow design interface1800. In one embodiment, a selection of a connection type from a set or palette of connection types is received from flow design interface1800. In flow design interface1800, a developer can, using an input device (not shown), select a source screen1820and drag to connect it to a target screen1820via a connection1810.

As shown inFIG. 18, screen sets1850comprising collections of custom screens1820can be grouped together in flow design interface1800. In an embodiment, flow design interface1800allows a designer to toggle between hiding details of connections1810to other screens1820within a screen set1850by collapsing screen views to icons and expanding screen views to show both the screens1820and connections1810to other screens1820within the screen set1850. In this way, a developer can collapse a screen set1850into something like a folder figure that hides the detail, or expand it to show all screens1820and connections1810within a screen set1850. The purpose of this is to reduce clutter within flow design interface1800, especially for applications with many screens. Connections1810between screens created in flow design interface1800will not work until they are used in an action attached to a menu, button, or another control is selected.

As shown inFIG. 19, menu1960can be used to profile, push, or save the new screens1820selected in flow design interface1800.

Example Computer Implementation

Various aspects of the present invention can be implemented by software, firmware, hardware, or a combination thereof.FIG. 20illustrates an example computer system2000in which the present invention, or portions thereof, can be implemented as computer-readable code. For example, the methods illustrated by the flowchart300ofFIG. 3can be implemented in system2000. The device application designer tool described above can also be implemented in system2000. The GUI described above with reference toFIGS. 7-19can be displayed via display interface20002on display2030. Various embodiments of the invention are described in terms of this example computer system2000. After reading this description, it will become apparent to a person skilled in the relevant art how to implement the invention using other computer systems and/or computer architectures.

Computer system2000includes one or more processors, such as processor2004. Processor2004can be a special purpose or a general purpose processor. Processor2004is connected to a communication infrastructure2006(for example, a bus, or network).

Computer system2000also includes a main memory2008, preferably random access memory (RAM), and may also include a secondary memory2010. Secondary memory2010may include, for example, a hard disk drive2012, a removable storage drive2014, flash memory, a memory stick, and/or any similar non-volatile storage mechanism. Removable storage drive2014may comprise a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash memory, or the like. The removable storage drive2014reads from and/or writes to a removable storage unit2018in a well known manner. Removable storage unit2018may comprise a floppy disk, magnetic tape, optical disk, etc. which is read by and written to by removable storage drive2014. As will be appreciated by persons skilled in the relevant art(s), removable storage unit2018includes a computer usable storage medium having stored therein computer software and/or data.

In alternative implementations, secondary memory2010may include other similar means for allowing computer programs or other instructions to be loaded into computer system2000. Such means may include, for example, a removable storage unit2022and an interface2020. Examples of such means may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM, or PROM) and associated socket, and other removable storage units2022and interfaces2020which allow software and data to be transferred from the removable storage unit2022to computer system2000.

Computer system2000may also include a communications interface2024. Communications interface2024allows software and data to be transferred between computer system2000and external devices. Communications interface2024may include a modem, a network interface (such as an Ethernet card), a communications port, a PCMCIA slot and card, or the like. Software and data transferred via communications interface2024are in the form of signals which may be electronic, electromagnetic, optical, or other signals capable of being received by communications interface2024. These signals are provided to communications interface2024via a communications path2026. Communications path2026carries signals and may be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, an RF link or other communications channels.

In this document, the terms “computer program medium” and “computer usable medium” are used to generally refer to media such as removable storage unit2018, removable storage unit2022, and a hard disk installed in hard disk drive2012. Signals carried over communications path2026can also embody the logic described herein. Computer program medium and computer usable medium can also refer to memories, such as main memory2008and secondary memory2010, which can be memory semiconductors (e.g. DRAMs, etc.). These computer program products are means for providing software to computer system2000.

Computer programs (also called computer control logic) are stored in main memory2008and/or secondary memory2010. Computer programs may also be received via communications interface2024. Such computer programs, when executed, enable computer system2000to implement the present invention as discussed herein. In particular, the computer programs, when executed, enable processor2004to implement the processes of the present invention, such as the steps in the methods illustrated by flowchart300ofFIG. 3discussed above. Accordingly, such computer programs represent controllers of the computer system2000. Where the invention is implemented using software, the software may be stored in a computer program product and loaded into computer system2000using removable storage drive2014, interface2020, hard drive2012, or communications interface2024.

The invention can work with software, hardware, and/or operating system implementations other than those described herein. Any software, hardware, and operating system implementations suitable for performing the functions described herein can be used.

APPENDIX

The attached Appendix forms a part of this application, and is thus herein incorporated by reference in its entirety. The Appendix provides a technical specification for an exemplary device application designer entitled ‘Bob.’ In particular, section 1.1.5 of the Appendix describes an exemplary generation wizard and section 1.1.7 describes an embodiment of how the ‘Bob’ device application designer can provide a developer with a device and platform-specific view of a UI control based on a selection of a device and platform. Section 5.5 of the Appendix describes an exemplary modeling tool that can be used to provide platform and device specific validation and allow for correction of device specific features of a mobile application design.

CONCLUSION