Question about slight difference in behavior

[DimaVartanian]

First of all, this looks awesome. I have been messing with this stuff myself and your solution looks like the best and most robust I've seen yet. Great work!

I haven't poked around the code yet but noticed a slight difference in behavior between this component and what Instagram/Facebook use. Is there any plan to add the ability to push a view onto the stack without expanding the navigation bar on the current view? Then, when popping back, popping back to the bar in the state it was in (so if it was hidden, leaving it hidden?).

To put it more simply, take a look at the Facebook app:

• If you hide the navigation bar then push a new view, the new view has a new navigation bar that gets pushed with it, not changing the root view at all.
• If you unhide the navigation bar and push a new view, it gets pushed like a view controller normally does and the new navigation item fades in over the old one.

I have introspected those other apps' view hierarchies using Spark Inspector on a jailbroken device in the past and as far as I remember the way Facebook accomplishes it is by having the status bar background actually being a separate view than the navigation bar itself, so it is able to stay anchored on the root view while the actual navigation bar is pushed on top of it with the next one. Instagram did the same thing but in their case it is more trivial because no matter what state it is in when you push, the pushed navigation bar is obviously a different view (not even the same color).

Anyways, the component is pretty awesome without this but it would perhaps be a little less jarring to the user if the navigation bar does not pop in as a new view is about to be pushed. I'm not sure if this can be easily added while maintaining the simplicity of the component.

[Mazyod]

@DimaVartanian Thanks for your kind words. I am really impressed by the Spark inspector approach using a jailbroken device, never thought of that!

So, about the idea, I am sold. Anything to improve this component, will improve our app experience anyways :)

Here is an initial rough experiment I did:

I think I used an easier way than playing with backgrounds and views. I set the navigation bar as hidden on viewWillDisappear: if it is contracted, and unhide it in the next view viewWillAppear:. This makes UIKit take care of the animation for us. I still have some concerns, though, so gonna look deeper into it soon.

[DimaVartanian]

This looks great and more natural than before for sure! So the only discrepancy in behavior now is that when you pop back to the original view, the navigation bar is always reset to the open state rather than going back to the state it was in when you pushed. This is really just a difference in behavior and not a usability issue like the other one was so it might not be very important or even needed. In any case, I'll take a look soon when I get a chance as well :).

[Mazyod]

Thanks, I meant to address the second point, but got dragged in by the first issue. I think it's a very simple matter to reserve the previous state. Honestly, I would keep it the way it is in our app, but an option can be added to reserve the last state for users to choose between the two.

My reason behind making it expand is that I feel the user probably went back using the back button, hence he is focused on the navigation bar. Taking that bar away, even though that's the initial state, might not be ideal for that case. I can see it working better in other cases, though.

[Mazyod]

I thought it was simple, but issues kept popping up.. Need to take a closer look at it.