Fork us on GitHub

Pixel Perfect - Text Input

Text fields, text areas and their nuanced native behavior
Pixel Perfect - Text Input

Pixel Perfect - Text Input

I started working on this post back in August and so much happened in between I just had to scrap the whole thing and start over again…​ I’ve discussed buttons before and now it’s time for TextField & TextArea. But before we go into that lets take a moment to talk about the problems that arose from the last installment of pixel perfect.

I made a lot of changes to Codename One but there was one particularly painful change: caps text. This proved to be a far more controversial change than I had intended and I had an interesting debate with Nick. I’d appreciate participation in the thread there or here. The gist of the debate is how can we change functionality people rely on without disrupting working code. I honestly didn’t think the caps text change was a big change or would cause the problems it did. However, having said that it’s really hard to rollout a feature without disrupting developers occasionally.

IMO one of the best ways around it is if more people used the source when working with Codename One:

  • You would see problematic things before they make it to the build servers

  • You would be able to patch/fix issues at least locally

  • Debugging into the code would be easier for you

So please use the source and help us all make a better product!

On Top Sidemenu Update

One of the things that did get some scrutiny over the past few weeks is the on-top side menu that caused quite a few regressions. We now have an up to date version of this code which should work nicely with the on-top side menu so if all goes according to plan we’ll flip the switch over this weekend.

As a reminder, we will transition from the original Toolbar sidemenu implementation to a completely new approach that solves a lot of the issues with the old side menu and looks closer to modern native side menus by residing on top of the UI. You can toggle this side menu on/off by invoking Toolbar.setOnTopSideMenu(true); in your init(Object) method (you should use false to turn it off).

Text Components on Android

The material design guideline includes several modes and states for text fields but generally this image represents the desired native look reasonably well:

Native Android text fields
Figure 1. Native Android text fields

One thing that isn’t clear from the screenshot is the floating label which is now becoming standard in Android. I think we’ll probably need a better abstraction for that one…​ Right now a similar UI in Codename One looks like this:

The before shot
Figure 2. The before shot

The current code for doing this looks like this:

TableLayout tl = new TableLayout(3, 2);
Form f = new Form("Pixel Perfect", tl);

TextField title = new TextField("", "Title");
TextField price = new TextField("", "Price");
TextField location = new TextField("", "Location");
TextArea description = new TextArea("");
description.setHint("Description");

f.add(tl.createConstraint().horizontalSpan(2), new FloatingHint(title));
f.add(tl.createConstraint().widthPercentage(30), new FloatingHint(price));
f.add(tl.createConstraint().widthPercentage(70), new FloatingHint(location));
f.add(tl.createConstraint().horizontalSpan(2), new FloatingHint(description));

f.show();

What’s Wrong

There are several problems when we look at the screenshots side by side:

  • No margin

  • Text field border is in Android 4.x style instead of the material design line style

  • Font color is wrong for the title label and the color of the bottom line (both should match)

  • The font is wrong both in the title label and the text

  • Floating hint makes sense in Android but we might need to rethink it for iOS

  • Price has a special case $ symbol prefix that has the color of the title label

Besides those things that are obvious from the screenshots here are a few other things that might be a problem:

  • Focus color behavior is incorrect - in native code the color of the title text and underline change on focus but not the color of the text itself

  • Error message labels should appear below in red

  • Hint text looks different from native hint text

As before I’ll try going through this list and I’ll try fixing these so the look will be more native.

Margin & Border

These are probably the easiest fixes to do with the exception of the colors. After making a few changes to the margin and the border and applying that to the theme we can now see this:

After applying margin and underline border change
Figure 3. After applying margin and underline border change

These were both pretty easy to fix in the designer tool, I just edited the Android native theme and changed the styling for the border and margin. I also needed a style for FloatingHint which matches the label on top. It needs to match the margin of the text field now.

Colors

One of the problem in the simulator screenshot process is that it hides the currently editing text, in the picture below it isn’t clear that the text we are editing is black while the line is blue and the label on top is also blue.

The editing line and label have the same color
Figure 4. The editing line and label have the same color

Right now we don’t have any way to define a standard color palette in the theme. So I can’t pick a color constant and need to pick a specific color for the border to work with. This is something we should probably address in the theme toolchain but it’s not a trivial fix and requires some thought. In general I’d like to define a color scheme and automatically generate the native Android colors.xml etc. to create a more uniform UX.

In terms of focus I had to do a bit more work. I added a new method to Component shouldRenderSelection() which can be overriden to indicate whether selection is shown. Normally in touch devices the selected state only appears when touching the screen so this is essential for this case.

Fonts

The fonts are also a pretty easy change. I used the native regular at first but then comparing it to the native UI it seems that the light version of the font is closer to the design.

Better sized roboto font
Figure 5. Better sized roboto font

I also styled the FloatingHint text with a smaller version of the same font and adapted the TextHint to use the same font with a gray color.

What’s Next

All of these changes should be up in the next update and might disrupt existing code. As I mentioned before this is expected as we move the product forward. In the next installment I’ll try to address the remaining issues and hopefully fine tune some of the behaviors:

  • The floating hint API is bad - we will need a new API to represent text field and label together both for iOS and Android

  • We will need a solution for the special case characters or icons that remain when typing and aren’t there as a hint. There are several tricks we can do but I need to give this some thought especially how they will work with something like a floating hint

  • We need to handle error messages in a standard way

I hope to address all of those quicker than I got around to doing this installment…​

Share this Post:

Posted by Shai Almog

Shai is the co-founder of Codename One. He's been a professional programmer for over 25 years. During that time he has worked with dozens of companies including Sun Microsystems.
For more follow Shai on Twitter & github.