Possible bug... Nav bar in App not rendering on iPhone correctly

Anvil Q&A
#1

This is happening on both Chrome and Safari. The linked app’s nav bar on the left is not being rendered at all.

https://anvil.works/build#clone:OEGXRJAK5LDRH7DU=7RHBAOWMQR42ZR6PHDLJSAJR

#2

I’ve created a couple of Roles that let you decide what to show and hide when the window is small.
This gives you the tools to decide what disappears, what stays, and what moves elsewhere, from the top nav.

Here’s a version of that app that keeps the hamburger button and app title visible when the window is small (including on mobile):

https://anvil.works/build#clone:DHRDXLLFDMKDY3I6=7MMCIQ57MQXCXBACUWKT7ZQ5

The ‘logged in as’ and ‘login’/‘logout’ buttons move to the side nav when the window is small:

15

When the window is larger, they are in the top nav as before:

00
Screen Shot 2019-06-27 at 18.20.00.png842×302 24.3 KB

How it works

As well as the original components:

  • label_login_state
  • button_login
  • button_logout

I have created:

  • label_login_state_mobile
  • button_login_mobile
  • button_logout_mobile

The original components have the small-window-hide role, and the new components have the small-window-visible role.

42
Screen Shot 2019-06-27 at 17.45.42.png1285×616 47 KB

I’ve added these lines to theme.css in the Assets, these are the lines that enact the show/hide:

.anvil-role-small-window-visible {
  display: none;
}

@media(max-width: 767px) {
  .anvil-role-small-window-hide {
    display: none;
  }
  .anvil-role-small-window-visible {
    display: block;
  }
}

(I also had to add padding to Labels in the sidebar by adding .sidebar-elt .label-text to this existing rule in dashboard.html) :

.sidebar-elt .content a.anvil-component, .sidebar-elt .label-text {
    padding-left: 14px;
    padding-right: 14px;
}
1 Like
#3

So the components don’t actually move; they just seem to move (to the user) due to one set of components hiding, while their doppelgangers un-hide. Right?

#4

That’s right, they ‘move’ just as things in motion pictures ‘move’ between frames… it’s all an illusion! wiggles fingers

#5

Works for me! :smile:

As an object-oriented guy, I feel compelled to distinguish between actually moving an object’s internal state and duplicating it. When objects are duplicated, it’s easy to forget the potential synchronization issues (e.g., whoops! I forgot to update member X on one of the duplicates…).

1 Like
#6

I tested the Login and Logout buttons on iPhone using safari. Nothing happens when you click them.

#7

I appreciate the work that was done here, but I feel like it’s showing to run counter to the claims that were made in the video made by this company listed here, at the 2:44 mark

"…or indeed on my phone. Anvil apps automatically work on small screens

To me, this means rendered in a faithful manner and well tested. Having buttons that don’t work and changing the fundamental layout doesn’t seem to support the claim made. Having to force your users to do something claimed to be automatic doesn’t seem very honest of a claim.

#8

Genuine question (as I’m no html/css expert by any meaningful measure), but would any system move components from one nav bar to another without some code?

In my mind what @shaun is demonstrating would be tough for the environment (ie CSS) to work out and execute on its own, and you’d still have to put the click events on the buttons (though they could be shared).

Can you point to how another system (or raw html/css) would handle the above? Like I say, genuine question as I’m keen to learn.

#9

@david.wylie, I did not intend to disparage or pooh-pooh the effort, or the effect. I am not arguing to automate the physical movement of objects from one container to another, codelessly or otherwise. Rather, I tried to

  1. encourage us all to use language more precisely and accurately (move != duplicate). When we talk about the behavior of systems that behave with mathematical precision.
  2. make explicit the tradeoffs and requirements of this inventive technique, so that it can be employed successfully with the least amount of surprise.

If that was not apparent from the start, then I absolutely apologize to all concerned.

You may want to move this to its own topic.

As I understand it, Embarcadero’s visual designer, RAD Studio, does allow for device-specific window layouts, with its FireMonkey library of visual components. The same underlying visual components, but themed, sized, placed and arranged differently, depending on the device and the orientation (landscape vs. portrait) of the screen.

But I haven’t looked at it in detail, so I don’t know whether it actually moves components from one container to another, e.g., on device rotate or window resize. It might be a tear-down-and-re-create sort of arrangement, for all I know. If you’re interested, they do have videos (e.g., Google Search, recent video), demonstrating how, as a developer, you would/could use their feature. I see the potential for picking up some extremely useful ideas there.

The parallels are very strong. Both systems store a visual-component layout as an object hierarchy in a file. Anvil’s visual designer uses a custom .yaml format; RAD Studio’s visual designer uses their own, Pascal-inspired text format. Both can create and customize layouts on-the-fly via code.

RAD Studio apps are desktop-based, not browser-based, so switching from one layout to another (e.g., landscape -> portrait) would typically be handled by their own library code, not CSS. However, it seems that such code can/would/should be event-driven, in both environments, so there may not be that much of a difference in practice.

#10

My response was to the OP at the suggestion Anvil was not being entirely straight with their claims. In my mind certain effects are always going to require JS/CSS/trickery and therefore the solution suggested was, in my mind, not unreasonable.

I think these days a lot of design magic (be it JS or CSS) is taken for granted as being automatic or part of “built in” features relating to responsive design, when in actual fact it’s just hidden in the background and often blindly included through JS & CSS libraries.

Whether things like that should be hidden from the Anvil developer so they too happen by magic is, I suppose, another question and one for which there will be many opinions, I’m sure :slight_smile:

All of that, of course, may be my lack of understanding of how a lot of front-endery works.