Now supports customized footer text attributes.

[diegoreymendez]

This fix allows for the customization of the footer's UIBarButtonItem global-appearance text attributes without CTAssetPickerController overriding it.

For example:

[[UIBarButtonItem appearance] setTitleTextAttributes:@{NSFontAttributeName:[UIFont systemFontOfSize:10], NSForegroundColorAttributeName: [UIColor whiteColor]} forState:UIControlStateNormal];

Another alternative to this fix could be to remove from CTAssetsPickerController.m the code that sets the footer's UIBarButtonItem text attributes.

[diegoreymendez]

Please @chiunam, let me know if you think there's a better solution to this issue.

[diegoreymendez]

Fixes this issue.

[1and2papa]

Hi @diegoreymendez, I prefer making the control to conform UIApperance rather than using properties for UI customisation. I made an experiment code [ae80272] to change the toolbar for that so it can be overridden by code like this:-

UIBarButtonItem *barButtonItem = [UIBarButtonItem appearanceWhenContainedIn:[UIToolbar class], [CTAssetsPickerController class], nil];
[barButtonItem setTitleTextAttributes:@{NSFontAttributeName:[UIFont systemFontOfSize:10], NSForegroundColorAttributeName: [UIColor redColor]} forState:UIControlStateNormal];

Please share your thought.

[diegoreymendez]

Hi @chiunam,

I've just tested it and it does indeed work. If you want to push this it'll be ok for us. Trying to conform to UIAppearance sounds like a good path.

My only concern: This will still override the parent project's default UIAppearance at first, even though it can be overridden again after the picker's creation. Could be tricky for the caller to figure this out. It would be really sweet if the picker didn't override previously set defaults (although I couldn't find a way to achieve this to be honest - that's why I chose the property at first).

A possible third alternative could be to just remove the appearance configuration from the library, and let your demo app set that up... although this would effectively make the library use the system colors by default when called by another app.

It seems like all solutions have pros and cons, so any of the proposed solutions would be ok for us. Just let me know what you decide and we'll modify our project accordingly.

Thank you very much!

[1and2papa]

I think it is fine to set appearance again after picker's creation as it follows lazy initialisation concept. Though I want to make it easier for guys using default UIAppearance proxy like you, I find no ways to get the values from default proxy.

The experiment code will be merged to the master branch. Stay tuned.