Sample chat app (live demo) and a question on layout handling with keyboard


Hi guys,

I have been working on a Dropsource chat app and you can check it out here:

The biggest issue I need help with is how to handle app layout when the keyboard pulls up. Currently I change the position of the View component which contains the text input for the message. This is done in the “Focused” event of the text input component. However, as you can see in the demo, the view goes back to the original position as soon as you start entering text. My question is whether Dropsource provides a simpler way to handle layout changes when the keyboard tray is open. If not, what would be the reason that the view disappears when you start entering text?



Interesting. I wonder if the original positioning is taking effect upon typing into the field here so it’s dropping the field back to the bottom and with that, hiding the field behind the keyboard when it does. In a code situation on iOS, I would create an Outlet to the constraint anchoring it to the bottom so that I could do some math based on the height of the keyboard to adjust that anchored value.

What if there was another view that was hidden that looked like the same view at the 1 anchored to the bottom of the screen, you could unhide it when tapping on the anchored 1 which gives a similar UX but it wouldn’t hide when typing into it since there is no actual position change, just a “hidden” property Boolean change. Then upon hitting send, you could complete the operation and hide the input view while the keyboard then slides away. It’s a workaround for sure here.

@Nate any thoughts on strategies to combat UI adjustments when keyboards appears/disappear?


Hey guys, we usually recommend placing your elements inside a scroll view to make the content accessible when the keyboard obscures the page.


Hey @sue, do you happen to have a tutorial or a sample showing the proper layout to make it work right? I played with adding a scroll view and the keyboard does push the bottom view with the message input (which is great!). However, there are several problems that I see. Let me show what I have first:

This is my layout:

The scroll view is configured to “stretch out” both vertically and horizontally:

I set a constraint so that the bottom panel “sticks” to the bottom:

Now, when I run the app, the scroll area is not stretched out as expected:

Also, another problem is that the bottom part of the chat area overlaps with the message input view. I could not figure out how to “stack” the table view and the message input view so that they are on top of each other AND would occupy 100% of the vertical space.

You can see the latest build at:



Hey Mark, first thing I’m wondering here is if you might get better results with your bottom panel view outside the scroll view rather than inside it…?


I tried that. When it is outside, it gets hidden behind the keyboard tray.


Ah right. Hm I’m not sure why it’s rendering with that space under it but will possibly need an engineer with some iOS expertise to look into it for you. Having a scrollable element inside another scrollable element might be doing something strange to the page layout.


I am doing it for a demo and really need some help from the Dropsource side. Can you get someone to look into it please?


Sure, I’ve left a note for someone to look into it, just a heads up though that the engineering team won’t be available until Mon.


Just in case something jumps out would you mind sharing a screenshot of the constraints you’re using on the table element?


That was it it! You’re so awesome! The height constraint for the table element was set to 90%. I adjusted it and now it looks exactly how I wanted it:

I just need to figure out how to auto-scroll to the bottom when new messages arrive and the app will be ready to be for the demos.

Thank you very much and Happy Thanksgiving!


Oh lol that’s what I was going to try, lucky guess… :relieved:

I don’t think we have the ability to scroll to the bottom although it might be worth experimenting with the table properties…


I tried this, but it didn’t help:

I am going to play with it some more.


Yeah in all honesty I don’t think we have the ability to do this but don’t want to rule it out in case there’s a workaround I haven’t come across.