Open drmarkpowell opened 11 years ago
Hi there, hmm that's strange. Are you experiencing the same issue within the demo project, or is it just from within your app?
The demo seems to run fine for me in iOS7, so it's likely to be something strange I've done in integrating it into my app. I'll look into it further.
-Mark
On Monday, November 4, 2013 at 2:39 AM, Michael Waterfall wrote:
Hi there, hmm that's strange. Are you experiencing the same issue within the demo project, or is it just from within your app?
— Reply to this email directly or view it on GitHub (https://github.com/mwaterfall/MWPhotoBrowser/issues/161#issuecomment-27676454).
One possible cause for the difference in behavior between my implementation and the demo is that in mine whenever the controls are hidden or shown, MWPhotoBrowser viewWillLayoutSubviews is called. For the PhotoBrowserDemo, it doesn't appear to do that based on what I'm observing. It's not apparent to me yet why viewWillLayoutSubviews is being called each time the controls are hidden or shown...the stack trace doesn't show enough relevant information...UIApplicationMain is calling layoutSublayersOfLayer on the UIView, but that's all I've got.
I had same issue on iOS7 (and not on iOS6). And I solved it by commenting out the line MWPhotoBrowser.m:1057:
_statusBarShouldBeHidden = hidden;
[UIView animateWithDuration:animationDuration animations:^(void) {
// [self setNeedsStatusBarAppearanceUpdate];
} completion:^(BOOL finished) {}];
This works for me too. Beautiful, and thank very much for the tip! Now I can move ahead with my integration.
It's definitely the animation of the status bar that's behaving differently in our integrations than in the PhotoBrowserDemo. You can definitely see the status bar animating away in the Demo, so it can certainly be done with animation without seeing the behavior we see...it's just not clear yet why this happens only for us.
The only difference I can point to in our approach versus the demo is that we're using the NIB or Storyboard approach and constructing the MWPhotoBrowser UIViewController along a different route (i.e. initWithCoder: followed by setDelegate: instead of initWithDelegate:) So then the question becomes, what does that have to do with it?
Mr. Waterfall, if a code example that reproduces this behavior would be useful to investigate this I'll be happy to provide it...let me know if you'd like that.
Hi guys, very sorry for the slow reply! @drmarkpowell yes I'd be happy to take a look into this issue if you have the time to put together a demo. Even better, if you could modify the current demo app to support adding using storyboards as well as the current method that would be great.
Let me first say that this photo browser library is great and I'm very excited to use it in my app.
There is one behavior in version 1.1.4 and I do not understand and might be a bug. The behavior is only under iOS7 and not iOS6.
If I have an image bigger than the display and it shows in the browser, it's fine at first, but then when the timer elapses and the controls are hidden, I get the photo shown larger than the current scale and an animated smooth zoom scaling it down to fit the view. Tap to show the controls, same thing: the larger image is animated and scales down to fit the view again. Sliding between images does not do this. If I pinch-zoom in on the image and toggle the controls, the scale I was viewing before is overridden and the photo animates and resizes to fit the view.
I am instantiating my MWPhotoBrowser from a storyboard, segue-ing from a UITableViewController, if that makes any difference.
Thanks to Michael Waterfall and the support community for building this great photo browser component!