Created protocol to improve injectability of lib.

jdg / MBProgressHUD

MBProgressHUD + Customizations

http://www.bukovinski.com/

MIT License

16.01k stars 3.56k forks source link

Created protocol to improve injectability of lib. #462

Closed Panajev closed 7 years ago

Panajev commented 7 years ago

Broken multiple classes and protocols in their own files.
Created protocol to allow implemented to use this implementation of Progress HUD or other implementations thus also improving their code testability.
Passes unit tests, but I have also checked manually the example and all of its options running on iOS Simulator.

Signed-off-by: Goffredo Marocchi goffredo.marocchi@gamesys.co.uk

Panajev commented 7 years ago

@jdg is this build going to TravisCI?

matej commented 7 years ago

One of the original design goals for MBProgressHUD was to just have it be one implementation file (and a header) for easy integration. While the code has grown a lot over time, I still see this as a positive attribute in this case, so I'd like to preserve that.

Panajev commented 7 years ago

Would it be a folder better for easy integration? Also while the easier integration has a big merit, wouldn't the improved separation in components be preferable? There are merits to breaking down to a single class per file.

Would you agree to merge it more if this were changed to go back to a single file solution?

On Mon, Mar 6, 2017 at 12:18 PM, Matej Bukovinski notifications@github.com wrote:

One of the original design goals for MBProgressHUD was to just have it be one implementation file (and a header) for easy integration. While the code has grown a lot over time, I still see this as a positive attribute in this case, so I'd like to preserve that.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jdg/MBProgressHUD/pull/462#issuecomment-284381219, or mute the thread https://github.com/notifications/unsubscribe-auth/AAiXLzK3gGw-HRyJTnzdCqDDTZti5dObks5ri_msgaJpZM4MTbR0 .

Panajev commented 7 years ago

Hello @matej would this be close to what you are looking for? I still think that the protocol for ProgressHUD should be a separate header and we should have separate implementation files for the other subcomponents (perhaps all importing the same MBProgressHUD header), but then again with Cocoapod I am not sure it matters if this takes one or multiple files.

I do not want to create an incompatible fork or a fork that cannot stay up to date, so I am happy to refactor it like this if it meets your standards for this library better.

Panajev commented 7 years ago

Hello @jdg, would you need additional changes for the PR?

matej commented 7 years ago

Sorry for the late replay, @Panajev. I think this complicates the structure unnecessary - without much benefit. I would like to keep this a simple one off class.

You can of course keep using it as you desire on your fork, but I'd opt to keep the main repository as is.