Typically, creating a mobile application (also referred to as an app, mobile app, enterprise mobile app, enterprise mobile application, etc.) may necessitate a mobile app developer to have an in-depth knowledge of platform specific interfaces associated with an application development platform and/or tool. This may include having a know-how of the platform and/or tool specific features and functionalities, understanding compliance norms for using platform and/or tool specific features and functionalities, etc. Such need for in-depth knowledge may have drawbacks due to increased complexity of platform and/or tool specific functionalities, changes in compliance norms, etc., thereby making the process of app development inefficient and redundant. Therefore, it may be challenging to simplify the build or generation of mobile apps, such that the process of building or generating the mobile apps is harmonized by minimizing or eliminating redundant efforts and inefficiency.
The claims set forth the embodiments with particularity. The embodiments are illustrated by way of examples and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. The embodiments, together with their advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings.
Embodiments of techniques related to building enterprise mobile applications are described herein. In the following description, numerous specific details are set forth to provide a thorough understanding of the embodiments. One skilled in the relevant art will recognize, however, that the embodiments can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail.
Reference throughout this specification to “cone embodiment”, “this embodiment” and similar phrases, means that a feature, structure, or characteristic described in connection with the embodiment is included in at least one of the one or more embodiments. Thus, the appearances of these phrases in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
Advancements in mobile technologies have propelled the number of mobile computing devices (such as personal digital assistants, enterprise digital assistants, smartphones, etc.) users. Further, such advancements have enhanced data processing and storage capabilities of, e.g., the smartphones. For example, the smartphones may include an operating system (e.g., Android®, Windows®, iOS®, etc.), that may provide access to respective mobile application distribution platforms (e.g., Google Play®, Windows Apps®, App Store®, etc.). The smartphones may connect with the mobile application distribution platform via a network (e.g., the Internet) and download the apps. An app may correspond to a bundled software application that may be executed on a mobile device, to provide specific operations or functionalities. When the app is triggered or instantiated, it may be executed on the mobile device to provide, for example, an interface (e.g., graphical user interface (GUI)), to receive user inputs, execute functionalities or process user requests and provide information or results that may be consumed by an end user. In an embodiment, the app may be built or generated using and/or reusing features and functionalities provided by a mobile application development framework (e.g., Apache® Cordova®), including application specific functionalities, common functionalities, etc. Typically, data or information related to a mobile app may be processed on client side (e.g., by the app on a mobile device) or on server side (e.g., remote servers deployed in cloud or/and on premise computing environments).
In an embodiment, building or generating the app may include building an executable application package (e.g., enterprise mobile application) or file by integrating components, scripts, routines, etc., that provide different functionalities. The integrated components may be compiled into a package as an executable file (e.g., including instructions associated with the different functionalities that may be executed by the processor of the mobile device) such that the integrated components, either independently or in cooperation, may facilitate execution of specific functionalities or operations. In an embodiment, the term enterprise mobile application may correspond to the app that may include functionalities. For example, a customer relationship management (CRM) system or application may facilitate managing relationships with the customers. The CRM system or application may manage the customer relationships via functionalities, such as solicitation (e.g., generating future customer prospects/leads through marketing), lead tracking (e.g., pre-sales—tracking customer responses, tracking sales leads, etc.), and relationship management (e.g., post-sale—prioritize responses, provide services, etc.). In an embodiment, the enterprise mobile application may be built or generated to include all or some of the referred functionalities.
In an embodiment, the terms software components or components, software routines or routines, software models or models, software engines or engines, software scripts or scripts, layers etc., may be used interchangeably throughout the specification, unless context warrants particular distinction(s) among the terms depending on implementation. The implementation primarily involves executing a computer readable code such as, a sequence of instructions by a processor of a computing device (e.g., a special purpose computer, a general-purpose computer, a mobile device, etc.) in an integrated environment (e.g., mobile application development framework). The computing device may function as the special purpose computer when the memory in the computing device stores instructions which when executed by the processor, provide execution of specific operations or functionalities. For example, such operations or functionalities, may not be limited to, but may include generating a project package by integrating plugins, graphical user interface elements, common functionalities, application specific functionalities, etc.; reusing components of the project package; generating configuration file; integrate functionalities and the configuration file to build or generate enterprise mobile application, etc. In an embodiment, the memory may store instructions that may not be limited to the aforementioned specific operations or functionalities. Unless the context warrants particular distinction(s), the cooperative execution of the referred arrangement of components, scripts, routines, etc., providing specific operations or functionalities may further improve the functioning of the special purpose computer. Further, the execution of the aforementioned specific operations or functionalities may also overcome the drawbacks or challenges, as described in the background section of the subject specification. Furthermore, the adaptation of the computing device to function as the special purpose computer may include executing the instructions to implement a mechanism to build or generate enterprise mobile applications. Such provision and utility provided by enterprise mobile apps may facilitate interaction between members of a team within a project, track status of projects, monitor potential problems, track data including financial details for the projects, etc.
In an embodiment, mobile application development framework 204 may provision building or generating enterprise mobile applications using markup programming and scripting. The markup programming and scripting may provide functionalities, for example, executing specific operations on data, extracting data, structuring unstructured data and rendering structured data on a user interface, etc. In an embodiment, the provision for building or generating the enterprise mobile application using the markup programming and scripting in the described mobile application development framework 204 may eliminate need for a mobile app developer from acquiring in-depth knowledge, for example, related to platform specific application program interfaces (APIs). For instance, such platform specific APIs may provision native features and/or functionalities that may be associated with specific operating systems, such as Android®, Windows®, iOS®, etc. In an embodiment, when the enterprise mobile app is built or generated using platform specific APIs, some of the native features and/or functionalities of the app may not optimally function on some mobile devices. In an embodiment, mobile application development framework 204 may provision developing or building enterprise mobile apps by wrapping or integrating functionalities or operations associated with enterprise application (e.g., application 202). The mobile application development framework 204 may additionally facilitate integration of other components and functionalities, such as common functionalities 208 (e.g., centralized login application), some or all functionalities (e.g., of application 202), graphical user interface elements 210, plugins, etc. The enterprise mobile apps may provision displaying the content like a web-view control on the enterprise mobile app, when the installed app is executed on the mobile device.
In an embodiment, a mobile application development framework specific project package (herein also referred to as project package 206) may be packaged and compiled (e.g., built or generated) by integrating multiple mobile application development framework specific plugins (also referred to as plugins), user interface elements, common functionalities 208, etc. The plugins, user interface elements, common functionalities 208, etc., in project package 206 may be customized and used when the enterprise mobile apps are built. In an embodiment, the term customizing or customization (e.g., of a component) may correspond to modifying an attribute (e.g., of the component), such that the customization (e.g., of the component) optimizes the functionality (e.g., of the component). Such optimization may provision the reusability of the component based on context specific functionality. In an embodiment, mobile application development framework 204 may receive a request for building or generating an enterprise mobile application. For example, an enterprise application (e.g., 202) may correspond to data processing and management systems for managing or executing specific functionalities. For example, the enterprise application may correspond to a Partner Relationship management (PRM). Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), shopping cart application, expense report management application, etc.), analytical applications, ramp-up knowledge transfer learning applications, service mobile platform application, etc. The enterprise application (e.g., 202) may be multi-tiered and may include integrated components, scripts, software engines, etc., that work either independently or in cooperation. The enterprise application may be consumed or used by an end user via user interfaces, web-browsers, etc. In an embodiment, plugins of mobile application development framework 204 may provision accessing and/or using specific features, such as instantiating specific applications, features, etc., on mobile devices. For example, such plugins may facilitate or provide accessing mobile device's native features or applications such as, camera, calendar, push notifications; providing interfaces for execution or consumption of multimedia content (e.g. photos, videos, etc.); using microphone for recording voice, etc. The components of project package 206 including the plugins (e.g., associated with mobile application development framework 204), user interface elements, common functionalities, etc., may be customized (e.g., via a selection) and reused (e.g., utilize or reutilize) based on the requirements (e.g., desired functionalities) of the enterprise mobile applications. For example, consider a request for building an enterprise mobile application associated with a CIM application. In an embodiment, the CRM application may be deployed on an on-premise or on cloud computing environment and may work in cooperation with a common functionality, for example, a centralized login application (e.g., single sign-on) that may facilitate user authentication and may provision logging into the CRM application. The centralized login application may provision login functionality via a graphical user interface with graphical user interface elements (e.g., data fields, text fields, buttons, etc.), where a user may enter his/her input credentials (e.g., user name, password, email address, etc.). Upon logging into the CRM application, the CRM application may provide user interfaces for managing customer relationships. For example, managing customer relationships may include providing services and subsequently following up with the customer on the services provided by setting up appointments and/or meetings. In an embodiment, the CRM application may include a calendar application that may facilitate managing appointments and/or meetings. The calendar application may be instantiated to provide graphical user interface that may display dates and an interface to input, modify, delete, etc., content on the calendar. This may include modifying content to manage appointments or meetings with the customer.
In an embodiment, consider the team managing the customer relationships may desire to manage customer relationships via an enterprise mobile app. The mobile application development framework 204 may receive a request for building the enterprise mobile application (e.g., enterprise mobile application 212) including the corresponding functionalities of the CRM application (e.g., 202). To build or generate the enterprise mobile application, an end-user may use and/or reuse the components of project package 206 and the functionalities of the CRM application. For example, the components of project package 206 including common functionalities 208 (e.g., login), one or more graphical user interface elements 210 (e.g., buttons, data fields, text fields, etc.), and plugins (e.g., associated with calendar application) may be integrated to build the enterprise mobile application (e.g., 212). In an embodiment, the mobile application development framework 204 may provide the platform for integrating the above described components and/or functionalities of application (e.g., 202, 206, 208, and 210) via reusability of the components (e.g., plugins, graphical user interface elements, common functionalities, etc.) with the functionalities of the CRM application. The enterprise mobile application built or generated via the above described mechanism may therefore be referred to as enterprise mobile application 212 (e.g., that may include the above described functionalities of the CRM application). In an embodiment, the plugins in project package 206 may be associated with functionalities that may correspond to instantiating applications and/or providing accessing multiple features of the mobile device. The enterprise mobile applications may include an integration of specific components (e.g., plugins, common functionalities 208, etc.) from the project package and other functionalities to generate a configuration file. In an embodiment, the configuration file may be stored in a central repository that may be accessible by the mobile application development framework. Such application specific configuration file may be retrieved from the central repository into local memory associated with the mobile application development framework and terminal commands (e.g., associated with mobile application development framework) may be executed to initiate the integration and build of the application specific mobile enterprise application.
In an embodiment, the corresponding enterprise mobile applications (e.g., 312, 314 in
In an embodiment, an enterprise mobile application may be built at a mobile application development framework by executing commands for integrating a configuration file. For example, such a configuration file may correspond to a project object model (POM) that may include information corresponding to contents of a project package, as well as other configuration information that may be used to build the enterprise mobile application. For example, the configuration information may correspond to plugins that may be associated with a mobile application development framework. In an embodiment, at the mobile application development framework, commands related to initialization and execution of a build lifecycle may be executed to build the enterprise mobile application. The execution of the commands may read the contents of the configuration file (e.g., project object model file) and integrate the components (e.g., application specific functionalities, common functionalities, plugins, graphical user interfaces, etc.), to build the enterprise mobile applications.
In an embodiment, the above described mechanism to build or generate enterprise mobile applications by reusing the components of the project package, functionalities of the applications, features of the mobile application development framework, etc., may optimize the mechanism to build or generate the enterprise mobile application. For example, such optimization may be achieved by reusing the components of the project package. The reuse of the plugins, the graphical user interface elements, the common functionalities, the application specific functionalities, applications, etc., may reduce the efforts for developing/building the enterprise mobile application, need for having in-depth know-how and complexity of learning the mobile application development framework. In an embodiment, the enterprise mobile applications built via the mobile application development framework may provide a centralized platform for managing the plugins, seeking authorizations, complying with security norms, etc., thereby simplifying the mechanism to seek approvals and comply with norms formulated by governing bodies or authorities, etc. The enterprise mobile application may be configurable and may eliminate redundancy of the app development efforts and harmonize building the enterprise mobile applications. The provision of centralized platform for managing the plugins, seeking authorizations, complying with security norms, etc., may further optimize the enterprise mobile application development process by eliminating the need for multiple points of communication, reducing the memory consumed, etc., thereby harmonizing the enterprise application development process.
Some embodiments may include the above-described methods being written as one or more software components. These components, and the functionality associated with each, may be used by client, server, distributed, or peer computer systems. These components may be written in a computer language corresponding to one or more programming languages such as functional, declarative, procedural, object-oriented, lower level languages and the like. They may be linked to other components via various application programming interfaces and then compiled into one complete application for a server or a client. Alternatively, the components maybe implemented in server and client applications. Further, these components may be linked together via various distributed programming protocols. Some example embodiments may include remote procedure calls being used to implement one or more of these components across a distributed programming environment. For example, a logic level may reside on a first computer system that is remotely located from a second computer system containing an interface level (e.g., a graphical user interface). These first and second computer systems can be configured in a server-client, peer-to-peer, or some other configuration. The clients can vary in complexity from mobile and handheld devices, to thin clients and on to thick clients or even other servers.
The above-illustrated software components are tangibly stored on a computer readable storage medium as instructions. The term “computer readable storage medium” should be taken to include a single medium or multiple media that stores one or more sets of instructions. The term “computer readable storage medium” should be taken to include any physical article that is capable of undergoing a set of physical changes to physically store, encode, or otherwise carry a set of instructions for execution by a computer system which causes the computer system to perform any of the methods or process steps described, represented, or illustrated herein. A computer readable storage medium may be a tangible computer readable storage medium. A computer readable storage medium may be a non-transitory computer readable storage medium. Examples of a non-transitory computer readable storage media include, but are not limited to: magnetic media, such as hard disks, floppy disks, and magnetic tape, optical media such as CD-ROMs, DVDs and holographic devices; magneto-optical media; and hardware devices that are specially configured to store and execute, such as application-specific integrated circuits (“ASICs”), programmable logic devices (“PLDs”) and ROM and RAM devices. Examples of computer readable instructions include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter. For example, an embodiment may be implemented using Java, C++, or other object-oriented programming language and development tools. Another embodiment may be implemented in hard-wired circuitry in place of, or in combination with machine readable software instructions.
A data source is an information resource. Data sources include sources of data that enable data storage and retrieval. Data sources may include databases, such as relational, transactional, hierarchical, multi-dimensional (e.g., OLAP), object oriented databases, and the like. Further data sources include tabular data (e.g., spreadsheets, delimited text files), data tagged with a markup language (e.g., XML data), transactional data, unstructured data (e.g., text files, screen scrapings), hierarchical data (e.g., data in a file system, XML data), files, a plurality of reports, and any other data source accessible through an established protocol, such as Open Data Base Connectivity (ODBC), produced by an underlying software system (e.g., ERP system), and the like. Data sources may also include a data source where the data is not tangibly stored or otherwise ephemeral such as data streams, broadcast data, and the like. These data sources can include associated data foundations, semantic layers, management systems, security systems and so on.
In the above description, numerous specific details are set forth to provide a thorough understanding of embodiments. One skilled in the relevant art will recognize, however that the embodiments can be practiced without one or more of the specific details or with other methods, components, techniques, etc. In other instances, well-known operations or structures are not shown or described in details.
Although the processes illustrated and described herein include series of steps, it will be appreciated that the different embodiments are not limited by the illustrated ordering of steps, as some steps may occur in different orders, some concurrently with other steps apart from that shown and described herein. In addition, not all illustrated steps may be required to implement a methodology in accordance with the one or more embodiments. Moreover, it will be appreciated that the processes may be implemented in association with the apparatus and systems illustrated and described herein as well as in association with other systems not illustrated.
The above descriptions and illustrations of embodiments, including what is described in the Abstract, is not intended to be exhaustive or to limit the one or more embodiments to the precise forms disclosed. While specific embodiments of, and examples for, the one or more embodiments are described herein for illustrative purposes, various equivalent modifications are possible within the scope, as those skilled in the relevant art will recognize. These modifications can be made in light of the above detailed description. Rather, the scope is to be determined by the following claims, which are to be interpreted in accordance with established doctrines of claim construction.