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
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:
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 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("");
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));
There are several problems when we look at the screenshots side by side:
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:
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.
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.
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
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.
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.
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.
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…