Why NVActivityIndicatorPresenter is deprecated, whats the alternate approach?

[preetamjadakar]

I see, in the latest release NVActivityIndicatorPresenter is deprecated, not sure why but I'm looking for its alternative.
My requirement is simple:
Something is deprecated meaning, planned for removal or not supported near future, so we can't just bear with the deprecation warnings.

• Should block UI(including Tabbar/Navigation bar)
• Can be called from any place,(not necessary from UIViewController sub-classes), but it should show on the visible screen
• Should show indicator at the center of the window by default.

My current implementation is as below:
var activityData = ActivityData()
To show: NVActivityIndicatorPresenter.sharedInstance.startAnimating(activityData, nil)
To hide: NVActivityIndicatorPresenter.sharedInstance.stopAnimating()

[sharplet]

Here's the simpler version that I'm using as a workaround as I move away from using app-global activity indicators. Hope it helps. (Note that I chose to put this API on UIWindow instead of UIViewController to avoid relying on global state like UIWindow.keyWindow. As such it's not quite a drop-in replacement.)

import NVActivityIndicatorView
import UIKit

final class BlockingActivityIndicator: UIView {
  private let activityIndicator: NVActivityIndicatorView

  override init(frame: CGRect) {
    self.activityIndicator = NVActivityIndicatorView(
      frame: CGRect(
        origin: .zero,
        size: NVActivityIndicatorView.DEFAULT_BLOCKER_SIZE
      )
    )
    activityIndicator.startAnimating()
    activityIndicator.translatesAutoresizingMaskIntoConstraints = false
    super.init(frame: frame)
    backgroundColor = UIColor.systemBackground.withAlphaComponent(0.6)
    addSubview(activityIndicator)
    NSLayoutConstraint.activate([
      activityIndicator.centerXAnchor.constraint(equalTo: safeAreaLayoutGuide.centerXAnchor),
      activityIndicator.centerYAnchor.constraint(equalTo: safeAreaLayoutGuide.centerYAnchor),
    ])
  }

  required init?(coder: NSCoder) {
    fatalError("init(coder:) has not been implemented")
  }
}

extension UIWindow {
  func startBlockingActivityIndicator() {
    guard !subviews.contains(where: { $0 is BlockingActivityIndicator }) else {
      return
    }

    let activityIndicator = BlockingActivityIndicator()
    activityIndicator.autoresizingMask = [.flexibleWidth, .flexibleHeight]
    activityIndicator.frame = bounds

    UIView.transition(
      with: self,
      duration: 0.3,
      options: .transitionCrossDissolve,
      animations: {
        self.addSubview(activityIndicator)
      }
    )
  }
}

[preetamjadakar]

Thanks @sharplet, this is still better and let's see what author has thought about this?

[ninjaprox]

@preetamjadakar Technically, it's still usable, you will get some warnings though. There are changes in the pod names so use pod 'NVActivityIndicatorView/Extended' instead as mentioned in 5.0.0 release note.

The above workaround should work. Originally, NVActivityIndicatorView only provides a set of loading animations, and to use it as a UI blocker, we should've used to in conjunction with other specialized UI blockers like MBProgressHUD or SVProgressHUD. Thanks to other folks' contributions, we have that function, which is NVActivityIndicatorPresenter, baked in NVActivityIndicatorView. Since there, NVActivityIndicatorPresenter is getting more robust, but it doesn't have proper care to address arisen issues—replying on UIWindow.keyWindow is an example. My rationale behind the deprecation is to keep things simple, to prevent new users from using it and therefore take it off the heat. Existing users should still be able to use it—with a small change as mentioned ealier—with warnings meaning it won't get new features added or bugs fixed soon.

Long story short, alternatives could be:

• Keep using it with NVActivityIndicatorView/Extended, I'm not removing it anytime soon.
• Craft the UI blocker yourself—maybe with the workaround above—or use it in conjunction with another HUB library.

Then what is NVActivityIndicatorPresenter future? As with existing issues and feature requests, maybe it's worth to be a separate pod—the question is if other pods out there are doing the job well, do we need another new one?—or if it gets enough attention, it'll still be NVActivityIndicatorView/Extended and as a nice add-on to NVActivityIndicatorView.

Thanks for understanding.

[gabors]

This is a really odd decision @ninjaprox
For one I hate build warnings, your notes state to use NVActivityIndicatorViewExtended, but provide to example on how to use this with SwiftPM.

[singh-karan-7]

This is honestly, quite stupid. Why would you do this? What's even the point?

[PierreBrisorgueil]

Keep using it with NVActivityIndicatorView/Extended, I'm not removing it anytime soon.

@ninjaprox am I wrong somewhere?

[isayeter]

Thanks for the example @Sharple , missing part to remove Activity for whom want to use @sharplet 's code.

    func finishBlockingActivityIndicator() {
        subviews.filter { $0 is BlockingActivityIndicator }.forEach { view in
            view.removeFromSuperview()
        }
    }