Automatic deployment of applications

Abstract

Embodiments generally relate to a method for automatically generating applications for multiple platforms based on one application code source. Embodiments include receiving a signal from a client device to initiate an application generation process, such as through a graphical user interface (GUI). In embodiments, the application generation process analyzes the application code to distinguish between core application code shared between many platforms and device-specific code, and then separates the core application code from the device-specific code. The core application code can then be deployed for use in multiple applications such as web applications, progressive web applications, or as a native mobile application when combined with device-specific code. Applications can be deployed with features that are automatically determined based on their deployment method and the feature set of each platform.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. patent application serial number 16 / 368,682 (ORACP0240 / ORA190138-US-NP), filed on March 28, 2019, and entitled “AUTO-DEPLOYMENT OF APPLICATIONS,” and U.S. provisional patent application serial number 62 / 743,420 (ORACP0240P / ORA190138-US-PSP), filed on October 9, 2018, and entitled “AUTO-DEPLOYMENT BETWEEN NATIVE MOBILEDEVICE, PROGRESSIVE WEB APPLICATIONS, AND WEB APPLICATIONS,” which are incorporated herein by reference for all purposes as if fully set forth in this application. Summary of the invention

[0003] Because consumers use many software platforms (e.g., mobile platforms, web platforms), companies often develop applications (often separate applications) for each platform. For example, companies often develop web applications that can be viewed on a computer browser or mobile phone browser that are separate from native mobile device applications. Further, native mobile device applications such as for the iOS platform will usually be developed separately from native mobile device applications for another application platform such as the ANDROID platform. Developing and maintaining separate applications for each of these platforms can be expensive and time-consuming.

[0004] Progressive web applications (PWAs) are a new type of application that is also developed and maintained by many companies. PWAs are web applications that have some features of native mobile applications, such as access to device permissions, push notifications, and home screen icons.

[0005] Software frameworks such as Cordova are available that allow developers to write code once and build native ANDROID, native iOS, PWA, and web applications based on this code. Doing so reduces development time because there is no need to maintain a separate code base for each platform. However, even with shared code, building and deploying applications for multiple platforms is still a manual, platform-specific process.

[0006] The embodiments described herein provide a method for automatically generating and deploying applications for different platforms (e.g., web, native iOS, native ANDROID, PWA) in response to an input signal, which may be a user-provided input or a signal generated from an automated pipeline.

[0007] Applications are deployed with features that are automatically determined based on their deployment method and the feature set of each platform. For example, if a web application can only obtain device location when the application is open, while a native mobile application can obtain device location both when the application is open and in the background, the deployed application will take into account the platform and such corresponding feature set. When a developer requests location tracking as a feature of their application, depending on the capabilities of the platform, the native mobile application will obtain location tracking when the app is active or in the background, while the web application will only obtain location tracking when the app is active. As in this example, features are automatically determined based on the deployment method and the platform's feature set without the need for further programming.

[0008] A further understanding of the nature and advantages of specific embodiments disclosed herein may be realized by reference to the remainder of the specification and the appended drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 A block diagram of an application generation environment on an example device is illustrated.

[0010] Figure 2 A block diagram of application code including core application code and device-specific code is illustrated.

[0011] Figure 3 A high-level flow chart showing an exemplary process for automatically generating an application is illustrated.

[0012] Figure 4 Illustrate a sample user interface developed for a mobile device.

[0013] Figure 5 An example user interface for managing configuration of device-specific code is illustrated.

[0014] Figure 6 Illustrate an example user interface for configuring iOS-specific build information.

[0015] Figure 7 Illustrated is an example user interface for configuring ANDROID-specific build information.

[0016] Figure 8 Illustrate an example user interface for configuring progressive web application specific build information.

[0017] Fig. 9 An example user interface for initiating an application rating process is illustrated.

[0018] Fig.10 Illustrate a sample user interface for configuring the deployment of an application to different platforms.

[0019] Fig.11 An example user interface for testing a rating application is illustrated.

[0020] Fig.12 A block diagram of an example system that may be used with implementations described herein is illustrated.

[0021] Fig.13 A block diagram of an example network environment is illustrated that may be used with implementations described herein. DETAILED DESCRIPTION

[0022] Embodiments generally relate to a method for automatically generating applications for multiple platforms based on one application code source. As described in more detail herein, one or more signals, such as from a client device, may be accepted to initiate an application generation process. During the application generation process, core application code that may be shared between all or some platforms may be determined and then isolated from device-specific code that may have been configured, such as by a developer or designer, etc. The core application code may then be deployed as an application such as a web application, a progressive web application, or when combined with device-specific code as a native mobile application, etc. The application may be deployed with features that are automatically determined based on factors such as its deployment method and the feature set of each platform.

[0023] The embodiments described herein provide a graphical user interface (GUI) that enables developers to define common requirements for applications that can be used in different platforms (e.g., web, native iOS, native ANDROID, PWA, etc.) in a convenient manner, and / or define device-specific requirements for applications to be deployed, and / or test applications that are automatically generated and deployed according to some embodiments.

[0024] Figure 1A block diagram of an application generation system 100 that can be used for the embodiments described herein, instantiated on an example device and platform, is illustrated. Shown are a client device 102, a web service 104, an ANDROID application 120, an iOS application 122, a progressive web application (PWA) 124, a web application 126, and a database 128 that can communicate with each other via a network 106. In various embodiments, the client device 102 can access services and data directly from the web service 104. In some embodiments, the client device 102 includes a form component 110 that is configured to generate a user interface (UI) component to receive input from one or more users. In some other embodiments, the client device 102 includes, for example, one or more GUIs for receiving input from one or more users, and the one or more GUIs may include a UI component generated by the form component 110.

[0025] The network 106 can also communicate with other client devices that can receive one or more generated applications. For example, ANDROID application 120, iOS application 122, and progressive web application 124 can be deployed to mobile devices, while web application 126 can be accessed by a desktop computer or laptop computer. Example implementations associated with application generation system 100 are described in more detail herein.

[0026] The application generation system 100 may be any type of computing system and / or data processing system, such as an enterprise computing environment, a client-server system, etc. The application generation system 100 may be configured to process data received from a user interface such as a keyboard, a mouse, etc., regarding processes such as determining and distinguishing code types, generation, configuration, modeling, tagging, data binding, maintenance, etc. associated with data elements, applications, information, etc. as described herein.

[0027] Note that application generation system 100 presents a specific example implementation in which computer code for implementing an embodiment may be implemented at least in part on a server. However, embodiments are not limited thereto. For example, a client-side software application hosted, for example, on client device 102 may provide application generation system 100 or portions thereof according to the present teachings without requiring communication between the client-side software application and the server.

[0028] In an exemplary embodiment, the application generation system 100 can be communicatively connected to a display configured to display data, for example, to its user. The display, screen, etc. as described herein can be a passive or active display suitable for allowing a user to view and interact with graphical data displayed thereon via a user interface. In other configurations, the display can be a touch screen display for interacting with its user and manipulating data by its user in response to touch, gestures, swipes, etc. Gestures can include single gestures, multi-touch gestures, and other combinations of gestures and user inputs suitable for allowing a user to determine and isolate code, generate applications, convert data, model, analyze, deploy patterns, maintain data, etc.

[0029] In some implementations, application generation system 100 may include a data source, such as database 128. As further described herein, database 128 may be one or more databases connected to application generation system 100 directly or indirectly, such as via network connection 106, and may be implemented as a non-transitory data structure stored on a computer-readable medium, such as a hard drive, solid-state drive (SSD), flash memory, etc., or may be stored as part of a cloud network.

[0030] The database 128 may include a data set 130. The data set 130 may include data as described herein. The data set 130 may also include data related to determining and distinguishing code, application deployment, application code, deployment mode, data attributes, data models, data structures, data hierarchies, node locations, values, value types, sums, visualizations, algorithms, code (e.g., C++, JSON, JavaScript, XSD, XML, etc.), sources, security, hashes, etc. In addition, the data set 130 may also include other data, data elements, and information, as well as information such as metadata, tags, development time information, runtime information, user configuration information, APIs, interface component information, library information, error threshold data, pointers, etc.

[0031] In an exemplary embodiment, the application generation system 100 can be adapted to receive data from the user interface and / or database 128 for processing. In one configuration, the application generation system 100 can be a software engine configured to receive and process input data (e.g., application deployment parameters) from its user and related to the data received from the user interface and / or database 128 in order to check the code, distinguish between code types, deploy and verify the deployed application relative to the deployment mode and error threshold. For example, during application deployment, the application generation system 100 can identify core application code and device-specific code relative to data attributes and / or factors such as differentiation and deployment criteria, feature sets of the receiving platform, type of application, etc.

[0032] In addition, the application generation system 100 can be used to determine whether errors in the deployed application are within acceptable thresholds, levels, etc., wherein some deployment error thresholds can be set for benign errors and / or for other types of errors acceptable to users and / or the system, thereby providing adjustable application deployment tolerances.

[0033] For example, the application generation system 100 may allow deployment of applications with acceptable error threshold levels, such as certain types of errors, acceptable errors, UI errors, software code errors, reference errors, etc. The application generation system 100 may also be configured to correct and resolve such errors in real time, for example, by using techniques such as code comparison, resolving references, assigning target "QNames", specifying relative routes, etc., recursively, with or without warnings to its users.

[0034] For example, in other embodiments, the application generation system 100 can be configured as a data analysis tool for performing analysis functions associated with data received from a user. Such analysis functions can include using analysis of code attributes and / or other factors to determine and distinguish between core application code and device-specific code. The analysis can also include determining attributes associated with the data, determining data types, types of deployment modes required, determining data values, data types, determining relationships with other data, interpreting metadata associated with the data, determining error types, tolerance data, etc.

