0
点赞
收藏
分享

微信扫一扫

Plug-in a UITextView Placeholder Label Extension

白衣蓝剑冰魄 2023-05-23 阅读 97


https://christiantietze.de/posts/2015/02/plugin-uitextview-placeholder-extension/

http://merowing.info/2012/03/automatic-removal-of-nsnotificationcenter-or-kvo-observers/#.U-Sx64CSxhY

Kevin McNeish created a Swift extension for UITextViewNSNotificationCenter

So this little extension is fairly involved behind the scenes. Still, it’s pretty straightforward. Have a look at Kevin’s sequence diagram to see the flow of information:


Plug-in a UITextView Placeholder Label Extension_ide

Sequence diagram, showing that setting the new placeholder attribute will (2) create a new label, (5/6) create and register a private notification handler, and (10) show/hide the label appropriately.

UITextView

Usually, and by “usually” I mean in the Apple-recommended way shown in example code and the docs, you’d place this logic in your view controllers. They, in turn, get convoluted with handling their sub view’s needs. Almighty view controllers make you app hard to extend and debug.

So Kevin’s extension really does one thing for you: it makes your code more readable and maintainable by taking user interaction logic out of the view controllers.

This would be more difficult to do as a category in Objective-C because of the property observers Kevin used. But well, that’s the power of Swift.

To create the placeholder, the extension adds an @IBInspectable property,placeholder: String?. It’s just a wrapper around the private optionalplaceholderLabel: UILabel? this extension also adds. When you set the placeholder value, the label is created. If you don’t use it, nothing changes. So this extension really affects only those instances of UITextViewNotificationProxy which responds to user interaction to show and hide the placeholder via UITextViewTextDidChangeNotification.NotificationProxy is just a super-thin container for an NSObjectProtocolobject which itself is just a container for block-based notification handling. Since deallocating NSObjectProtocol instances won’t cause them to de-register themselves from their associated notification center, you need the proxy primarily to call removeObserver(_:) on deinit, which is the newdeallocNotificationProxy, slightly rephrased in my own terms, looks like this:

class NotificationProxy: UIView {
    
    weak var notificationHandler: NSObjectProtocol!
    
    lazy var notificationCenter: NSNotificationCenter! = {
        return NSNotificationCenter.defaultCenter()
    }()
    
    func addObserverForName(name: String?, object: AnyObject?, queue: NSOperationQueue?, usingBlock: (NSNotification!) -> ()) {
        notificationHandler = notificationCenter.addObserverForName(name, object: object, queue: queue, usingBlock: usingBlock)
    }

    deinit {
        notificationCenter.removeObserver(notificationHandler)
    }
}

UIView so the extension can keep a strong reference to this helper object by using addSubview(_:). It’s a little hacky, but it works.

Take a look at Kevin’s article to learn more and get the example code.

NotificationProxy inherit from UIView, which is wrong to me semantically, I really love this simple solution.


举报

相关推荐

0 条评论