WO2013091672A1 - Verfahren zur erzeugung von ausführbarem code - Google Patents

Verfahren zur erzeugung von ausführbarem code Download PDF

Info

Publication number
WO2013091672A1
WO2013091672A1 PCT/EP2011/006560 EP2011006560W WO2013091672A1 WO 2013091672 A1 WO2013091672 A1 WO 2013091672A1 EP 2011006560 W EP2011006560 W EP 2011006560W WO 2013091672 A1 WO2013091672 A1 WO 2013091672A1
Authority
WO
WIPO (PCT)
Prior art keywords
unit
data
executable code
operator
code
Prior art date
Application number
PCT/EP2011/006560
Other languages
English (en)
French (fr)
Inventor
Philipp FAISST
Igor ERIK
Original Assignee
Paade Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Paade Gmbh filed Critical Paade Gmbh
Priority to US14/367,279 priority Critical patent/US20150033203A1/en
Priority to PCT/EP2011/006560 priority patent/WO2013091672A1/de
Priority to EP12826617.8A priority patent/EP3245586A1/de
Priority to EP12821112.5A priority patent/EP2828744B1/de
Priority to US14/367,384 priority patent/US20150052361A1/en
Priority to PCT/DE2012/100399 priority patent/WO2013110254A1/de
Priority to PCT/DE2012/100398 priority patent/WO2013110253A1/de
Priority to US14/366,763 priority patent/US10050839B2/en
Publication of WO2013091672A1 publication Critical patent/WO2013091672A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/34—Graphical or visual programming

