Hello folks! We have been very busy writing a lot of mobile apps in 2017. We are hopeful to get the same opportunity in 2018. We write native mobile Xamarin apps using a couple different versions. Currently, we are using Xamarin.iOS version – 184.108.40.206, Xamarin.Android version – 220.127.116.11.
There are a number of great reasons we create Xamarin apps. The primary reason is that Xamarin helps us produce fast and smooth applications with native design and performance in a “mostly” single codebase for both iOS and Android platforms. For a lot of our Xamarin apps, we are using Xamarin.Forms. In particular, we are using Xamarin.Forms version 2.3.4.
Anyone that creates mobile apps knows that there will be blood… and challenges. A lot of the technologies are bleeding edge. And of course, during the development process, we faced a certain number of our own challenges. We strongly believe in using the principles of the HEART Framework / GSM model for UI / UX development and metric measurement.
Today we want to discuss implementing a solution that affects almost all of our applications regarding the Adoption and Task Success items of the HEART Framework. We hope this helps anyone looking for solutions to dealing with any of these particular associated areas:
- iOS Keyboard Hide Content
- Xamarin Keyboard Issue
- Keyboard Custom Renderer
- Xamarin Forms Hide Content
- Xamarin Keyboard Overlap Entry
- Xamarin Keyboard Overlap Textfield
- Xamarin iOS Cover Entry
Data, data, data. In particular, user input data. In almost every application or program we have ever built (web, mobile, bots, you name it..) we require user input in the form of data. Typically we require the app user to enter some form of data for user interaction. Some examples are:
- Fields for login and password.
- Setting a monetary amount.
- User registration purposes.
- Sending an app download request message to a friend.
We are constantly creating micro-interactions within our apps and app workflows to perform tasks which are intuitive, meaningful, and fast. Making the UI / UX intuitive, meaningful, and fast is easier said than done. Especially when the native controls behave in unexpected ways. Let’s use one of our Xamarin apps for a specific example.
We created an app for Support For Your Cause. This is a startup that offers mobile apps to 501(c)(3) businesses, charities, congregations, and non-profits for free. The free mobile apps allow these non-profits to accept electronic monetary donations. Great people and great concept. You can find them here (link to www.supportforyourcause.com).
Their app requires a fair amount of user input data during different micro-interactions and workflows. This was storyboarded and designed purposefully to eliminate as many taps and swipes as possible. However, their users would still need to enter a various field of data, such as username for authentication, and so on.
While creating their iOS application for Apple devices, we had a UI/UX issue. One piece of required data, in particular, wreaked havoc on our form and keyboard. The data was the donation dollar amount to give. Obviously, the only way to enter a custom amount is to use an onscreen keyboard. And for iOS, the keyboard overtakes and overlaps the entry fields so the user can’t actually see the data as they enter it.
This required the user to essentially guess what they are typing. Not only is this not intuitive nor meaningful if there is a mistake, but it would not be fast either. Even adding a custom monetary donation amount, as simple as a UI task as can be, caused trouble. Below you can see the screenshots of this problem.
Fortunately, during our troubleshooting research, we found a special library for Xamarin.Forms that solves this problem. However, this library presented us with a new problem. Instead of covering the data field, it lifted the data field in the UI off the visible screen. This behaved the same way, regardless of the entry or the position on the UI screen. It would simply lift the data entry control off the visible part of the screen.
We have two places where this behavior was particularly worrisome. The first is in a WebView. The second is for pages that have a very large carousel item count. For both of these pages, this library lifts up the entire page. So data entry control was lifted off the visible portion of the screen as well.
We decided to use the source code of this library to rewrite it for our needs. We did this through the use of Custom Renderer functionality. Custom Renderers are a special feature of Xamarin.Forms. We used this to create restrictions for our pages to correct keyboard overlapping for iOS applications.
See our code snippet and the iOS native app results below:
As you can see, Xamarin.Forms custom renderers worked for our needs in this situation. We have used them in many places since. By working closely with the UI/UX team we found a solution to make a simple app workflow task smoother using custom renderers. CONTACT US if you have any additional questions.
Hope this helps. Until next time, happy designing and coding!
1,721 total views, 1 views today