Improve layout on keyboard popup

[Bluebugs]

On mobile when a keyboard popup, it will cover the window partially (and not necessarily always in a single rectangular shape). This can lead to your entry being hidden and other side effect. It would be nice if the layout could adapt the displayed information properly. At start a simple resize of the canvas might do. Later on, it might require more complex logic.

[Godrigos]

I've noticed it too. Even on recent realese 1.4.2. The keyboard covers the bottom part of the mobile app version.

[stuartmscott]

On Android this could be resolved by adding android:windowSoftInputMode="adjustResize" to the activity's manifest entry, making it resize when the on-screen keyboard (soft input) becomes visible. @andydotxyz I assume that if the system resizes the GoNativeActivity that change will propagate down accordingly.

Not sure about iOS tho, sorry

[Godrigos]

This may be a dumb question, but since I'm not a professional developer... How would I edit the AndroidManifest.xml after the dist package is created by fyne-cross? I tryed apktool (v2.5.0) but it return an error and the apk is not decoded, so I can't edit the manifest. Simply unzipping the apk gives me a corrupted uneditable file.

[andydotxyz]

I think the packaged AndroidManifest is a binary XML file, so you can edit it with tools that support binary XML editing.

[Godrigos]

Well I'm sorry to say that after searching for software capable of editing/decoding a binaty xml, and finally using Android Studio to decode it. I was unable to consistently test it once I changed the file to add the android:windowSoftInputMode="adjustResize" but was unable to repack the apk with the altered version.
I will keep reading and trying, I just wanted to update you after the responses. I will just rest a bit over it, and let my brain process all the information I had contatc with.
Thanks for the help.

[andydotxyz]

Ah, that sounds promising.
You could try editing the template manifest inside our cmd/fyne/internal/mobile code - then install that command and package as before?

[Godrigos]

Ok, I edited the cmd/fyne/internal/mobile/manifest.go and added android:windowSoftInputMode="adjustResize" to var manifestTmpl. I was unable to install that (not allowed errors), but packaged it again with fyne package -os android -appID "com.github.godrigos.goPCR" -name "goPCR" (stopped using fyne-cross now that I figured out how to use fyne command with the android-ndk). This time the generated apk has a android:windowSoftInputMode="0x10" in its manifest, which wasn't there before the edit, but the behaviour when installed in my cell didn't change, the keyboard still covers part of the fields.

[andydotxyz]

We may have to code in the window size into the toolkit after all.

[andydotxyz]

Now that we have the idea of safe areas on the canvas it could be re-used to avoid drawing under keyboards I think - should be much faster than manipulating the window, but does need to be coded into the driver.

[sdassow]

This is unfortunately a showstopper on mobile for my current project. Is there a way to help with this? Maybe some hints where to start digging?

[andydotxyz]

Only the hint I left above - the safe area of the canvas would need to update to increase the bottom padding to match the keyboard height, then everything should update appropriately.

See the InteractiveArea method on mobile driver for a starting point in the Go code.

[andydotxyz]

This is unfortunately a showstopper on mobile for my current project. Is there a way to help with this? Maybe some hints where to start digging?

The best thing you can do now is to test the PR and give any feedback :)

[sdassow]

Awesome, visually it's exactly what I'm expecting. And nice to see what I was doing wrong when trying to figure it out myself, thanks!

From a function perspective something isn't entirely right yet: when an Entry is active and a Button is tapped, the keyboard closes but the tap itself isn't registered, only a second tap on the button triggers it.
Isolated code example that I'm using to test this outside the app where I see this below.
Enter the input so the keyboard comes up and try to tap the button and it should be visible what I mean.

package main

import (
	"fmt"

	"fyne.io/fyne/v2/app"
	"fyne.io/fyne/v2/container"
	"fyne.io/fyne/v2/layout"
	"fyne.io/fyne/v2/widget"
)

func main() {
	a := app.New()
	w := a.NewWindow("Hello World")

	count := 0
	l := widget.NewLabel("Hello World!")
	b := widget.NewButton("Tap", func() {
		count++
		l.SetText(fmt.Sprintf("tapped: %d", count))
	})
	c := container.New(
		layout.NewBorderLayout(l, b, nil, nil),
		l,
		b,
		widget.NewMultiLineEntry(),
	)

	w.SetContent(c)
	w.ShowAndRun()
}

[andydotxyz]

Thanks for checking this out @sdassow

From a function perspective something isn't entirely right yet: when an Entry is active and a Button is tapped, the keyboard closes but the tap itself isn't registered, only a second tap on the button triggers it.

Is that different to how things work now? I think they may be two disconnected issues...

[sdassow]

Is that different to how things work now? I think they may be two disconnected issues...

Well, a button that hasn't moved by the virtual keyboard does behave different and triggers the tap directly even when in an input field.
Adjusted example code with two buttons to show both aspects:

package main

import (
	"fmt"

	"fyne.io/fyne/v2/app"
	"fyne.io/fyne/v2/container"
	"fyne.io/fyne/v2/layout"
	"fyne.io/fyne/v2/widget"
)

func main() {
	a := app.New()
	w := a.NewWindow("Hello World")

	count := 0
	l := widget.NewLabel("Hello World!")
	ontapped := func() {
		count++
		l.SetText(fmt.Sprintf("tapped: %d", count))
	}

	b1 := widget.NewButton("Tap 1", ontapped)
	t := container.New(
		layout.NewHBoxLayout(),
		l,
		layout.NewSpacer(),
		b1,
	)

	b2 := widget.NewButton("Tap 2", ontapped)
	c := container.New(
		layout.NewBorderLayout(t, b2, nil, nil),
		t,
		b2,
		widget.NewMultiLineEntry(),
	)

	w.SetContent(c)
	w.ShowAndRun()
}

That might be a disconnected issue anyways, but it now becomes noticeable.

[andydotxyz]

Resolved on develop branch ready for v2.5.0

[xaionaro]

@andydotxyz : Thanks! Do you mind referencing which exactly commit fixes this? Just educational purposes, I was looking into the same problem few week ago, and now I'm curious how it was supposed to be solved :)
(of course feel free to ignore the question)

[sdassow]

@andydotxyz : Thanks! Do you mind referencing which exactly commit fixes this? Just educational purposes, I was looking into the same problem few week ago, and now I'm curious how it was supposed to be solved :) (of course feel free to ignore the question)

Had the same, see #4773 🙂