Definitions

  • the invention relates to a method for generating executable code according to claim 1.
  • the invention relates to a method for generating executable code, which is intended to be executed on a mobile terminal, with at least one appbuilder unit having at least one memory unit in which at least one basic code is stored, at least one input module and at least a creation module, wherein in a first process section via the input module by an operator desired functions and / or data are entered and embedded in a later process section, the creation module at least a portion of the desired functions and / or data in the basic code.
  • executable code is intended in particular a in a package, in particular a file written sequence of data-processing instructions, in particular assembler and / or machine code to be understood, which are intended to run an at least semi-automatic ⁇ ULTRASONIC program.
  • the packet and / or the instructions to certain conditions, in particular to a processor to be used, which in particular works with the RISC instruction set and / or a further development thereof and / or whose architecture is based on ARM technology, and / or to an operating system in which the executable code is - -
  • a “mobile terminal” should in particular be understood to mean a terminal with a weight of less than 2 kg, in particular less than 1 kg, advantageously less than 500 g, preferably less than 200 g.
  • the mobile terminal has at least one touch-sensitive, in particular capacitive, resistive and / or inductive, display which serves as an operator interface, in particular the mobile terminal is a mobile phone, in particular a smartphone, or a tablet
  • the mobile terminal has at least one communication interface, in particular at least one GPRS, EDGE, UMTS and / or W-LAN interface,
  • the mobile terminal has at least one position sensor, in particular a GPS receiver,
  • the mobile terminal at least one acceleration sensor.
  • the mobile terminal has at least one video, photo and / or audio recording unit.
  • the mobile terminal preferably has at least one, for mobile purposes, in particular with regard to a display on displays with a screen diagonal of less than 20 cm, advantageously less than 15 cm and / or with regard to an operation by touch display, optimized operating system, for example iOS, Android, Windows Phone and / or Blackberry OS on.
  • An "appbuild unit” is to be understood to mean in particular an at least semi-automatic unit.
  • An appbuilder unit preferably has at least one arithmetic unit, at least one memory unit and at least one operating program stored in the memory unit, which is intended to be executed by the arithmetic unit
  • the memory unit and the arithmetic unit are integrated in a data processing system, in particular a PC, preferably a server
  • the memory unit and the arithmetic unit are connected to one another via a network connection, in particular integrated into different data processing systems
  • Storage unit is to be understood in particular a unit which is intended to store data, in particular digitally, preferably non-volatile.
  • the storage unit is preferably formed by at least one hard disk, in particular SSD.
  • a “basic code” is to be understood as meaning, in particular, an incomplete program code present in a, preferably object-oriented, programming language, in particular a high-level language, for example object c, java, C * +, Visual Basic, or Comparable Code module which is provided to provide a connection to input and / or output functions, in particular GPS functions, display functions, communication functions, vibration functions, sensor functions, image and / or sound recording functions, of the mobile terminal the first code module is provided for accessing interfaces provided by the operating system of the mobile terminal.
  • the basic code has at least one second code module which is provided to provide a connection possibility with a database unit.
  • An "input module” is to be understood in particular as an interface between the operator and the appbuilder unit.
  • Embedding of functions and / or data into the basic code should in particular mean that the functions, in particular a map display, of GPS information, a database access and / or other conceivable functions, associated code modules are integrated into the basic code at a suitable location or the data, in particular ⁇ special graphics data and / or content data stored in a memory area of the basic code are the.
  • the modified by integration preferably present in a high level language, basic code, converted after the embedding, by the Clearellmodul in assembly and / or Ma ⁇ schin code, particularly compiled.
  • a simple possibility can be provided to generate at least one executable code.
  • the input module is operated remotely.
  • Operation via “remote access” should be understood to mean, in particular, an operation via a network interface, in particular via at least one telecommunication line, in particular DSL, ISDN or similar.
  • the appbuilder unit has at least one network interface at least the Internet, at least temporarily, in particular at least 80%, advantageously at least 95%, preferably at least 99% of a day, a month and / or a year.
  • the Appbuilder unit offers a Web interface to which the operator access via the Internet
  • the operator need not have any knowledge of a written programming language for the execution of the first to later section of the method, in particular, no programming knowledge at all. Assuming that the operator has "knowledge of a written programming language " , it should be understood in particular that the operator has at least one basic syntax and / or semantics of at least one written high-level language, - -
  • object c in particular object c, Java, C ++, VB, or comparable, and / or an assembler language and / or machine code knows and / or can apply.
  • the operator produces functional relationships between individual desired functions and / or data by intuitive linking, in particular drag ' n ' drop and / or line linking, of objects abstracted as function blocks.
  • function blocks are provided which allow input of mathematical functions.
  • the input unit provides an input area at least similar to a graphical programming language, such as G, for example.
  • a simple, efficient and / or intuitive possibility for generating executable code can be provided.
  • arbitrary operators can generate their own executable code tailored to their needs.
  • the input module directs the operator in the first method section through at least one configuration menu.
  • the operating program of the appbuilder unit in particular a web interface, has a menu structure which enables the operator, at least during the first method section, to choose between any configuration points of the user interface
  • the Appbuilderü stores to a new project added features and / or Da ⁇ th to allow an interruption in the configuration and subsequent sequel.
  • a simple configuration can be made possible.
  • At least industry information be entered by the operator in the first method section, in particular at a first point in the configuration menu.
  • information is to be distinguished between an application for goods and services, and different industry-specific effects to be triggered with the executable code, in particular processing, may be understood as meaning "branch information"
  • the appbuyer unit proposes to the operator different functions and / or data that should and / or could be embedded.
  • the appbuilder unit fades in inappropriate functions and / or data for entered industry information, in particular in the configuration menu.
  • NEN and / or Daren be manually re-displayed by the operator.
  • a better clarity and / or a lighter configuration can be achieved.
  • layout properties be entered by the operator in the first method section, in particular in a second point of the configuration menu.
  • layout properties is to be understood in particular as meaning properties which influence an optical appearance, at least of the later, executable code, on the mobile terminal.More, the operator specifies a menu structure, in particular the operator indicates a number, a size, a label and / or In particular, the operator specifies graphical information, in particular a coloring and / or at least a background graphic
  • at least content data be input by the operator in the first method section.
  • Content data should in particular be understood to mean data which has an effect to be achieved by the executable code pull.
  • goods and / or service information is entered as content data.
  • content data is time-varying data. In particular, it can be achieved that contents can already be output, in particular displayed, in a first embodiment of the generated executable code.
  • At least a first intermediate step at least part of the desired functions and / or data in a database unit, in particular publicly accessible, be stored.
  • the first intermediate step preferably takes place before the first and the later method section.
  • the first intermediate step takes place as one of the first or as the first step of the later method section.
  • at least the content data is stored in a database unit.
  • at least part of the layout information, in particular at least the graphic information is stored in the database unit.
  • a "database unit" is to be understood as meaning in particular a unit which has at least one information and / or data storage object, In particular, the information and / or data storage object differs from a pure ROM categorized or data storage object - -
  • the database unit returns information requested in dependence on parameters of a command path and / or stores data stored in parameters of the command path.
  • the database unit is integrated into a data processing system which is connected to at least one network, in particular at least the Internet, at least temporarily, in particular at least 80%, advantageously at least 95%, preferably at least 99% of one day.
  • the executable code after generation is intended to connect, preferably automatically, in particular regularly, to the database unit in order to update content data, layout information and / or other conceivable data.
  • the appbuilder unit has at least one further generation module that generates at least one preview package in at least one second intermediate step.
  • the second intermediate step preferably takes place before the later method section.
  • a "preview package" is to be understood in particular as meaning a data packet in which the desired functions and / or data are stored.
  • the preview packet becomes a mobile terminal in the context of the second or further intermediate step, in particular indirectly via a data memory, in particular a database unit to which the mobile terminal has access, in particular via a special, executable code
  • the mobile terminal has a special, executable code, which is provided with the aid of the preview package, a functionality and / or an appearance
  • the preview package is independent of an operating system, in particular a comfortable possibility can be provided, a functionality and / or an appearance test image of the executable code to be generated, with a particularly cumbersome, time-consuming and / or expensive, - -
  • the executable code can be dispensed with.
  • At least two basic codes are stored in the memory unit, from which the setting unit at least two executable codes with at least equivalent, preferably identical, codes in the later method section by embedding at least one equal part of the desired functions and / or data in the respective basic code.
  • Two mobile devices are particularly "different" when they have at least different operating systems.
  • different executable codes for a operation with respectively different mobile Endge ⁇ boards In particular, time can be saved which would be necessary for the separate creation of different codes with at least equivalent functionality.
  • the appbuilder unit sets the at least one generated executable code on at least one sales platform in a concluding method step.
  • a "setting on a sales platform" is to be understood in particular as meaning that forms, in particular web forms, of the sales platform are automatically filled in and / or a verification, in particular a signing, of the executable code is carried out automatically
  • the appbuyer unit is intended to set executable codes generated on different mobile terminals in different sales platforms .
  • the operator sets prices for the executable code independently of or depending on the sales platform, and / or make it available free of charge.
  • FIG. 1 is a schematic representation of a method according to the invention in a schematic representation
  • FIG. 2 systems according to the invention in a schematic representation.
  • Figure 1 shows a flow of a method for generating executable code 10, 10 ' , which is intended to be executed on mobile terminals 1 2, 1 2 ' .
  • the mobile terminals 1 2, 1 2 ' are designed as smartphones with i-OS or Android operating system.
  • the method is performed with a system 1 4 having an appbuilder unit 16 ( Figure 2).
  • the appbuilder unit 16 has a memory unit 18, an input module 20 and a build module 22. In the memory unit 1 8 two basic codes 24, 24 'are deposited.
  • the appbuilder unit 16 also has a network interface 26, which is intended to connect the appbuilder unit 16 to the Internet.
  • the system 14 further comprises a remote access interface 28, which is intended to access the input module 20 of the appbuilder unit 16 via the Internet and the network interface 26.
  • the remote access interface 28 is designed here as a PC, but may also be designed as any IT terminal.
  • the input module 20 is operated remotely. The method begins, triggered by an operator by calling in a first step SO a web interface provided by the input module 20. In this case, it is provided that the operator logs on to a user account before continuing the procedure.
  • a first method section S 1 the operator inputs desired radio sounds and / or data D 1, D 2, D 3, D 4 via the input module 20.
  • the input module 20 directs the operator in the first method section S 1 through a configuration menu. - -
  • sector information D 1 is input by the operator via the input module 20 in a first configuration step corresponding to a method step S 1.
  • Options could be restaurant, search service, goods sales or similar.
  • the appbuilder unit 1 6 proposes corresponding layout and functional suggestions to the operator in the next method steps S 1 2, S 1 3.
  • layout properties D2 are entered by the operator.
  • the appbuilder unit 16 provides the operator with the possibility to select between different, particularly suitable, prefabricated design variants determined on the basis of the industry information D 1. If the suggestions do not seem appropriate to him, the operator can also display further prefabricated design variants for a selection, adapt a prefabricated design variant, or independently define positions, sizes and labels of information areas and buttons. Furthermore, the operator is given the opportunity to choose between different designs, colors and background images or even to design a design, color and background images. Furthermore, menu structures and their graphic design are entered by the operator. In the first method section S 1, the operator inputs desired functions D 3. The desired functions D3 are connected to desired buttons.
  • suitable functions D 3 are proposed to the operator. This is done in a configuration step of the configuration ⁇ menus, corresponding to a step S 1. 3
  • the operator determines which action, for example a display of a menu, an input of data into a database unit 30, a read-out of
  • the appbuilder 16 directs the operator to missing important functions, such as a termination function, and to idle buttons. Alternatively or additionally, it is conceivable that the appbuild unit 16 displays lists during the first method section S 1 in which unoccupied buttons or functions not yet used are listed.
  • the appbuilder unit 16 gives the operator, via the input module 20, the possibility of entering more complex functions, for example for processing sensor signals and / or for combining a plurality of functions of the mobile terminal 1 2, 1 2 ', via an interface comparable to a graphical programming language ,
  • content data D 4 are entered by the operator.
  • Content data D4 in this case is data that is to be displayed to a user as a function of interactions of the user with the finished, executable code 10, 10 'in information areas of the layout, for example information on one or more products, goods or services that an operator assigns to the user to provide through the executable code, a list or table of data, such as product data, location data or user data, images, text and the like.
  • the operator also determines which of the content data, for example, for large, rapidly varying data sets, should only be stored in the database unit 30 in order to avoid large data transfers.
  • step S 1 3 it is conceivable that content data are stored in a further database unit and the access to this additional database unit was defined by function in step S 1 3, so access data for this additional database unit were deposited.
  • the operator terminates the configuration through a corresponding function of the configuration menu and the process continues.
  • the operator can use the configuration menu between any process steps S 1 1, S 1 2, S 1 3, S 1 4 of the process ⁇ section S 1 change.
  • the database unit 30 is part of the system 14.
  • the database unit 30 is in this case connected to the appbuilder unit 16 via the Internet.
  • a first intermediate step S2 part of the desired functions and / or data D 1, D 2, D 3, D 4 are stored in the database unit 30.
  • the appbuilder unit 16 has a further creation module 32.
  • the further generation module 32 generates a preview packet 34.
  • the preview packet 34 comprises all functions and / or data D1, D2, D3, D4 entered during the first method section S1.
  • the preview package 34 is stored in a database unit 35.
  • An executable code 36, the previewapp is provided, which is executed on a mobile terminal 38 and thereby simulates a functionality of the executable code 10, 10 'to be created with the aid of the preview package 34.
  • the previewapp connects to the database unit 35, identifies itself with access data of the operator and gives the operator the option of selecting between different preview packages 34 stored in the database unit 35.
  • the preview package 34 is analyzed and interpreted by the preview app.
  • the appbuilder unit 16 provides the operator with the opportunity to skip the second intermediate step S3.
  • the process continues with a later method section S4. Alternatively, the operator may return to the first method section S l.
  • the operator is asked in a method step S41 to specify for which operating systems a suitable executable code 10, 10 ' is to be created.
  • the generation module 22 embeds a same part of the desired functions and / or data D 1, D 2, D 3, D 4 into the basic codes 24, 24 ' .
  • two executable codes 10, 10 ' are generated with equivalent functionality for two different mobile terminals 1 2, 1 2 ' .
  • the desired functions D3 are provided by automatically inserting suitable, specially prepared code modules in the basic code 24, 24 ' .
  • a first of the basic codes 24 and the corresponding code modules are written in object c.
  • a second basic code 24 'and the corresponding code modules are written in java. From the first basic code 24, in a method step S42 a first, executable - -
  • Code 10 is generated, which is suitable for an application with the operating system i-OS on the first mobile terminal ⁇ device 1 2.
  • a second, executable code 10 ' is generated in a method step S43, which is suitable for an application with the Android operating system on the second mobile terminal 1 2 '.
  • graphical information and content data D4 are held in an excluded from a compilation memory area and attached to the auscommendedba ⁇ ren code 10, 10 'suitable.
  • the executable codes 10, 10 ' generated are set for corresponding sales platforms 40, 40 ' .
  • the sales platforms 40, 40 ' are designed as online stores which are each specialized in executable codes for the corresponding operating systems. Alternatively or additionally, a setting in cross-operating sales platforms is conceivable. If an operator has not provided user data to the sales platforms 40, 40 ' , the app building unit 16 automatically creates user accounts on these sales platforms 40, 40 ' . Furthermore, the appbuilder unit 16 automatically executes referencing and signing operations for the executable code 10, 10 'from a sales platform 40, 40'.
  • the appbuilder unit 16 has a maintenance module 42.
  • the operator can access the maintenance module via a web interface of any terminals, in particular mobile terminals or PCs.
  • the operator can change the graphical information and the content data D4 stored in the database unit 30 via the maintenance module 42.
  • the maintenance module 42 manages settings of a user account of the operator for the appbuilder unit 16 and the user accounts for the sales platforms 40, 40 '.
  • FIG. 2 shows two systems 44, 44 ' with the appbuilder unit 16 and in each case one mobile terminal 1 2, 1 2', which is provided to execute the executable code 10, 10 ' generated by the appbuilder unit 16. Furthermore, FIG.
  • FIG. 2 shows two systems 46, 46 ' each having a mobile terminal 1 2, 1 2', in each case an executable code 10, 10 'and at least one database unit 30, which is provided for part of the desired functions and / or data D l, D2, D3, D4 of the executable code publicly available to store. Furthermore, it can be provided that the database units 30, 35 are designed as individual database instructions.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • User Interface Of Digital Computer (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Telephone Function (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zur Erzeugung von ausführbarem Code ( 10, 10'), der dazu vorgesehen ist, auf einem mobilen Endgerät (12, 12') ausgeführt zu werden, mit zumindest einer Appbuildereinheit (16), die zumindest eine Speichereinheit (18), in der zumindest ein Grundcode (24, 24') hinterlegt ist, zumindest ein Eingabemodul (20) und zumindest ein Erstellmodul (22) aufweist, wobei in einem ersten Verfahrensabschnitt (S l ) über das Eingabemodul (20) von einem Bediener gewünschte Funktionen und/oder Daten (D 1, D2, D3, D4) eingegeben werden und in einem späteren Verfahrensabschnitt (S4) das Erstellmodul (22) zumindest einen Teil der gewünschten Funktionen und/oder Daten (D1, D2, D3, D4) in den Grundcode (24, 24') einbettet.

Description

Verfahren zur Erzeugung von ausführbarem Code
Stand der Technik
Die Erfindung betrifft ein Verfahren zur Erzeugung von ausführbarem Code nach Anspruch 1.
Es ist bekannt, Programme, die dazu vorgesehen sind, auf Smartphones oder Ahnlichem zu laufen, separat zu programmieren. Dazu benutzen Programmierer Codemodule und verknüpfen diese unter Anwen- dung ihrer Programmierkenntnisse zu gewünschten Funktionen.
Vorteile der Erfindung Die Erfindung betrifft ein Verfahren zur Erzeugung von ausführbarem Code, der dazu vorgesehen ist, auf einem mobilen Endgerät ausgeführt zu werden, mit zumindest einer Appbuildereinheit, die zumindest eine Speichereinheit, in der zumindest ein Grundcode hinterlegt ist, zumindest ein Eingabemodul und zumindest ein Erstellmodul aufweist, wobei in einem ersten Verfahrensabschnitt über das Eingabemodul von einem Bediener gewünschte Funktionen und/oder Daten eingegeben werden und in einem späteren Verfahrensabschnitt das Erstellmodul zumindest einen Teil der gewünschten Funktionen und/oder Daten in den Grundcode einbettet. Unter„ausführbarem Code" soll insbesondere eine in ein Paket, insbesondere eine Datei, geschriebene Folge von informatischen Anweisungen, insbesondere Assembler- und/oder Maschinencode, verstanden werden, die dazu vorgesehen sind, ein zumindest halbautomati¬ sches Programm ablaufen zu lassen. Vorzugsweise sind das Paket und oder die Anweisungen an be- stimmte Bedingungen, insbesondere an einen zu nutzenden Prozessor, der insbesondere mit dem RISC- Befehlssatz und/oder einer Weiterentwicklung dessen arbeitet und/oder dessen Architektur auf ARM- Technologie basiert, und/oder an ein Betriebssystem, in dessen Rahmen der ausführbare Code ausge- - -
führt werden soll, angepasst, insbesondere speziell kompiliert. Unter einem„mobilen Endgerät" soll insbesondere ein Endgerät mit einem Gewicht von weniger als 2 kg, insbesondere weniger als 1 kg, vorteilhaft weniger als 500 g, vorzugsweise weniger als 200 g, verstanden werden. Vorzugsweise weist ein mobiles Endgerät zumindest eine netzunabhängige Stromversorgung, insbesondere eine Akkueinheit und/oder eine Solargeneratoreinheit auf. Vorzugsweise weist das mobile Endgerät zumindest ein berührungsempfindliches, insbesondere kapazitives, resistives und/oder induktives, Display auf, das als Bedienerschnittstelle dient. Insbesondere ist das mobile Endgerät als Mobiltelefon, insbesondere Smartphone, oder als Tablet-PC ausgebildet. Insbesondere weist das mobile Endgerät zumindest eine Kommunikationsschnittstelle, insbesondere zumindest eine GPRS-, EDGE-, UMTS- und/oder W-LAN-Schnittstelle, auf. Insbesondere weist das mobile Endgerät zumindest einen Positionssensor, insbesondere einen GPS- Empfänger, auf. Insbesondere weist das mobile Endgerät zumindest einen Beschleunigungssensor auf. Insbesondere weist das mobile Endgerät zumindest eine Video-, Foto- und/oder Audioaufzeichnungseinheit auf. Vorzugsweise weist das mobile Endgerät zumindest ein, auf mobile Zwecke, insbesondere hinsichtlich einer Anzeige auf Displays mit einer Bildschirmdiagonale von weniger als 20 cm, vorteilhaft weniger als 15 cm und/oder hinsichtlich einer Bedienung per Touchdisplay, optimiertes Betriebssystem, beispielsweise iOS, Android, Windows Phone und/oder Blackberry-OS auf. Unter einer„Appbuilderein- heit" soll insbesondere eine zumindest halbautomatische Einheit verstanden werden. Vorzugsweise weist eine Appbuildereinheit zumindest eine Recheneinheit, zumindest eine Speichereinheit und zumindest ein, in der Speichereinheit hinterlegres Betriebsprogramm auf, das dazu vorgesehen ist, von der Rechenein- heit ausgeführt zu werden. Vorzugsweise sind die Speichereinheit und die Recheneinheit in eine Datenverarbeitungsanlage, insbesondere einen PC, vorzugsweise einen Server, integriert. Alternativ ist es denkbar, dass die Speichereinheit und die Recheneinheit über eine Netzwerkverbindung miteinander verbunden sind, insbesondere in unterschiedliche Datenverarbeitungsanlagen integriert sind. Unter einer „Speichereinheit" soll insbesondere eine Einheit verstanden werden, die dazu vorgesehen ist, Daten, insbesondere digital, vorzugsweise nicht flüchtig, abzuspeichern. Vorzugsweise ist die Speichereinheit von zumindest einer Festplatte, insbesondere SSD, gebildet. Unter einem„Grundcode" soll insbesondere ein in einer, vorzugsweise objektorientierten, Programmiersprache, insbesondere einer Hochsprache, beispielsweise object c, java, C*+, Visual Basic, oder Vergleichbarem, vorliegender, unvollständiger Programmcode verstanden werden. Insbesondere weist der Grundcode zumindest ein erstes Codemodul auf, das dazu vorgesehen ist, eine Verbindung zu Ein- und/oder Ausgabefunktionen, insbesondere GPS- Funktionen, Anzeigefunktionen, Kommunikationsfunktionen, Vibrationsfunktionen, Sensorfunktionen, Bild- und/oder Tonaufzeichnungsfunktionen, des mobilen Endgeräts bereitzustellen. Insbesondere ist zumindest das erste Codemodul dazu vorgesehen, auf von dem Betriebssystem des mobilen Endgeräts bereitgestellte Schnittstellen zurückzugreifen. Insbesondere weist der Grundcode zumindest ein zweites Codemodul auf, das dazu vorgesehen ist, eine Verbindungsmöglichkeit mit einer Datenbankeinheit bereitzustellen. Unter einem„Eingabemodul" soll insbesondere eine Schnittstelle zwischen dem Bediener und der Appbuildereinheit verstanden werden. Unter einer„Einbettung" von Funktionen und/oder Daten in den Grundcode soll insbesondere verstanden werden, dass den Funktionen, insbesondere einer Kartenanzeige, einer GPS-lnformation, einem Datenbankzugriff und/oder weitere denkbare Funktionen, zugeordnete Codemodule in den Grundcode an geeigneter Stelle integriert werden bzw. die Daten, insbe¬ sondere Grafikdaten und/oder Inhaltsdaten, in einem Speicherbereich des Grundcodes hinterlegt wer- den. Insbesondere wird der durch Integration modifizierte, vorzugsweise in einer Hochsprache vorliegende, Grundcode, im Anschluss an die Einbettung, durch das Erstellmodul in Assembler- und/oder Ma¬ schinencode umgewandelt, insbesondere kompiliert. Es kann insbesondere eine einfache Möglichkeit bereitgestellt werden, zumindest einen ausführbaren Code zu erzeugen.
Weiterhin wird vorgeschlagen, dass das Eingabemodul per Fernzugriff bedient wird. Unter einer Bedienung per„Fernzugriff" soll insbesondere eine Bedienung über eine Netzwerkschnittstelle, insbesondere über zumindest eine Telekommunikationsleitung, insbesondere DSL, ISDN oder Vergleichbarem, verstanden werden. Insbesondere weist die Appbuildereinheit zumindest eine Netzwerkschnittstelle auf. Insbesondere ist die Appbuildereinheit mit zumindest einem Netzwerk, insbesondere zumindest dem Internet, zumindest zeitweise, insbesondere zumindest 80 %, vorteilhaft zumindest 95 %, vorzugsweise zumindest 99 % eines Tages, eines Monats und/oder eines Jahres, verbunden ist. Insbesondere bietet die Appbuildereinheit ein Webinterface an, auf das der Bediener per Internet zugreifen kann. Es kann insbesondere eine einfache Bedienung erreicht werden. Insbesondere kann erreicht werden, dass die Appbuildereinheit von mehr als einem Bediener gleichzeitig bedient werden kann. Insbesondere kann ein Zugriff auf die Appbuildereinheit von beliebigen Endgeräten, insbesondere PCs, Smartphones oder Ähnlichem, bereitgestellt werden.
Ferner wird vorgeschlagen, dass der Bediener zur Ausführung des ersten bis späteren Verfahrensabschnitts keine Kenntnisse über eine geschriebene Programmiersprache aufweisen muss, insbesondere über gar keine Programmierkenntnisse verfügen muss. Darunter, dass der Bediener„Kenntnisse über eine geschriebene Programmiersprache aufweist", soll insbesondere verstanden werden, dass der Bediener zumindest eine grundlegende Syntax und/oder Semantik zumindest einer geschriebenen Hochsprache, - -
insbesondere object c, Java, C++, VB, oder Vergleichbarem, und/oder einer Assembler Sprache und/oder von Maschinencode kennt und/oder anwenden kann. Insbesondere ist es denkbar, dass der Bediener funktionale Zusammenhänge zwischen einzelnen gewünschten Funktionen und/oder Daten durch intuitive Verknüpfung, insbesondere Drag'n'Drop und/oder Linienverknüpfung, von als Funktions- blocken abstrahierten Objekten herstellt. Insbesondere sind Funktionsblöcke vorgesehen, die eine Eingabe von mathematischen Funktionen erlauben. Insbesondere stellt die Eingabeeinheit einen einer grafischen Programmiersprache, wie beispielsweise G, zumindest ähnlichen Eingabebereich zur Verfügung. Es kann insbesondere eine einfache, effiziente und/oder intuitive Möglichkeit zur Erzeugung von ausführbarem Code bereitgestellt werden. Insbesondere können beliebige Bediener eigenen, auf ihre Be- dürfnisse zugeschnittenen, ausführbaren Code erzeugen.
Weiterhin wird vorgeschlagen, dass das Eingabemodul den Bediener in dem ersten Verfahrensabschnitt durch zumindest ein Konfigurationsmenü leitet. Insbesondere weist das Betriebsprogramm der Appbuil- dereinheit, insbesondere ein Webinterface, eine Menüstruktur auf, die es dem Bediener ermöglicht, zumindest während des ersten Verfahrensabschnitts zwischen beliebigen Konfigurationspunkten des
Konfigurationsmenüs hin- und herzuspringen, um Änderungen und/oder Korrekturen vorzunehmen. Insbesondere speichert die Appbuildereinheit zu einem neuen Projekt hinzugefügte Funktionen und/oder Da¬ ten ab, um eine Unterbrechung der Konfiguration und eine spätere Fortsetzung zu ermöglichen. Es kann insbesondere eine einfache Konfiguration ermöglicht werden.
Ferner wird vorgeschlagen, dass von dem Bediener in dem ersten Verfahrensabschnitt, insbesondere bei einem ersten Punkt im Konfigurationsmenü, zumindest Brancheninformationen eingegeben werden. Unter „Brancheninformationen" sollen insbesondere Informationen verstanden werden, die einen Anwendungsbereich des zu erzeugenden, ausführbaren Codes beschreiben. Insbesondere wird hierbei zwi- sehen einer Anwendung auf Waren und Dienstleistungen unterschieden. Weiterhin kann zwischen unterschiedlichen mit dem ausführbaren Code auszulösenden, branchenspezifischen Wirkungen, insbesondere Abwicklung eines Kaufs, Anzeige zumindest einer Information, Reservierung einer Dienstleistung und/oder weiteren denkbaren Wirkungen, unterschieden werden. Insbesondere werden in Abhängigkeit von eingegebenen Brancheninformationen dem Bediener durch die Appbuildereinheit unterschiedliche Funktionen und/oder Daten vorgeschlagen, die eingebettet werden sollten und/oder könnten. Insbesondere blendet die Appbuildereinheit für eingegebene Brancheninformationen ungeeignete Funktionen und/oder Daten, insbesondere im Konfigurationsmenü, aus. Insbesondere können ausgeblendete Funktio- - -
nen und/oder Daren durch den Bediener manuell wieder eingeblendet werden. Es kann insbesondere eine bessere Übersichtlichkeit und/oder eine leichtere Konfiguration erreicht werden.
Weiterhin wird vorgeschlagen, dass von dem Bediener in dem ersten Verfahrensabschnitt, insbesondere in einem zweiten Punkt des Konfigurationsmenüs, zumindest Layouteigenschaften eingegeben werden. Unter„Layouteigenschaften" sollen insbesondere Eigenschaften verstanden werden, die ein optisches Erscheinungsbild, zumindest des späteren, ausführbaren Codes, auf dem mobilen Endgerät beeinflussen. Insbesondere gibt der Bediener eine Menüstruktur vor. Insbesondere gibt der Bediener eine Anzahl, eine Größe, eine Beschriftung und/oder eine Position von Schaltflächen vor. Insbesondere schlägt die Appbuildereinheit Layouteigenschaften anhand von eingegebenen Brancheninformationen vor. Insbesondere legt der Bediener grafische Informationen, insbesondere eine Farbgebung und/oder zumindest eine Hintergrundgrafik, fest. Insbesondere legt der Bediener eine Größe und/oder eine Position zumindest eines Informationsbereichs fest. Ferner wird vorgeschlagen, dass von dem Bediener in dem ersten Verfahrensabschnitt zumindest Inhaltsdaten eingegeben werden. Unter„Inhaltsdaten" sollen insbesondere Daten verstanden werden, die sich auf eine zu erzielende Wirkung des ausführbaren Codes beziehen. Insbesondere werden Waren- und/oder Dienstleistungsinformationen als Inhaltsdaten eingegeben. Insbesondere sind Inhaltsdaten zeitlich veränderliche Daten. Es kann insbesondere erreicht werden, dass bereits bei einer ersten Ausfüh- rung des erzeugten ausführbaren Codes Inhalte ausgebbar, insbesondere anzeigbar, sind.
Weiterhin wird vorgeschlagen, dass in zumindest einem ersten Zwischenschritt zumindest ein Teil der gewünschten Funktionen und/oder Daten in einer Datenbankeinheit, insbesondere öffentlich zugänglich, abgespeichert werden. Vorzugsweise liegt der erste Zwischenschritt zeitlich vor dem ersten und dem späteren Verfahrensabschnitt. Alternativ ist es denkbar, dass der erste Zwischenschritt als einer der ersten oder als erster Schritt des späteren Verfahrensabschnitts erfolgt. Insbesondere werden zumindest die Inhaltsdaten in einer Datenbankeinheit gespeichert. Insbesondere wird zumindest ein Teil der Layoutinformationen, insbesondere zumindest die grafischen Informationen, in der Datenbankeinheit abgelegt. Unter einer„Datenbankeinheit" soll insbesondere eine Einheit verstanden werden, die zumindest ein Informations- und/oder Datenspeicherobjekt aufweist. Insbesondere unterscheidet sich das Informationsund/oder Datenspeicherobjekt von einem reinen Festspeicher. Insbesondere weist die Datenbankeinheit ein Betriebsprogramm auf, das Daten des Informations- und/oder Datenspeicherobjekts kategorisiert - -
und/oder miteinander verknüpft abspeichert. Insbesondere gibt die Datenbankeinheit in Abhängigkeit von Parametern eines Befehlspfads angeforderte Informationen zurück und/oder speichert in Parametern des Befehlspfads hinterlegte Daten ab. Insbesondere ist die Datenbankeinheit in eine Datenverarbeitungsanlage integriert, die mit zumindest einem Netzwerk, insbesondere zumindest dem Internet, zumindest zeitweise, insbesondere zumindest 80 %, vorteilhaft zumindest 95 %, vorzugsweise zumindest 99 % eines Tages, verbunden ist. Insbesondere ist der ausführbare Code nach Erzeugung dazu vorgesehen, sich, vorzugsweise automatisch, insbesondere regelmäßig, mit der Datenbankeinheit zu verbinden, um Inhaltsdaten, Layoutinformationen und/oder weitere denkbare Daten zu aktualisieren. Unter„öffentlich zugänglich" soll insbesondere verstanden werden, dass mehr als nur der Bediener, insbesondere zumindest Anwender, die später den erzeugten, ausführbaren Code ausführen, insbesondere über den zu erzeugenden, ausführbaren Code auf die Daten der Datenbankeinheit zugreifen können. Insbesondere werden bei einer Aktualisierung lediglich neue Daten übertragen, um einen Umfang eines Datentransfers und/oder insbesondere Kosten zu reduzieren. Insbesondere kann eine einfache Veränderbarkeit zumindest der Inhaltsdaten erreicht werden. Insbesondere kann auf eine Erzeugung eines neuen, ausführbaren Codes und insbesondere daraus folgende große Datentransfers, insbesondere auf Anwenderseite, verzichtet werden.
Vorteilhaft wird vorgeschlagen, dass die Appbuildereinheit zumindest ein weiteres Erstellmodul aufweist, das in zumindest einem zweiten Zwischenschritt zumindest ein Previewpaket erzeugt. Vorzugsweise erfolgt der zweite Zwischenschritt vor dem späteren Verfahrensabschnitt. Unter einem„Previewpaket" soll insbesondere ein Datenpaket verstanden werden, in dem die gewünschten Funktionen und/oder Daten hinterlegt sind. Insbesondere wird das Previewpaket im Rahmen des zweiten oder eines weiteren Zwischenschritts zu einem mobilen Endgerät, insbesondere indirekt über einen Datenspeicher, insbesondere einer Datenbankeinheit, auf die das mobile Endgerät, insbesondere über einen speziellen, ausführ- baren Code, Zugang hat, übertragen. Insbesondere weist das mobile Endgerät einen speziellen, ausführbaren Code auf, der dazu vorgesehen ist, mit Hilfe des Previewpakets eine Funktionalität und/oder ein Erscheinungsbild des zu erzeugenden ausführbaren Codes zu simulieren, wobei im Vergleich zum zu erzeugenden, ausführbaren Code eine höhere Rechenleistung benötigt wird. Insbesondere ist das Previewpaket unabhängig von einem Betriebssystem. Es kann insbesondere eine komfortable Möglichkeit bereitgestellt werden, eine Funktionalität und/oder ein Erscheinungsbild des zu erzeugenden ausführbaren Codes zu testen, wobei auf eine, insbesondere umständliche, zeitraubende und/oder kostenintensive, - -
Veröffentlichung, insbesondere eine Erzeugung und/oder eine Einstellung in einer Verkaufsplattform, des ausführbaren Codes verzichtet werden kann.
Weiterhin wird vorgeschlagen, dass in der Speichereinheit zumindest zwei Grundcodes gespeichert sind, aus denen die Erstelleinheit in dem späteren Verfahrensabschnitt durch Einbettung zumindest eines gleichen Teils der gewünschten Funktionen und/oder Daten in den jeweiligen Grundcode zumindest zwei ausführbare Codes mit zumindest äquivalenter, vorzugsweise gleicher, Funktionalität für zumindest zwei unterschiedliche mobile Endgeräte erzeugt. Zwei mobile Endgeräte sind insbesondere dann„unterschiedlich", wenn sie zumindest unterschiedliche Betriebssysteme aufweisen. Insbesondere liegen die Grundcodes in unterschiedlichen Programmiersprachen vor. Es kann insbesondere erreicht werden, dass unterschiedliche, ausführbare Codes, die für einen Betrieb mit jeweils unterschiedlichen mobilen Endge¬ räten zum Zwecke einer gleichen Anwendung vorgesehen sind, ein gleiches und/oder äquivalentes Erscheinungsbild und eine gleiche und/oder äquivalente Funktionalität aufweisen. Insbesondere kann Zeit gespart werden, die für die separate Erezeugung unterschiedlicher Codes mit zumindest äquivalenter Funktionalität nötig wäre.
Ferner wird vorgeschlagen, dass die Appbuildereinheit in einem abschließenden Verfahrensschritt den zumindest einen erzeugten ausführbaren Code auf zumindest einer Verkaufsplattform einstellt. Unter einem„Einstellen auf einer Verkaufsplattform" soll insbesondere verstanden werden, dass automatisch Formulare, insbesondere Webformulare, der Verkaufsplattform ausgefüllt werden und/oder automatisch eine Verifizierung, insbesondere eine Signierung, des ausführbaren Codes durchgeführt wird. Insbesondere ist der ausführbare Code nach Einstellung auf der Verkaufsplattform durch beliebige Anwender beziehbar, insbesondere herunterladbar. Insbesondere ist die Appbuildereinheit dazu vorgesehen, zur Ausführung auf unterschiedlichen mobilen Endgeräten erzeugte, ausführbare Codes in unterschiedlichen Verkaufsplattformen einzustellen. Insbesondere legt der Bediener, unabhängig oder abhängig von der Verkaufsplattform, Preise für den ausführbaren Code fest und/oder stellt ihn kostenfrei zur Verfügung.
Zeichnungen
Weitere Vorteile ergeben sich aus der folgenden Zeichnungsbeschreibung. In den Zeichnungen ist e Ausführungsbeispiel der Erfindung dargestellt. Die Zeichnungen, die Beschreibung und die Ansprüch enthalten zahlreiche Merkmale in Kombination. Der Fachmann wird die Merkmale zweckmäßigerweise auch einzeln betrachten und zu sinnvollen weiteren Kombinationen zusammenfassen.
Es zeigen:
Fig. 1 eine schematische Darstellung eines erfindungsgemäßen Verfahrens in schema- tischer Darstellung und
Fig. 2 erfindungsgemäße Systeme in schematischer Darstellung.
Beschreibung des Ausführungsbeispiels
Figur 1 zeigt einen Ablauf eines Verfahrens zur Erzeugung von ausführbarem Code 10, 10', der dazu vorgesehen ist, auf mobilen Endgeräten 1 2, 1 2' ausgeführt zu werden. Die mobilen Endgeräte 1 2, 1 2' sind als Smartphones mit i-OS bzw. Android-Betriebssystem ausgebildet. Das Verfahren wird mit einem System 1 4, das eine Appbuildereinheit 16 aufweist, ausgeführt (Figur 2). Die Appbuildereinheit 16 weist eine Speichereinheit 1 8, ein Eingabemodul 20 und ein Erstellmodul 22 auf. In der Speichereinheit 1 8 sind zwei Grundcodes 24, 24' hinterlegt. Die Appbuildereinheit 16 weist weiterhin eine Netzwerkschnittstelle 26 auf, die dazu vorgesehen ist, die Appbuildereinheit 16 an das Internet anzubinden. Das System 1 4 weist weiterhin eine Fernzugriffsschnittstelle 28 auf, die dazu vorgesehen ist, über das Internet und die Netzwerkschnittstelle 26 auf das Eingabemodul 20 der Appbuildereinheit 16 zuzugreifen. Die Fernzugriffsschnittstelle 28 ist hier als PC ausgebildet, kann jedoch auch als beliebiges IT-Endgerät ausgebildet sein. Das Eingabemodul 20 wird per Fernzugriff bedient. Das Verfahren beginnt, durch einen Bediener ausgelöst, indem dieser in einem initialen Verfahrensschritt SO ein Webinterface, das von dem Eingabemodul 20 bereitgestellt wird, aufruft. Hierbei ist es vorgesehen, dass sich der Bediener vor Fortführung des Verfahrens an einem Benutzerkonto anmeldet.
In einem ersten Verfahrensabschnitt S 1 gibt der Bediener über das Eingabemodul 20 gewünschte Funk- Honen und/oder Daten D l , D2, D3, D4 ein. Zu einer Ausführung des Verfahrens sind hierbei keinerlei Kenntnisse des Bedieners über eine geschriebene Programmiersprache nötig. Das Eingabemodul 20 leitet den Bediener in dem ersten Verfahrensabschnitt S l durch ein Konfigurationsmenü. - -
In dem ersten Verfahrensabschnitt S .1 werden in einem ersten Konfigurationsschritt, der einem Verfahrensschritt S l 1 entspricht, von dem Bediener über das Eingabemodul 20 Brancheninformationen D l eingegeben. Auswahlmöglichkeiten könnten hierbei Gastwirtschaft, Suchdienst, Warenverkauf oder Ähnliches sein. In Abhängigkeit von den eingegebenen Brancheninformationen D l schlägt die Appbuil- dereinheit 1 6 dem Bediener in den nächsten Verfahrensschritten S 1 2, S 1 3 entsprechende Layout- und Funktionsvorschläge vor.
In einem darauf folgenden Konfigurationsschritt, der einem Verfahrensschritt S l 2 entspricht, werden von dem Bediener Layouteigenschaften D2 eingegeben. Die Appbuildereinheit 1 6 stellt dem Bediener die Möglichkeit bereit, zwischen verschiedenen, anhand der Brancheninformationen D l bestimmten, besonders geeigneten, vorgefertigten Gestaltungsvarianten auswählen. Der Bediener kann sich, wenn ihm die Vorschläge ungeeignet erscheinen, auch weitere vorgefertigte Gestaltungsvarianten zu einer Auswahl anzeigen lassen, eine vorgefertigte Gestaltungsvariante anpassen, oder eigenständig Positionen, Größen und Beschriftungen von Informationsbereichen und Schaltflächen festlegen. Weiterhin wird dem Bediener die Möglichkeit gegeben, zwischen unterschiedlichen Designs, Farbgebungen und Hintergrundbildern auszuwählen oder selber ein Design, eine Farbgebung und Hintergrundbilder zu gestalten. Weiterhin werden Menüstrukturen und deren grafische Gestaltung durch den Bediener eingegeben. In dem ersten Verfahrensabschnitt S 1 gibt der Bediener gewünschte Funktionen D3 ein. Die gewünschten Funktionen D3 werden mit gewünschten Schaltflächen verbunden. In Abhängigkeit von eingegebenen Brancheninformationen D 1 und eingegebenen Layouteigenschaften D2 werden dem Bediener geeignete Funktionen D3 vorgeschlagen. Dies erfolgt in einem Konfigurationsschritt des Konfigurations¬ menüs, der einem Verfahrensschritt S 1 3 entspricht. Der Bediener legt fest, welche Aktion, beispielsweise eine Anzeige eines Menüs, eine Eingabe von Daten in eine Datenbankeinheit 30, ein Auslesen von
Daten aus der Datenbankeinheit 30, eine Beendigung oder Ausblendung des ausführbaren Codes 10, 10', eine Kartenanzeige, eine Suchfunktion, die beispielsweise aktuelle GPS-Koordinaten als Parameter übernimmt, eine Übermittlung einer bestimmten oder aus einem Datensatz ausgewählten Koordinate oder Adresse an eine Routingfunktion des mobilen Endgeräts 1 2, 1 2', ein Routingverfahren, ein Zugriff auf ein Kommunikationssystem wie Email, Telefonie oder Instant-Messaging, Aufzeichnung und/oder
Versendung von Bild und/oder Ton und/oder weiter Denkbares, bei Betätigung der jeweiligen Schaltflächen ausgeführt wird bzw. welche Funktionen ausgeführt wurden. Weiterhin gibt der Bediener ge- - -
wünschte Funktionen D3 ein, indem er festlegt, welche Aktion oder welche Aktionen auf ein bestimmtes Ereignis, das beispielsweise auf Sensorsignalen, wie von einem Beschleunigungssensor, einer Kamera oder eines Mikrofons beruht, folgen soll. Bei Abschluss dieses Verfahrensschritts S l 3 weist die Appbuil- dereinheit 16 den Bediener auf fehlende wichtige Funktionen, beispielsweise eine Beendigungsfunktion und auf unbelegte Schaltflächen hin. Alternativ oder zusätzlich ist es denkbar, dass die Appbuilderein- heit 16 während des ersten Verfahrensabschnitts S l Listen anzeigt, in denen unbelegte Schaltflächen bzw. noch nicht verwendete Funktionen aufgelistet sind. Die Appbuildereinheit 16 gibt dem Bediener über das Eingabemodul 20 die Möglichkeit, komplexere Funktionen, beispielsweise zur Verarbeitung von Sensorsignalen und/oder zur Kombinierung von mehreren Funktionen des mobilen Endgeräts 1 2, 1 2', über ein, mit einer grafischen Programmiersprache vergleichbares, Interface einzugeben.
In einem weiteren Verfahrensschritt S 14 des ersten Verfahrensabschnitts S l bei der Konfiguration werden durch den Bediener Inhaltsdaten D4 eingegeben. Inhaltsdaten D4 sind hierbei Daten, die einem Anwender in Abhängigkeit von Interaktionen des Anwenders mit dem fertigen, ausführbaren Code 10, 10' in Informationsbereichen des Layouts angezeigt werden sollen, beispielsweise Informationen zu einem oder mehreren Produkten, Waren oder Dienstleistungen, die ein Bediener dem Anwender über den ausführbaren Code anbieten möchte, eine Liste oder Tabelle von Daten, beispielsweise Produktdaten, Ortsdaten oder Benutzerdaten, Bilder, Texte und Vergleichbares. Der Bediener legt weiterhin fest, welche der Inhaltsdaten, beispielsweise bei großen, schnell veränderlichen Datensätzen, lediglich in der Datenbankeinheit 30 gespeichert werden sollen, um große Datenübertragungen zu vermeiden. Weiter¬ hin ist es denkbar, dass Inhaltsdaten in einer weiteren Datenbankeinheit hinterlegt sind und der Zugriff auf diese weitere Datenbankeinheit per Funktion im Verfahrensschritt S 1 3 festgelegt wurde, also Zugangsdaten für diese weitere Datenbankeinheit hinterlegt wurden. Ist eine Eingabe von Daten abgeschlossen, beendet der Bediener über eine entsprechende Funktion des Konfigurationsmenüs die Konfiguration und das Verfahren wird fortgesetzt. Der Bediener kann mit Hilfe des Konfigurationsmenüs zwischen beliebigen Verfahrensschritten S 1 1 , S 1 2, S 1 3, S 1 4 des Verfahrens¬ abschnitts S 1 wechseln. Die Datenbankeinheit 30 ist Bestandteil des Systems 14. Die Datenbankeinheit 30 ist hierbei über das Internet mit der Appbuildereinheit 16 verbunden. In einem ersten Zwischenschritt S2 werden ein Teil der gewünschten Funktionen und/oder Daten D 1 , D2, D3, D4 in der Datenbankeinheit 30 abgespeichert. - -
Es werden sowohl die Inhaltsdaten D4, als auch die grafischen Informationen über Design, Farbgebung und Hintergrundbild in der Datenbankeinheit 30 hinterlegt, so dass ein Bediener nachträglich oder sai¬ sonal das Erscheinungsbild des ausführbaren Codes 10, 10' anpassen kann. Die Appbuildereinheit 16 weist ein weiteres Erstellmodul 32 auf. In einem zweiten Zwischenschritt S3 erzeugt das weitere Erstellmodul 32 ein Previewpaket 34. Das Previewpaket 34 umfasst sämtliche, während des ersten Verfahrensabschnitts S l eingegebene Funktionen und/oder Daten D l , D2, D3, D4. Das Previewpaket 34 wird in einer Datenbankeinheit 35 abgespeichert. Es ist ein ausführbarer Code 36, die Previewapp, vorgesehen, der auf einem mobilen Endgerät 38 ausgeführt wird und dabei eine Funktionalität des zu erstellenden ausführbaren Codes 10, 10' mit Hilfe des Previewpakets 34 simuliert. Dazu verbindet sich die Previewapp mit der Datenbankeinheit 35, identifiziert sich mit Zugangsdaten des Bedieners und gibt dem Bediener die Möglichkeit, zwischen verschiedenen in der Datenbankeinheit 35 gespeicherten Previewpaketen 34 auszuwählen. Das Previewpaket 34 wird von der Previewapp analysiert und interpretiert.
Die Appbuildereinheit 16 stellt dem Bediener die Möglichkeit bereit, den zweiten Zwischenschritt S3 zu überspringen.
Ist der Bediener mit den Ergebnissen des Previewpakets 34 zufrieden oder überspringt er den Zwi- schenschritt S3, wird mit einem späteren Verfahrensabschnitt S4 fortgesetzt. Alternativ kann der Bediener zu dem ersten Verfahrensabschnitt S l zurückkehren.
Zu Beginn des späteren Verfahrensabschnitts S4 wird in einem Verfahrensschritt S41 der Bediener aufgefordert anzugeben, für welche Betriebssysteme ein geeigneter, ausführbarer Code 10, 10' erstellt werden soll. Entsprechend bettet in dem späteren Verfahrensabschnitt S4 das Erstellmodul 22 einen gleichen Teil der gewünschten Funktionen und/oder Daten D l , D2, D3, D4 in die Grundcodes 24, 24' ein. Dabei werden beispielsweise zwei ausführbare Codes 10, 10' mit äquivalenter Funktionalität für zwei unterschiedliche, mobile Endgeräte 1 2, 1 2' erzeugt. Die gewünschten Funktionen D3 werden durch automatische Einfügung geeigneter, speziell dafür vorbereiteter Codemodule in den Grundcode 24, 24' bereitgestellt. Ein erster der Grundcodes 24 und die korrespondierenden Codemodule sind in object c geschrieben. Ein zweiter Grundcode 24' und die korrespondierenden Codemodule sind in java geschrieben. Aus dem ersten Grundcode 24 wird in einem Verfahrensschritt S42 ein erster, ausführbarer - -
Code 10 erzeugt, der zu einer Anwendung mit dem Betriebssystem i-OS auf dem ersten mobilen End¬ gerät 1 2 geeignet ist. Aus dem zweiten Grundcode 24' wird in einem Verfahrensschritt S43 ein zweiter, ausführbarer Code 10' erzeugt, der zu einer Anwendung mit dem Betriebssystem Android auf dem zweiten mobilen Endgerät 1 2' geeignet ist. Dabei werden grafische Informationen und Inhaltsdaten D4 in einem von einer Kompilierung ausgeschlossenen Speicherbereich vorgehalten und an den ausführba¬ ren Code 10, 10' geeignet angehängt.
In Fortbildungen der Erfindung ist denkbar, dass mehr als zwei Grundcodes für unterschiedliche Be¬ triebssysteme vorgehalten werden, aus denen ausführbare Codes mit gleicher Funktionalität erstellt werden.
Im Anschluss an die Erzeugung der ausführbaren Codes 10, 10' werden in einem abschließenden Verfahrensschritt S5 die erzeugten ausführbaren Codes 10, 10' bei entsprechenden Verkaufsplattformen 40, 40' eingestellt. Die Verkaufsplattformen 40, 40' sind als Online-Stores ausgebildet, die jeweils auf ausführbare Codes für die entsprechenden Betriebssysteme spezialisiert sind. Alternativ oder zusätzlich ist eine Einstellung bei betriebssystemübergreifenden Verkaufsplattformen denkbar. Wurden von einem Bediener keine Benutzerdaten zu den Verkaufsplattformen 40, 40' angegeben, erstellt die Appbuilde- reinheit 16 automatisch Benutzerkonten auf diesen Verkaufsplattformen 40, 40'. Weiterhin führt die Appbuildereinheit 16 automatisch von einer Verkaufsplattform 40, 40' geforderte Referenzierungs- und Signierungsvorgänge für den ausführbaren Code 10, 10' aus.
Weiterhin weist die Appbuildereinheit 16 ein Wartungsmodul 42 auf. Der Bediener kann auf das Wartungsmodul per Webinterface von beliebigen Endgeräten, insbesondere auch mobilen Endgeräten oder PCs, zugreifen. Der Bediener kann über das Wartungsmodul 42 die grafischen Informationen und die Inhaltsdaten D4, die in der Datenbankeinheit 30 hinterlegt sind, verändern. Weiterhin sind durch das Wartungsmodul 42 Einstellungen eines Benutzerkontos des Bedieners für die Appbuildereinheit 16 und die Benutzerkonten für die Verkaufsplattformen 40, 40' verwaltbar.
Im Grundcode 24, 24' ist ein Modul vorgesehen, das eine regelmäßige, tägliche Aktualisierung des erzeugten ausführbaren Codes 10, 10' auf Basis von in der Datenbankeinheit 30 hinterlegten Daten veranlasst. Hierbei werden lediglich veränderte Daten übertragen, um den Datenverkehr gering zu halten. Weiterhin zeigt Figur 2 zwei Systeme 44, 44' mit der Appbuildereinheit 16 und jeweils einem mobilen Endgerät 1 2, 1 2', das dazu vorgesehen ist, den von der Appbuildereinheit 16 erzeugten, ausführbaren Code 10, 10' auszuführen. Ferner zeigt Figur 2 zwei Systeme 46, 46' mit jeweils einem mobilen Endgerät 1 2, 1 2', jeweils einem ausführbaren Code 10, 10' und zumindest einer Datenbankeinheit 30, die dazu vorgesehen ist, einen Teil der gewünschten Funktionen und/oder Daten D l , D2, D3, D4 des ausführbaren Codes öffentlich zugänglich abzuspeichern. Weiterhin kann vorgesehen sein, dass die Datenbankeinheiten 30, 35 als einzelne Datenbankeinheif ausgebildet sind.
Bezugszeichen
10 ausführbarer Code D l Brancheninformationen
10' ausführbarer Code D2 Layouteigenschaften
1 2 mobiles Endgerät D3 Funktionen
1 2' mobiles Endgerät D4 Inhaltsdaten
14 System SO Verfahrensschritt
16 Appbuildereinheit S l Verfahrensabschnitt
1 8 Speichereinheit S i l Verfahrensschritt
20 Eingabemodul S 1 2 Verfahrensschritt
22 Erstellmodul S 1 3 Verfahrensschritt
24 Grundcode S 14 Verfahrensschritt
24' Grundcode S2 Zwischenschritt
26 Netzwerkschnittstelle S3 Zwischenschritt
28 Fernzugriffsschnittstelle S4 Verfahrensabschnitt
30 Datenbankeinheit S41 Verfahrensschritt
32 Erstellmodul S42 Verfahrensschritt
34 Previewpaket S43 Verfahrensschritt
35 Datenbankeinheit S5 Verfahrensschritt
36 ausführbarer Code
38 mobiles Endgerät
40 Verkaufsplattform
40' Verkaufsplattform
42 Wartungsmodul
44 System
44' System
46 System
46' System

Claims

Ansprüche
1. Verfahren zur Erzeugung von ausführbarem Code ( 10, 10 ), der dazu vorgesehen ist, auf einem mobilen Endgerät ( 1 2, 1 2') ausgeführt zu werden, mit zumindest einer Appbuildereinheit ( 16), die zumindest eine Speichereinheit ( 18), in der zumindest ein Grundcode (24, 24') hinterlegt ist, zumindest ein Eingabemodul (20) und zumindest ein Erstellmodul (22) aufweist, wobei in einem ers¬ ten Verfahrensabschnitt (S D über das Eingabemodul (20) von einem Bediener gewünschte Funk¬ tionen und/oder Daten (D l , D2, D3, D4) eingegeben werden und in einem späteren Verfahrensabschnitt (S4) das Erstellmodul (22) zumindest einen Teil der gewünschten Funktionen und/oder Daten (D l , D2, D3, D4) in den Grundcode (24, 24') einbettet.
2. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Eingabemodul (20) per Fernzugriff bedient wird.
3. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Bediener zur Ausführung des ersten bis späteren Verfahrensabschnitts (S l , S4) keine Kenntnisse über eine geschriebene Programmiersprache aufweisen muss.
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Eingabemodul (20) den Bediener in dem ersten Verfahrensabschnitt (S l ) durch zumindest ein Konfigurationsmenü leitet.
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass von dem Bediener in dem ersten Verfahrensabschnitt (S 1 ) zumindest Brancheninformationen (D 1 ) eingegeben werden.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass von dem Bediener in dem ersten Verfahrensabschnitt (S l ) zumindest Layouteigenschaften (D2) eingege¬ ben werden.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass von dem Bediener in dem ersten Verfahrensabschnitt (S l ) zumindest Inhaltsdaten (S4) eingegeben wer¬ den.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass in zumin¬ dest einem ersten Zwischenschritt (S2) zumindest ein Teil der gewünschten Funktionen und/oder Daten (D l , D2, D3, D4) in einer Datenbankeinheit (30) abgespeichert werden.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die App- buildereinheit ( 16) zumindest ein weiteres Erstellmodul (32) aufweist, das in zumindest einem zweiten Zwischenschritt (S3) zumindest ein Previewpaket (34) erzeugt.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass in der Speichereinheit ( 18) zumindest zwei Grundcodes (24, 24') gespeichert sind, aus denen die Er¬ stelleinheit in dem späteren Verfahrensabschnitt (S4) durch Einbettung zumindest eines gleichen Teils der gewünschten Funktionen und/oder Daten (D l , D2, D3, D4) in den jeweiligen Grundcode (24, 24') zumindest zwei ausführbare Codes ( 10, 10') mit zumindest äquivalenter Funktio¬ nalität für zumindest zwei unterschiedliche mobile Endgeräte ( 1 2, 1 2') erzeugt.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die App- buildereinheit ( 16) in einem abschließenden Verfahrensschritt (S5) den zumindest einen erzeugten ausführbaren Code ( 10, 10') auf zumindest einer Verkaufsplattform (40, 40') einstellt.
System mit zumindest einer Appbuildereinheit ( 16) zur Ausführung eines Verfahrens nach einem der vorhergehenden Ansprüche.
System nach Anspruch 1 2, gekennzeichnet durch zumindest eine Fernzugriffsschnittstelle (28), die dazu vorgesehen ist, auf ein Eingabemodul (20) der Appbuildereinheit ( 16) zuzugreifen.
1 4. System nach Anspruch 1 2 oder 1 3, gekennzeichnet durch zumindest ein mobiles Endgerät ( 1 2, 12'), das dazu vorgesehen ist, zumindest einen von der Appbuildereinheit ( 16) erzeugten, ausführbaren Code ( 10, 10') auszuführen.
15. System nach einem der Ansprüche 1 2 bis 14, gekennzeichnet durch zumindest eine Datenbankeinheit (30), die dazu vorgesehen ist, zumindest einen Teil der in dem ersten Verfahrensabschnitt (S 1 ) eingegebenen, gewünschten Funktionen und/oder Daten (D 1 , D2, D3, D4) abzuspeichern.
16. Grundcode, der dazu vorgesehen ist, durch Einbettung von gewünschten Funktionen und/oder Daten (D 1 , D2, D3, D4) in einem Verfahren nach einem der Ansprüche 1 bis 1 1 in einen aus¬ führbaren Code ( 10, 10') umgewandelt zu werden.
17. Ausführbarer Code, der durch ein Verfahren nach einem der Ansprüche 1 bis 1 1 erzeugt wur¬ de.
1 8. Ausführbarer Code, der dazu vorgesehen ist, auf einem mobilen Endgerät (38) ausgeführt zu werden und dabei eine Funktionalität eines ausführbaren Codes ( 10, 10') nach Anspruch 17 mit Hilfe eines Previewpakets (34), insbesondere nach Anspruch 9, zu simulieren.
19. System mit zumindest einem mobilen Endgerät ( 1 2, 1 2'), zumindest einem ausführbaren Code ( 10, 10] nach Anspruch 17 und zumindest einer Datenbankeinheit (30), die dazu vorgesehen ist, zumindest einen Teil der gewünschten Funktionen und/oder Daten (D l , D2, D3, D4) des ausführbaren Codes ( 10, 10') abzuspeichern.
PCT/EP2011/006560 2011-12-23 2011-12-23 Verfahren zur erzeugung von ausführbarem code WO2013091672A1 (de)

Priority Applications (8)

Application Number Priority Date Filing Date Title
US14/367,279 US20150033203A1 (en) 2011-12-23 2011-12-23 Method for generating executable code
PCT/EP2011/006560 WO2013091672A1 (de) 2011-12-23 2011-12-23 Verfahren zur erzeugung von ausführbarem code
EP12826617.8A EP3245586A1 (de) 2011-12-23 2012-12-21 Verfahren zum aufbau einer verschlüsselten verbindung zwischen zwei kommunikationsgeräten nach vorherigem schlüsselaustausch über eine kurzstreckenverbindung
EP12821112.5A EP2828744B1 (de) 2011-12-23 2012-12-21 Verfahren zum aufbau eines sternförmigen kommunikationsnetzes bestehend aus einem zentralknoten und peripherknoten durch eine vom zentralknoten bereitgestellte web applikation basierend auf hardware identifiern
US14/367,384 US20150052361A1 (en) 2011-12-23 2012-12-21 Method for setting up an encrypted connection between two communication appliances following prior key interchange via a shorthaul connection
PCT/DE2012/100399 WO2013110254A1 (de) 2011-12-23 2012-12-21 Verfahren zum aufbau eines sternförmigen kommunikationsnetzes bestehend aus einem zentralknoten und peripherknoten durch eine vom zentralknoten bereitgestellte web applikation basierend auf hardware identifiern
PCT/DE2012/100398 WO2013110253A1 (de) 2011-12-23 2012-12-21 Verfahren zum aufbau einer verschlüsselten verbindung zwischen zwei kommunikationsgeräten nach vorherigem schlüsselaustausch über eine kurzstreckenverbindung
US14/366,763 US10050839B2 (en) 2011-12-23 2012-12-21 Method for setting up a star-shaped communication network consisting of a central node and peripheral nodes via a web application provided by the central node on the basis of hardware identifiers

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2011/006560 WO2013091672A1 (de) 2011-12-23 2011-12-23 Verfahren zur erzeugung von ausführbarem code

Publications (1)

Publication Number Publication Date
WO2013091672A1 true WO2013091672A1 (de) 2013-06-27

Family

ID=45509412

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2011/006560 WO2013091672A1 (de) 2011-12-23 2011-12-23 Verfahren zur erzeugung von ausführbarem code

Country Status (2)

Country Link
US (1) US20150033203A1 (de)
WO (1) WO2013091672A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8176468B2 (en) * 2005-12-01 2012-05-08 Cypress Semiconductor Corporation Multivariable transfer functions

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1712995A1 (de) * 2005-04-15 2006-10-18 Research In Motion Limited System und Verfahren zur Unterstützung der Verpackung, des Veröffentlichen und des Wiederveröffentlichen von drahtlosen Komponent-anwendungen
US20110161912A1 (en) * 2009-12-30 2011-06-30 Qualzoom, Inc. System for creation and distribution of software applications usable on multiple mobile device platforms

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE202006000135U1 (de) * 2006-01-05 2006-04-20 Framework Systems Gmbh Vorrichtung zum Erzeugen von Programmcode eines Nutzerprogrammes
US8260278B2 (en) * 2006-05-12 2012-09-04 The Mitre Corporation Framework for agile mobile applications
US8261231B1 (en) * 2011-04-06 2012-09-04 Media Direct, Inc. Systems and methods for a mobile application development and development platform
US8739282B1 (en) * 2013-03-14 2014-05-27 Parse, Inc. Mobile development platform in a cloud based architecture

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1712995A1 (de) * 2005-04-15 2006-10-18 Research In Motion Limited System und Verfahren zur Unterstützung der Verpackung, des Veröffentlichen und des Wiederveröffentlichen von drahtlosen Komponent-anwendungen
US20110161912A1 (en) * 2009-12-30 2011-06-30 Qualzoom, Inc. System for creation and distribution of software applications usable on multiple mobile device platforms

Also Published As

Publication number Publication date
US20150033203A1 (en) 2015-01-29

Similar Documents

Publication Publication Date Title
DE10216271B4 (de) Kulturschnittstellenprotokoll-Anwendung, Verfahren zum Schaffen einer kulturspezifischen Benutzerschnittstelle und entsprechendes Computerprogrammprodukt
EP1245430B1 (de) Verfahren und Vorrichtung zur Erzeugung einer Anzeige-Bedienumgebung einer Mensch-Maschine-Schnittstelle
DE102006021400A1 (de) Verfahren und Vorrichtung zum Bereitstellen eines einem dargestellten Symbol zugeordneten Auswahlmenüs
EP3341245A1 (de) Verfahren und vorrichtung zum bereitstellen eines empfehlungssignals zum steuern zumindest einer funktion in einem fahrzeug
EP1589416A2 (de) Verfahren und System zum Erzeugen eines Quellcodes für ein Computerprogramm
DE19960048A1 (de) Zeitgesteuerte Startbedingungen für Aktivitäten in Workflow-Management-Systemen
EP0838054B1 (de) Verfahren und steuereinrichtung für eine graphische steuerung von abläufen in einem netzwerkmanagementsystem
EP2171582B1 (de) Fernbedienung eines browser-programms
WO2013091672A1 (de) Verfahren zur erzeugung von ausführbarem code
DE102018205953A1 (de) Verfahren zum Betreiben einer Bedienvorrichtung eines Geräts, um einen Anzeigeinhalt festzulegen, sowie Bedienvorrichtung und Gerät
EP2642359A1 (de) Entwicklungseinrichtung und Verfahren zum Erstellen eines Steuergeräteprogramms
EP3528473A1 (de) Verfahren, client-computer und computerprogramm zur ausführung von quellcode an einem client-computer
EP2220557B1 (de) Implementierung des user interfaces von mobiltelefonen auf basis von browser technologie
DE102005018864B4 (de) Verfahren und System zum Erzeugen eines Quellcodes für ein Computerprogramm
DE10085323B4 (de) Einrichtung und Verfahren zum dynamischen Sichtbarmachen der Fähigkeiten und zum Konfigurieren von Hardwaregeräten eines Computersystems
DE69425894T2 (de) Anordnung und Verfahren zum Erstellen von Software
EP2632191B1 (de) Verfahren zum Ausgeben von Interaktionselementen
DE102018115630B4 (de) Verfahren zum Erstellen und Betreiben einer Website mit Eingabemöglichkeit
EP2184678A1 (de) Automatisierte Generierung einer Computer-Applikation
DE102008045123B4 (de) Assistenz- und Informationsvorrichtung in einem Kraftfahrzeug sowie Verfahren zum Ausgeben von Informationen
WO2018072776A1 (de) Verfahren und system zur auswahl und darstellung von webseiteninhalten
DE10306810B4 (de) Verfahren und Anordnung zur Darstellung von Software-Assistenten auf mobilen Endgeräten
EP3117303B1 (de) Container mit einheitlichem look and feel mehrerer applikationen
DE202021103037U1 (de) System zur Darstellung von Prozessgrafiken in der Prozess- und Anlagenautomatisierung
DE102021126062A1 (de) Verfahren und System zum Konvertieren von Daten aus einem Ursprungsdateiformat in ein Zieldateiformat

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11811011

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2011811011

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 14367279

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 11811011

Country of ref document: EP

Kind code of ref document: A1