ideas to remove NSCoding as requirement in UIView subclasses

Using Swift
1

Hi all,

For better or worse I still hand code most of my views. I am getting
frustrated by the constant compiler error that I haven't updated "required
init(coder:)", which is something that will never be executed in my case.

Is there some hacky mechanism that I could use to create a subtype that
doesn't conform to all protocols of the parent? Seems like recipe for
disaster so I suspect it's not built into swift directly.

Is there a creative way to use UIViews, but with the dependency on NSCoding
removed? I am open to total hacks.

Thanks!
Lou

2

Oh wow, I stumbled on this immediately after posting: For anyone else that
fills their NSCoding initializers with assert(false), switch them to
fatalError("message")

···

On Sat, Oct 8, 2016 at 9:22 AM, Lou Zell <lzell11@gmail.com> wrote:

Hi all,

For better or worse I still hand code most of my views. I am getting
frustrated by the constant compiler error that I haven't updated "required
init(coder:)", which is something that will never be executed in my case.

Is there some hacky mechanism that I could use to create a subtype that
doesn't conform to all protocols of the parent? Seems like recipe for
disaster so I suspect it's not built into swift directly.

Is there a creative way to use UIViews, but with the dependency on
NSCoding removed? I am open to total hacks.

Thanks!
Lou

3

This is a wrong place to ask. This topic is part of the iOS SDK from Apple not part of Swift itself or libraries like Foundation.

···

--
Adrian Zubarev
Sent with Airmail

Am 8. Oktober 2016 um 18:32:50, Lou Zell via swift-users (swift-users@swift.org(mailto:swift-users@swift.org)) schrieb:

Oh wow, I stumbled on this immediately after posting: For anyone else that fills their NSCoding initializers with assert(false), switch them to fatalError("message")

On Sat, Oct 8, 2016 at 9:22 AM, Lou Zell <lzell11@gmail.com(mailto:lzell11@gmail.com)> wrote:
> Hi all,
>
> For better or worse I still hand code most of my views. I am getting frustrated by the constant compiler error that I haven't updated "required init(coder:)", which is something that will never be executed in my case.
>
> Is there some hacky mechanism that I could use to create a subtype that doesn't conform to all protocols of the parent? Seems like recipe for disaster so I suspect it's not built into swift directly.
>
> Is there a creative way to use UIViews, but with the dependency on NSCoding removed? I am open to total hacks.
>
> Thanks!
> Lou
>

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

4

Lou, you can create a "class BaseView: UIView" which will serve as a
default view your views will subclass and inside it, add the init required
by NSCoding, make its body `fatalError("Not implemented!")` and add the
following attribute on the init: `@available(*, unavailable)`. Then you'll
not need to declare it in every view that subclasses the BaseView.

Tadeas

···

On Sat, Oct 8, 2016 at 8:23 PM Adrian Zubarev via swift-users < swift-users@swift.org> wrote:

This is a wrong place to ask. This topic is part of the iOS SDK from Apple
not part of Swift itself or libraries like Foundation.

--
Adrian Zubarev
Sent with Airmail

Am 8. Oktober 2016 um 18:32:50, Lou Zell via swift-users (
swift-users@swift.org) schrieb:

Oh wow, I stumbled on this immediately after posting: For anyone else that
fills their NSCoding initializers with assert(false), switch them to
fatalError("message")

On Sat, Oct 8, 2016 at 9:22 AM, Lou Zell <lzell11@gmail.com> wrote:

Hi all,

For better or worse I still hand code most of my views. I am getting
frustrated by the constant compiler error that I haven't updated "required
init(coder:)", which is something that will never be executed in my case.

Is there some hacky mechanism that I could use to create a subtype that
doesn't conform to all protocols of the parent? Seems like recipe for
disaster so I suspect it's not built into swift directly.

Is there a creative way to use UIViews, but with the dependency on
NSCoding removed? I am open to total hacks.

