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

Support for vectorized masking #4

Open
Mazyod opened this issue Aug 7, 2014 · 5 comments
Open

Support for vectorized masking #4

Mazyod opened this issue Aug 7, 2014 · 5 comments

Comments

@Mazyod
Copy link
Collaborator

Mazyod commented Aug 7, 2014

Hey!

I thought I'd start an issue with this new task I am tackling, so I can dump the ideas and issues I com across..

First thing's first, what is this about?

To make the component as not dissimilar as possible, the component needs to draw the splash view with a clipped shape in the middle. That shape would animate out by expanding until it essentially takes over the whole view. At that point, the view behind should be fully visible. So, there is no fading here.

@Mazyod
Copy link
Collaborator Author

Mazyod commented Aug 7, 2014

So, the first issue I came across is: How to handle the current implementation?

I think the current implementation is useful by itself, and could be used, so I won't be replacing it. I am, however, seeing two possible approaches:

  1. Add a new init method that takes a UIBezierPath, and save the bezier path.

The issue here is, everywhere in the code, we have to add if statements. Check if we are using the bezier path, then do this, otherwise do nothing. Same thing for the image.

Here is an example:

- (void)drawRect:(CGRect)rect
{
  /* Only override draw rect for vectorized splash screen */
  if (!self.bezierPath) {
    return [super drawRect:rect];
  }

  CGContextRef context = UIGraphicsGetCurrentContext();
  CGContextAddRect(context, self.bounds);
  CGContextAddPath(context, self.bezierPath.CGPath);

  [self.backgroundViewColor setFill];
  CGContextEOFillPath(context);
}
  1. Provide an abstract superclass interface, and have different implementations in two subclasses.

I think this is a better approach, since it modularly separates the two functionalities. We should also hide those classes from the user, and provide a convenient "factory" method, since the user doesn't need to worry about the exact subclass he is using.

From this, I realized there will be some major overhauls to the component, but it will be hidden within the component.

Maz

@callumboddy
Copy link
Owner

Yep, I do like this idea. There is no need to worry about overhauling, it is one of the reasons the Pod is still 0.1.1. I think it is a really good idea as we should be able to mimic the twitter animation exactly.

I am happy for you to go ahead with either of these approaches.

@callumboddy
Copy link
Owner

A couple of other features to consider as well:

  • adding a background image/pattern behind
  • not masking the icon

what is your opinion here?

@callumboddy
Copy link
Owner

I am also going to have a look at creating some new unique transition styles the user can then select from.

@Mazyod
Copy link
Collaborator Author

Mazyod commented Aug 7, 2014

I love the transitions idea! Maybe you can create a new issue for each feature/bug?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants