-I use table view headers in my app, so this was my main motivation for this pull request. These no longer get overwritten.

-UITableView is a UIScrollView, so no reason (as far as I can tell?) to have separate functions for each. attachToTableView now calls attachToScrollView.

-beginLoadingAnimated allows you to choose if you want to animate the appearance of the refresh control, or have it show up instantly. Also, in my previous pull request, I didn't set the state to Refreshing in beginLoading, which was causing problems, so i fixed that too.

-Some of the math with the content insets was weird, so I simplified it a bit. Now, the content inset is only changed when beginLoading is called (to add REFRESH_CONTROL_HEIGHT), and when finishedLoading is called (to switch back to the original).

-Reduced overall length by about 60 lines, and I've tested the demo project and everything seems to still work. I'm uncertain if the the coverView functionality still works; I don't really understand what the purpose of it is, so I can't tell if I've broken it. Let me know if I need to fix it.

In BOZPongRefreshControl.m line 58. The properties scrollView and refreshTarget should be weak, not strong. This class does not own these objects, so it should not retain them. This memory leak can be shown in the example project by running the Instruments allocation tool. Every time you open/close the "On a ScrollView" option, it adds ~350KB of memory usage because it is keeping every instance of the scrollView in memory that you ever open. This may not be much in this case, but it my project it was keeping open ~6MB of memory each time.

I have added interactivity to the control. When you set the property interactive to YES, the scrolling of the scrollView/tableView controls the vertical position of the right paddle.

Fun fact: I have added an artificial delay for one of the reload operations in my App to let the user play for a few seconds. :)

When the user rotates the device, the view will adjust its frame, set the paddles/ball at the appropriate positions, and resume animation.

Note: There is still an issue with the cover view in landscape orientation and when the user rotates the device from a different view controller and returns to the previous one.

Also, I'm relatively new to GitHub and any feedback on the effectiveness of my code would be highly appreciated.

I was considering modifying the project so that the user can control one of the paddles by tilting the iPhone/Pad . (Keeping the current system would also be an option.) Is this something worth doing?

The refreshControl is playing its animation, then I push a second viewcontroller. I press the back button and the refreshcontrol is stucked. How do we keep the animation playing?

Added a default state for the reflectedBallDirection point in -determineReflectedDirectionOfBall to ensure a garbage value won't be returned in the -determineNextBallDestination method.

My app has autorotation turned off (Portrait only).

When I pull down on the refresh control to expose the Pong view, then rotate, the Pong view will disappear and the table offset will still be there.

When I try to pull down again, nothing happens, when I let go, the Pong view shows up again and closes, causing the table offset to go back to normal.

My solution, remove the NotificationCenter observer for changeOrientation because I will never need it. Perhaps in the future a property can be created in BOZPongRefreshControl to enable/disable the autorotation code after initializing it.

This is the greatest idea since sliced bread! Would love to use this in my project. However does not seem like it is still maintained. Will this work well with the latest iOS version and play well with swift?

hello, cool control you have here. But one problem is that, the control stops when user press home button and open the app back.

viewWillAppear and viewWillDisappear cannot solve the problem

If the table view is scrolled without user interaction, the pong view will not know the current offset of the table, so it may show up on screen unintentionally.

The case that I ran into: I have cells that expand/collapse when they are tapped. If you tap a cell in the middle of the table, the device will automatically move the cells below, thus having no effect on the position of the Pong view up above. However if you tap the last item in the list, it will move everything above. When collapsing, it will scroll the cells down, which also brings down the pong view.

As soon as I scroll the table manually, it sees the correct offset and removes the pong view.

My fix for this was to include a call to "[self.pongRefreshControl scrollViewDidScroll];" after the cell is collapsed, which allows the pong view to update to the correct offset with the new table position.

Maybe this isn't a full-on bug, because I can't find a solution without a major refactor in the Pong library, but it should probably be included in the ReadMe as a footnote to call scrollViewDidScroll in cases where the table might be scrolled outside of "scrollViewDidScroll"

First of all - this is fantastic, very well done - really cool and awesome!!! :) Congrats!

Would be awesome to have the user be able to see the animation for fun when they pull down - right now the requests are pretty fast so the user only sees the animation for a short time (since the animation starts when the control is pulled down and released).

See the other apps that do it this way - Snapchat, new YikYak.

Sweet job, this is really cool!

(Also I tried decreasing the ball travel time to 0.5 to show the user more of the game / make it clearer what is happening when they pull down and it seemed rushed. I think the solution is just to make the game show for longer, it's fun to watch and I'm sure people will refresh just to see it!)