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

Finished the full view documentation #55

Merged
merged 22 commits into from
Mar 9, 2017

Conversation

jacksontaylor13
Copy link
Contributor

Started adding in the documentation for the sort functions and finished the documentation for all of the full view animation extensions.

Started adding in the documentation for the sort functions and finished the documentation for all of the full view animation extensions.
Found a small memory leak in the library that needed to be fixed. Turned out that Spruce was holding onto the  objects so we needed to make sure that it was a weak reference. If that  goes away then we will simply skip it.
Currently we don't have time to allow the example app to support landscape orientation. To fix this, we will just lock it to portrait. Down the road this is something we plan to change.
On smaller devices the start selector was not being shown fully. Added this selector so that it does onto the next line rather than cutting off the title.
Copy link
Collaborator

@mattyohe mattyohe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leaving 2 comments for now. That's as far as I got in review.

@@ -93,6 +100,9 @@ public extension UIView {
}
}

/*
As a nicety, if the view is fading in then we know it does not need to be visible. So let's hide the view so that it does not intercept any touch events while it is transparent.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment seems to state the opposite of what happens later?

if the view is fading in then we know it does not need to be visible.
So you set isFading to true.

let's hide the view
It appears on line 119 you check to see if isFading is true, and then if it is, I expect you to hide the view. You however set isHidden to false?

@@ -93,6 +100,9 @@ public extension UIView {
}
}

/*
As a nicety, if the view is fading in then we know it does not need to be visible. So let's hide the view so that it does not intercept any touch events while it is transparent.
Copy link
Collaborator

@mattyohe mattyohe Mar 7, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

intercept any touch events while it is transparent.

I don't believe UIKit allows a transparent view to receive touches.

Rather than using a label inside a scroll view to try and remove the wrapping, placed the code inside a unscrollable . This allows the text to be wrapped and also copied.
Since there were quite a few comments, it made it easier to put them all in one pull request. This way we could both avoid
merge conflicts and try to get everything so that nothing is left out. In this PR, I renamed all of the `Spruce` methods
so that they don't include the prefix.
Since `Swift` extensions are essentially categories in objective-c, we need to make sure that
we prefix each of the methods with an identifying symbol. To do so, we changed methods such
as `spruceUp` to `spruce_up` so that the prefix is `spruce_`. Anywhere we have a extended method
this prefix is attached.

The question is whether or not `spruce_` is a good prefix. Whether we should keep it or change it?
And with this new prefix should we change any of the method names so that they make more sense.

We were playing around with the idea of `spruce_animate` instead of `spruce_up`. Let us know your
thoughts :)
This PR will rename the methods back to their initial state. Also changes around some enums so that their values make more sense lyrically.
In order to avoid conflicts with namespaces, we took the computed variable approach. This would entail creating a `Spruce`
struct that would encapsulate a `UIView`. This way you would simply call `view.spruce.animate` rather than having to use
`view.spruceAnimate`. This looks a little bit cleaner and will show all methods under that one variable.
@jacksontaylor13 jacksontaylor13 changed the base branch from documentation/sort-functions-documentation-2 to develop March 8, 2017 18:58
@jacksontaylor13 jacksontaylor13 merged commit 84dbf87 into develop Mar 9, 2017
@jacksontaylor13 jacksontaylor13 deleted the documentation/sort-functions-documentation-3 branch March 9, 2017 19:11
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

Successfully merging this pull request may close these issues.

2 participants