On Mar 8, 2011, at 1:44 PM, Chris Markle wrote: > 1. Camera used to take picture or video (UIImagePickerController). > Want to save image that was taken to the camera roll like happens with > the camera app. That saving process starts when the user returns from > the camera. If they then go to the Photo Library (again with > UIImagePickerController), we don't let them do that until the image is > fully saved since we want them to be able to see them image in the > library that they just shot. So when they tap the "photo library" > button, we (as Kyle said) "throwing up a modal 'please wait' UI" until > the save to photo library function is completed, at which point we > show the photo library.
I'll just use this as an example of how my own thinking runs when faced with this sort of situation. I confront the matter in terms of MVC: * The actual saving of the image into the camera roll is model - this is your data. If you use UIImageWriteToSavedPhotosAlbum you can arrange to be notified asynchronously by setting the completionTarget, completionSelector, and optionally the contextInfo. The iOS 4 calls with completion handler are parallel. * Doing something in response to the situation with the model is the job of the controller. So, to communicate between the two, I'd use a notification (from the model) just before we start to save and another notification (from the model) when the save is completed. The controller's job is then to maintain state; you could have an ivar, photoLibraryUnavailable, and set it to YES in response to the first notification and to NO in response to the second. * The problem of what the user should see is view, but the controller is in charge of it. Presumably the controller will respond to the two notifications appropriately. The question is then what's appropriate. That's a design decision; many opinions are valid. Personally I would shun the notion you express: > when they tap the "photo library" > button, we (as Kyle said) "throwing up a modal 'please wait' UI" Rather, I'd ask myself why the user is able to tap the photo library button at all, if the photo library is not available. Don't make the user wrong by providing a button and then punishing the user for tapping it. The button should instead disappear, perhaps, or become inactive, or be replaced by a spinning activity indicator. This is why we're maintaining state in the controller; at any given moment, the interface should reflect the state of things and the range of possible steps that the user can perform, and the controller can consult its state to make it so. Even if you were to switch temporarily to a modal view that just says Saving, that's better than having a button that slaps the user's hand. That's my philosophy, anyway... But this is no longer an architectural matter, but a sheer problem of philosophy and how you want the user to feel about your app. m. -- matt neuburg, phd = [email protected], http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Among the 2007 MacTech Top 25, http://tinyurl.com/2rh4pf Programming iOS 4! http://www.apeth.net/matt/default.html#iosbook RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html TidBITS, Mac news and reviews since 1990, http://www.tidbits.com _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
