Demystifying Views in iOS · Embed Segues | raywenderlich.com

🎓 Courses & Articles
1
This is a companion discussion topic for the original entry at https://www.raywenderlich.com/4518-demystifying-views-in-ios/lessons/21
2

Why we need to hide the back card by the end of the video?

3

@catie Can you please help with this when you get a chance? Thank you - much appreciated! :]

4

@michael.arianto I think to make sure we load only one when starting the app.
if we don’t hide, top card view might show the back side together with the named buttons below. You can try to unhide the back, THEN complete the challenge on the next video. On first load, it might start with a back side and named buttons…

5

thank you @arvnq for responding. I’ll make sure to not extend the video subscription here since they barely respond to questions in the forum.

6

@michael.arianto :laughing: i just got curious on your question and tried it out. just fire away any questions. You might get some answers from other viewers as well :wink: happy coding.

7

Thanks, @arvnq! That’s exactly right. One of the card sides needs to be hidden at all times; the way we did that in the NIB file, I think, is the easiest option. Here’s what it could look like if we didn’t take that step. :slightly_frowning_face:37%20PM

And @michael.arianto, I’m sorry it took this long to get back to you. If there’s anything else I can help you with, let me know. I don’t think you should expect a lack of response to any forum questions.

8

Sorry to dig this up again, but I’m still kind of struggling with the functionality of CardSuperView in this context.
Am I correct in assuming that the CardView that we hide on app launch stays hidden for as long as the app runs and basically only the one side/subview that was initially not hidden is displayed but flipped to the side requested by pickNewCard()? So CardSuperView owns two subviews of which one is only ever displayed, with the one hidden only required to supplement a readily loaded nib/view for the displayed subview to flip to, should it be requested by pickNewCard()? I hope this makes sense the way I’m phrasing it.
Following that logic, I would guess that one cannot make any assumptions about the order in which the subviews are displayed once loaded from the nib, which is why the wrong side could initially show up.

9

Am I correct in assuming that the CardView that we hide on app launch stays hidden for as long as the app runs and basically only the one side/subview that was initially not hidden is displayed but flipped to the side requested by pickNewCard() ? So CardSuperView owns two subviews of which one is only ever displayed, with the one hidden only required to supplement a readily loaded nib/view for the displayed subview to flip to, should it be requested by pickNewCard() ?

No, both FrontCardView and BackCardView will take turns being hidden. The order in which they load from the nib is determined by their ordering in its document outline. If that knowledge only adds to your confusion, let me know what I might be able to clear up!

10

Thanks for the prompt reply! I am trying to reason it through right now, please correct me if I’m wrong:

Should the back side of the card be picked on app launch, that would cause the front side, which is not hidden, to be flipped to the back and in turn consequently be hidden by the .showHideTransitionViews options on UIView.transistion. If, on the other hand, the front side is picked, this would be resolved by the line to: side == self.side ? self : otherSide. Does that sound about right?

If so, I missed the .showHideTransitionViews bit that does the hiding and showing. To the end of always having a side hidden, this must initially be done on app launch.

What I still don’t quite get is how this has not caused any trouble before when we were only dealing with the back side of the card on app launch. Why was it not necessary to hide one side then? Or better to say: How can, in fact, the back side end up on top of the front card when this should be resolved by the setCard method (causing the back card to flip to the front) and is not due to random ordering from when the nib is loaded. I would be glad if you could further clarify that part.

Edit: I think I got it: Before we had to deal with two sides the issue was simply resolved by placing the Front Card before the Back Card in the .xib file, resulting in the back card being placed on top of the front on loading. Is that correct?

1 Like
11

@catie @jessycatterwaul Can you please help with this when you get a chance? Thank you - much appreciated! :]

12

Yep, you’ve got it — sorry I missed this!