[0035] For example, the application generation system 100 can be configured to receive and analyze properties of the data set 130 to determine core application code component requirements, thereby determining device-specific code requirements, web application values, progressive application values, key / value pairs, string identifiers, data characteristics, error types, tolerance levels, schema types, user interface configurations, definitions, data processing instructions, data attributes, data hierarchies, nodes, node positions within the hierarchy, values, data types, sums, algorithms, sources, security, hashes, etc. associated with the data set 130.

[0036] The application generation system 100 may receive an existing data set 130 from a database 128 for processing. Such a data set 130 may include and represent a composite of individual data sets 130 and data elements related to, for example, organizational data, which may include data such as occupational data, salary data, personal data, etc. In addition, the data set 130 may include other types of data, data elements, and information, such as contact data, sales data, product data, scientific data, financial data, medical data, census data, etc.

[0037] The application generation system 100 may be configured to receive configuration data related to the data, the associated data sets 130, and other data associated with the data for presenting the data on a display, such as user interface components, icons, user pointing device signals, etc. In an exemplary embodiment, the application generation system 100 may be configured to present 2D and 3D graphical models and simulations to allow a user to obtain more information about the data sets 130 associated with the data. In one embodiment, upon receiving instructions from a user, such as through a user interface, a portion of the application generation system 100 may be configured to generate a real-time display of interactive changes to the data selected by its user.

[0038] Figure 2 A block diagram 200 of application code 202 is shown, which includes core application code 204 and device-specific code 206. The core application code 204 can be determined by the web service 104 and then isolated from the device-specific code 206 to generate an application such as a progressive web application 124, a web application 126, etc. In other embodiments, the core application code 304 and the device-specific code 306 can be used together to generate other types of applications such as native mobile applications, embedded applications, application programming interface (API) applications, etc., which in some embodiments can be, for example, ANDROID applications 120, iOS applications 122, etc.

[0039] In an embodiment, the application generation system 100 can be configured to determine what is the core application code 204 and the device-specific code 206 or a combination thereof. For example, the application generation system 100 can be configured to analyze the application code and determine whether the analyzed code is the core application code 204, the device-specific code 206, or other types of code based on attributes, data, and other inputs such as metadata, code values, code attributes, flags, the type of code used (e.g., JavaScript, C++, etc.). In this configuration, the application generation system 100 can be used to learn and store the differences between code types to improve processor efficiency when processing application code.

[0040] The core application code 204 may be code that is represented as the "core" of a particular application, which may then be used as a base for building code source code. In other embodiments, the core application code 204 may be defined as "core" via a data standard. In this context, a user (such as a developer) may mark and / or define which portions of the code are "core" and which may or may not be critical operating code elements. For example, a developer may provide information to the application generation system 100 that specifies that code written by a particular entity, group, etc. is considered to be the "core" of an application, or may specify that "core" means code that must be used in every instance of a deployed application, or code that is critical to a particular user, etc.

[0041] Device-specific code 206 may be code designed for a specific device platform, such as iOS, ANDROID, etc. Device-specific code 206 may also be code developed for a specific platform, taking into account specific standards related to the operation of the platform. For example, for a mobile platform, device-specific code 206 may be code required for a specific mobile device. Thus, device-specific code 206 may be code designed to operate on a specific device or a class of specific devices.

[0042] In other embodiments, such core application code 204 and device-specific code 206 may be determined and divided based on other factors such as processor efficiency, load time, feature set, etc. For example, core application code 204 may be considered a subset of application code that may be employed by an application in order to use fewer processor resources, reduce load time, implement a reduced feature set, emphasize or deemphasize graphics, focus or de-focus on specific processing tasks, set up power-up and power-down sequences, etc.

[0043] Figure 3An example high-level flow diagram of an application generation process 300 is illustrated. At 302, a system such as a client device 102 may obtain developer-provided input from, for example, a form component 110, which provides a GUI, etc., to accept the input. At 304, the client device 102 may then use a web service 104 to isolate the core application code 204 from the device-specific code 206 over a network 106. At 306, 308, and 310, the application generation process 300 may employ an application deployment channel such as a web service 104 to deploy the application to one or more platforms. For example, the application generation process 300 may deploy an ANDROID application 120, an iOS application 122, or a progressive web application 124 to a mobile device, or it may deploy a web application 126.

[0044] In some implementations, process 300 accepts one or more signals to initiate an application generation process at 302. For example, a user may input a signal via a UI input to initiate generation of an application for use on one or more platforms, such as a Web application 126, an ANDROID application 120, an iOS application 122, or a progressive Web application 124 to a mobile device, etc.

