iOS7 integration. Should I wait?


#1

Hi Shinobi team,

With iOS 7 right around the corner, I’m updating my set of apps to the new UI style. I’m in the middle of changes surrounding the FlowView with iOS 7. While most of it seems to work ok, I’m definitally running into some odd behavior. Without getting into NDA territory, we all know the status bar behavior is different on iOS7. This seems to have affected scrollviews and the FlowView. Specifically I now need to look at contentOffset values to get an accurate value as to the actual visable area of the FlowView. What’s odd is this contentOffset value is constantly changing and is unreliable. 

I’m hoping that this is just a side effect of OS 7 paried with a control built for iOS 6. Should I move on to other issues in my app and circle back around to this once there’s a proper build of the Shinobi contols for iOS 7? Or is there a “correct” way I should be doing this?

Thanks,
Wes


#2

Hi wfilleman,

In which components are you detecting this odd behaviour? Also, which version of our components are you using?

Can you provide console logs, screenshots or a sample project to help us identify the issue your experiencing?

Kind regards,
Andrew Polkinghorn


#3

Hi Andrew,

I’m using a combination of the Flow View Controller with the Navigation slider control. The FlowView is the main view under the sliding navigation controller. When I make the call to [SEssentials getInfo]; I get back:  Shinobi Controls Version: Version: 2.0.0 - Standard edition, released on Jun 14 2013

It looks like I’m fighting two issues when compiling under iOS 7.

  1. Some of my views where I use the Flow Controller are specificlly laid out so that the FlowView managed views do not exceed the display area. This is done specificially to prevent the user from scrolling. Under iOS 7 it looks like the top of the FlowView extends upward to under the status bar to achieve the content contextual feel introduced in iOS 7. For the most part this works as it looks like iOS 7, or something, is inserting a negative offset (most of the time…see issue 2) for the ContentOffset value. This causes the layout to initially appear correctly, but the FlowView scrolls upto the very top of the screen under the status bar. This is not the effect I want. The top “dead space” under the navigation controller and status bar shouldn’t count as “scollable” space since the content is offset.

In this image you see the correct layout before I drag my finger up in the second image:

In iOS6 since the managed views didn’t exceed the display space the Shinobi Control would NOT scroll. This is good and the behavior I want. This is critcal becuase of the joystick OpenGL control on the screen. I can’t have the flowview scrolling when the user tries to use the joystick.

In this image I’ve dragged my finger up and cause the flowview to scroll under the navigation controller and top status bar. Not sure I understand why this happens since that top space is offset by the contentoffset value. My assumption is this should behave exactly like iOS6 which is that it doesn’t scroll.

Issue 2: ContentOffset values in the FlowView are not predictable.

I hope this is something I’m doing, but I can’t seem to pinpoint what I would be doing to cause this. On portrait startup, the content offset is {0,0}.
After startup I rotate to Landscape and the contentOffset goes to {0,-80}
Rotating back to Portrait sets the contentOffset to {0,-54}
A few more rotation tests in various parts of the app lead to the following FlowView contentOffset values:
{0,-64}
{0,-80}
{0,-52}
{0,-53}
{0,-79}

Because of the unpredicatble contectOffset values, the code that resizes the manged subviews taking the contentoffset into account results in a resized image that doesn’t fit in the FlowView:

There should be equal top/bottom space in that image above.

Any ideas? What else can I help provide?

Wes


#4

UPDATE

Issue 1: Just FYI: There is a new iOS 7 setting on the view controller that if set causes the viewController to go back to how it worked under iOS 6. I can confirm that this does work, however, you don’t get the new iOS 7 blurred view behind the NavController and status bar.

Should there be another way to prevent the FlowView from scrolling in this scenario using the new iOS 7 contentOffset method where the content of the FlowView is 100% visable on the screen?

Issue 2: I actually got this mostly fixed, but ran into a related issue. First, what I did differently. Under iOS6 SDK I found that I needed to set the NavigationBar to autoresize to get it to work properly under the iOS 6 SDK:

[[UINavigationBar appearance] setAutoresizingMask:UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleBottomMargin | UIViewAutoresizingFlexibleHeight | UIViewAutoresizingFlexibleRightMargin];

As it turns out this was screwing with the contentOffset values in some way. I removed this line of code and all of a sudden the contentOffset was now (mostly) set to {0,-64} as expected. Also under iOS6 this seems to now work when compiled under the iOS 7.0 SDK.

I say mostly because there was another change and residule issue left. The second change was to not add managedViews to the FlowView until (void) viewDidAppear was called. Then I could add managed views to the FlowView and have the contentOffset correctly set to {0,-64}.

The remaining issue I’m still seeing is under this specific scenario:
If I scroll the FlowView where the content is now behind the nav and status bars and then rotate the device, the contentOffset values get set back to {0,0} for the FlowView. If the content is 100% below the nav bar and status bar then on rotation the contentOffset stays correctly at {0,-64}.

Are there any transforms being applied to the ScrollView?
https://devforums.apple.com/message/870730#870730
There’s also a report of iOS 6 AutoLayout maybe causing an issue similar to this:
https://devforums.apple.com/message/872701#872701


#5

Hi Wes,

We are currently investigating the issues you raised in this post. However, is it possible for you to send us a project replicating these issues to info@shinobicontrols.com?

This would really help us find the source of the issue.

Kind Regards,
Andrew Polkinghorn


#6

Thanks Andrew, I sent you a demo project file.

For other’s reading this, I found out that Issue 2 was my fault. In further digging I discovered that the ContentOffset value will absolutly change as the user scrolls. What I should be looking at is the ContentInset.top value. This will tell the code properly how far offset the content starts compared to the frame. Once I changed my code to look at ContentInset.top, Issue 2 went away.

All that’s left is Issue 1. Hopefully the demo project provided will shed some light on this one.

Thanks,
Wes


#7

Hi Andrew,

I was able to implement a workaround for Issue 1 that you or other’s might find helpful. It works on iOS7 to account for the flowview context display under the navigation bar and status bar.

To recap, the issue with iOS7 is that the FlowView now is exposed and blurred when sliding under the navigation controller and status bar. What this means is that the bounds of the flowview frame are now the entire screen instead of just the space under the navigation controller.

iOS 7 sets up the FlowView’s UIScrollView by setting the contentInset.top value to 64 (statusbar height + navigation controller height) so that the content of the VlowView appears right below the NavigationController as expected. This is fine except the FlowView wants to use that space behind the navigation controller and status bar to scroll even when the content of the FlowView fits on the screen. In my application, I can’t have the FlowView scroll for any reason if the content fits on the page. This is how the FlowView works on iOS 5/6.

To solve this I did the following in my code:

 After adding a managedSubview by calling: [myFlow addManagedSubview:view]; I added this code:

if (myFlow.contentSize.height <= myFlow.bounds.size.height)
    myFlow.scrollEnabled = NO;
else
    myFlow.scrollEnabled = YES;

This stops the FlowView from scrolling when the content is smaller or equal to the bounds of the flowview.

This gets us most of the way there. There is another problem exposed on iOS 7. When the user has scrolled down the flowview and then perform an action that clears all the subviews, the content offset needs to be reset back to {0, -64} where -64 is the value found in myFlow.contentInset.top. This properly resets the FlowView’s scrollView position back to the top. I added this line after the part in my code where I remove all managedViews from the FlowView:

self.myFlow.contentOffset = CGPointMake(0, (-1) * self.myFlow.contentInset.top);

With these two additions in my code, I was able to work around Issue 1 on iOS7.