Open Radar

 
SUMMARY
As you may well know, extending a UIActivity requires the programmer to override a few methods.

The methods that are unequivocally required to be overridden are:
- (NSString *)activityType;
- (NSString *)activityTitle;
- (UIImage *)activityImage;
- (BOOL)canPerformWithActivityItems:(NSArray *)activityItems;
- (void)prepareWithActivityItems:(NSArray *)activityItems;

The programmer also has to override one and just one of the following:
- (UIViewController *)activityViewController;
- (void)performActivity;


THE ISSUES
This API presents some issues regarding how programmers extend a UIActivity:

1. activityType's only use for the programmer is to be able to exclude it from the UIActivityViewController. This renders useless as the programmer can instead not add it to the applicationActivities.

If an id is internally required, it should handled internally and thus transparently to the programmer.

2. prepareWithActivityItems: just doesn't need to be there. It runs after the user has tapped on the UIActivity and practically immediately after this method is done, the activityViewController or performActivity is called, making it useless to be on a separated method.

The activity items should be passed as a parameters to whatever method performs the activity.

3. Having to choose if the right method to override is activityViewController or performActivity is for ones confusing and for seconds restrictive, since the programmer needs to decide on build time if the activity will be silent or if it will present a UIViewController.

Both activityViewController and performActivity should be unified into a single method that will allow the programmer to decide if he wants to show a UIViewController or not while performing the activity.


THE REQUIREMENTS
Main:
* The programmer must be able to decide in run time if he wants to present a UIViewController or run in background, by using a unified method, to perform the activity.

Secondaries:
* The programmer shouldn't have to override a separate method to prepare the activity items while it could be simple sent as a parameter to the unified perform activity method.
* The programmer shouldn't have to deal with the activityType at all.


A PROPOSED SOLUTION
This project (attached also) is a sample of how much easier it is to extend a UIActivity with this proposed changes, while loosing none of its great functionality.

https://github.com/marianoabdala/ZYActivity


SUPPORT
The project was featured on:
http://iosdevweekly.com/issues/71/
http://uiactivities.com/post/37633196615/zyactivity-an-easier-to-inherit-uiactivity

Also, in 9 days it gathered over 30 stars on GitHub, which I interpret as support or preference over the regular UIActivity API.


THANKS!
For taking the time to read through this and for being open to suggestions.