--- title: "Configuration of FieldBuddy Swift" canonical: "https://help.fieldbuddy.com/space/FBDOCS/blog/4860149762/Configuration%20of%20FieldBuddy%20Swift" format: markdown --- ## Introduction  FieldBuddy Swift is an application based on a custom configuration This configuration allows us to build the application the way we want by adding or removing screens, fields, components, validation, condition rendering and events. By using this custom configuration, we can provide an unique application based on what each customer wants to have and use.  This blog explains briefly the creation of the configuration, its usage and its contributions to FieldBuddy Swift quality for customers. The team provides a fully customized application that suits the needs of the customers. Everything can be built according to the demand. Enjoy reading! ## How is the configuration built?  Let’s get a bit deeper in this configuration. What is the configuration and how is it made? The FieldBuddy Swift configuration depends on 2 components: the Briefcase and the Configuration. Briefcase determines data model for mobile application, while Configuration contains information about UI elements and interactions. ### The Briefcase  The first part of the FieldBuddy Swift configuration consists of the Salesforce data model that we want to use in the application. We describe entities that we want to use in the FieldBuddy Swift application by referring to specific salesforce objects and fields, as well as relationships between objects. Those relationships will build our data as a graph of objects that the application will display. Here is a quick example of what is used in FieldBuddy Swift :  ![image](media://859a29a2-9b31-4952-82ec-faab46623698) For example: if we want Swift to use an object called work order, we can link it with many items that we add in the application. Also, few attachments can be added to a single work order or item.  This briefcase has to be valid (that can be checked in the Salesforce configuration editor tool that we use) before being used. That is because we can’t use a field that doesn’t exist in our objects. For example, if we want to display the name of an object we need to provide the name field in the briefcase for that object. Also, if we want to add a field that doesn’t exist or if we make a mistake in the name, we will have an error in the configuration validation because it must exist in the briefcase. The following configuration of the briefcase allows the usage of Id, name, created Date and product type fields for a product. Swift will receive data for mentioned objects with declared fields including the metadata. ![image](media://619d6ccf-1d3a-46ac-b2a2-f53746eec33b) If a customer has any custom, non-standard Salesforce fields, they can be added to Swift via the briefcase by just declaring them.  All the fields created in Salesforce and added to the briefcase have a specific defined type (like string, date, picklist, number, boolean and so forth). Those types are retrieved from the metadata when Swift gets them. Thanks to metadata, Swift is able to recognize the types and build fields in the application. Here is an example of metadata given for Work Order object in Salesforce:  ``` "prefixid": "a0j", "plurallabel": "Work Orders", "name": "FIELDBUDDY__Work_Order__c", "label": "Work Order", "fields": [ { "updateable": false, "type": "ID", "scale": 0, "referenceToRelationshipNames": [], "referenceTo": [], "precision": 0, "picklistvalues": [], "name": "Id", "length": 18, "label": "Record ID", "controllerName": null, "accessible": true }, { "updateable": false, "type": "STRING", "scale": 0, "referenceToRelationshipNames": [], "referenceTo": [], "precision": 0, "picklist values": [], "name": "Name", "length": 80, "label": "Work Order Name", "controllerName": null, "accessible": true }, ``` We can see in the metadata that the name, type, label, and other properties of fields are defined directly. Thanks to that, Swift will read the metadata and will automatically know how the element needs to be built in the application. ![image](media://c83754ff-3734-48a8-aa51-3602c2dd20ed) Some fields are editable and some fields are notSwift will also read this information and allow the user to edit or not. That is why we can edit some fields of a work order details but some other fields like the name or the ID not. After the briefcase is correctly set up, we can build the second part of the configuration. ### Configuration file The second configuration part is a file that provides every information that will allow us to build the UI of the application. It contains the settings, apps and screens.  We will see what is possible to do in the configuration with few examples in the possibilities part. ## Customization So, as we can see, we are able to add and remove apps, screens and sub components from the config. Also we can fill them with components and everything that we need to build the UI. Swift is very much customizable on demand and we can do nearly everything. However, a customer can ask us if he needs to add a particular component or field an element of the application. That’s what configuration is all about. ### Field customization Add or remove fields in the config, link them with data binding from the Salesforce back-end. Display them how you want, replace their label and so forth. Configuration allows us to provide every type of field that we want, no matter if it’s a date, a picklist with custom values, or a simple text. | | | | --- | --- | | ![image](media://8c4549d4-47c4-41c2-a044-a320f0965655) | ![image](media://925b8a73-ab5b-4cf0-9d75-8fcbf06264ea) | | | | | --- | --- | | ![image](media://cd0406ab-7b5a-4190-9107-256cae4da24c) | ![image](media://56925dc6-986b-4821-a6cf-3d5cfa3e6088) | ### Conditional rendering FieldBuddy configuration allows us to set up conditional rendering for the application components. We can build a custom condition for components that will hide the component if the condition is not validated. If we want to, we can provide multiple conditions for a single component. Conditional rendering is when we want to display something depending on an event or a value. For example if we have a work order, we can display some fields that won't be visible if we have a location based work order. For example, the following field can be displayed only if the work order type is an installation. ![image](media://04e37dcd-f6aa-490e-8302-fdb57d9b286b) For this example, we also have some lock icons that are displayed because the work order is closed, so we won't be able to update it. If the work order is open or in process, those icons will not be displayed and we will be able to update the work order information. For this, Swift is updated when syncing data from Salesforce. When it retrieves the data, it will update the app content depending on the data. Also, conditional rendering will also be updated since some parameters have been changed. ### Events We can also add custom events such as redirections when a custom condition is filled. That allows us to navigate through the application without using a routing system. ## Multiple apps support As mentioned above, one of the features of the configuration file is that it supports multiple applications for FieldBuddy Swift . Thanks to that, we can now have our Work Orders Application but also the Time Registration Application directly in Swift. Also, each app is given a proper independent configuration. Thanks to that, we can add or remove a screen or a component in each application. This is an example structure of FieldBuddy Swift configuration that supports multiple apps and allows us to customize the information and components displayed in the screens. It is possible to navigate through the different applications from the application drawer menu as we can see in this picture :  ![image](media://8c8264f4-2712-4938-80f2-50e726099061) Also, applications included in FieldBuddy Swift are defined in the configuration :  ``` "apps": [ { "name": "WorkOrders", "defaultScreen": "WorkOrders", "title": "${Label.WorkOrdersApp}", "defaultTitle": "Work Orders", "icon": "briefcase", "default": false, "screens": [...] }, { "name": "TimeRegistration", "defaultScreen": "TimeRegistrationDashboard", "title": "${Label.TimeRegistrationApp}", "defaultTitle": "Time Registration", "icon": "clock-o", "default": true, "appSettings": { }, "screens": [...] }, { "name": "WorkOrdersAssignment", "pluggableByDefault": false, "title": "${Label.WorkOrdersAssignment}", "icon": "user", "defaultTitle": "Google with Params", "url": { "isVisualForce": false, "endpoint": "https://www.google.com/search", "params": { "q": "${CURRENT_WORK_ORDER}" } } ] ``` Excepting screens, each application is given various properties and settings. In those properties we can provide the name and logo of the app in the drawer menu, the default screen of the app which will be the first screen displayed and also define if the application is the default application or not. Some applications can be custom built applications like Work Orders and Time Registration, but it is also possible to add a simple link to the website of the customer company or to the FieldBuddy support for example. ## Now, what’s next ? Despite all the good effects and advantages of this configuration and the way it is built. It can still be difficult to use and understand because it is a very big file that contains a lot of information.  Also, it can take a lot of time to build the precise configuration that we want to use because it is  constructed as a very big JSON file. In the future, we want to improve the usage of the configuration and make it easier to build and understand. We could think about a generator for the configuration. This generator could allow us to select the FieldBuddy Swift version that we want to use and show everything that we can put in the configuration, depending on the application, screen or component selected and fill in the information that we want in order to customize the application. Also, this tool would be very useful to show what is missing or what can be added in the configuration. It would tell us if we miss or fail a requirement in the configuration and block the generation until it is correctly added or updated. **Author : **AMARY Clément, intern in FieldBuddy development team [Clément's Linkedin](https://fr.linkedin.com/in/cl%C3%A9ment-amary-8a7532194/en)