[0045] At 304, the process 300 isolates or separates the core application code 204 from the device-specific code 206. For example, as described above, the process 300 can analyze a variety of attributes and / or other criteria to determine what code is the core application code 204 and the device-specific code 206. This analysis may or may not require user input, as the process 300 can be configured to discern the difference between the two types of code by analyzing code operations, code attributes, code types, code identifiers, introspection, metadata, flags, markers, etc. Once the process 300 has determined which code is the core application code 204 and which code is the device-specific code 206, the process 300 can mark the two types of code with different identifiers and / or store the two types of code in order to isolate or separate the core application code 204 from the device-specific code 206.

[0046] In some scenarios, the core application code 204 and the device-specific code 206 may be a subset of code that may be deployed across a variety of different platforms. In some implementations, such core application code 204 and device-specific code 206 may be configured to allow such receiving platforms to operate within one or more acceptable error tolerance thresholds. For example, the core application code 204 may be a subset of code that causes different amounts of errors that are acceptable relative to the error tolerance thresholds of the receiving platform.

[0047] At 306, the process 300 deploys the core application code 204 as a web application. In some scenarios, such core application code 204 for a web application may be different relative to other types of applications. For example, the core application code 204 for a web application may be a subset of the core application code 204 obtained from 304. Thus, in such a scenario, the core application code 204 may be adapted for a particular deployment. Further, such a process 300 may enable and / or disable portions of the code as needed to allow a particular set of core application code 204 to be deployed across a variety of platforms.

[0048] At 308, the process 300 deploys the core application code 204 as a progressive web application. In some scenarios, such core application code 204 for a progressive web application may be different relative to other types of applications. For example, the core application code 204 for a progressive web application may be a subset of the core application code obtained from 304. Thus, in such a scenario, the core application code 204 may be adapted for a particular web application deployment. Further, such a process 300 may enable and / or disable portions of the code as needed to allow a particular set of core application code 204 to be deployed across numerous web application platforms. In other scenarios, the core application code 204 is a subset of the code that may be deployed between a variety of different web application platforms.

[0049] At 310, the process 300 deploys the core application code 204 and the device-specific code 206 as a native mobile application. In an exemplary scenario, such core application code 204 and device-specific code 206 for a native mobile application may be different relative to other types of applications. For example, the core application code 204 of the native mobile application may be a subset of the core application code 204 and device-specific code 206 obtained from 304. Thus, in this scenario, the core application code 204 may be suitable for a specific native mobile application deployment. Further, such a process 300 may enable and / or disable a portion of the code as needed to allow a specific set of core application code 204 and device-specific code to be deployed across numerous platforms. In other scenarios, the core application code 204 may be a subset of code that can be deployed between various different native mobile application platforms.

[0050] Figure 4 is an example user interface for mobile development. On display screen 400, users (e.g., developers) can specify the layout and functionality of their applications independently of the platform through a GUI or the like. For example, a developer can configure an application to have the ability to take photos or use GPS for location tracking. The application can also be configured with visual layout items such as charts or loading icons.

[0051] In an embodiment, screen 400 may include a resource interface 402 configured to accept user input for configuring a mobile application, a mobile screen layout tool 404, and a reporting tool 406. Resource interface 402 provides a user with a resource tool 408 configured to provide a user with tools (such as application flows, application resources, root pages, etc.) for allowing the user to develop a mobile application, as well as other tools, such as tools for setting error threshold levels, tools for defining certain types of errors, acceptable errors, reference errors, etc.

[0052] Mobile screen layout tools 408 may include a chart development tool 410, a measurement tool 412, a customization tool 414, and a mobile application simulation tool 416. In an embodiment, chart development tool 410 may be configured to display pre-designed charts for user selection. Measurement tool 412 may be configured to provide the user with a plurality of measurement instruments for display on screen 400. Customization tool 412 may be configured with customization tools for allowing the user to customize the display and functionality of screen 400.

[0053] Mobile application simulation tool 416 can be used to simulate the selection results of UI elements and functions. For example, in this scenario, the simulated mobile phone 418 displays the selected chart 420, graph 422, and chat function 424.

[0054] In an embodiment, the reporting tool 406 provides the user with control over properties such as visual reporting properties 426 and general properties 428. For example, the visual reporting properties may allow the user to define properties such as reporting properties. The general properties 428 may allow the user to define properties such as access key properties, access key labels, categories, etc.

[0055] Figure 5 is an example user interface 500 for managing configuration of device-specific code (e.g., build profiles). Interface 500 includes a build window 502 that is configured to allow a user to configure various aspects of an application build, such as configuration settings, setting a build profile, etc. For example, for each deployed native mobile application, a build profile 504 may be configured using build window 502.

[0056] When button 506 is selected in screen 500, a user (e.g., a developer) may be navigated to another screen where, for example, Figure 6 and Figure 7 Specify build characteristics for an application, such as a native mobile application, as shown in .

[0057] Figure 6 An example user interface screen 600 for specifying iOS specific build information is shown. Although specific platform features such as hardware or operating system options can be discussed, the features of the embodiments can be used with any suitable platform or platform features. UI screen 600 may include multiple inputs for selecting and / or inputting options to specify all device-specific information of an iOS application. For example, a developer may have options for specifying a build profile name 602, a build type 604, a package identifier 606, a package version name 608 and a package version 610, a developer certificate 612, an authorization file 616, a signing identity 618, etc. In some embodiments, UI screen 600 may include UI widgets such as a check box 620 to set a specific build as a default build for grading and / or publishing applications.

[0058] Figure 7An example user interface screen 700 for specifying ANDROID specific build information is shown. Screen 700 may include options for specifying all device-specific information for an application, such as an ANDROID application. For example, a user (e.g., a developer) may have options for specifying a build configuration file name 602, a build type 604, an application identifier 702, an application version name 704, a version code 706, a developer keystore 708, a keystore password 710, a key alias 712, a key password 714, and the like.

[0059] Figure 8 An example user interface screen 800 for specifying progressive web application specific build information is shown. UI screen 800 may include a progressive web application build UI interface 802, which may include, for example, options for specifying an application name 804, an abbreviation 806, a description 808, a theme color 810, an application icon 810, a file cache mode 812, and the like.

[0060] Fig. 9 An example user interface screen 900 is shown for starting the application staging process once the device-specific information is configured. In screen 900, the user interface may have a button 902 for navigating to the deployment screen, such as Fig.10 As shown. The terms "staged" and "deployed" may be used interchangeably herein. In an embodiment, UI screen 900 may also include a stage identifier 904 for indicating which applications are being staged for deployment.

[0061] Fig.10 1000 is an example user interface screen 1000 for configuring the deployment of an application to different platforms. In screen 1000, a user (e.g., a developer) can specify an application URL for a web application in field 1002. The user can also configure progressive web application settings 1004, which can include, for example, setting up offline caching, notifications, and specifying a name and icon associated with the application. In addition, the user can configure native mobile application settings 1006, including setting up multiple application builds such as an iOS build and an ANDROID build. For example, native mobile application settings 1006 may include options for setting permissions, certificates, etc., as well as enabling features such as GPS tracking and notifications, specifying a name and icon associated with the application, etc.

[0062] Fig.11An example user interface screen 1100 for testing a hierarchical application is shown. In screen 1100, a user (e.g., a developer) can test a hierarchical application in a UI interface such as a browser by installing the hierarchical application on a phone using a QR code, etc. In one embodiment, screen 1100 may include a build application tool 1102 configured to build an application based on various build inputs received, such as from the inputs described herein, and then generate application generation instructions 1104 (e.g., a QR code) that, when launched, generate an application on a host device 1106 (e.g., a mobile phone).

[0063] Fig.12 A block diagram of an example system 1200 that can be used for the embodiments described herein is illustrated. The example system 1200 can support or run various hardware modules and / or software modules and their associated methods discussed with reference to the embodiments described herein. Note that some embodiments can be implemented using one or more independent applications (e.g., resident in a user device) and / or one or more web-based applications implemented using a combination of client-side code and server-side code. Although the system 1200 performs the embodiments described herein, in other embodiments, any suitable component or combination of components associated with the system 1200 or any suitable one or more processors associated with the system 1200 can facilitate the execution of the embodiments described herein. In various embodiments, the system 1200 may not have all the components shown and / or may have other elements, which include components of other types that replace or are in addition to those components shown herein.

[0064] The general system 1200 includes user devices 1260 to 1290, including one or more desktop computers 1260, one or more notebook computers 1270, one or more smart phones 1280, one or more mobile phones 1285, and one or more tablet computers 1290. The general system 1200 can interface with any type of user device capable of displaying and navigating web pages or other types of electronic documents and UIs, and / or executing applications, such as a thin client computer, an Internet-enabled mobile phone, a mobile Internet access device, a tablet computer, an e-book, or a personal digital assistant. Although the system 1200 is shown with five user devices, any number of user devices can be supported.

[0065] Web server 1210 is used to process requests from web browsers and independent applications for web pages, electronic documents, enterprise data or other content, and other data from user computers. Web server 1210 can also provide push data or comprehensive content related to enterprise operations, such as RSS subscription feeds.

[0066] The application server 1220 operates one or more application programs. The application program can be implemented as one or more scripts or programs written in any programming language or any scripting language, such as Java, C, C++, C#, such as JavaScript or European Computer Manufacturers Association Script (ECMAScript), Perl, Hypertext Preprocessor (PHP), Python, Ruby, or Tool Command Language (TCL). Application programs can be built using libraries or application frameworks such as Rails, Enterprise JavaBeans, or .NET. Web content can be created using Hypertext Markup Language (HTML), Cascading Style Sheets (CSS), and other web technologies (including template languages ​​and parsers).

