Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Entry did not moves upwards when keyboard is raised #1199

Closed
SelvaKumar68 opened this issue Jan 17, 2018 · 1 comment
Closed

Entry did not moves upwards when keyboard is raised #1199

SelvaKumar68 opened this issue Jan 17, 2018 · 1 comment

Comments

@SelvaKumar68
Copy link

SelvaKumar68 commented Jan 17, 2018

In my custom component I have used one property type of Xamarin.Forms View. My scenario is I am adding Xamarin.Forms Entry (or any other text field) to the view and placing the component to bottom of the screen. While focusing the entry keyboard will popup and the field moves above the keypad and allows us to enter value it is the expected behaviour but in may case entry stays at the same position. So we unable to see what we are editing in entry field. Could you please help me on this?.

Expected Behavior

The Entry becomes disappear with the half of the screen untill the keyboard overlaps.

Actual Behavior

The Entry has to move up with the keyboard takes over the screen

Sample link: https://bugzilla.xamarin.com/attachment.cgi?id=23581

Issue reproducing Video link: https://mail.google.com/mail/u/0/?ui=2&ik=fe63368efa&view=att&th=160310781053cca3&attid=0.1&disp=safe&realattid=f_jawhdor00&zw

@davidortinau
Copy link

Archive.zip

@SelvaKumar68 I'm not sure what's going on with the layout you have in the linked sample. The ScrollView is commented out. I rebuilt a more simple reproduction linked above that works on iOS and Android.

The main key is to put your content within a ScrollView. The content will slide into view.

Another option to consider is how you want to configure the input mode via Android's UseWindowSoftInputModeAdjust. The documentation is here.

If you have any other issues to report in the future related to Xamarin.Forms, please file them at https://github.com/xamarin/Xamarin.Forms/issues/new.

jonpryor pushed a commit that referenced this issue Jun 10, 2021
Changes: xamarin/monodroid@76c04cd...1f2ce15

  * xamarin/monodroid@1f2ce1562: [tools/msbuild] only run _GetPrimaryCpuAbi for Fast Dev (#1208)
  * xamarin/monodroid@691310ede: Bump android-sdk-installer to use Mono.Unix (#1207)
  * xamarin/monodroid@48843fcb2: [tools/msbuild] <GetPrimaryCpuAbi/> selects backup RIDs for .NET 6 (#1205)
  * xamarin/monodroid@4af48f54b: [tools/fastdev] Add error checking when writing data to disk. (#1204)
  * xamarin/monodroid@65b7b2dd4: [tools/fastdev] Rework Unix timestamp calculation code in xamarin.find. (#1202)
  * xamarin/monodroid@401f170e9: [build] fix `dotnet tool install` command (#1203)
  * xamarin/monodroid@a879b250b: Bump to 032d840, xamarin/androidtools@355d015 (#1199)
  * xamarin/monodroid@9f9ee378c: [tools/msbuild] Missing translations for XA0135 (#1198)

Changes: dotnet/android-tools@683f375...49936d6

  * dotnet/android-tools@49936d6: Merge pull request #124 from xamarin/update-libzipsharp
  * dotnet/android-tools@ef78dfc: Bump LibZipSharp to 2.0.0-alpha6
  * dotnet/android-tools@e3d708c: [BaseTasks] fix `\`-delimited paths on macOS (#122)
  * dotnet/android-tools@bdcf899: Reference the new Mono.Unix nuget (#123)
  * dotnet/android-tools@90d7621: [BaseTasks] add ABI detection for RIDs (#121)
  * dotnet/android-tools@79e3b97: [JdkInfo] handle invalid XML from /usr/libexec/java_home (#120)
  * dotnet/android-tools@81519fe: Add SECURITY.md (#119)


Xamarin.Android uses the Mono's Mono.Posix assembly on Unix machines
to perform tasks not possible with BCL classes, provided by the
[`Mono.Posix.NETStandard` NuGet][0].  The `Mono.Posix` source has been
extracted into the [mono/mono.posix repo][1], which is used to build
the new [`Mono.Unix` NuGet package][2].

Update the xamarin/xamarin-android repo -- and various dependencies --
to use the `Mono.Unix` package instead of `Mono.Posix.NETStandard`.
This includes the [`Xamarin.LibZipSharp` NuGet][3], as of
dotnet/android-libzipsharp@cf5e33c6.

`Mono.Unix` no longer uses the older `libMonoPosixHelper` dynamic
library, replaced by a new `libMono.Unix` native library.
Unfortunately, this change broke a number of tests since the
`Mono.Unix.dll` assembly was no longer able to find its companion
native shared library.  While the `Mono.Posix.NETStandard` NuGet
package provides the `libMonoPosixHelper` native library, in practice
the *actual* `libMonoPosixHelper` that was used was the "system"
library included with the system mono.

`Mono.Unix`'s new native helper library, however, must be taken from
the NuGet and both the Mono and dotnet runtimes must be told where to
load the library from once a P/Invoke into `Mono.Unix` is encountered
in managed code.  The native library is copied from the NuGet to the
referencing application's output directory and it should be loaded from
there.  This proved to be easy for the "legacy" Mono: a simple
[`dllmap` configuration][4] and everything works as it should.

With `dotnet` however, dllmap doesn't work.  `dotnet` has instead a
number of mechanisms to configure where the native libraries can be
found (5 I think).  Unfortunately, the mechanisms either require that
a main executable of the application calls the APIs on entry (e.g. in
the `Main()` method) or that a JSON configuration file is provided for
the application, telling the runtime where the native libraries reside.
In case of `Xamarin.Android.Build.Tasks` there is no main executable we
can configure, since it works in the MSBuild context, providing tasks
and utilities to build Xamarin.Android apps.  In this instance, `dotnet`
could be persuaded to find the libraries by calling one of the 5 APIs.
The problem with this approach, however, is that this action would have
to be performed at **every** possible entry point to the
`Xamarin.Android.Build.Tasks` assembly, since any of them could be used
as the first one.  While certainly possible, it would be both fragile
and an unnecessary maintenance burden.  Instead, a simpler (albeit a
bit kludgy) solution was chosen: the `src/Xamarin.Android.Build.Tasks`
build process now takes care of generating a fat (multi-architecture)
binary for macOS hosts (including `x86-64` and `arm64` architectures)
using the `lipo` utility, then it copies the resulting binary to the
same directory where `Xamarin.Android.Build.Tasks.dll` and
`Mono.Unix.dll` live.  The Linux shared library is also copied to the
same location.  The `dotnet` runtime is able to find and load shared
libraries that are in the same directory as the assembly that needs
them and everything works as expected.

[0]: https://www.nuget.org/packages/Mono.Posix.NETStandard/5.20.1-preview
[1]: https://github.com/mono/mono.posix
[2]: https://www.nuget.org/packages/Mono.Unix/
[3]: https://www.nuget.org/packages/Xamarin.LibZipSharp
[4]: https://www.mono-project.com/docs/advanced/pinvoke/dllmap/
@ghost ghost locked as resolved and limited conversation to collaborators Jun 9, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants