A typical application comprises a User Interface (UI) enabling a user to operate the application, for example enter data, receive results, or the like, a database for storing data related to the application, and one or more business logic modules (also referred to as “logic”) for operating on the data in accordance with the user's instructions, including retrieving, modifying, storing, or deleting data.
In older architectures, sometimes referred to as “first generation”, an application executed by a mobile device was a stand-alone application, in which all components, including the UI, logic and database were local and compatible with the device and its operating system. In such architectures, the application was not and did not have to be in any type of communication with a server platform during execution.
In some exemplary embodiments, while the application itself may be fully stored on and executed by the mobile device, it may contact an external source such as a server for obtaining updated data, such as weather data, stock quotes, or the like.
In more modern architectures, sometimes referred to as “generation1.5”, the UI components resided on and were compatible with the mobile device, but the database and often also the business logic were provided by a web server, such that the application had to be in ongoing communication with the server for proper operation. In these architectures, the application communicated with a predetermined server, and proprietary data types may have been exchanged between the mobile device and the server.
In more modern architectures, supported for example by current “application stores”, sometimes referred to as “second generation”, the UI is still executed by the mobile device and the logic and database reside on a web server, but a single server can serve a multiplicity of UI types, each compatible with a mobile device or type of an operating system. This is similar to the classic web-based service architecture, wherein the main difference between the “second generation” and the “generation 1.5” architectures is that in the “second generation” each server can serve a multiplicity of different applications.
In all the above-mentioned architectures, the process of developing, distributing and executing applications suffers from three main problematic areas: developing the application, which requires design and programming stages; marketing and distributing the application; and updating the application and providing users with new versions without bothering the user.
Current solutions comprise application generation tools or environments, and continue by directing the developers to application stores or markets such as AppStore™ for distributing the application. The mobile device may be configured to contact the application store to check for updates for installed applications, and if any such update is found, the device overwrites the previous version with the updated one.