[0067] The data application running on the application server 1220 is suitable for processing input data and user computer requests, and can store or retrieve data from the data storage device or database 1230. The database 1230 stores data created and used by the data application. In some embodiments, the database 1230 includes a relational database suitable for storing, updating, and retrieving data in response to SQL format commands or other database query languages. Other embodiments may use unstructured data storage architectures and non-relational (NoSQL) databases.

[0068] In some implementations, the application server 1220 includes one or more general-purpose computers capable of executing programs or scripts. In some implementations, the web server 1210 is implemented as an application running on one or more general-purpose computers. The web server 1210 and the application server 1220 can be combined and executed on the same computer.

[0069] The electronic communication network 1240-1250 enables communication between user computers 1260-1290, web server 1210, application server 1220, and database 1230. In some embodiments, the network 1240-1250 may further include any form of electrical or optical communication equipment, including wired network 1240 and wireless network 1250. The network 1240-1250 may also combine one or more local area networks (such as Ethernet), wide area networks (such as the Internet, cellular carrier data networks), and virtual networks (such as virtual private networks).

[0070] System 1200 is an example of a system for executing an application according to some embodiments. In some embodiments, application server 1210, web server 1220, and database 1230 (optionally) can be combined into an application and system of a single server computer. In further embodiments, virtualized applications and virtual machine applications can be used to implement one or more of application server 1210, web server 1220, and database 1230.

[0071] In a further embodiment, all or part of the web service functions and application service functions can be integrated into the application running on each user's computer. For example, a JavaScript application on a user's computer can be used to obtain or analyze data and display a part of the application.

[0072] In various implementations, system 1200 may not have all of the components shown and / or may have other elements including other types of components instead of or in addition to those shown herein.

[0073] Fig.13 1300 is a general block diagram of a computing device 1300 that can be used to implement the embodiments described herein. As an example, the computing device 1300 can be configured to implement the following Figure 3 Alternatively or additionally, the computing device 1300 may be configured to implement at least a portion of the application generation process 300 shown. Figures 4 to 11 At least a portion of the user interface shown. Fig.13 The computing device 1300 may be described as performing one or more steps in the embodiments herein, but in other embodiments, any suitable component or combination of components of the computing device 1300 or any suitable one or more processors associated with the system 1300 may facilitate performance of the steps.

[0074] Fig.13A block diagram of an example computing system 1300 that can be used with the implementations described herein is shown. For example, the computing system 1300 can be used to implement Fig.12 The user devices 1260 to 1290 and server devices 1210, 1220 of the present invention are used to perform the method implementation described herein. In some embodiments, the computing system 1300 may include a processor 1302, an operating system 1304, a memory 1306, and an input / output (I / O) interface 1308. In various embodiments, the processor 1302 can be used to implement the various functions and features described herein, and to perform the method implementation described herein. Although the processor 1302 is described as performing the implementation described herein, any suitable component or combination of components of the system 1300 or any suitable one or more processors associated with the system 1300 or any suitable system can perform the steps. The implementation described herein can be performed on a user device, a server, or a combination of the two.

[0075] The computing device 1300 also includes software applications 1310, which may be stored in the memory 1306 or any other suitable storage location or computer-readable medium. The software applications 1310 provide instructions that enable the processor 1302 to perform the functions described herein and other functions. The components of the computing system 1300 may be implemented by one or more processors, or any combination of hardware devices, and any combination of hardware, software, firmware, etc.

[0076] For ease of explanation, Fig.13 A block is shown for each of the processor 1302, operating system 1304, memory 1306, I / O interface 1308, and software application 1310. These blocks 1302, 1304, 1306, 1308, and 1310 may represent multiple processors, operating systems, memories, I / O interfaces, and software applications. In various implementations, the computing system 1300 may not have all of the components shown and / or may have other elements, including other types of components instead of or in addition to those shown herein.

[0077] Although the specification has been described with respect to specific embodiments thereof, these specific embodiments are merely illustrative and not restrictive.

[0078] Any suitable programming language can be used to implement the routine of specific embodiment, and the programming language includes C, C++, Java, assembly language, etc. Different programming techniques such as programming or object-oriented can be adopted. The routine can be performed on a single processing device or multiple processors. Although these steps, operations or calculations may be presented in a specific order, this order can be changed in different specific embodiments. In some specific embodiments, multiple steps shown in order in this specification can be performed simultaneously.

[0079] Particular embodiments may be implemented in a non-transitory processor-readable storage device for use with or in conjunction with an instruction execution system, apparatus, system, computer, or device. Particular embodiments may be implemented in software or hardware, or a combination of both, in the form of control logic. The control logic may be operable when executed by one or more processors to perform the content described in the particular embodiments. For example, a tangible medium such as a hardware storage device may be used to store control logic that may include executable instructions.

[0080] Particular embodiments may be implemented using a programmed general-purpose digital computer, by using application-specific integrated circuits, programmable logic devices, field programmable gate arrays, optical systems, chemical systems, biological systems, quantum systems, or nanoengineered systems, etc. Other components and mechanisms may be used. In general, the functionality of a particular embodiment may be implemented by any means known in the art. Distributed networked systems, components, and / or circuits may be used. Cloud computing or cloud services may be employed. The communication or transmission of data may be wired, wireless, or by any other means.

[0081] It should also be understood that, as is useful depending on the particular application, one or more of the elements depicted in the drawings / figures may also be implemented in a more separate or integrated manner, or even removed or rendered inoperable in some cases. It is also within the spirit and scope of the present application to implement a program or code that can be stored in a machine-readable medium to allow a computer to perform any of the above methods.

[0082] "Processor" includes any suitable hardware and / or software system, mechanism or component that processes data, signals or other information. The processor may include a system with a general-purpose central processing unit, multiple processing units, a dedicated circuit for implementing the function, or other systems. Processing does not have to be limited to a geographic location or have time constraints. For example, the processor can perform its functions in "real time", "offline", in "batch mode", etc. Part of the processing can be performed at different times and different locations by different (or the same) processing systems. Examples of processing systems may include servers, clients, end-user devices, routers, switches, networked storage devices, etc. A computer can be any processor that communicates with a memory. The memory can be any suitable processor-readable storage medium, such as a random access memory (RAM), a read-only memory (ROM), a disk or optical disk, or other tangible media suitable for storing instructions executed by a processor.

[0083] As used in the specification herein and throughout the claims that follow, “a,” “an,” and “the” include plural referents unless the context clearly dictates otherwise. Likewise, as used in the specification herein and throughout the claims that follow, the meaning of “in” includes “in” and “on” unless the context clearly dictates otherwise.

[0084] Therefore, although specific embodiments have been described herein, a certain range of modifications, various changes and substitutions are intended in the foregoing disclosure, and it should be understood that in some instances, some features of specific embodiments may be employed without corresponding use of other features without departing from the scope and spirit as previously described. Therefore, many modifications may be made to adapt a particular situation or material to the basic scope and spirit.

Claims

1. A method for automatically generating and deploying an application, the method comprising: Receives a signal to start the application generation process; receiving application code for analysis; examining properties of the application code to determine core application code and device-specific code, wherein the core application code is code that can be shared between platforms, and wherein the device-specific code is at least one of: code designed for a specific device platform, code developed for a specific platform and taking into account specific standards related to operation of the platform, code required for a specific mobile device, or code designed to operate on a specific device or a specific class of devices; Isolate core application code from device-specific code; as well as An application is deployed on a specific platform, the deployed application using at least a subset of the core application code appropriate for the deployment.

2. The method of claim 1, wherein: The application is deployed with characteristics that are automatically determined based on its deployment method and the feature set of each platform.

3. The method of claim 1, wherein: Checking the properties of the application code further includes determining a subset of the core application code to be deployed as a web application based on the properties of the application code.

4. The method of claim 1, wherein: Examining the properties of the application code further includes determining a subset of the core application code to be deployed as a progressive web application based on the properties of the application code.

5. The method of claim 1, wherein: Examining the properties of the application code further includes determining a subset of the core application code and a subset of the device-specific code to be deployed as a native mobile application based on the properties of the application code.

6. The method of claim 1, further comprising: Core application code requirements of at least one platform are analyzed to determine whether the core application code will run within at least one acceptable fault tolerance threshold on the platform.

7. The method of claim 1, further comprising: Core application code requirements of at least one platform are analyzed to determine whether the device-specific code will run within at least one acceptable error tolerance threshold on the platform.

8. The method of claim 1, further comprising: Core application code requirements of at least two platforms are analyzed to determine a subset of core application code that is acceptable for use on the at least two platforms within at least one acceptable fault tolerance threshold for each of the at least two platforms.

9. The method of claim 1, further comprising: Core application code requirements of at least one platform are analyzed to determine a subset of core application code acceptable for use on the at least one platform within at least one acceptable processor efficiency level for the at least one platform.

10. The method of claim 1, further comprising: Device-specific code requirements of at least one platform are analyzed to determine a subset of device-specific code that is acceptable for use on the at least one platform within at least one acceptable processor efficiency level for the at least one platform.

11. A non-transitory computer-readable medium comprising one or more instructions executable by one or more processors to: Receives a signal to start the application generation process; receiving application code for analysis; examining properties of the application code to determine core application code and device-specific code, wherein the core application code is code that can be shared between platforms, and wherein the device-specific code is at least one of: code designed for a specific device platform, code developed for a specific platform and taking into account specific standards related to operation of the platform, code required for a specific mobile device, or code designed to operate on a specific device or a specific class of devices; Isolate core application code from device-specific code; and An application is deployed on a specific platform, the deployed application using at least a subset of the core application code appropriate for the deployment.

