JavaFX on iOS and Android - are we there yet?

[Pedro Duque Vieira]

>
> This is something worth thinking about. I noticed the fonts weren't the
> right size, implying that the port on iOS isn't picking up the best font
> size, and all the UI controls are sized based on the font, so in theory
> this might be sufficient. But it is true a spin-off with bigger insets
> might be necessary (but it isn't clear to me at least that this will be
> needed).


I don't think basing the controls size on the font used is the best
solution, at least for embeded/mobile. The design guidelines for each
platform mention a min size a control should have so that your finger is
able to touch it and there is no way 2 controls side by side can be
mistakenly touched. This differs from platform to platform as each as its
own studies on the size a control should have for you to easily touch it
with a finger. So this is based on studies which are in turn based on
peoples finger sizes.

Yes, we already show the native keyboard. One mechanism we've discussed for
> input methods is to have some attributes you can add to a
> TextInputControl's properties map, which can then be used to show the right
> keyboard UI.

Cool!!
That's kind of the way you do it in HTML5: you add an attribute saying
which type of text is going to be entered on the input field.

Thanks, best regards,


On Wed, Oct 23, 2013 at 12:35 AM, Richard Bair <richard.bair at oracle.com>wrote:

>
> On Oct 22, 2013, at 9:38 AM, Pedro Duque Vieira <
> pedro.duquevieira at gmail.com> wrote:
>
> These have are just styled CheckBoxes (or Toggle buttons, or Radio
>> Buttons). We've done this for example for DukePad.
>
> Yes that's right but I think that as it is used so much on Android, ios
> and windows 8 it should have a control representation. For instance the
> same can be said of checkbox, you can make one out of a styled toggle
> button but as it is used so much it merits being a control.
>
>
> This is true. From a class count perspective (and embedded) it probably
> would have been better for us not to do CheckBox and RadioButton, but just
> do ToggleButton with some static final ints for doing the styling. But then
> again, maybe not.
>
> > and in having controls that have the necessary properties so that they
> can
> > be "touchable".
> I'm talking about having the appropriate size for instance for you to
> touch it. You can't use Modena straight out for a mobile app. Perhaps
> having a Modena spinoff that has touch in mind.
>
>
> This is something worth thinking about. I noticed the fonts weren't the
> right size, implying that the port on iOS isn't picking up the best font
> size, and all the UI controls are sized based on the font, so in theory
> this might be sufficient. But it is true a spin-off with bigger insets
> might be necessary (but it isn't clear to me at least that this will be
> needed).
>
> What about input controls that popup the ios keyboard for entering text.
> Is this already available? If not how can these be achieved. Also we should
> keep in mind that the keyboard has to change in accordance to what the user
> has to enter: address, number, email, etc..
>
>
> Yes, we already show the native keyboard. One mechanism we've discussed
> for input methods is to have some attributes you can add to a
> TextInputControl's properties map, which can then be used to show the right
> keyboard UI.
>
> Richard
>



-- 
Pedro Duque Vieira