boztalay / bozpongrefreshcontrol Goto Github PK

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?

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!)

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.

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"

This is not an issue but I don't know another place to say it.

It works fine on iPhone 6 with 8.1.2

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?

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.