12. The non-transitory computer readable medium of claim 11, wherein: The application is deployed with characteristics that are automatically determined based on its deployment method and the feature set of each platform.

13. The non-transitory computer readable medium of claim 11, wherein: Checking the properties of the application code further includes determining a subset of the core application code to be deployed as a web application based on the properties of the application code.

14. The non-transitory computer readable medium of claim 11, wherein: Examining the properties of the application code further includes determining a subset of the core application code to be deployed as a progressive web application based on the properties of the application code.

15. The non-transitory computer readable medium of claim 11, wherein: Examining the properties of the application code further includes determining a subset of the core application code and a subset of the device-specific code to be deployed as a native mobile application based on the properties of the application code.

16. The non-transitory computer readable medium of claim 11, further comprising: Core application code requirements of at least one platform are analyzed to determine whether the core application code will run within at least one acceptable fault tolerance threshold on the platform.

17. The non-transitory computer readable medium of claim 11, further comprising: Device-specific code requirements of at least one platform are analyzed to determine whether the device-specific code will run within at least one acceptable error tolerance threshold on the platform.

18. The non-transitory computer readable medium of claim 11, further comprising: Core application code requirements of at least two platforms are analyzed to determine a subset of core application code that is acceptable for use on the at least two platforms within at least one acceptable fault tolerance threshold for each of the at least two platforms.

19. The non-transitory computer readable medium of claim 11, further comprising: Core application code requirements of at least one platform are analyzed to determine a subset of core application code that is acceptable for use on the at least one platform within an acceptable processor efficiency level for the at least one platform.

20. An apparatus for generating and deploying an application in a computing environment, the computing environment comprising one or more computing devices in communication with an application generation system executing software, the software being configured to generate and deploy an application accessible to the one or more computing devices, a computing device in the one or more computing devices being configured to perform the following steps: Receives a signal to start the application generation process; receiving application code for analysis; examining properties of the application code to determine core application code and device-specific code, wherein the core application code is code that can be shared between platforms, and wherein the device-specific code is at least one of: code designed for a specific device platform, code developed for a specific platform and taking into account specific standards related to operation of the platform, code required for a specific mobile device, or code designed to operate on a specific device or a specific class of devices; Isolate core application code from device-specific code; and An application is deployed on a specific platform, the deployed application using at least a subset of the core application code appropriate for the deployment.

21. A computing device comprising: one or more processors; as well as A display screen coupled to the one or more processors, wherein the one or more processors execute instructions to cause the display screen to display a graphical user interface (GUI), the graphical user interface comprising: a first GUI configured to enable a user to specify a layout and functionality of an application to be generated that is platform independent; a second GUI configured to enable the user to configure device-specific information; and a third GUI comprising a first UI component configured to enable the user to deploy the application in different platforms, wherein the application is generated based on at least the specified layout and functionality and the device-specific information, wherein: generating application code based on information specified in the first GUI and configured in the second GUI, examining properties of the application code to determine core application code and device-specific code, wherein the core application code is code that can be shared between platforms, and wherein the device-specific code is at least one of: code designed for a specific device platform, code developed for a specific platform and taking into account specific standards related to operation of the platform, code required for a specific mobile device, or code designed to operate on a specific device or a specific class of devices; isolating the core application code from the device-specific code; and The application is deployed with characteristics that are automatically determined based on its deployment method and the feature set of each platform.

22. The computing device of claim 21, wherein: A subset of the core application code to be deployed is determined to be a web application based on properties of the application code.

23. The computing device of claim 21, wherein: The subset of core application code to be deployed is determined to be a progressive web application based on properties of the application code.

24. The computing device of claim 21, wherein: A subset of the core application code and a subset of the device-specific code to be deployed are determined to be native mobile applications based on properties of the application code.

25. The computing device of claim 21, wherein: Core application code requirements of at least one platform are analyzed to determine whether the core application code will run within at least one acceptable fault tolerance threshold on the platform.

26. The computing device of claim 21, wherein: Device-specific code requirements of at least one platform are analyzed to determine whether the device-specific code will run within at least one acceptable error tolerance threshold on the platform.

27. The computing device of claim 21, wherein: Core application code requirements of at least two platforms are analyzed to determine a subset of core application code that is acceptable for use on the at least two platforms within at least one acceptable fault tolerance threshold for each of the at least two platforms.

28. The computing device of claim 21, wherein: Core application code requirements of at least one platform are analyzed to determine a subset of core application code that is acceptable for use on the at least one platform within an acceptable processor efficiency level for the at least one platform.

29. The computing device of claim 21, wherein: Core application code requirements of at least one platform are analyzed to determine a subset of device-specific application code that is acceptable for use on the at least one platform within an acceptable processor efficiency level for the at least one platform.

30. The computing device of claim 21, wherein: The third GUI further includes a second UI component for enabling the user to initiate an application generation process to generate an application for a different platform; and Among them, the automatically generated and deployed applications are further tested for different platforms.

Images