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

Allow a default subject to be provided #41

Closed
irace opened this issue May 6, 2015 · 4 comments
Closed

Allow a default subject to be provided #41

irace opened this issue May 6, 2015 · 4 comments
Milestone

Comments

@irace
Copy link
Contributor

irace commented May 6, 2015

As per @prendio – allow a default subject to be provided rather than explicitly registering subjects for individual activity types using the registerSubject:forActivityType: method added in this pull request.

(This isn’t particularly pressing since there isn’t public API for extensions to read this value, and only Mail and Messages support subjects out of the built-in activities (which only change once a year, at most), but we only just realized that the latter does yesterday, so who knows what else we could potentially be missing?)

A couple of options:

  • Use the attributedTitle value if it exists and a subject was not explicitly registered for a given activity type
  • Add a @property (nonatomic, copy) NSString *defaultSubject; property
  • Document that calling registerSubject:forActivityType: with a nil activity type will register it as the default. I think I like this one the best.

Thoughts?

@prendio2
Copy link
Contributor

prendio2 commented May 6, 2015

registerSubject:forActivityType: with nil activity seems like a good call to me

@AriX
Copy link
Contributor

AriX commented May 6, 2015

Using attributedTitle as a fallback default also seems like a good idea.

@irace
Copy link
Contributor Author

irace commented May 6, 2015

I think either would be good but this issue spelling out how complicated the API is becoming might be a compelling reason for favoring attributedTitle.

@irace
Copy link
Contributor Author

irace commented May 11, 2015

Closing in favor of the refactor proposed in this issue: #43

@irace irace closed this as completed May 11, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants