UIImagePickerControllerSourceTypeCamera 的父视图问题
我对 UIImagePickerControllerSourceTypeCamera 有一个奇怪的问题。我的应用程序可以选择从图库中选择照片，或使用相机拍照。如果我选择图库，我会选择一张照片并返回到我的视图，没有任何问题。
然而，当使用 UIImagePickerControllerSourceTypeCamera 时，当我返回它时，它似乎对我的视图做了一些奇怪的事情。
例如，我在 viewDidLoad 方法中有一堆代码，如果需要的话，它会根据某些因素移动视图中的某些对象 - 当我退出 UIImagePickerControllerSourceTypeCamera 时，此代码会被调用，但当我退出图库时，不会被调用。
这是预期的吗？
I have an odd problem with UIImagePickerControllerSourceTypeCamera. My application gives the choice to select a pic from the gallery, or take a photo with the camera. If I choose the gallery, I pick a photo and return to my view, no issues.
However, when using UIImagePickerControllerSourceTypeCamera, it appears to do something odd with my view when I return to it.
For example, I have a bunch of code in the viewDidLoad method which moves some objects in the view if it needs to based on some factors - this code gets called when I exit the UIImagePickerControllerSourceTypeCamera, but doesnt get called when I exit the gallery.
Is this expected?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为您的视图被资源密集型相机触发的
didReceiveMemoryWarning事件所转储。您可以强制模拟器在没有相机的情况下生成内存警告来测试该理论。一般来说，viewDidLoad 需要能够处理多次调用。它不是一个
init方法。如果 self.view 设置为 nil 并且稍后需要重新创建视图，则会再次调用它。可能有一个更合适的位置来放置导致问题的任何代码，但是init方法很棘手，因为指定的初始化程序会被 nib 加载绕过。当从 nib 加载时，会调用该类的
initWithCoder，这会绕过整个 init 过程，因为假定解档会吸入已初始化的对象。因此，重新初始化对象可能会破坏一些东西，比如调用 loadView ，它本质上与笔尖包含的内容相冲突，因为它应该以编程方式构造笔尖中已有的内容。您仍然可以像往常一样重写 initWithCoder，只要您像您应该的那样将参数传递给super即可，但是如果您使用指定的初始值设定项初始化对象，则不会调用此方法。当然，如果您需要担心，您可以将要在这两个方法中执行的所有代码放入一个方法中，该方法从两个重写的方法中调用。I think your view is getting dumped by the
didReceiveMemoryWarningthing which is being triggered by the resource-intensive camera stuff. You can force the simulator to generate a memory warning without the camera to test this theory.Generally speaking, viewDidLoad needs to be able to deal with getting called multiple times. It's not an
initmethod. It gets called again ifself.viewgets set to nil and the view later needs to be recreated. There may be a more appropriate place to put any code you have there that's causing problems, but theinitmethods are tricky because the designated initializer is bypassed by nib loading.When loaded from a nib, the class's
initWithCoderis called instead which bypasses the whole init process because dearchiving is assumed to be sucking in an already-initialized object. Therefore reinitializing the object might break stuff, like call loadView which essentially conflicts with what a nib contains as it's supposed to programmatically construct what the nib already has in it. You can still override initWithCoder as usual though as long as you pass through the args tosuperlike you should, but then this will not get called if you initialize the object with the designated initializer. Of course if you need to worry about that you can put all the code you want executed in both into a method that gets called from both overridden methods.