是否可以使用encodeObject来存档UIPickerView？
我想恢复我的视图状态，并且我的视图有一个UIPickerView。
UIPickerView 在我看来它有图形组件，即背景轮图像。我知道 UIImage 无法存档。任何带有图像的东西，比如UIImageView，您必须先将图像设置为nil，然后才能对其进行编码。
但是，UIPickerView符合NSCoding标准。这意味着encodeObject和decodeObject应该可以工作。
但他们不这么认为。我的意思是，它们不会导致任何错误。但解码后，你得到的UIPickerView没有任何图像。看上去不太好啊！
这是前后对比的照片，只是为了证明我没有发疯：
之前
< strong>After
现在，我知道我可以简单地存储当前用户选择，并重新创建视图通过调用选择器的selectRow方法。但说实话，我很好奇。为什么UIPickerView NSCoding 兼容，如果它不是真的并且您无法做任何进一步的事情来恢复背景轮图像？
I want to restore my view state, and my view has aUIPickerView.
UIPickerView looks to me like it has graphics components, namely the background wheel image. I know thatUIImage cannot be archived. Anything with an image, likeUIImageView, you have to first set the image tonilbefore you can encode it.
However,UIPickerViewisNSCodingcompliant. That means thatencodeObjectanddecodeObjectshould work.
They don't though. I mean, they don't cause any errors. But after decoding, you get theUIPickerViewwithout any images. It doesn't look good!
Here's a before and after shot just to prove I'm not going mad:
Before
After
Now, I know that I could simply store the current user selection, and recreate the view by invoking the picker'sselectRowmethod. But really, I'm curious. Why isUIPickerView NSCoding compliant if it isn't really and you can't do anything further to get the background wheel image back?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
你似乎已经回答了你自己的问题。
UIImageView符合NSCoding但不保存UIImage（显然因为图像保存在其他地方）所以为什么你会期望UIPickerView< /code> 的行为有何不同？根据我读过的内容（尽管从未做过），
UIViews上的NSCoding用于保存状态（框架、可见性等）而不是实际视图。虽然苹果方面有点不一致，但对我来说这似乎是合乎逻辑的，因为整个 UIView 库已经在 iOS 中，为什么要浪费时间和时间呢？空间重新序列化所有这些数据？从您提出的解决方案中获得的唯一好处是少一点样板代码（用于重置视图），并且有可能减慢对象的读取/写入速度（因为它必须考虑图像）
You seemed to have answered your own question.
UIImageViewconforms toNSCodingyet does not save theUIImage(obviously since the image is saved elsewhere) so why would you expectUIPickerViewto behave any differently?From what I've read (although never done)
NSCodingonUIViewsis used to save state (frame, visibility, etc) not the actual view. Although a little inconsistent on Apple's part, it seems logical to me, since the entire UIView library is already in iOS, why waste time & space reserializing all that data?The only thing that would be gained from your proposed solution would be a little less boilerplate code (for resetting the view) and has the potential to slowing the reading/writing of the objects down (because it has to account for the images)