5

Background

Public custom settings included as part of a managed package can be maintained by users of the target org if they have the Customize Application permission, which seems somewhat heavy handed, but it does work.

Protected custom settings are completely hidden, and can not be accessed via the GUI or via Apex; given that any records in the custom setting are not included in the package (i.e. it's empty in the target org). They could me modified and accessed via code in the managed package, so you could use them to store some dynamic values as determined by a user of your code/page.

The question:

If I wanted to use a list-type custom setting in a managed package in one of the most common use cases (i.e. storing a list of values I want cached, such as state codes) does this mean the only way to do so would be to check if there are any values there, insert a list if not, and then read them?

The insert would only happen the very first time and after that the caching would be efficient, but it seems like a bit of a work around for when you just want a static list—you might as well just use a static array inside a class.

Improve this question

3 Answers 3

Reset to default
10

I would recommend using the new Install Script functionality of managed packages. You could initialise the list when the package is installed (saves having to do the check in code you are proposing)

Link to the InstallHandler interface documentation

Improve this answer
5

I think there are three considerations here:

  1. Is the data static, or will it change as a result of user interaction
  2. How much data is involved
  3. Is the data identical for every subscriber

Custom settings are designed to be used where data is "written seldom and read often". If the data doesn't change then perhaps "written once read often" might be better provided in an Apex static Map as you say.

If you use a static map though you of course pay an overhead of script statements for initialisation and heap usage, so as the size of data increases, this approach becomes more expensive to your package-scoped governors.

If this cost is prohibitive, then as you suggest list custom settings will serve, and the answer already posted to use install scripts is a good one. However, the total size of custom settings is governed, and I think this is scoped to the org as a whole, and not to your package alone.

If the data may differ between subscribers then of course a static Apex Map will not do, and a protected list custom setting is the way to go. For a package publisher to be able to manipulate an individual subscriber's data in a protected custom setting using subscriber access in the publisher's LMO is a great strength of protected custom settings.

So, if the amount of data is relatively small, is static and identical across subscribers, I would opt for an Apex static Map.

Improve this answer
2

You mentioned state lists, I suspect you have other settings going in there but as an FYI in Spring 13 SFDC finally is releasing - State and Country Picklists — Beta

https://na1.salesforce.com/help/doc/en/salesforce_spring13_release_notes.pdf

Page 117

Improve this answer
1
  • 1
    Yeah, I used that just for an example — I knew it was coming up but it's also one that everybody can relate to :)
    – Matt Lacey ♦
    Jan 11, 2013 at 3:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .