Skip to content
This repository has been archived by the owner on Jun 8, 2023. It is now read-only.

Empty padding at the bottom of screens #457

Closed
AmigoDeluxe opened this issue Apr 5, 2020 · 83 comments
Closed

Empty padding at the bottom of screens #457

AmigoDeluxe opened this issue Apr 5, 2020 · 83 comments
Labels
bug Something isn't working follow up Thunkable to follow up moved Moved to internal tracker

Comments

@AmigoDeluxe
Copy link

Platform

✕ Android, ✕ Android companion

Steps to Reproduce

On the X Android companion: Preview any project, even ones that have not been edited in ages
On the X Android: Any apps compiled after (approximately) Saturday, April 4th 2020

Expected Behavior

There should not be any white gaps in the bottom of the app screens

Actual Behavior

There is a white gap on the bottom of the app's screen

Screenshots

Plenty of them, here: https://community.thunkable.com/t/problem-live-test-onandroid-screen-empty-padding-at-the-bottom/552876

@MrMazzone
Copy link

I can confirm this behavior. Seeing it on my end.

@kezb765
Copy link

kezb765 commented Apr 6, 2020

I have the same problem, when enabling "scrollable" for a column (setting "scrollable" for the whole screen is not always an option).

@josmas
Copy link
Contributor

josmas commented Apr 6, 2020

Thanks all for the report and confirmation. We are testing a number of changes on columns; we'll get back to you as soon as we know more. Thanks!

@josmas josmas added bug Something isn't working follow up Thunkable to follow up moved Moved to internal tracker triage Needs reproducible example labels Apr 6, 2020
@AmigoDeluxe
Copy link
Author

@josmas out of curiosity, did anything change in the backend? If not, how would you explain this change impacting everybody?

@josmas
Copy link
Contributor

josmas commented Apr 7, 2020

hi @AmigoDeluxe this looks like a library upgrade and the style tag behaving slightly different in the newer version. The change would most likely have happened on the Companion itself, and those changes in UI rendering trickle down to compiled apps. We are still trying to figure it out though, so take that with a pinch of salt! :)

@hencehuman
Copy link

Thought it was just me... how's it coming along?

@grfr58
Copy link

grfr58 commented Apr 9, 2020

I found a tournaround for this problem. On the screen set the bottom margin first as negative number example -30 and test the app and then you can try to set to 0.
For me it fix the problem. I think is a missing default value on the library

@hencehuman
Copy link

hencehuman commented Apr 9, 2020 via email

@AmigoDeluxe
Copy link
Author

What library?

@AmigoDeluxe
Copy link
Author

AmigoDeluxe commented Apr 9, 2020

So, setting the screen's bottom margin to -30, viewing the app in the companion, then setting it to 0 and viewing the app in the companion does not solve the issue. At least not in my case.

@hencehuman
Copy link

hencehuman commented Apr 10, 2020 via email

@hencehuman
Copy link

hencehuman commented Apr 10, 2020 via email

@grfr58
Copy link

grfr58 commented Apr 10, 2020 via email

@josmas
Copy link
Contributor

josmas commented Apr 10, 2020

All, there is an update that should fix some of the padding issues. Let us know if that is not the case. But please note that this needs a new Companion app and we are waiting for Apple to approve the latest build, so it might take a while to show up.

@josmas
Copy link
Contributor

josmas commented Apr 10, 2020

@AmigoDeluxe this was a combination of and upgrade to react native 0.61 and us having a constant height for the status bar.

@josmas josmas removed the triage Needs reproducible example label Apr 10, 2020
@AmigoDeluxe
Copy link
Author

Just installed Thunkable Companion version 175 on my device but I am not seeing any improvement on this issue. I tried refreshing my project, deleting the app's cached data, tried again, no love. The app's screen is shifted downwards creating white gap at the top and hiding its very bottom. @josmas is this the version we should be expecting or is there another on its way?

Thanks
K

@grfr58
Copy link

grfr58 commented Apr 11, 2020 via email

@AmigoDeluxe
Copy link
Author

Not with version 175 of the Companion. I would rather wait for a proper fix.

@josmas
Copy link
Contributor

josmas commented Apr 11, 2020

