Properly implementing Scroll Views


#1

Alright! I know this has been asked/discussed here quite a few times but I’m going to ask it again because the answers don’t exactly work for me.

First off, I’m trying to properly implement a login page with 2 fields, username and password. I have these fields centrally placed and using percentage based constraints for all 4 constraint value and whenever the password field is focused, it is then covered by the keyboard. I searched this and the recommendation is to place these fields into a scroll view. I did that, built the app and then all of the fields are stacked on top of each other. The assumption here is that the elements inside of a scroll view will have to be set to a static constraint. I set the constraints to a static px value and then BAM, all is good. Or at least I thought it was. I run the app on a smaller device screen and the fields extend beyond the screen.

So my question to the community to the community is, how does everyone else handle this? Are nested elements within a scroll view supposed to not scale with the actual view? Is this normal functionality or a bug within Dropsource? I have include some screenshots of how this is setup. Also, I know that smaller iOS devices are going to be phased out but I just want to make sure that I’m setting this up correctly with as many devices support as possible.

Email text field Constraints

Scroll View Constraints

iPhone X View

iPhone 5s View


#2

Mine did same.

I had an image inside the scroll that pushed it off the page because the image was larger than the screen.

I used a List View for its inherent scrolling and set it to Static instead. Not sure if this would apply to you though.


#3

Images and their native sizing can mess with scrollviews as their internal elements infomation is how scrollviews figure out their sizing and scroll distances etc. It’s a weaker area for Dropsource in that many times in these situations, you will hard code some fixes for different models, sizes, etc… to help the Scrollview class in edge cases.

This isn’t the 1st time I’ve seen older models like the 4 and 5 series iPhones not displaying as intended when the new 8-X models look as expected.


#4

Hey @wade
It’s not really the image I’m having issues with but the actual text input elements. I think it’s the issue of trying to not have the input elements hidden by the keyboard being open and just increasing the end user experience overall.

So just an example, displaying a users profile that has many input fields for first name, last name, email, address, etc. There could be a good number of fields and I’m not sure what constraints need to be set. I’ve tried many combinations and none really seem to get it exactly right. Maybe this is a take the good with bad type of situation and adjust my layout?


#5

Actually now that I’m testing, I see that the only issue is with the 5s. So I’m going to test, test, retest, and then test some more with different constraints. With iOS13 launching this September, the only device I really have an issue with would be the iphone SE which is the same screen size as the 5s. And it’s only with text input elements within a scroll. Other than that, everything else seems to render just fine. Sorry for crying wolf here.


#6

Thanks for the details and update. I wish I had a better solution than agreeing with “tons of tests with different constraints”. You aren’t crying wolf at all. That’s what this forum is here for.

As for the take the good with the bad or adjust UI… I think there’s arguments both ways truly. Another thing some due in UI designs for screens like this where it’s “sort of static but really dynamic due to giving space for a keyboard sometimes” is to treat the page like a tableview. They build the screen out using table cells and imagery to mock a static screen that also inherently places nicely with a keyboard natively. It’s not the easiest thing or the easiest to manage from Dropsource’s perspective but it’s a thing that is done sometimes.

Great job pushing forward!