flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cosma Colanicchia <cosma...@gmail.com>
Subject Re: Air Stage Text Issue
Date Sun, 17 Nov 2013 17:36:43 GMT
I’d like to propose a different view on the problem.

Many native mobile components provide a separate UI strategy for display
end edit: think of single and multiple selection controls, date and time
input controls, etc. Text input controls, in native applications, have a
mixed approach: sometimes, especially on phones and in landscape mode,
provide an input area that is actually part of the soft keyboard, instead
of using the original control UI for interaction. Other times, the original
control is directly used.

I think that, for the majority of mobile applications, it would be a
perfectly reasonable tradeoff to always use a dedicated UI for editing
content. This could be done using the native soft keyboard functionalities,
if the AIR runtime does provide the required hooks. Otherwise, we could
implement a TextPopupInput control managing a popup-on-edit UI. The popup
should only take into account the soft keyboard, instead of clipping,
scrolling, occlusion, etc.

In general, I think we could provide a set of popup edit controls for
mobile, that IMO are currently missing (single selection, multiple
selection, date, time and date/time, etc).

This is not a perfect solution for mobile applications heavily focused on
text input operations (e.g. a note-taking app or a mobile word processor)
but could be a reasonable and consistent for form-based and simpler input
operations, that is the most common scenario in mobile apps.

2013/11/17 Maurice Amsellem <maurice.amsellem@systar.com>

> Thank you Mr. Flexicious  for the code :-)
> I am taking pretty much the same approach, expect that I have encapsulated
> StageText and ImageProxy in its own class, like in StyleableStageText.
> That way, it can be reused in TextAreaStageSkin as well.
> There is something I don't understand in your implementation:
> StyleableStageText implementation is very complex, because the StageText
> which is always displayed, does not belong to the DL, while the proxyImage
> is displayed only in some situations (throw effect after scroll and nested
> popups).
> I tried to tweak it like you did, and abandoned, because the approach we
> are taking ( proxyimage displayed by default, and stage text when editing)
> is antagonist to the one implemented in SST, and the tweaking code was
> actually more complex that rewriting everything from scratch.
> So I am rather surprized that you managed to conciliate both and that the
> resulting code is so simple.
> Don't you have some side effects ?  does it work on Android as well?
> Maurice
> -----Message d'origine-----
> De : Flexicious.com [mailto:flexicious@gmail.com]
> Envoyé : dimanche 17 novembre 2013 17:31
> À : dev@flex.apache.org
> Objet : Re: Air Stage Text Issue
> For what its worth, we have a skin that solves the issue atleast for our
> scenarios.
> http://blog.flexicious.com/post/Scrolling-Issues-With-TextInput-for-Flex-Air-Mobile-Native-StageText.aspx
> .
> It may not be the best workaround, but its better than what we had. For
> us, it was not only scrolling, but things like dropdowns and date pickers
> (which we also skinned for mobile) appeared underneath the stage text.
> On Sun, Nov 17, 2013 at 10:29 AM, Alex Harui <aharui@adobe.com> wrote:
> >
> >
> > On 11/17/13 2:59 AM, "Maurice Amsellem" <maurice.amsellem@systar.com>
> > wrote:
> >
> > >>What I am saying to myself to get some motivation to go ahead, is
> > >>that the "partial occluding" issue could be solved by modifying the
> > >>application code, so that nothing comes in the way
> > >Of the edited text.
> > And note that, in most cases, the next best solution is to modify the
> > application code so that scrolling is not needed.  Just have more
> > screens that you can swipe between.  That kind of modification might
> > be better than trying to implement code that makes sure text inputs
> > don't get partially clipped.
> > >
> > >But I know that it won't prevent people from coming to this forum
> > >(because the other Flex fora are not active) and calling us names :-(
> > Well, they are already complaining, so I doubt things will get worse.
> >
> > -Alex
> >
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message