@AmigoDeluxe yes, 175 should contain a fix for column padding.

Is this happening in more cases than columns? If anyone can link to a minimal project with the issue, especially if it is not column related, I can try and reproduce again.

@AmigoDeluxe
Copy link
Author

AmigoDeluxe commented Apr 11, 2020

Update: I set all my project's screens margins and paddings to 0 for all four sides and interestingly enough, that fixed the top white space however, the bottom of the screen is still off. And then, all by accident, I tilted my device to landscape and... ta daaaaa!!! The very bottom of the screen is now visible... So there seems to be something specific to portrait mode. If you wonder what that is... it is the bottom navigation bar which is not visible on landscape mode.

I then tilted my device back to portrait mode and got the known issue of the companion showing the contents of the app screen up to the middle of the screen and... guess what? I can now see the bottom elements of my app's screen!

I then switched to gesture navigation so to not have the navigation bar at the bottom and restarted the companion app holding my device in portrait mode and noticed that where there used to be the navigation bar, there is still a white gap.

So let's take a moment and agree on:

a. What top of the app's screen means and
b. What bottom of the app's screen means.

Here is my take:
The top of the app's screen should be determined based on the below cases:

  • If the status bar is disabled in the screen's options in Thunkable then the top of the app's screen should be the top of the smartphone's screen.
  • if the status bar is enabled in the screen's options in Thunkable then then top of the app's screen should be the first line under the status bar.

Here we have another sub-case, where the status bar is enabled but in translucent mode meaning that the app's screen top extends behind the status bar, reaching the top of the smartphone's screen. With that being said, Thunkable should update its platform to support these options:

  1. Off
  2. On
  3. On (Translucent)

Now that we have addressed the top, let's address the bottom:

The bottom of the app's screen should depend on whether the navigation bar or gesture navigation is selected on the device:

  • If gesture navigation is selected then the bottom of the app's screen should be the first line above the gesture bar.
  • If the navigation bar is selected then the bottom of the app's screen should be the first line above the navigation bar.

As before, we have another sub-case where the navigation bar is selected but with that extra option of being able to hide it by pressing a fourth key in the bar which can be enabled through Android's options. By pressing the "Hide navigation keys" button the navigation bar disappears and at that point, the bottom of the app's screen should become the bottom of the smartphone's physical screen just like it happens with any other app (i.e. WhatsApp, Yahoo Weather) in such scenario. Swiping up to reveal the navigation bar again should dynamically set the bottom of the app's screen to the first line of the once again visible navigation bar.

So here is the current situation:

  • The top of the app's screen has no white gap over it but is behind the status bar (translucent scenario described above) which is not the expected behaviour unless a 3rd option is added to the "ShowStatusbar" option in Thunkable. On my Samsung Galaxy S10 device, things are slightly worse as the entire screen is shifted upwards by a few pixels chopping off a part of the screen which is visible on all of my other Android devices and creating an equivalent gap right above the navigation bar at the bottom of the screen.
  • The bottom of the app's screen is right above the navigation bar which at first sight appears to be ok but once I switch to gesture navigation, I once again see the gap.

It is also worth noting that there appears to be a difference in the way screens set as scrollable vs screens not set as scrollable behave. Screens not set as scrollable are aware of the presence of the navigation bar and are sized correctly at the bottom when opened vs. the screens which are set as scrollable.

@josmas does this help at all? Oh, and one more thing... I don't believe the problem is "column padding" as you mention in your previous message but rather a "screen padding" problem. I believe this is a good place troubleshooting the status bar being set to translucent as described here:

https://reactnative.dev/docs/0.61/statusbar#translucent

Thanks
K

@AmigoDeluxe
Copy link
Author

@josmas, would you like any additional information on this issue? What do you think about the above mentioned?

Thanks

@josmas
Copy link
Contributor

josmas commented Apr 15, 2020

@AmigoDeluxe thanks a million for the extra info, that should be enough to track this down but unfortunately I haven't had a chance to look into it. Hoping to have some time towards the end of the week, but that is all very helpful!

@josmas
Copy link
Contributor

josmas commented Apr 21, 2020

FYI: We are still looking into this. Unfortunately it seems to have more edge cases than we anticipated.

