String view is a representation of the type as character string. Let’s assume we know a person called Jonh Smith. In different contexts we might need refer to him as “John”, “John Smith” or “Mr. Smith”. To be able to do it, we have to define 3 different String views on type Person:
1) “<First name>”,
2) “<First name> <Last name>”,
3) “<Salutations>. <Last Name>”.
This example illustrates the basic idea behind the string views. If we define a new String view on type Foo and it has to include reference to another complex type Bar, it is possible to specify which of type Bar String view should be included in the Foo’s view that is being defined. For instance, if we have a type “Monthly salary”, it might be necessary to represent it in the following format “February 2018 – John Smith”. When defining this view, we would specify that String view 2) of Person type from above example should be used.
The view’s maximum length is 128 Unicode characters. In application search is performed on data that appears in the string views. No security check is performed when searching on string views. This means that string views should not contain sensitive information or should be marked as “Do not list in search results”.
String views are pre-built. When a view is created or changed, it triggers update or creation of string view data during first deploy of the application after such changes. If updated application instance contains a large number of records over which string view has to be built, it might cause a delay at a start-up of the application.