Text view is a readable representation of the type as character string. Let’s assume we know a person called Jonh Smith. In different contexts, we might need to refer to him as “John”, “John Smith” or “Mr. Smith”. To be able to do it, we have to define 3 different Text views on type Person:
1) “<First name>”,
2) “<First name> <Last name>”,
3) “<Salutations>. <Last Name>”.
This example illustrates the basic idea behind the text views. If we define a new Text view on type Foo and it has to include a reference to another complex type Bar, it is possible to specify which one of the type Bar Text views 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 Text view 2) of Person type from the 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 text views. No security check is performed when searching on text views. This means that text views should not contain sensitive information or should be marked as “Do not list in search results”.
Text views are pre-built. When a view is created or changed, it triggers the update or creation of text view data during the first deploy of the application after such changes. If an updated application instance contains a large number of records over which text view has to be built, it might cause a delay at the start-up of the application.