Using Resource Files with your Power Apps

A lot of developed solutions use a resource file (sometimes more than one) to store the UI strings. There are reasons why this kind of file is used:

• Encoding: the content of the files can be encoded (in UTF8 mostly) to avoid issues with the display of special chars
• Only one place contains all strings
• Reusable
• No need to put the fingers into the code, mostly after several months to fix a typo
• Facilitate the maintenance of the application
• Easier to manage multilingual application
• A developer can use it to be consumed by the code and the file can be easily shared with people, to perform proofreading or translations independently of the application life cycle

With Power Apps, you can use several ways to do it. We will see two of them.

Principle

Whatever the solution, the base of the resource file is still the same:

1. ID: a unique identifier for technical purposes mainly (a number or a GUID). Use an incremental number beginning by 1
2. Lang: mandatory if your application supports MUI. If your application does not support multilingual, it is not necessary. If you do not know it yet, or if your application can potentially supports other langs, it is preferable to use it
3. Key: the identifier used by the application to get the displayed string
4. Value: THE STRING that will be displayed in your application

Example

The SharePoint List

The big advantage of this method is that it is easy to implement, and you can update the strings directly from a SharePoint list without editing the application - and anybody can do it.

There are some points to consider:

1. Anybody who needs to access the application must have access to the SharePoint list in read-only mode at least
2. It is necessary to add a provisioning script or a list template to a dedicated SharePoint site for each application that uses this method
3. Using only one site collection for all applications, and can be an advantage
4. Using SharePoint becomes a prerequisite. Some easy applications do not need this
5. SharePoint can be slow to return the list item, and your application and the user experience can be affected
6. Because it is easy to add, edit or delete an item, it can therefore become dangerous. It is necessary to manage the different permissions levels and users with sufficient rights must be careful (well trained)
7. It can increase considerably the number of requests against the SharePoint service. If too many requests are sent, the SharePoint service can block some of them (threshold)

Maybe some other technical points can be found. All this to say, use it sparingly 😉

[note]Note

However, a SharePoint list is really useful to store the settings of an application

The Excel File

Such as a lot of other kinds of applications, a file to store the strings can be used with Power Apps.

There are some points to consider:

1. The Excel file can be embedded into the application (the size of the application will be increased in accordance with the weight of the resource file)
2. The Excel file can be called from a SharePoint site (one call to get a file). In my case, I can not successfully import an Excel file from a SharePoint site. Always the same error (I will update this post once I found a solution 😉)
3. It is possible to share it and update it in the application directly or by updating the file from the SharePoint site (if the connector works)
4. Everyone knows how works Excel. It's much easier to explain how to maintain it than a SharePoint list (sometimes 😁 not need to have SharePoint skills)

• Tags:
• Power Platform
• Power Apps
• Excel
• Getting Started
• Microsoft 365
• SharePoint