Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace +load usage in NSValueTransformer / AWSMTLValueTransformer configuration #4288

Open
bdfreese opened this issue Aug 30, 2022 · 1 comment
Labels
core Issues related to AWSCore feature-request Request a new feature

Comments

@bdfreese
Copy link

Not sure if this really qualifies as a bug, so filing as a feature request.

Which AWS Services is the feature request for?
Not a particular service, but AWSCore/Mantle (related to AWSMTLValueTransformer / NSValueTransformer)

Is your feature request related to a problem? Please describe.
While reviewing the SDK for integration into our application, we noticed there is use of the +load method within AWSCore. The implementation of +load here ensures these transformers are registered with NSValueTransformer in time for usage; however +load runs as soon as the framework is loaded into the application's process memory, so this code will be run on (pre-)launch of the app and take up some time there, even if the user never interacts with, e.g., a specific feature that actually uses the SDK within the app. While this specific code is pretty minimal, it's not ideal to have it run on every launch, even if the SDK is never actually used. As of iOS 15, the system may load dependencies/frameworks well before the user even tries to launch the app, so this is even less ideal in more recent iOS versions.

Describe the solution you'd like
A different/lazier approach to registering these value transformers; maybe using +initialize on some central AWSCore class.

This doesn't seem quite as trivial as changing +load->+initialize, since the first usage of custom transformers could be within that same method, and +initialize is lazily called on the first message to the class.
That said, it looks like AWSMTLValueTransformer is used in many of the model classes, so maybe having an +[AWSMTLValueTransformer initialize] method would suffice for cases where having the transformer registered would actually matter (I think this only wouldn't work if the SDK uses NSValueTransformer itself instead of AWSMTLValueTransformer at some point where the custom transformers would be needed).
Otherwise, if there happens to be some class within AWSCore that would always be messaged before the SDK did anything with the transformers (perhaps a model base class like AWSMTLModel), an +initialize method there could work too; or perhaps some other 'lazy registration' approach not involving load or initialize at all exists.

Describe alternatives you've considered
N/A

Additional context
Some relevant links/documentation:

  • "Value transformers are typically registered by an application’s delegate class, in response to receiving a initialize: class message. This allows registration to occur early in the application startup process, providing access to the value transformers as nib files load." - Value Transformer Programming Guide
  • "For example, NSValueTransformer or NSURLProtocol subclasses can't use +initialize to register themselves with their superclasses, because you set up a chicken-and-egg situation." - mikeash.com
  • Apple's initialize/load docs
  • Apple's prewarming docs
@royjit royjit added feature-request Request a new feature core Issues related to AWSCore pending-triage Issue is pending triage labels Sep 2, 2022
@atierian
Copy link
Member

Thanks for opening this feature request @bdfreese. We appreciate the thorough details and considerations you included. We'll respond here with any updates.

@atierian atierian removed the pending-triage Issue is pending triage label Dec 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Issues related to AWSCore feature-request Request a new feature
Projects
None yet
Development

No branches or pull requests

3 participants