@balancedkitchen
Copy link

balancedkitchen commented Apr 24, 2020

I have the same problem!
Are you working on resolving it? Appeared after another update! Why are there always a lot of problems after update up?

@AmigoDeluxe
Copy link
Author

@josmas imagine how inconvenient this is for tens of developers who actually earn their living by applications they built. How is the troubleshooting progressing? Feel free to find us on Discord (https://discord.gg/wgRCzA8) and discuss about the issue if you need help.

@ghost
Copy link

ghost commented May 4, 2020

Following this. My users just noted this to me which means not only the Thunkable developers notice anymore.

@balancedkitchen
Copy link

Anyone who wants compensation or a refund to write to this email: billing@thunkable.com. If you are lucky, someone can reply.

@ghost
Copy link

ghost commented May 4, 2020

Anyone who wants compensation or a refund to write to this email: billing@thunkable.com. If you are lucky, someone can reply.

Probably not looking for a refund. But would love to hear about any updates or potential updates in the works for these.

@josmas
Copy link
Contributor

josmas commented May 5, 2020

Hi all,

as mentioned before, this seems to be a number of related issues. We will soon provide more options for the style bar (there are a number of requests about this) and we are tracking down all the spacing issues (we have refreshed row and column components), as well as moving to version 37 (this will take a bit longer, but it seems to be a lot more stable with regards to the status bar, as noted in a thread above). The first couple of changes will be visible to test users by the end of the week, and if all goes well and all is actually fixed, we will release to all after that. Thanks all for your patience with this.

@josmas
Copy link
Contributor

josmas commented May 5, 2020

heyy @AmigoDeluxe I am trying to replicate case 3 above: This is a project with the things you note there Screen no-scroll, column scroll, and column height is set to "Fit contents" as it should and the screen vertical alignment is set to Top: https://x.thunkable.com/copy/71c453c4aae02ee75f2cd8313b46cfca
I do not see the blank space though. Any other settings I might be missing? I placed a button and an image just to have something in the column, but I guess unless you have a lot of stuff in the column, the scrolling won't come into place?

@ghost
Copy link

ghost commented May 5, 2020

I have an example but it's from my main project. so theres a lot of extra crap but you can see the issue pretty much on each screen. Would that be helpful at all @josmas

@josmas
Copy link
Contributor

josmas commented May 5, 2020

@Jaredgib and @AmigoDeluxe actually, I believe the trick to trigger the issue is to set for instance the image to a height of 1500 so it forces the scrolling behaviour, then I can see a red (made the background that color) gap. If you can confirm, that would be great!

I believe we are covering that issue with the changes in column, but need to double check. I'll let you know as soon as I do.

@josmas
Copy link
Contributor

josmas commented May 6, 2020

We've released what we believe is a fix for case 3 above (by @AmigoDeluxe). You will need Companion version 185 to see it though.
We'll keep working on status bar issues within the upgrade also mentioned above.

@balancedkitchen
Copy link

There has been no progress in resolving the problem for more than a month. I no longer regret requesting a refund for my PRO account

@hencehuman
Copy link

hencehuman commented May 10, 2020 via email

@balancedkitchen
Copy link

Hello josmas ,
because I'm just criticizing, I decided to help a little. This problem (but to a lesser extent) is observed from the moment you make the screens automatically created when using the TopTabNavigator and the BottomTabNavigator. When there are visible and invisible columns and rows, changes occur after opening the screen. As I said here, the problem only occurs in certain cases. Subsequently, the problem becomes bigger by the accumulation of an error in logic, which is duplicated in each newly created screen function. Carefully check how the open TopTabNavigator and BottomTabNavigator works when you need to perform the function of cloning elements that need to be loaded. Each time you open the screen, making the original source invisible after cloning. Make a correction in a cloned item (such as text) and refresh the screen for the correction to appear. Opening, not starting! If you find out what caused this problem, you will find a solution for the following ones.
PS: I don't know if I was able to express myself correctly. I am willing to provide the necessary assistance because this platform has great potential. What is extremely annoying is that after each addition of a feature or component I have to check if the old ones are working properly.

@josmas
Copy link
Contributor

josmas commented May 12, 2020

Hi @balancedkitchen thanks for the extra information.
I am not sure I am reading it correctly. I have created this project to try and reproduce the issues you are seeing with columns. In the first tab of the navigator I clone a column, give it a random background color and show it. As you can see, columns keep being added but their size does not change. Second tab does the same cloning but the columns are made invisible, and the original column keeps its size too. Can you let me know if I got that correct or is there some interaction that I am missing that would show the issues with sizes? This is the project https://x.thunkable.com/copy/add0fbb7010a9c1cf05c31dd517c30ab

@balancedkitchen
Copy link

Hello @josmas ,
That’s not exactly what I meant but you seem to have understood me to a certain extent. When looking at the project when opening (Clones Show) а column has to be cloned (Column1). After color change with (Button1) only the column with change color has to be visible but in your project a second one appears. When going to (Clones hide) and you come back to (Clones Show) the process has to start again (with one visible column) but we get as many cloned columns as times we have switched between the screens. When using (Button1) the change of colors has to be with every click but it only work once. This issue is not connected with the saving of space for invisible columns or rows, it’s connected with the function for opening the screen.
Sorry it’s really hard for me to explain it to you.

@josmas
Copy link
Contributor

josmas commented May 13, 2020

Hi @balancedkitchen if this is about Screen.Opens I would suggest reading the discussion in here. There is also a follow up here (also linked from that first thread). The code that goes inside Opens or Starts should not have an effect if run multiple times. This is called idempotence and I realise these are kind of advanced programming concepts, but they become necessary at certain stages when you are developing a more advanced app. We'd be happy to explore some other ways to write the code you use in Opens; it's not always possible to find just a replacement or full match, but at times it can be close. Feel free to open a thread in the community and tag me if you want to explore some options.

@balancedkitchen
Copy link

balancedkitchen commented May 14, 2020

Hello
Take a look at this project (which completely copies your with slight modifications). You will notice that the screen open command does not work the same when the screen is in TopTap Navigator and outside it.

Here is the link: https://x.thunkable.com/copy/9bccee66fc6e3c2a9e7006e6921ed058

PS: Regarding the links you have left - Thank you. I will get acquainted with them in detail.
Before you automatically added the screens in Top_Tab_Navigator and Bottom_Tab_Navigator, the screen open function worked as in the example I created for your project

@josmas
Copy link
Contributor

josmas commented May 18, 2020

If I am reading this correctly, the different behaviour is due to the fact that a top or bottom navigator can be thought out as subscreens of the navigator itself, that will be alive for as long as the navigator is.

When you open a screen and then navigate out of it, the screen will be closed. So in your example, the columns do not accumulate (like in the top navigator) because they are disposed of when the user goes to another screen. When the user goes back, both Starts and Opens are called.

In the case of the navigator, the navigator screens are not killed or disposed of, so by going to another tab in the navigator, the previous one is not closed as such. So the columns previously created are still alive and they stack.

Does that make any sense?

@balancedkitchen
Copy link

balancedkitchen commented May 21, 2020

Hello @josmas
After this detailed explanation, You have helped me realize how to fix many of the problems with my previous applications after the update . Does this make any sense? I do not know! But let us return to the main problem we are discussing here. Here is a link to a really simple application that visualizes the cases in which it appears.

https://x.thunkable.com/copy/a806d6ab7895dd3af9e0b7caa873377b

@balancedkitchen
Copy link

Any progress?

@AmigoDeluxe
Copy link
Author

Heya. I just noticed the below blocks are now available... Perhaps it is worth playing with them to see if they help at all:

image

@balancedkitchen
Copy link

@AmigoDeluxe a look at this app and you will understand the big problem.
https://x.thunkable.com/copy/a806d6ab7895dd3af9e0b7caa873377b

@AmigoDeluxe
Copy link
Author

I believe you, I had issues too (I opened the bug report actually 😁) but found a workaround which I posted above. Not ideal but at least it works. I hope you have time to check if the new features I mention in my reply to you.

@josmas
Copy link
Contributor

josmas commented May 25, 2020

@balancedkitchen is the issue that when you make it scrollable the height changes?

A scrollable component cannot have a height of fill container because the container is scrollable so it does not have an end as such. So it will reset to fit contents. Not sure if that is what is happening here. If you change the screen background color to anything not white you'll see it when you click on the button at the bottom of your screen.

@AmigoDeluxe we've added those 3 new properties while we are working on the v37 upgrade; hopefully that will provide enough flexibility for now.

@balancedkitchen
Copy link

Okay @josmas. I'm sure you're aware of what bug I'm trying to present to you, even though I haven't followed the basic rule for fill container and fit contents. Here is the same example, but the rule for fill container and fit contents has already been observed. Strange! The application functions in the same way.
Application function:
Visualization of the current state of the columns.
Actions:

  1. Launch the application:
    Row 1 with contents 2 buttons changing the functions of the columns to scroll or not to scroll
    Column 1 - visible and scrolling. Contents Label 1 and Button 3
    Column 2 - invisible and scroll
    Label 1 - cloned 20 times in Column 1 containing the tex status of all columns.
    Label 2 - cloned 20 times in Column 2 containing the tex status of all columns.
    Result: BUG
    Column 1 does not fill the entire screen (I think this is incorrect)
  2. Using Button 2, change Column 2 so that it does not scroll.
    Result: Column 1 already fills the entire screen!
  3. Using Button 2, change Column 2 to scroll.
    Result: Column 1 again does not fill the entire screen!
  4. Using Button 4, change Column 2 to be visible and Column 1 to invisible.
    Result: BUG
    Column 2 does not fill the entire screen (I think this is incorrect)
  5. Using Button 1, change Column 1 so that it does not scroll.
    Result: Column 2 already fills the entire screen!
    I hope that is enough.
    PS: I know how to easily get around this bug. But I do not think it is right to leave this problem unresolved. My English is not very good for which I apologize!

https://x.thunkable.com/copy/7efc41466dfd9f0792f2fec3d3f76087

@josmas
Copy link
Contributor

josmas commented May 25, 2020

Hi @balancedkitchen I can now see the interaction between the two columns. If Column 2 is scrollable, it will use up the space even if it is set as hidden. That does not seem right. I did not understand the problem before. I will have a look at it when I have a chance, thanks for the example project that is very helpful.
It seems to be related to the issues we are having with screen orientation on Android, in which scrollable components are also messed up. Thanks!

@jaredgibb
Copy link

jaredgibb commented Oct 5, 2020

@josmas @AmigoDeluxe so after reading this thread. I’m still unsure how to get rid of that white space? Makes dark mode look silly 👎
B9D553C0-2ADC-485A-B3BE-190CD587D870

@josmas
Copy link
Contributor

josmas commented Oct 6, 2020

hi @jaredgibb I am not sure what you are pointing at, is there a space between the navigator end and the screen end?
Is this a particular version of iOS? There seem to be a couple of issues with navigator spacing that are new and unrelated to the discussion on this thread. One is that the top navs appear under the status bar, and this seems to be at the bottom, but could also be because that space at the top is not properly handled. Can you please open a different thread and add more details about your layout and what you are testing on? Thanks.

@MrMazzone
Copy link

@josmas @jaredgibb I know a new thread needs to be opened for this. But, I believe that space needs to be there because of the iOS gesture navigation. I am assuming that this probably only appears when you use the Bottom Nav, as without the spacing think about how difficult it would be to differentiate between nav bar swipe/press and "Charts" button swipe/press.

Now, changing the color of that area is a different story... I believe that padding exists on all versions of iOS with gesture nav, but the background color extends through that area. Maybe just a tweak to Bottom Nav where the background color is extended past the navigator would easily solve this issue.

@AmigoDeluxe
Copy link
Author

How about setting the screen color to the same blue color as the rest of the screen? Would that change the background color behind the gesture nav bar?

@jane-d-alt
Copy link
Contributor

In response to the original issue: apps tested an downloaded to Android no longer have any gap at the bottom of the screen. This applies to apps with colorful Screen background colors, apps with components such as Buttons at the bottom of the Screen, and apps with Bottom Tab Navigators. We will close this issue now. Apologies for not following up when this behavior was originally resolved.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working follow up Thunkable to follow up moved Moved to internal tracker
Projects
None yet
Development

No branches or pull requests

9 participants