- Description
- General App Concept
- The Concept of Modules in B1
- Conclusion of the concepts
- How to use it
- 1. Create an App
- 2. Create a Module
- 3. Launch App
- Attributes
Description
Apps can be created in Build.One using the SwatApp object type. When creating them, an initial screen, theme and some other configurations can be set. An app can be exported to deploy it as a standalone environment on a selected server, see Application Deployment via Portainer .
General App Concept
An application can be created in B1 using different approaches. For this, the following approaches are available:
- One app per repository
- An app can be separated by creating and managing it in its own repository.
- Advantages:
- The app and the data are fully separated from other applications created with B1
- Disadvantages:
- Each of the repositories must always be kept up to date
- Apps have difficult access to functions and data from other B1 apps
- One repository with multiple apps
- A repository can be used to create and manage multiple applications. The apps and modules have access to the different functionalities. App A is able to call functions from App B. In Application Deployment via Portainer , the apps are then separated by the "DEFAULT_APP" attribute in the deployment .yml. However, in the deployed environment, it is possible to access the functions of all applications if the technical flow allows it.
- The apps are then displayed either individually or together via a designated menu structure. This is controlled by the Main Menu Code attribute in the SWAT App object, which is filled with the menu structure code. The following image shows how the menu structures are set up. In 1 & 2 you can see the apps separated from each other. If you only enter the code "AAS" or "ABS" in the Main Menu Code attribute of the SWAT APP object, you will only see the screens that is in the folders. If you want to display both structures in one app, you have to create a combined structure as shown in 3.
- Advantages:
- The apps can access their functionalities among each other
- The one repository is the single point of truth and thus only needs to be maintained once
- Disadvantages:
- The app data and flows are not isolated from each other
The Concept of Modules in B1
Modules are used in B1 to logically separate objects.
- An app can contain N modules.
- A module belongs to an app.
- Apps can also access objects that are not in one of their own modules.
A module can be thought of as a folder structure to help you find objects in B1 more quickly. Suggestions could be:
Suggestions for module naming in B1:
- AutoGenObjectsAppA → Here you can collect all base objects that were created with the Quickbilder.
- AutoGenObjectsAppB → Here you can collect all base objects that were created with the Quickbilder.
- <Functional area> → E.g. OrderObjects, SalesObjects, WarehouseObjects
Defining modules is important. This is because the base folder that you specify when creating modules is where the objects in the repository/gitpod are stored. The objects created in B1 are usually in the form of .JSON or .smartrepo files. These are created in B1 and then need to be exported from B1 to Gitpod/Bitbucket in order to be persisted. With the modules we tell B1 where to export the objects in the source code overview and in which structure to store them.
Conclusion of the concepts
In B1, applications and modules play a crucial role in the structuring and design of applications. Modules are used to logically divide applications, allowing for better organisation and management of functionality. In addition, applications can be managed either within their own repository or collectively within a repository that handles multiple applications.
The menu structure plays a pivotal role in controlling the visualisation of the app, providing users with a seamless navigation experience. Through strategic menu design, users can efficiently access different features and functionalities within the application.
A notable advantage is the ability to manage multiple apps within a single repository. This approach significantly reduces the effort required for updates and maintenance. In addition, the consolidation of applications within a repository enables seamless integration and the creation of enhanced workflows within the B1 environment.
In addition, applications have the ability to access objects within different modules, promoting interoperability and enabling developers to create cohesive and connected experiences for users. This connectivity enhances the overall functionality and usability of B1 applications, contributing to a more efficient and streamlined user experience.
How to use it
1. Create an App
- Go to Designe → Applications in the sidebar
- Click on “Create new App”
- Complete the data for your application (Check App - Attributes for more info)
- Click on Create
2. Create a Module
- Go to Designe → Applications in the sidebar
- Select the floating action button in the bottom right corner and click on the plus
- Fill out the form
- Module Name → Name of the module
- Application → Select the created application where it belongs to
- Data folder → Call it like the module
- Press confirm to create the module
3. Launch App
Once you have created your application you can test it by launching it
- Go to Applications in the sidebar
- Select the App that you want to launch
- Click on Launch Application or double click the app in the card view
- See your application in a new tab of your browser
Attributes
Attribute | Description | Example/Values |
Code | Unique identifier in the system of the App | String |
Name | UI or readable name of the App | String |
Description | Long text that describes the App | String |
Theme | Initial theme that is loaded when the App is opened | Theme |
Login Screen | Screen that is used in the login | Screen |
Startup Screen | Screen that is used as home screen once the user has logged in | Screen |
Base Layout Screen | Screen that defines the layout for the whole app, things like Taskbars or the area to open windows are adjusted with this Layout | Screen |
Main Menu Code | ID of the menu that is going to be used in the sidebar | Menu ID |
Background Image | Image that is placed as background of the application | Image |
Translation File | Path to the json with translations | Path |
Back to Documentation
Back to Home Page