Display progress HUD in a specific view

[toohotz]

I realized that in my own project I wanted the flexibility to add the hud to a specific view and not to the overall view in general all the time. Wanted to get your thoughts on if you would like this option as well in the master branch for others that would like this as well.

[honkmaster]

I got a problem with these addition: It is only for one specific method (progress). You forgot that if something like this is added it should go also with images etc. (showSuccess, ...).

[toohotz]

@honkmaster Good point, added the inView property to the other methods and tested them out within my own project and the demo project. Feel free to let me know what you think of it.

[toohotz]

@honkmaster do you still have an interest in this feature?

[brandons]

@honkmaster @toohotz Bumping this. We could definitely use this functionality. Anything keeping it from being mergeable? Happy to help out if needed.

[MrMatthewDavis]

+1 on getting this added. However, does the dispatchOnce functionality mess anything up in this use case if the HUD is to be added to multiple different views?

[toohotz]

@honkmaster added also some nullability specifiers for use in Swift to prevent the explicitly unwrapped optionals from causing issues with improper usage.

[honkmaster]

Now this PR ist mutliple things at once. 1) Show in specific view 2) Nullability. However, I am working on the HUD today and will see what I can do.

[brandons]

@honkmaster Being able to add the progress spinner to a specific view and multiple views at once would be great. :)

[toohotz]

@honkmaster Noticed that the nullability specifiers were added in from another commit. Have the changes resolved on my end though I wanted to understand better why for the completion block of + (void)dismissWithDelay:(NSTimeInterval)delay completion:(nullable SVProgressHUDDismissCompletion)completion; was made optional and not concrete. Personally find it better if this were concrete but that's just my opinion.

[brandons]

@honkmaster Can we get this merged in?

[toohotz]

@honkmaster any updates on this PR? Seems like others are interested in having this feature.

[brandons]

For anyone that just wants an indefinite spinner, you can just use SVIndefiniteAnimatedView. It will start animating on it's own when you add it to another view.

[toohotz]

+ (void)setContainerView:(UIView*)containerView; should do the job also @brandons but I found it useful to be to just add directly to the view of choice as opposed to resetting the containerView, a bit of personal preference I suppose.

[honkmaster]

@toohotz @brandons As said earlier, if you would split your commits and bugfixes to single pull requests I could merge them quite easily. However, at the moment this PR does fix / add multiple things at once. Merging would clutter the timeline and adds additional workload for me ... Thus I keep away from this at the moment.

[toohotz]

@honkmaster agreed, realized that much after my commit for the bugfix that it was fixed anyway so I removed the commit for the nullability and updated my functions as well as documented the README also.

[NikKovIos]

Sorry, but... will this feature be available? I mean attaching to a specific view, thus blocking this view.

I used + (void)setContainerView:(UIView*)containerView; but then it's not convenience to browse back containerView to a window level.

[toohotz]

@NikKovIos I'm still waiting on @honkmaster to review this PR. @honkmaster any updates?

[honkmaster]

I am working today on the HUD. During this I was browsing the commit history and thinking about @NikKovIos comment. He is correct, the containerView was added for this purpose (adding to a specific view). I agree that it is not that convenient.

[toohotz]

@honkmaster agreed that is the purpose of the containerView I just added these convenience methods to allow the containerView to sit on the window level and also when the view is no longer used, you have to remember to reset the containerView to nil in order for it to go back to the window level. Again the purpose of this was to one time set a HUD to be displayed on a specific view and not worry about the keep up of the containerView. If you have no interest in this however I can keep it on my fork for the few that have found use out of this feature.