Thanks!
Lou

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

5

Tadeas - Just what I was looking for. Thank you!

class BaseView: UIView {
    @available(*, unavailable)
    required init?(coder aDecoder: NSCoder) {
        fatalError("Not implemented!")
    }
}

···

On Mon, Oct 10, 2016 at 11:45 AM, Tadeas Kriz <tadeas@brightify.org> wrote:

Lou, you can create a "class BaseView: UIView" which will serve as a
default view your views will subclass and inside it, add the init required
by NSCoding, make its body `fatalError("Not implemented!")` and add the
following attribute on the init: `@available(*, unavailable)`. Then you'll
not need to declare it in every view that subclasses the BaseView.

Tadeas

On Sat, Oct 8, 2016 at 8:23 PM Adrian Zubarev via swift-users < > swift-users@swift.org> wrote:

This is a wrong place to ask. This topic is part of the iOS SDK from
Apple not part of Swift itself or libraries like Foundation.

--
Adrian Zubarev
Sent with Airmail

Am 8. Oktober 2016 um 18:32:50, Lou Zell via swift-users (
swift-users@swift.org) schrieb:

Oh wow, I stumbled on this immediately after posting: For anyone else
that fills their NSCoding initializers with assert(false), switch them to
fatalError("message")

On Sat, Oct 8, 2016 at 9:22 AM, Lou Zell <lzell11@gmail.com> wrote:

Hi all,

For better or worse I still hand code most of my views. I am getting
frustrated by the constant compiler error that I haven't updated "required
init(coder:)", which is something that will never be executed in my case.

Is there some hacky mechanism that I could use to create a subtype that
doesn't conform to all protocols of the parent? Seems like recipe for
disaster so I suspect it's not built into swift directly.

Is there a creative way to use UIViews, but with the dependency on
NSCoding removed? I am open to total hacks.

Thanks!
Lou

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

6

You're welcome! Glad to be helpful :)

Tadeas

···

On Mon, Oct 10, 2016 at 9:12 PM Lou Zell <lzell11@gmail.com> wrote:

Tadeas - Just what I was looking for. Thank you!

class BaseView: UIView {
    @available(*, unavailable)
    required init?(coder aDecoder: NSCoder) {
        fatalError("Not implemented!")
    }
}

On Mon, Oct 10, 2016 at 11:45 AM, Tadeas Kriz <tadeas@brightify.org> > wrote:

Lou, you can create a "class BaseView: UIView" which will serve as a
default view your views will subclass and inside it, add the init required
by NSCoding, make its body `fatalError("Not implemented!")` and add the
following attribute on the init: `@available(*, unavailable)`. Then you'll
not need to declare it in every view that subclasses the BaseView.

Tadeas

On Sat, Oct 8, 2016 at 8:23 PM Adrian Zubarev via swift-users < > swift-users@swift.org> wrote:

This is a wrong place to ask. This topic is part of the iOS SDK from Apple
not part of Swift itself or libraries like Foundation.

--
Adrian Zubarev
Sent with Airmail

Am 8. Oktober 2016 um 18:32:50, Lou Zell via swift-users (
swift-users@swift.org) schrieb:

Oh wow, I stumbled on this immediately after posting: For anyone else that
fills their NSCoding initializers with assert(false), switch them to
fatalError("message")

On Sat, Oct 8, 2016 at 9:22 AM, Lou Zell <lzell11@gmail.com> wrote:

Hi all,

For better or worse I still hand code most of my views. I am getting
frustrated by the constant compiler error that I haven't updated "required
init(coder:)", which is something that will never be executed in my case.

Is there some hacky mechanism that I could use to create a subtype that
doesn't conform to all protocols of the parent? Seems like recipe for
disaster so I suspect it's not built into swift directly.

Is there a creative way to use UIViews, but with the dependency on
NSCoding removed? I am open to total hacks.

Thanks!
Lou

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users