You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Maurice Amsellem <ma...@systar.com> on 2013/11/24 02:22:13 UTC
Mobile TextInput swipe
Hi Team,
I am currently working on the swipe issue with ScrollableStageText on mobile and would like your advice / help
The issue is the following: you cannot initiate a scroll/swipe by touching inside a TextInput or TextArea.
1) current situation:
- in ScrollableStageText, the StageText is only shown when TI is in focus, and is replaced by a proxy when out of focus.
- when scrolling, only the proxies are scrolled, so it works well.
- when editing TI2 after TI1:
- TI1 receives focus out => TI1 stageText is hidden, proxy shown
- TI2 receives the focus on mouse down => TI2 stage text is focused
- stageText for TI2 is displayed (and proxy hidden)
=> the problem, is that since focus is set on mousedown, it's too late to detect scrolling,
so I had to prevent it, by calling event.preventDefautl() in touchInteractionStarting handler.
2) proposed solution
To overcome that issue, I changed the focus to be set on MOUSE UP, instead of mouse down, so that I can detection touch scroll, and prevent editing.
It works pretty well but has the following side effect :
When editing TI1 after TI2, the soft keyboard (which was visible), lowers when pressing TI2, and raises back when releasing your finger.
The reason for that is that is when pressing TI2:
- TI1 has received focus out, so its StageText it's not visible anymore
- TI2 did not receive focus yet, so its stageText is not visible yet
=> no stageText, no SoftKeyboard.
TI2 stage text is assigned focus only when finger is released.
3) proposed solution to the side effect:
Since the only way of having a soft keyboard visible is to have an active StageText, and call assingFocus() on it,
I added a dummy static StageText to the stage, with no text and a viewport extent of 0,0.
This stageText is assigned focus between the time finger is pressed, so TI1 and TI2 stage texts are not visible, and the finger is released, where TI2 stage text is displayed.
That way, the soft keyboard does not disappear.
______________
It works well, but I consider the dummy StageText as a HORRIBLE HACK.
So if someone has a better solution that also meets the requirements, I will be happy to take it.
Regards,
Maurice
-----Message d'origine-----
De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
Envoyé : vendredi 22 novembre 2013 11:37
À : dev@flex.apache.org
Objet : RE: Mobile TextInput Implementation status
Hi,
I fixed the two issues that were reported in the JIRA ticket by Colins Childs.
fixed two issues reported above:
- two focused text inputs
- stage text floating above content.
Committed and pushed to develop branch
https://git-wip-us.apache.org/repos/asf?p=flex-sdk.git;a=commit;h=9e4bf21f
Mobile Mustella test pass:
- mobile/components/TextInput
- mobile/compoents/TextArea
- mobile/Softkeyboard
-----Message d'origine-----
De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
Envoyé : mardi 19 novembre 2013 18:18
À : dev@flex.apache.org
Objet : RE: Mobile TextInput Implementation status
Sure. You need mobilecomponents and mobiletheme
-----Message d'origine-----
De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de OmPrakash Muppirala Envoyé : mardi 19 novembre 2013 18:14 À : dev@flex.apache.org Objet : RE: Mobile TextInput Implementation status
On Nov 19, 2013 9:05 AM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>
> Since jenkins is down, do you need the updated swc ?
Which project is it? I can just compile it and drop it in the sdk directory.
Thanks,
Om
>
> -----Message d'origine-----
> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
> OmPrakash
Muppirala
> Envoyé : mardi 19 novembre 2013 17:55
> À : dev@flex.apache.org
> Objet : RE: Mobile TextInput Implementation status
>
> On Nov 19, 2013 4:53 AM, "Maurice Amsellem"
> <ma...@systar.com>
> wrote:
> >
> > Fixed a few other issues
> > (see https://issues.apache.org/jira/browse/FLEX-33166)
> > > FIXED : Soft keyboard partially closes/opens when moving the
> > > focus
> from one TI to another.
> > > to fix the issue above, had to trigger TI edition on mousedown
> > > instead
> of mouse click (like in StyleableStageText)
> > > fixed bug caused by the above.
> >
> > All related mustella test pass. ( mobile/TextInput, mobile/TextArea,
> mobile/SoftKeyboard)
> >
> > Om, can you please make a last test run on Android, so I can close
> > the
> ticket.
> >
>
> Will do, later in the night for me.
>
> Thanks,
> Om
>
> > Maurice
> >
> > -----Message d'origine-----
> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
> > Envoyé : mardi 19 novembre 2013 00:36 À : dev@flex.apache.org Objet
> > : RE: Mobile TextInput Implementation status
> >
> > Just received results of Om testing on Android (Tested on Samsung
> > Galaxy
> SIII (Android 4.1.2) and Samsung Galaxy Tab 2 (Android 4.2.2)).
> > It's working fine.
> > Thanks you Om for the quick testing, that's really good news.
> >
> > Maurice
> > -----Message d'origine-----
> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
> > Envoyé : lundi 18 novembre 2013 16:49 À : dev@flex.apache.org Objet
> > : Mobile TextInput Implementation status
> >
> > Memory profiling of the new skins:
> >
> > It's as expected: alloc memory = pixel width x pixel height x
> > 4bytes
> per pixel.
> >
> > First figure is for iPad , second is for iPad retina.
> >
> > - 25KB / 100 KB of bitmap memory allocated for a single line TI with
> default size
> > - ~500KB / ~ 2 MB for a pages stuffed with text inputs / text Areas
> > - 3 MB / 12 MB for a full-page TA => in this case, it's better to
> > use the
> old skins.
> >
> > The bitmap is allocated while the TI is added to the stage, and
> > disposed
> when it's removed from the stage
> >
> > Maurice
> >
> > -----Message d'origine-----
> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
> > Envoyé : lundi 18 novembre 2013 02:10 À : dev@flex.apache.org Objet
> > : RE: Mobile TextInput Implementation status
> >
> >
> > 1) to help debug if something goes wrong on Android, you can set the
> following mx_internal flag:
> > ScrollableStageText.debugProxyImage = true;
> >
> > It will display the proxy bitmaps in magenta background.
> >
> > 2) proxy methods in ScrollableStageText has been abstracted on
> > purpose to
> DisplayObject instead of Bitmap.
> > This is so that one could override the class to use another proxy (eg.
> StyleableTextField) which is less memory consuming than bitmaps.
> > In wich case, you will have to override:
> > createProxy
> > updateProxy
> > disposeProxy
> >
> > 3) StageTextSkinBase inner textDisplay creation method is
> > externalized so
> that it can be customized.
> >
> > Example for ScrollableStageTextInputSkin:
> > override protected function
createTextDisplay():IStyleableEditableText
> > {
> > return new ScrollableStageText(multiline);
> > }
> >
> > That way, you can derive from existing skins, instead of monkey
> > patching
> the default skin, if you only need to change the internal editable
> text
class.
> >
> > Note also that displayText is now of type IStyleableEditableText,
> > instead
> of StyleableStageText, for the same purpose.
> >
> > Regards,
> >
> > Maurice
> >
> > -----Message d'origine-----
> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
> > Envoyé : lundi 18 novembre 2013 01:49 À : dev@flex.apache.org Objet
> > : RE: Mobile TextInput Implementation status
> >
> > Run mustella tests:
> > Mobile/Components/TextInput
> > Mobile/components/TextArea
> > Mobile/StageText
> >
> > All pass.
> >
> > Maurice
> >
> > -----Message d'origine-----
> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
> > Envoyé : lundi 18 novembre 2013 01:11 À : dev@flex.apache.org Objet
> > : RE: Mobile TextInput Implementation status
> >
> > Hi, I have committed and pushed tentative fix for
> https://issues.apache.org/jira/browse/FLEX-33166
> >
> > Tested on iPad 2 / 3.
> > Not tested on Android.
> > I couldn't run mustella mobile tests. For some reason, they are
> > broken
> on my machine ( says: Passes: 0 / Fails: 0).
> >
> > The new skins are now the defaults for TextInput and TextArea on mobile:
> >
> > TextInput skinClass =
> > spark.skins.mobile.ScrollingStageTextInputSkin
> > TextArea skinClass = spark.skins.mobile.ScrollingStageTextAreaSkin
> >
> > The old skins are still there, under the same name.
> >
> > Please review and tests, and this is a sensitive change...
> >
> > Your comments and feedback are welcome.
> >
> > Maurice
> >
> > -----Message d'origine-----
> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
> > Envoyé : lundi 18 novembre 2013 00:08 À : dev@flex.apache.org Objet
> > : RE: Mobile TextInput Implementation status
> >
> > Founds some bugs, so I won't commit until they are fixed...
> >
> > Maurice
> >
> > -----Message d'origine-----
> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
> > Envoyé : dimanche 17 novembre 2013 21:18 À : dev@flex.apache.org Objet :
> RE: Mobile TextInput Implementation status
> >
> > >I can help out with Android testing.
> > Thanks
> >
> > >Should I wait for the nightly or are these fixes on a branch?
> > >Nightly
> would be preferable so as to allow more people to test the fix.
> > I will push to the develop/ so that they be in the nightly
> >
> > >It would be better to keep the old one around with the same name.
> > >Folks
> might have subclassed it to build their own implementations.
> >
> > What about :
> > ScrollableStageText
> > ScrollableStageTextInputSkin
> >
> > For the new classes ?
> >
> > Maurice
> >
> > -----Message d'origine-----
> > De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
> > OmPrakash
> Muppirala Envoyé : dimanche 17 novembre 2013 20:27 À :
> dev@flex.apache.orgObjet : Re: Mobile TextInput Implementation status
> >
> > On Nov 17, 2013 10:56 AM, "Maurice Amsellem"
> > <ma...@systar.com>
> > wrote:
> > >
> > > Hi,
> > >
> > > Here is a brief status of the implementation of Mobile Text Input,
> > > along
> > with some questions:
> > >
> > > Implementation overview:
> > > The change is mainly on the class StyleableStageText, which now
> > > takes the
> > opposite approach than the previous one:
> > > - display proxy image bitmap by default
> > > - display StageText only when editing
> > > StageTextInputSkin/StageTextAreaSkin has been modified to use this
> > > class
> > >
> > > - to make it easier to change StageTextInputSkin internal
> > StyleableStageText component, the variable textDisplay is now of
> > type
> IStyleableEditText
> > >
> > > Behavior changes:
> > > - scrolling and overlapping of text is well managed , as it
> > > always uses
> > the bitmap proxy, which is a Flex component: all the text inputs
> > are
> scrolling
> > > - text occluding while editing is not managed yet, which means
> > > the
> > edited text may overlap other UIs. (TO BE DONE)
> > >
> > > Testing:
> > > - tested on iPad 2 and iPad 3: TI in scrolling forms, TI in
callouts
> > > - *NEEDS TO BE TESTED ON ANDROID*
> > > - memory consumption tests yet to be done
> > > - mustella test yet to be run
> > >
> > >
> > > Questions:
> > > - Can someone please test on Android ?
> >
> > I can help out with Android testing. Should I wait for the nightly
> > or
> are these fixes on a branch? Nightly would be preferable so as to
> allow
more people to test the fix.
> >
> > Thanks,
> > Om
> >
> > > - I have chosen to directly replace StyleableStageText.
> > > Maybe I can also leave the old StyleableStageText with a different
> > > name,
> > so that it can be used in case there is an issue with the new one ?
> > or
> the other way?
> >
> > It would be better to keep the old one around with the same name.
> > Folks
> might have subclassed it to build their own implementations.
> >
> > > Now that it is an interface, it's easy to subclass the
> > StageTextInputSkin, and override createTextDisplay() to use another
class.
> > >
> > >
> > > Maurice
> > >
Re: Mobile TextInput swipe
Posted by Lee Burrows <su...@leeburrows.com>.
To unsubscribe, send an email to dev-unsubscribe@flex.apache.org
<ma...@flex.apache.org>
On 25/11/2013 09:56, vijay kumar wrote:
> Please remove me from this mailing list
>
>
> On Sun, Nov 24, 2013 at 6:52 AM, Maurice Amsellem <
> maurice.amsellem@systar.com> wrote:
>
>> Hi Team,
>>
>> I am currently working on the swipe issue with ScrollableStageText on
>> mobile and would like your advice / help
>>
>> The issue is the following: you cannot initiate a scroll/swipe by
>> touching inside a TextInput or TextArea.
>>
>> 1) current situation:
>>
>> - in ScrollableStageText, the StageText is only shown when TI is in focus,
>> and is replaced by a proxy when out of focus.
>> - when scrolling, only the proxies are scrolled, so it works well.
>>
>> - when editing TI2 after TI1:
>> - TI1 receives focus out => TI1 stageText is hidden, proxy shown
>> - TI2 receives the focus on mouse down => TI2 stage text is focused
>> - stageText for TI2 is displayed (and proxy hidden)
>>
>> => the problem, is that since focus is set on mousedown, it's too late to
>> detect scrolling,
>> so I had to prevent it, by calling event.preventDefautl() in
>> touchInteractionStarting handler.
>>
>> 2) proposed solution
>> To overcome that issue, I changed the focus to be set on MOUSE UP, instead
>> of mouse down, so that I can detection touch scroll, and prevent editing.
>>
>> It works pretty well but has the following side effect :
>> When editing TI1 after TI2, the soft keyboard (which was visible), lowers
>> when pressing TI2, and raises back when releasing your finger.
>>
>> The reason for that is that is when pressing TI2:
>> - TI1 has received focus out, so its StageText it's not visible anymore
>> - TI2 did not receive focus yet, so its stageText is not visible yet
>> => no stageText, no SoftKeyboard.
>> TI2 stage text is assigned focus only when finger is released.
>>
>> 3) proposed solution to the side effect:
>> Since the only way of having a soft keyboard visible is to have an active
>> StageText, and call assingFocus() on it,
>> I added a dummy static StageText to the stage, with no text and a
>> viewport extent of 0,0.
>> This stageText is assigned focus between the time finger is pressed, so
>> TI1 and TI2 stage texts are not visible, and the finger is released, where
>> TI2 stage text is displayed.
>> That way, the soft keyboard does not disappear.
>> ______________
>>
>> It works well, but I consider the dummy StageText as a HORRIBLE HACK.
>> So if someone has a better solution that also meets the requirements, I
>> will be happy to take it.
>>
>> Regards,
>>
>> Maurice
>>
>> -----Message d'origine-----
>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>> Envoyé : vendredi 22 novembre 2013 11:37
>> À : dev@flex.apache.org
>> Objet : RE: Mobile TextInput Implementation status
>>
>> Hi,
>> I fixed the two issues that were reported in the JIRA ticket by Colins
>> Childs.
>>
>> fixed two issues reported above:
>> - two focused text inputs
>> - stage text floating above content.
>>
>>
>> Committed and pushed to develop branch
>> https://git-wip-us.apache.org/repos/asf?p=flex-sdk.git;a=commit;h=9e4bf21f
>>
>> Mobile Mustella test pass:
>> - mobile/components/TextInput
>> - mobile/compoents/TextArea
>> - mobile/Softkeyboard
>>
>>
>> -----Message d'origine-----
>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>> Envoyé : mardi 19 novembre 2013 18:18
>> À : dev@flex.apache.org
>> Objet : RE: Mobile TextInput Implementation status
>>
>> Sure. You need mobilecomponents and mobiletheme
>>
>> -----Message d'origine-----
>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de OmPrakash
>> Muppirala Envoyé : mardi 19 novembre 2013 18:14 À : dev@flex.apache.orgObjet : RE: Mobile TextInput Implementation status
>>
>> On Nov 19, 2013 9:05 AM, "Maurice Amsellem" <ma...@systar.com>
>> wrote:
>>> Since jenkins is down, do you need the updated swc ?
>> Which project is it? I can just compile it and drop it in the sdk
>> directory.
>>
>> Thanks,
>> Om
>>
>>> -----Message d'origine-----
>>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>> OmPrakash
>> Muppirala
>>> Envoyé : mardi 19 novembre 2013 17:55
>>> À : dev@flex.apache.org
>>> Objet : RE: Mobile TextInput Implementation status
>>>
>>> On Nov 19, 2013 4:53 AM, "Maurice Amsellem"
>>> <ma...@systar.com>
>>> wrote:
>>>> Fixed a few other issues
>>>> (see https://issues.apache.org/jira/browse/FLEX-33166)
>>>>> FIXED : Soft keyboard partially closes/opens when moving the
>>>>> focus
>>> from one TI to another.
>>>>> to fix the issue above, had to trigger TI edition on mousedown
>>>>> instead
>>> of mouse click (like in StyleableStageText)
>>>>> fixed bug caused by the above.
>>>> All related mustella test pass. ( mobile/TextInput, mobile/TextArea,
>>> mobile/SoftKeyboard)
>>>> Om, can you please make a last test run on Android, so I can close
>>>> the
>>> ticket.
>>> Will do, later in the night for me.
>>>
>>> Thanks,
>>> Om
>>>
>>>> Maurice
>>>>
>>>> -----Message d'origine-----
>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> Envoyé : mardi 19 novembre 2013 00:36 À : dev@flex.apache.org Objet
>>>> : RE: Mobile TextInput Implementation status
>>>>
>>>> Just received results of Om testing on Android (Tested on Samsung
>>>> Galaxy
>>> SIII (Android 4.1.2) and Samsung Galaxy Tab 2 (Android 4.2.2)).
>>>> It's working fine.
>>>> Thanks you Om for the quick testing, that's really good news.
>>>>
>>>> Maurice
>>>> -----Message d'origine-----
>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> Envoyé : lundi 18 novembre 2013 16:49 À : dev@flex.apache.org Objet
>>>> : Mobile TextInput Implementation status
>>>>
>>>> Memory profiling of the new skins:
>>>>
>>>> It's as expected: alloc memory = pixel width x pixel height x
>>>> 4bytes
>>> per pixel.
>>>> First figure is for iPad , second is for iPad retina.
>>>>
>>>> - 25KB / 100 KB of bitmap memory allocated for a single line TI with
>>> default size
>>>> - ~500KB / ~ 2 MB for a pages stuffed with text inputs / text Areas
>>>> - 3 MB / 12 MB for a full-page TA => in this case, it's better to
>>>> use the
>>> old skins.
>>>> The bitmap is allocated while the TI is added to the stage, and
>>>> disposed
>>> when it's removed from the stage
>>>> Maurice
>>>>
>>>> -----Message d'origine-----
>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> Envoyé : lundi 18 novembre 2013 02:10 À : dev@flex.apache.org Objet
>>>> : RE: Mobile TextInput Implementation status
>>>>
>>>>
>>>> 1) to help debug if something goes wrong on Android, you can set the
>>> following mx_internal flag:
>>>> ScrollableStageText.debugProxyImage = true;
>>>>
>>>> It will display the proxy bitmaps in magenta background.
>>>>
>>>> 2) proxy methods in ScrollableStageText has been abstracted on
>>>> purpose to
>>> DisplayObject instead of Bitmap.
>>>> This is so that one could override the class to use another proxy (eg.
>>> StyleableTextField) which is less memory consuming than bitmaps.
>>>> In wich case, you will have to override:
>>>> createProxy
>>>> updateProxy
>>>> disposeProxy
>>>>
>>>> 3) StageTextSkinBase inner textDisplay creation method is
>>>> externalized so
>>> that it can be customized.
>>>> Example for ScrollableStageTextInputSkin:
>>>> override protected function
>> createTextDisplay():IStyleableEditableText
>>>> {
>>>> return new ScrollableStageText(multiline);
>>>> }
>>>>
>>>> That way, you can derive from existing skins, instead of monkey
>>>> patching
>>> the default skin, if you only need to change the internal editable
>>> text
>> class.
>>>> Note also that displayText is now of type IStyleableEditableText,
>>>> instead
>>> of StyleableStageText, for the same purpose.
>>>> Regards,
>>>>
>>>> Maurice
>>>>
>>>> -----Message d'origine-----
>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> Envoyé : lundi 18 novembre 2013 01:49 À : dev@flex.apache.org Objet
>>>> : RE: Mobile TextInput Implementation status
>>>>
>>>> Run mustella tests:
>>>> Mobile/Components/TextInput
>>>> Mobile/components/TextArea
>>>> Mobile/StageText
>>>>
>>>> All pass.
>>>>
>>>> Maurice
>>>>
>>>> -----Message d'origine-----
>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> Envoyé : lundi 18 novembre 2013 01:11 À : dev@flex.apache.org Objet
>>>> : RE: Mobile TextInput Implementation status
>>>>
>>>> Hi, I have committed and pushed tentative fix for
>>> https://issues.apache.org/jira/browse/FLEX-33166
>>>> Tested on iPad 2 / 3.
>>>> Not tested on Android.
>>>> I couldn't run mustella mobile tests. For some reason, they are
>>>> broken
>>> on my machine ( says: Passes: 0 / Fails: 0).
>>>> The new skins are now the defaults for TextInput and TextArea on
>> mobile:
>>>> TextInput skinClass =
>>>> spark.skins.mobile.ScrollingStageTextInputSkin
>>>> TextArea skinClass = spark.skins.mobile.ScrollingStageTextAreaSkin
>>>>
>>>> The old skins are still there, under the same name.
>>>>
>>>> Please review and tests, and this is a sensitive change...
>>>>
>>>> Your comments and feedback are welcome.
>>>>
>>>> Maurice
>>>>
>>>> -----Message d'origine-----
>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> Envoyé : lundi 18 novembre 2013 00:08 À : dev@flex.apache.org Objet
>>>> : RE: Mobile TextInput Implementation status
>>>>
>>>> Founds some bugs, so I won't commit until they are fixed...
>>>>
>>>> Maurice
>>>>
>>>> -----Message d'origine-----
>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> Envoyé : dimanche 17 novembre 2013 21:18 À : dev@flex.apache.orgObjet :
>>> RE: Mobile TextInput Implementation status
>>>>> I can help out with Android testing.
>>>> Thanks
>>>>
>>>>> Should I wait for the nightly or are these fixes on a branch?
>>>>> Nightly
>>> would be preferable so as to allow more people to test the fix.
>>>> I will push to the develop/ so that they be in the nightly
>>>>
>>>>> It would be better to keep the old one around with the same name.
>>>>> Folks
>>> might have subclassed it to build their own implementations.
>>>> What about :
>>>> ScrollableStageText
>>>> ScrollableStageTextInputSkin
>>>>
>>>> For the new classes ?
>>>>
>>>> Maurice
>>>>
>>>> -----Message d'origine-----
>>>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>>> OmPrakash
>>> Muppirala Envoyé : dimanche 17 novembre 2013 20:27 À :
>>> dev@flex.apache.orgObjet : Re: Mobile TextInput Implementation status
>>>> On Nov 17, 2013 10:56 AM, "Maurice Amsellem"
>>>> <ma...@systar.com>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> Here is a brief status of the implementation of Mobile Text Input,
>>>>> along
>>>> with some questions:
>>>>> Implementation overview:
>>>>> The change is mainly on the class StyleableStageText, which now
>>>>> takes the
>>>> opposite approach than the previous one:
>>>>> - display proxy image bitmap by default
>>>>> - display StageText only when editing
>>>>> StageTextInputSkin/StageTextAreaSkin has been modified to use this
>>>>> class
>>>>>
>>>>> - to make it easier to change StageTextInputSkin internal
>>>> StyleableStageText component, the variable textDisplay is now of
>>>> type
>>> IStyleableEditText
>>>>> Behavior changes:
>>>>> - scrolling and overlapping of text is well managed , as it
>>>>> always uses
>>>> the bitmap proxy, which is a Flex component: all the text inputs
>>>> are
>>> scrolling
>>>>> - text occluding while editing is not managed yet, which means
>>>>> the
>>>> edited text may overlap other UIs. (TO BE DONE)
>>>>> Testing:
>>>>> - tested on iPad 2 and iPad 3: TI in scrolling forms, TI in
>> callouts
>>>>> - *NEEDS TO BE TESTED ON ANDROID*
>>>>> - memory consumption tests yet to be done
>>>>> - mustella test yet to be run
>>>>>
>>>>>
>>>>> Questions:
>>>>> - Can someone please test on Android ?
>>>> I can help out with Android testing. Should I wait for the nightly
>>>> or
>>> are these fixes on a branch? Nightly would be preferable so as to
>>> allow
>> more people to test the fix.
>>>> Thanks,
>>>> Om
>>>>
>>>>> - I have chosen to directly replace StyleableStageText.
>>>>> Maybe I can also leave the old StyleableStageText with a different
>>>>> name,
>>>> so that it can be used in case there is an issue with the new one ?
>>>> or
>>> the other way?
>>>> It would be better to keep the old one around with the same name.
>>>> Folks
>>> might have subclassed it to build their own implementations.
>>>>> Now that it is an interface, it's easy to subclass the
>>>> StageTextInputSkin, and override createTextDisplay() to use another
>> class.
>>>>>
>>>>> Maurice
>>>>>
>
>
--
Lee Burrows
ActionScripter
Re: Mobile TextInput swipe
Posted by vijay kumar <ku...@gmail.com>.
Please remove me from this mailing list
On Sun, Nov 24, 2013 at 6:52 AM, Maurice Amsellem <
maurice.amsellem@systar.com> wrote:
> Hi Team,
>
> I am currently working on the swipe issue with ScrollableStageText on
> mobile and would like your advice / help
>
> The issue is the following: you cannot initiate a scroll/swipe by
> touching inside a TextInput or TextArea.
>
> 1) current situation:
>
> - in ScrollableStageText, the StageText is only shown when TI is in focus,
> and is replaced by a proxy when out of focus.
> - when scrolling, only the proxies are scrolled, so it works well.
>
> - when editing TI2 after TI1:
> - TI1 receives focus out => TI1 stageText is hidden, proxy shown
> - TI2 receives the focus on mouse down => TI2 stage text is focused
> - stageText for TI2 is displayed (and proxy hidden)
>
> => the problem, is that since focus is set on mousedown, it's too late to
> detect scrolling,
> so I had to prevent it, by calling event.preventDefautl() in
> touchInteractionStarting handler.
>
> 2) proposed solution
> To overcome that issue, I changed the focus to be set on MOUSE UP, instead
> of mouse down, so that I can detection touch scroll, and prevent editing.
>
> It works pretty well but has the following side effect :
> When editing TI1 after TI2, the soft keyboard (which was visible), lowers
> when pressing TI2, and raises back when releasing your finger.
>
> The reason for that is that is when pressing TI2:
> - TI1 has received focus out, so its StageText it's not visible anymore
> - TI2 did not receive focus yet, so its stageText is not visible yet
> => no stageText, no SoftKeyboard.
> TI2 stage text is assigned focus only when finger is released.
>
> 3) proposed solution to the side effect:
> Since the only way of having a soft keyboard visible is to have an active
> StageText, and call assingFocus() on it,
> I added a dummy static StageText to the stage, with no text and a
> viewport extent of 0,0.
> This stageText is assigned focus between the time finger is pressed, so
> TI1 and TI2 stage texts are not visible, and the finger is released, where
> TI2 stage text is displayed.
> That way, the soft keyboard does not disappear.
> ______________
>
> It works well, but I consider the dummy StageText as a HORRIBLE HACK.
> So if someone has a better solution that also meets the requirements, I
> will be happy to take it.
>
> Regards,
>
> Maurice
>
> -----Message d'origine-----
> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
> Envoyé : vendredi 22 novembre 2013 11:37
> À : dev@flex.apache.org
> Objet : RE: Mobile TextInput Implementation status
>
> Hi,
> I fixed the two issues that were reported in the JIRA ticket by Colins
> Childs.
>
> fixed two issues reported above:
> - two focused text inputs
> - stage text floating above content.
>
>
> Committed and pushed to develop branch
> https://git-wip-us.apache.org/repos/asf?p=flex-sdk.git;a=commit;h=9e4bf21f
>
> Mobile Mustella test pass:
> - mobile/components/TextInput
> - mobile/compoents/TextArea
> - mobile/Softkeyboard
>
>
> -----Message d'origine-----
> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
> Envoyé : mardi 19 novembre 2013 18:18
> À : dev@flex.apache.org
> Objet : RE: Mobile TextInput Implementation status
>
> Sure. You need mobilecomponents and mobiletheme
>
> -----Message d'origine-----
> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de OmPrakash
> Muppirala Envoyé : mardi 19 novembre 2013 18:14 À : dev@flex.apache.orgObjet : RE: Mobile TextInput Implementation status
>
> On Nov 19, 2013 9:05 AM, "Maurice Amsellem" <ma...@systar.com>
> wrote:
> >
> > Since jenkins is down, do you need the updated swc ?
>
> Which project is it? I can just compile it and drop it in the sdk
> directory.
>
> Thanks,
> Om
>
> >
> > -----Message d'origine-----
> > De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
> > OmPrakash
> Muppirala
> > Envoyé : mardi 19 novembre 2013 17:55
> > À : dev@flex.apache.org
> > Objet : RE: Mobile TextInput Implementation status
> >
> > On Nov 19, 2013 4:53 AM, "Maurice Amsellem"
> > <ma...@systar.com>
> > wrote:
> > >
> > > Fixed a few other issues
> > > (see https://issues.apache.org/jira/browse/FLEX-33166)
> > > > FIXED : Soft keyboard partially closes/opens when moving the
> > > > focus
> > from one TI to another.
> > > > to fix the issue above, had to trigger TI edition on mousedown
> > > > instead
> > of mouse click (like in StyleableStageText)
> > > > fixed bug caused by the above.
> > >
> > > All related mustella test pass. ( mobile/TextInput, mobile/TextArea,
> > mobile/SoftKeyboard)
> > >
> > > Om, can you please make a last test run on Android, so I can close
> > > the
> > ticket.
> > >
> >
> > Will do, later in the night for me.
> >
> > Thanks,
> > Om
> >
> > > Maurice
> > >
> > > -----Message d'origine-----
> > > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
> > > Envoyé : mardi 19 novembre 2013 00:36 À : dev@flex.apache.org Objet
> > > : RE: Mobile TextInput Implementation status
> > >
> > > Just received results of Om testing on Android (Tested on Samsung
> > > Galaxy
> > SIII (Android 4.1.2) and Samsung Galaxy Tab 2 (Android 4.2.2)).
> > > It's working fine.
> > > Thanks you Om for the quick testing, that's really good news.
> > >
> > > Maurice
> > > -----Message d'origine-----
> > > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
> > > Envoyé : lundi 18 novembre 2013 16:49 À : dev@flex.apache.org Objet
> > > : Mobile TextInput Implementation status
> > >
> > > Memory profiling of the new skins:
> > >
> > > It's as expected: alloc memory = pixel width x pixel height x
> > > 4bytes
> > per pixel.
> > >
> > > First figure is for iPad , second is for iPad retina.
> > >
> > > - 25KB / 100 KB of bitmap memory allocated for a single line TI with
> > default size
> > > - ~500KB / ~ 2 MB for a pages stuffed with text inputs / text Areas
> > > - 3 MB / 12 MB for a full-page TA => in this case, it's better to
> > > use the
> > old skins.
> > >
> > > The bitmap is allocated while the TI is added to the stage, and
> > > disposed
> > when it's removed from the stage
> > >
> > > Maurice
> > >
> > > -----Message d'origine-----
> > > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
> > > Envoyé : lundi 18 novembre 2013 02:10 À : dev@flex.apache.org Objet
> > > : RE: Mobile TextInput Implementation status
> > >
> > >
> > > 1) to help debug if something goes wrong on Android, you can set the
> > following mx_internal flag:
> > > ScrollableStageText.debugProxyImage = true;
> > >
> > > It will display the proxy bitmaps in magenta background.
> > >
> > > 2) proxy methods in ScrollableStageText has been abstracted on
> > > purpose to
> > DisplayObject instead of Bitmap.
> > > This is so that one could override the class to use another proxy (eg.
> > StyleableTextField) which is less memory consuming than bitmaps.
> > > In wich case, you will have to override:
> > > createProxy
> > > updateProxy
> > > disposeProxy
> > >
> > > 3) StageTextSkinBase inner textDisplay creation method is
> > > externalized so
> > that it can be customized.
> > >
> > > Example for ScrollableStageTextInputSkin:
> > > override protected function
> createTextDisplay():IStyleableEditableText
> > > {
> > > return new ScrollableStageText(multiline);
> > > }
> > >
> > > That way, you can derive from existing skins, instead of monkey
> > > patching
> > the default skin, if you only need to change the internal editable
> > text
> class.
> > >
> > > Note also that displayText is now of type IStyleableEditableText,
> > > instead
> > of StyleableStageText, for the same purpose.
> > >
> > > Regards,
> > >
> > > Maurice
> > >
> > > -----Message d'origine-----
> > > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
> > > Envoyé : lundi 18 novembre 2013 01:49 À : dev@flex.apache.org Objet
> > > : RE: Mobile TextInput Implementation status
> > >
> > > Run mustella tests:
> > > Mobile/Components/TextInput
> > > Mobile/components/TextArea
> > > Mobile/StageText
> > >
> > > All pass.
> > >
> > > Maurice
> > >
> > > -----Message d'origine-----
> > > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
> > > Envoyé : lundi 18 novembre 2013 01:11 À : dev@flex.apache.org Objet
> > > : RE: Mobile TextInput Implementation status
> > >
> > > Hi, I have committed and pushed tentative fix for
> > https://issues.apache.org/jira/browse/FLEX-33166
> > >
> > > Tested on iPad 2 / 3.
> > > Not tested on Android.
> > > I couldn't run mustella mobile tests. For some reason, they are
> > > broken
> > on my machine ( says: Passes: 0 / Fails: 0).
> > >
> > > The new skins are now the defaults for TextInput and TextArea on
> mobile:
> > >
> > > TextInput skinClass =
> > > spark.skins.mobile.ScrollingStageTextInputSkin
> > > TextArea skinClass = spark.skins.mobile.ScrollingStageTextAreaSkin
> > >
> > > The old skins are still there, under the same name.
> > >
> > > Please review and tests, and this is a sensitive change...
> > >
> > > Your comments and feedback are welcome.
> > >
> > > Maurice
> > >
> > > -----Message d'origine-----
> > > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
> > > Envoyé : lundi 18 novembre 2013 00:08 À : dev@flex.apache.org Objet
> > > : RE: Mobile TextInput Implementation status
> > >
> > > Founds some bugs, so I won't commit until they are fixed...
> > >
> > > Maurice
> > >
> > > -----Message d'origine-----
> > > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
> > > Envoyé : dimanche 17 novembre 2013 21:18 À : dev@flex.apache.orgObjet :
> > RE: Mobile TextInput Implementation status
> > >
> > > >I can help out with Android testing.
> > > Thanks
> > >
> > > >Should I wait for the nightly or are these fixes on a branch?
> > > >Nightly
> > would be preferable so as to allow more people to test the fix.
> > > I will push to the develop/ so that they be in the nightly
> > >
> > > >It would be better to keep the old one around with the same name.
> > > >Folks
> > might have subclassed it to build their own implementations.
> > >
> > > What about :
> > > ScrollableStageText
> > > ScrollableStageTextInputSkin
> > >
> > > For the new classes ?
> > >
> > > Maurice
> > >
> > > -----Message d'origine-----
> > > De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
> > > OmPrakash
> > Muppirala Envoyé : dimanche 17 novembre 2013 20:27 À :
> > dev@flex.apache.orgObjet : Re: Mobile TextInput Implementation status
> > >
> > > On Nov 17, 2013 10:56 AM, "Maurice Amsellem"
> > > <ma...@systar.com>
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > Here is a brief status of the implementation of Mobile Text Input,
> > > > along
> > > with some questions:
> > > >
> > > > Implementation overview:
> > > > The change is mainly on the class StyleableStageText, which now
> > > > takes the
> > > opposite approach than the previous one:
> > > > - display proxy image bitmap by default
> > > > - display StageText only when editing
> > > > StageTextInputSkin/StageTextAreaSkin has been modified to use this
> > > > class
> > > >
> > > > - to make it easier to change StageTextInputSkin internal
> > > StyleableStageText component, the variable textDisplay is now of
> > > type
> > IStyleableEditText
> > > >
> > > > Behavior changes:
> > > > - scrolling and overlapping of text is well managed , as it
> > > > always uses
> > > the bitmap proxy, which is a Flex component: all the text inputs
> > > are
> > scrolling
> > > > - text occluding while editing is not managed yet, which means
> > > > the
> > > edited text may overlap other UIs. (TO BE DONE)
> > > >
> > > > Testing:
> > > > - tested on iPad 2 and iPad 3: TI in scrolling forms, TI in
> callouts
> > > > - *NEEDS TO BE TESTED ON ANDROID*
> > > > - memory consumption tests yet to be done
> > > > - mustella test yet to be run
> > > >
> > > >
> > > > Questions:
> > > > - Can someone please test on Android ?
> > >
> > > I can help out with Android testing. Should I wait for the nightly
> > > or
> > are these fixes on a branch? Nightly would be preferable so as to
> > allow
> more people to test the fix.
> > >
> > > Thanks,
> > > Om
> > >
> > > > - I have chosen to directly replace StyleableStageText.
> > > > Maybe I can also leave the old StyleableStageText with a different
> > > > name,
> > > so that it can be used in case there is an issue with the new one ?
> > > or
> > the other way?
> > >
> > > It would be better to keep the old one around with the same name.
> > > Folks
> > might have subclassed it to build their own implementations.
> > >
> > > > Now that it is an interface, it's easy to subclass the
> > > StageTextInputSkin, and override createTextDisplay() to use another
> class.
> > > >
> > > >
> > > > Maurice
> > > >
>
--
Thanks,
Vijay Kumar
Re: Mobile TextInput swipe
Posted by Alex Harui <ah...@adobe.com>.
I'm not sure what you mean by "central", but if you're saying that it
isn't clear that a FocusManager is even needed and you could rely on
built-in AIR behavior, that would definitely be worth a try.
-Alex
On 11/24/13 12:16 PM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>IMO, the whole concept of "focus" is much less central on mobile platform
>than it can be on desktop, mainly because there nothing such as Tab or
>arrow keys on a mobile.
>The notable exceptions are:
>- Text Input fields
>- Windows / Popup on mobile (for the hard "back"/"menus" keys).
>
>WDYT?
>
>Maurice
>
>
>-----Message d'origine-----
>De : Alex Harui [mailto:aharui@adobe.com]
>Envoyé : dimanche 24 novembre 2013 16:44
>À : dev@flex.apache.org
>Objet : Re: Mobile TextInput swipe
>
>All this reminded me that I don't think there were any serious upgrades
>to FocusManager for mobile, and it is quite possible that there should be.
>Maybe the whole framework in mobile-mode should ignore mouseDown and
>determine if the gesture is a tap or not before assigning focus.
>
>In FlexJS with the plug-ins, it allows for a possibility of a
>touch-oriented FocusManager if one is needed.
>
>-Alex
>
>On 11/24/13 2:40 AM, "Maurice Amsellem" <ma...@systar.com>
>wrote:
>
>>
>>>BTW, I haven't tried any versions of your code, but I'm still
>>>surprised that text selection works. I would think that trying to
>>>swipe-select a word or placing the insertion cursor >at an exact spot
>>>would also be problematic with the bitmap proxy in the way.
>>
>>You must put the focus on the text before doing any selection (that
>>usual on mobile). So when you focus, the proxy is hidden and the
>>StageText shown, that's why it works.
>>
>>>Let's step back a bit. Why is it too late to detect scrolling on
>>>mousedown? The MX DataGrid tears down its item editors when scrolling
>>>starts. Isn't that similar?
>>The diifrence is that on Desktop, you scroll with the scroll bar,
>>whereas on mobile, you scroll by "swiping" directly on the content.
>>This causes issue for focusing text, but also for selecting an item in
>>a list, etc...
>>So there is a general mechanism that is implemented in
>>TouchScrollingHelp
>>(IIUC) that detects such behavior based on timers and movement
>>thresholds and will trigger touchInteractionStart.
>>
>>As DarkStone says, touchInteractionStart is triggered after mousedown,
>>so if the focus in bound to mouseDown, it's too late.
>>
>>>Does there really need to be more than one StageText instance in play?
>>>When TI1 loses focus can TI2 use that same StageText instance?
>>
>>Actually, it does: ScrollingStageText uses an internal pool, that will
>>reuse the same instance if it has the same properties (multiline, font
>>size, etc).
>>
>>-----Message d'origine-----
>>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 24 novembre
>>2013 06:38 À : dev@flex.apache.org Objet : Re: Mobile TextInput swipe
>>
>>BTW, I haven't tried any versions of your code, but I'm still surprised
>>that text selection works. I would think that trying to swipe-select a
>>word or placing the insertion cursor at an exact spot would also be
>>problematic with the bitmap proxy in the way.
>>
>>Let's step back a bit. Why is it too late to detect scrolling on
>>mousedown? The MX DataGrid tears down its item editors when scrolling
>>starts. Isn't that similar?
>>
>>Does there really need to be more than one StageText instance in play?
>>When TI1 loses focus can TI2 use that same StageText instance?
>>
>>
>>-Alex
>>
>>On 11/23/13 5:22 PM, "Maurice Amsellem" <ma...@systar.com>
>>wrote:
>>
>>>Hi Team,
>>>
>>>I am currently working on the swipe issue with ScrollableStageText on
>>>mobile and would like your advice / help
>>>
>>>The issue is the following: you cannot initiate a scroll/swipe by
>>>touching inside a TextInput or TextArea.
>>>
>>>1) current situation:
>>>
>>>- in ScrollableStageText, the StageText is only shown when TI is in
>>>focus, and is replaced by a proxy when out of focus.
>>>- when scrolling, only the proxies are scrolled, so it works well.
>>>
>>>- when editing TI2 after TI1:
>>> - TI1 receives focus out => TI1 stageText is hidden, proxy shown
>>> - TI2 receives the focus on mouse down => TI2 stage text is focused
>>> - stageText for TI2 is displayed (and proxy hidden)
>>>
>>>=> the problem, is that since focus is set on mousedown, it's too late
>>>to detect scrolling, so I had to prevent it, by calling
>>>event.preventDefautl() in touchInteractionStarting handler.
>>>
>>>2) proposed solution
>>>To overcome that issue, I changed the focus to be set on MOUSE UP,
>>>instead of mouse down, so that I can detection touch scroll, and
>>>prevent editing.
>>>
>>>It works pretty well but has the following side effect :
>>>When editing TI1 after TI2, the soft keyboard (which was visible),
>>>lowers when pressing TI2, and raises back when releasing your finger.
>>>
>>>The reason for that is that is when pressing TI2:
>>>- TI1 has received focus out, so its StageText it's not visible
>>>anymore
>>>- TI2 did not receive focus yet, so its stageText is not visible yet
>>>=> no stageText, no SoftKeyboard.
>>>TI2 stage text is assigned focus only when finger is released.
>>>
>>>3) proposed solution to the side effect:
>>>Since the only way of having a soft keyboard visible is to have an
>>>active StageText, and call assingFocus() on it, I added a dummy
>>>static StageText to the stage, with no text and a viewport extent of
>>>0,0.
>>>This stageText is assigned focus between the time finger is pressed,
>>>so
>>>TI1 and TI2 stage texts are not visible, and the finger is released,
>>>where TI2 stage text is displayed.
>>>That way, the soft keyboard does not disappear.
>>> ______________
>>>
>>>It works well, but I consider the dummy StageText as a HORRIBLE HACK.
>>>So if someone has a better solution that also meets the requirements,
>>>I will be happy to take it.
>>>
>>>Regards,
>>>
>>>Maurice
>>>
>>>-----Message d'origine-----
>>>De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>Envoyé : vendredi 22 novembre 2013 11:37 À : dev@flex.apache.org Objet
>>>: RE: Mobile TextInput Implementation status
>>>
>>>Hi,
>>>I fixed the two issues that were reported in the JIRA ticket by Colins
>>>Childs.
>>>
>>>fixed two issues reported above:
>>>- two focused text inputs
>>>- stage text floating above content.
>>>
>>>
>>>Committed and pushed to develop branch
>>>https://git-wip-us.apache.org/repos/asf?p=flex-sdk.git;a=commit;h=9e4b
>>>f
>>>21f
>>>
>>>Mobile Mustella test pass:
>>>- mobile/components/TextInput
>>>- mobile/compoents/TextArea
>>>- mobile/Softkeyboard
>>>
>>>
>>>-----Message d'origine-----
>>>De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>Envoyé : mardi 19 novembre 2013 18:18
>>>À : dev@flex.apache.org
>>>Objet : RE: Mobile TextInput Implementation status
>>>
>>>Sure. You need mobilecomponents and mobiletheme
>>>
>>>-----Message d'origine-----
>>>De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>>OmPrakash Muppirala Envoyé : mardi 19 novembre 2013 18:14 À :
>>>dev@flex.apache.org Objet : RE: Mobile TextInput Implementation status
>>>
>>>On Nov 19, 2013 9:05 AM, "Maurice Amsellem"
>>><ma...@systar.com>
>>>wrote:
>>>>
>>>> Since jenkins is down, do you need the updated swc ?
>>>
>>>Which project is it? I can just compile it and drop it in the sdk
>>>directory.
>>>
>>>Thanks,
>>>Om
>>>
>>>>
>>>> -----Message d'origine-----
>>>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>>> OmPrakash
>>>Muppirala
>>>> Envoyé : mardi 19 novembre 2013 17:55 À : dev@flex.apache.org Objet :
>>>> RE: Mobile TextInput Implementation status
>>>>
>>>> On Nov 19, 2013 4:53 AM, "Maurice Amsellem"
>>>> <ma...@systar.com>
>>>> wrote:
>>>> >
>>>> > Fixed a few other issues
>>>> > (see https://issues.apache.org/jira/browse/FLEX-33166)
>>>> > > FIXED : Soft keyboard partially closes/opens when moving the
>>>> > > focus
>>>> from one TI to another.
>>>> > > to fix the issue above, had to trigger TI edition on mousedown
>>>> > > instead
>>>> of mouse click (like in StyleableStageText)
>>>> > > fixed bug caused by the above.
>>>> >
>>>> > All related mustella test pass. ( mobile/TextInput,
>>>> > mobile/TextArea,
>>>> mobile/SoftKeyboard)
>>>> >
>>>> > Om, can you please make a last test run on Android, so I can close
>>>> > the
>>>> ticket.
>>>> >
>>>>
>>>> Will do, later in the night for me.
>>>>
>>>> Thanks,
>>>> Om
>>>>
>>>> > Maurice
>>>> >
>>>> > -----Message d'origine-----
>>>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> > Envoyé : mardi 19 novembre 2013 00:36 À : dev@flex.apache.org
>>>> > Objet
>>>> > : RE: Mobile TextInput Implementation status
>>>> >
>>>> > Just received results of Om testing on Android (Tested on Samsung
>>>> > Galaxy
>>>> SIII (Android 4.1.2) and Samsung Galaxy Tab 2 (Android 4.2.2)).
>>>> > It's working fine.
>>>> > Thanks you Om for the quick testing, that's really good news.
>>>> >
>>>> > Maurice
>>>> > -----Message d'origine-----
>>>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> > Envoyé : lundi 18 novembre 2013 16:49 À : dev@flex.apache.org
>>>> > Objet
>>>> > : Mobile TextInput Implementation status
>>>> >
>>>> > Memory profiling of the new skins:
>>>> >
>>>> > It's as expected: alloc memory = pixel width x pixel height x
>>>> > 4bytes
>>>> per pixel.
>>>> >
>>>> > First figure is for iPad , second is for iPad retina.
>>>> >
>>>> > - 25KB / 100 KB of bitmap memory allocated for a single line TI
>>>> > with
>>>> default size
>>>> > - ~500KB / ~ 2 MB for a pages stuffed with text inputs / text
>>>> > Areas
>>>> > - 3 MB / 12 MB for a full-page TA => in this case, it's better to
>>>> > use the
>>>> old skins.
>>>> >
>>>> > The bitmap is allocated while the TI is added to the stage, and
>>>> > disposed
>>>> when it's removed from the stage
>>>> >
>>>> > Maurice
>>>> >
>>>> > -----Message d'origine-----
>>>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> > Envoyé : lundi 18 novembre 2013 02:10 À : dev@flex.apache.org
>>>> > Objet
>>>> > : RE: Mobile TextInput Implementation status
>>>> >
>>>> >
>>>> > 1) to help debug if something goes wrong on Android, you can set
>>>> > the
>>>> following mx_internal flag:
>>>> > ScrollableStageText.debugProxyImage = true;
>>>> >
>>>> > It will display the proxy bitmaps in magenta background.
>>>> >
>>>> > 2) proxy methods in ScrollableStageText has been abstracted on
>>>> > purpose to
>>>> DisplayObject instead of Bitmap.
>>>> > This is so that one could override the class to use another proxy
>>>>(eg.
>>>> StyleableTextField) which is less memory consuming than bitmaps.
>>>> > In wich case, you will have to override:
>>>> > createProxy
>>>> > updateProxy
>>>> > disposeProxy
>>>> >
>>>> > 3) StageTextSkinBase inner textDisplay creation method is
>>>> > externalized so
>>>> that it can be customized.
>>>> >
>>>> > Example for ScrollableStageTextInputSkin:
>>>> > override protected function
>>>createTextDisplay():IStyleableEditableText
>>>> > {
>>>> > return new ScrollableStageText(multiline);
>>>> > }
>>>> >
>>>> > That way, you can derive from existing skins, instead of monkey
>>>> > patching
>>>> the default skin, if you only need to change the internal editable
>>>> text
>>>class.
>>>> >
>>>> > Note also that displayText is now of type IStyleableEditableText,
>>>> > instead
>>>> of StyleableStageText, for the same purpose.
>>>> >
>>>> > Regards,
>>>> >
>>>> > Maurice
>>>> >
>>>> > -----Message d'origine-----
>>>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> > Envoyé : lundi 18 novembre 2013 01:49 À : dev@flex.apache.org
>>>> > Objet
>>>> > : RE: Mobile TextInput Implementation status
>>>> >
>>>> > Run mustella tests:
>>>> > Mobile/Components/TextInput
>>>> > Mobile/components/TextArea
>>>> > Mobile/StageText
>>>> >
>>>> > All pass.
>>>> >
>>>> > Maurice
>>>> >
>>>> > -----Message d'origine-----
>>>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> > Envoyé : lundi 18 novembre 2013 01:11 À : dev@flex.apache.org
>>>> > Objet
>>>> > : RE: Mobile TextInput Implementation status
>>>> >
>>>> > Hi, I have committed and pushed tentative fix for
>>>> https://issues.apache.org/jira/browse/FLEX-33166
>>>> >
>>>> > Tested on iPad 2 / 3.
>>>> > Not tested on Android.
>>>> > I couldn't run mustella mobile tests. For some reason, they are
>>>> > broken
>>>> on my machine ( says: Passes: 0 / Fails: 0).
>>>> >
>>>> > The new skins are now the defaults for TextInput and TextArea on
>>>>mobile:
>>>> >
>>>> > TextInput skinClass =
>>>> > spark.skins.mobile.ScrollingStageTextInputSkin
>>>> > TextArea skinClass = spark.skins.mobile.ScrollingStageTextAreaSkin
>>>> >
>>>> > The old skins are still there, under the same name.
>>>> >
>>>> > Please review and tests, and this is a sensitive change...
>>>> >
>>>> > Your comments and feedback are welcome.
>>>> >
>>>> > Maurice
>>>> >
>>>> > -----Message d'origine-----
>>>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> > Envoyé : lundi 18 novembre 2013 00:08 À : dev@flex.apache.org
>>>> > Objet
>>>> > : RE: Mobile TextInput Implementation status
>>>> >
>>>> > Founds some bugs, so I won't commit until they are fixed...
>>>> >
>>>> > Maurice
>>>> >
>>>> > -----Message d'origine-----
>>>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> > Envoyé : dimanche 17 novembre 2013 21:18 À : dev@flex.apache.org
>>>>Objet :
>>>> RE: Mobile TextInput Implementation status
>>>> >
>>>> > >I can help out with Android testing.
>>>> > Thanks
>>>> >
>>>> > >Should I wait for the nightly or are these fixes on a branch?
>>>> > >Nightly
>>>> would be preferable so as to allow more people to test the fix.
>>>> > I will push to the develop/ so that they be in the nightly
>>>> >
>>>> > >It would be better to keep the old one around with the same name.
>>>> > >Folks
>>>> might have subclassed it to build their own implementations.
>>>> >
>>>> > What about :
>>>> > ScrollableStageText
>>>> > ScrollableStageTextInputSkin
>>>> >
>>>> > For the new classes ?
>>>> >
>>>> > Maurice
>>>> >
>>>> > -----Message d'origine-----
>>>> > De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>>> > OmPrakash
>>>> Muppirala Envoyé : dimanche 17 novembre 2013 20:27 À :
>>>> dev@flex.apache.orgObjet : Re: Mobile TextInput Implementation
>>>> status
>>>> >
>>>> > On Nov 17, 2013 10:56 AM, "Maurice Amsellem"
>>>> > <ma...@systar.com>
>>>> > wrote:
>>>> > >
>>>> > > Hi,
>>>> > >
>>>> > > Here is a brief status of the implementation of Mobile Text
>>>> > > Input, along
>>>> > with some questions:
>>>> > >
>>>> > > Implementation overview:
>>>> > > The change is mainly on the class StyleableStageText, which now
>>>> > > takes the
>>>> > opposite approach than the previous one:
>>>> > > - display proxy image bitmap by default
>>>> > > - display StageText only when editing
>>>> > > StageTextInputSkin/StageTextAreaSkin has been modified to use
>>>> > > this class
>>>> > >
>>>> > > - to make it easier to change StageTextInputSkin internal
>>>> > StyleableStageText component, the variable textDisplay is now of
>>>> > type
>>>> IStyleableEditText
>>>> > >
>>>> > > Behavior changes:
>>>> > > - scrolling and overlapping of text is well managed , as it
>>>> > > always uses
>>>> > the bitmap proxy, which is a Flex component: all the text inputs
>>>> > are
>>>> scrolling
>>>> > > - text occluding while editing is not managed yet, which means
>>>> > > the
>>>> > edited text may overlap other UIs. (TO BE DONE)
>>>> > >
>>>> > > Testing:
>>>> > > - tested on iPad 2 and iPad 3: TI in scrolling forms, TI in
>>>callouts
>>>> > > - *NEEDS TO BE TESTED ON ANDROID*
>>>> > > - memory consumption tests yet to be done
>>>> > > - mustella test yet to be run
>>>> > >
>>>> > >
>>>> > > Questions:
>>>> > > - Can someone please test on Android ?
>>>> >
>>>> > I can help out with Android testing. Should I wait for the
>>>> > nightly or
>>>> are these fixes on a branch? Nightly would be preferable so as to
>>>> allow
>>>more people to test the fix.
>>>> >
>>>> > Thanks,
>>>> > Om
>>>> >
>>>> > > - I have chosen to directly replace StyleableStageText.
>>>> > > Maybe I can also leave the old StyleableStageText with a
>>>> > > different name,
>>>> > so that it can be used in case there is an issue with the new one ?
>>>> > or
>>>> the other way?
>>>> >
>>>> > It would be better to keep the old one around with the same name.
>>>> > Folks
>>>> might have subclassed it to build their own implementations.
>>>> >
>>>> > > Now that it is an interface, it's easy to subclass the
>>>> > StageTextInputSkin, and override createTextDisplay() to use
>>>> > another
>>>class.
>>>> > >
>>>> > >
>>>> > > Maurice
>>>> > >
>>
>
RE: Mobile TextInput swipe
Posted by Maurice Amsellem <ma...@systar.com>.
IMO, the whole concept of "focus" is much less central on mobile platform than it can be on desktop, mainly because there nothing such as Tab or arrow keys on a mobile.
The notable exceptions are:
- Text Input fields
- Windows / Popup on mobile (for the hard "back"/"menus" keys).
WDYT?
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com]
Envoyé : dimanche 24 novembre 2013 16:44
À : dev@flex.apache.org
Objet : Re: Mobile TextInput swipe
All this reminded me that I don't think there were any serious upgrades to FocusManager for mobile, and it is quite possible that there should be.
Maybe the whole framework in mobile-mode should ignore mouseDown and determine if the gesture is a tap or not before assigning focus.
In FlexJS with the plug-ins, it allows for a possibility of a touch-oriented FocusManager if one is needed.
-Alex
On 11/24/13 2:40 AM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>
>>BTW, I haven't tried any versions of your code, but I'm still
>>surprised that text selection works. I would think that trying to
>>swipe-select a word or placing the insertion cursor >at an exact spot
>>would also be problematic with the bitmap proxy in the way.
>
>You must put the focus on the text before doing any selection (that
>usual on mobile). So when you focus, the proxy is hidden and the
>StageText shown, that's why it works.
>
>>Let's step back a bit. Why is it too late to detect scrolling on
>>mousedown? The MX DataGrid tears down its item editors when scrolling
>>starts. Isn't that similar?
>The diifrence is that on Desktop, you scroll with the scroll bar,
>whereas on mobile, you scroll by "swiping" directly on the content.
>This causes issue for focusing text, but also for selecting an item in
>a list, etc...
>So there is a general mechanism that is implemented in
>TouchScrollingHelp
>(IIUC) that detects such behavior based on timers and movement
>thresholds and will trigger touchInteractionStart.
>
>As DarkStone says, touchInteractionStart is triggered after mousedown,
>so if the focus in bound to mouseDown, it's too late.
>
>>Does there really need to be more than one StageText instance in play?
>>When TI1 loses focus can TI2 use that same StageText instance?
>
>Actually, it does: ScrollingStageText uses an internal pool, that will
>reuse the same instance if it has the same properties (multiline, font
>size, etc).
>
>-----Message d'origine-----
>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 24 novembre
>2013 06:38 À : dev@flex.apache.org Objet : Re: Mobile TextInput swipe
>
>BTW, I haven't tried any versions of your code, but I'm still surprised
>that text selection works. I would think that trying to swipe-select a
>word or placing the insertion cursor at an exact spot would also be
>problematic with the bitmap proxy in the way.
>
>Let's step back a bit. Why is it too late to detect scrolling on
>mousedown? The MX DataGrid tears down its item editors when scrolling
>starts. Isn't that similar?
>
>Does there really need to be more than one StageText instance in play?
>When TI1 loses focus can TI2 use that same StageText instance?
>
>
>-Alex
>
>On 11/23/13 5:22 PM, "Maurice Amsellem" <ma...@systar.com>
>wrote:
>
>>Hi Team,
>>
>>I am currently working on the swipe issue with ScrollableStageText on
>>mobile and would like your advice / help
>>
>>The issue is the following: you cannot initiate a scroll/swipe by
>>touching inside a TextInput or TextArea.
>>
>>1) current situation:
>>
>>- in ScrollableStageText, the StageText is only shown when TI is in
>>focus, and is replaced by a proxy when out of focus.
>>- when scrolling, only the proxies are scrolled, so it works well.
>>
>>- when editing TI2 after TI1:
>> - TI1 receives focus out => TI1 stageText is hidden, proxy shown
>> - TI2 receives the focus on mouse down => TI2 stage text is focused
>> - stageText for TI2 is displayed (and proxy hidden)
>>
>>=> the problem, is that since focus is set on mousedown, it's too late
>>to detect scrolling, so I had to prevent it, by calling
>>event.preventDefautl() in touchInteractionStarting handler.
>>
>>2) proposed solution
>>To overcome that issue, I changed the focus to be set on MOUSE UP,
>>instead of mouse down, so that I can detection touch scroll, and
>>prevent editing.
>>
>>It works pretty well but has the following side effect :
>>When editing TI1 after TI2, the soft keyboard (which was visible),
>>lowers when pressing TI2, and raises back when releasing your finger.
>>
>>The reason for that is that is when pressing TI2:
>>- TI1 has received focus out, so its StageText it's not visible
>>anymore
>>- TI2 did not receive focus yet, so its stageText is not visible yet
>>=> no stageText, no SoftKeyboard.
>>TI2 stage text is assigned focus only when finger is released.
>>
>>3) proposed solution to the side effect:
>>Since the only way of having a soft keyboard visible is to have an
>>active StageText, and call assingFocus() on it, I added a dummy
>>static StageText to the stage, with no text and a viewport extent of 0,0.
>>This stageText is assigned focus between the time finger is pressed,
>>so
>>TI1 and TI2 stage texts are not visible, and the finger is released,
>>where TI2 stage text is displayed.
>>That way, the soft keyboard does not disappear.
>> ______________
>>
>>It works well, but I consider the dummy StageText as a HORRIBLE HACK.
>>So if someone has a better solution that also meets the requirements,
>>I will be happy to take it.
>>
>>Regards,
>>
>>Maurice
>>
>>-----Message d'origine-----
>>De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>Envoyé : vendredi 22 novembre 2013 11:37 À : dev@flex.apache.org Objet
>>: RE: Mobile TextInput Implementation status
>>
>>Hi,
>>I fixed the two issues that were reported in the JIRA ticket by Colins
>>Childs.
>>
>>fixed two issues reported above:
>>- two focused text inputs
>>- stage text floating above content.
>>
>>
>>Committed and pushed to develop branch
>>https://git-wip-us.apache.org/repos/asf?p=flex-sdk.git;a=commit;h=9e4b
>>f
>>21f
>>
>>Mobile Mustella test pass:
>>- mobile/components/TextInput
>>- mobile/compoents/TextArea
>>- mobile/Softkeyboard
>>
>>
>>-----Message d'origine-----
>>De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>Envoyé : mardi 19 novembre 2013 18:18
>>À : dev@flex.apache.org
>>Objet : RE: Mobile TextInput Implementation status
>>
>>Sure. You need mobilecomponents and mobiletheme
>>
>>-----Message d'origine-----
>>De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>OmPrakash Muppirala Envoyé : mardi 19 novembre 2013 18:14 À :
>>dev@flex.apache.org Objet : RE: Mobile TextInput Implementation status
>>
>>On Nov 19, 2013 9:05 AM, "Maurice Amsellem"
>><ma...@systar.com>
>>wrote:
>>>
>>> Since jenkins is down, do you need the updated swc ?
>>
>>Which project is it? I can just compile it and drop it in the sdk
>>directory.
>>
>>Thanks,
>>Om
>>
>>>
>>> -----Message d'origine-----
>>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>> OmPrakash
>>Muppirala
>>> Envoyé : mardi 19 novembre 2013 17:55 À : dev@flex.apache.org Objet :
>>> RE: Mobile TextInput Implementation status
>>>
>>> On Nov 19, 2013 4:53 AM, "Maurice Amsellem"
>>> <ma...@systar.com>
>>> wrote:
>>> >
>>> > Fixed a few other issues
>>> > (see https://issues.apache.org/jira/browse/FLEX-33166)
>>> > > FIXED : Soft keyboard partially closes/opens when moving the
>>> > > focus
>>> from one TI to another.
>>> > > to fix the issue above, had to trigger TI edition on mousedown
>>> > > instead
>>> of mouse click (like in StyleableStageText)
>>> > > fixed bug caused by the above.
>>> >
>>> > All related mustella test pass. ( mobile/TextInput,
>>> > mobile/TextArea,
>>> mobile/SoftKeyboard)
>>> >
>>> > Om, can you please make a last test run on Android, so I can close
>>> > the
>>> ticket.
>>> >
>>>
>>> Will do, later in the night for me.
>>>
>>> Thanks,
>>> Om
>>>
>>> > Maurice
>>> >
>>> > -----Message d'origine-----
>>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>> > Envoyé : mardi 19 novembre 2013 00:36 À : dev@flex.apache.org
>>> > Objet
>>> > : RE: Mobile TextInput Implementation status
>>> >
>>> > Just received results of Om testing on Android (Tested on Samsung
>>> > Galaxy
>>> SIII (Android 4.1.2) and Samsung Galaxy Tab 2 (Android 4.2.2)).
>>> > It's working fine.
>>> > Thanks you Om for the quick testing, that's really good news.
>>> >
>>> > Maurice
>>> > -----Message d'origine-----
>>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>> > Envoyé : lundi 18 novembre 2013 16:49 À : dev@flex.apache.org
>>> > Objet
>>> > : Mobile TextInput Implementation status
>>> >
>>> > Memory profiling of the new skins:
>>> >
>>> > It's as expected: alloc memory = pixel width x pixel height x
>>> > 4bytes
>>> per pixel.
>>> >
>>> > First figure is for iPad , second is for iPad retina.
>>> >
>>> > - 25KB / 100 KB of bitmap memory allocated for a single line TI
>>> > with
>>> default size
>>> > - ~500KB / ~ 2 MB for a pages stuffed with text inputs / text
>>> > Areas
>>> > - 3 MB / 12 MB for a full-page TA => in this case, it's better to
>>> > use the
>>> old skins.
>>> >
>>> > The bitmap is allocated while the TI is added to the stage, and
>>> > disposed
>>> when it's removed from the stage
>>> >
>>> > Maurice
>>> >
>>> > -----Message d'origine-----
>>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>> > Envoyé : lundi 18 novembre 2013 02:10 À : dev@flex.apache.org
>>> > Objet
>>> > : RE: Mobile TextInput Implementation status
>>> >
>>> >
>>> > 1) to help debug if something goes wrong on Android, you can set
>>> > the
>>> following mx_internal flag:
>>> > ScrollableStageText.debugProxyImage = true;
>>> >
>>> > It will display the proxy bitmaps in magenta background.
>>> >
>>> > 2) proxy methods in ScrollableStageText has been abstracted on
>>> > purpose to
>>> DisplayObject instead of Bitmap.
>>> > This is so that one could override the class to use another proxy
>>>(eg.
>>> StyleableTextField) which is less memory consuming than bitmaps.
>>> > In wich case, you will have to override:
>>> > createProxy
>>> > updateProxy
>>> > disposeProxy
>>> >
>>> > 3) StageTextSkinBase inner textDisplay creation method is
>>> > externalized so
>>> that it can be customized.
>>> >
>>> > Example for ScrollableStageTextInputSkin:
>>> > override protected function
>>createTextDisplay():IStyleableEditableText
>>> > {
>>> > return new ScrollableStageText(multiline);
>>> > }
>>> >
>>> > That way, you can derive from existing skins, instead of monkey
>>> > patching
>>> the default skin, if you only need to change the internal editable
>>> text
>>class.
>>> >
>>> > Note also that displayText is now of type IStyleableEditableText,
>>> > instead
>>> of StyleableStageText, for the same purpose.
>>> >
>>> > Regards,
>>> >
>>> > Maurice
>>> >
>>> > -----Message d'origine-----
>>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>> > Envoyé : lundi 18 novembre 2013 01:49 À : dev@flex.apache.org
>>> > Objet
>>> > : RE: Mobile TextInput Implementation status
>>> >
>>> > Run mustella tests:
>>> > Mobile/Components/TextInput
>>> > Mobile/components/TextArea
>>> > Mobile/StageText
>>> >
>>> > All pass.
>>> >
>>> > Maurice
>>> >
>>> > -----Message d'origine-----
>>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>> > Envoyé : lundi 18 novembre 2013 01:11 À : dev@flex.apache.org
>>> > Objet
>>> > : RE: Mobile TextInput Implementation status
>>> >
>>> > Hi, I have committed and pushed tentative fix for
>>> https://issues.apache.org/jira/browse/FLEX-33166
>>> >
>>> > Tested on iPad 2 / 3.
>>> > Not tested on Android.
>>> > I couldn't run mustella mobile tests. For some reason, they are
>>> > broken
>>> on my machine ( says: Passes: 0 / Fails: 0).
>>> >
>>> > The new skins are now the defaults for TextInput and TextArea on
>>>mobile:
>>> >
>>> > TextInput skinClass =
>>> > spark.skins.mobile.ScrollingStageTextInputSkin
>>> > TextArea skinClass = spark.skins.mobile.ScrollingStageTextAreaSkin
>>> >
>>> > The old skins are still there, under the same name.
>>> >
>>> > Please review and tests, and this is a sensitive change...
>>> >
>>> > Your comments and feedback are welcome.
>>> >
>>> > Maurice
>>> >
>>> > -----Message d'origine-----
>>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>> > Envoyé : lundi 18 novembre 2013 00:08 À : dev@flex.apache.org
>>> > Objet
>>> > : RE: Mobile TextInput Implementation status
>>> >
>>> > Founds some bugs, so I won't commit until they are fixed...
>>> >
>>> > Maurice
>>> >
>>> > -----Message d'origine-----
>>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>> > Envoyé : dimanche 17 novembre 2013 21:18 À : dev@flex.apache.org
>>>Objet :
>>> RE: Mobile TextInput Implementation status
>>> >
>>> > >I can help out with Android testing.
>>> > Thanks
>>> >
>>> > >Should I wait for the nightly or are these fixes on a branch?
>>> > >Nightly
>>> would be preferable so as to allow more people to test the fix.
>>> > I will push to the develop/ so that they be in the nightly
>>> >
>>> > >It would be better to keep the old one around with the same name.
>>> > >Folks
>>> might have subclassed it to build their own implementations.
>>> >
>>> > What about :
>>> > ScrollableStageText
>>> > ScrollableStageTextInputSkin
>>> >
>>> > For the new classes ?
>>> >
>>> > Maurice
>>> >
>>> > -----Message d'origine-----
>>> > De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>> > OmPrakash
>>> Muppirala Envoyé : dimanche 17 novembre 2013 20:27 À :
>>> dev@flex.apache.orgObjet : Re: Mobile TextInput Implementation
>>> status
>>> >
>>> > On Nov 17, 2013 10:56 AM, "Maurice Amsellem"
>>> > <ma...@systar.com>
>>> > wrote:
>>> > >
>>> > > Hi,
>>> > >
>>> > > Here is a brief status of the implementation of Mobile Text
>>> > > Input, along
>>> > with some questions:
>>> > >
>>> > > Implementation overview:
>>> > > The change is mainly on the class StyleableStageText, which now
>>> > > takes the
>>> > opposite approach than the previous one:
>>> > > - display proxy image bitmap by default
>>> > > - display StageText only when editing
>>> > > StageTextInputSkin/StageTextAreaSkin has been modified to use
>>> > > this class
>>> > >
>>> > > - to make it easier to change StageTextInputSkin internal
>>> > StyleableStageText component, the variable textDisplay is now of
>>> > type
>>> IStyleableEditText
>>> > >
>>> > > Behavior changes:
>>> > > - scrolling and overlapping of text is well managed , as it
>>> > > always uses
>>> > the bitmap proxy, which is a Flex component: all the text inputs
>>> > are
>>> scrolling
>>> > > - text occluding while editing is not managed yet, which means
>>> > > the
>>> > edited text may overlap other UIs. (TO BE DONE)
>>> > >
>>> > > Testing:
>>> > > - tested on iPad 2 and iPad 3: TI in scrolling forms, TI in
>>callouts
>>> > > - *NEEDS TO BE TESTED ON ANDROID*
>>> > > - memory consumption tests yet to be done
>>> > > - mustella test yet to be run
>>> > >
>>> > >
>>> > > Questions:
>>> > > - Can someone please test on Android ?
>>> >
>>> > I can help out with Android testing. Should I wait for the
>>> > nightly or
>>> are these fixes on a branch? Nightly would be preferable so as to
>>> allow
>>more people to test the fix.
>>> >
>>> > Thanks,
>>> > Om
>>> >
>>> > > - I have chosen to directly replace StyleableStageText.
>>> > > Maybe I can also leave the old StyleableStageText with a
>>> > > different name,
>>> > so that it can be used in case there is an issue with the new one ?
>>> > or
>>> the other way?
>>> >
>>> > It would be better to keep the old one around with the same name.
>>> > Folks
>>> might have subclassed it to build their own implementations.
>>> >
>>> > > Now that it is an interface, it's easy to subclass the
>>> > StageTextInputSkin, and override createTextDisplay() to use
>>> > another
>>class.
>>> > >
>>> > >
>>> > > Maurice
>>> > >
>
Re: Mobile TextInput swipe
Posted by DarkStone <Da...@163.com>.
Hi Maurice,
Okay, I see. You are doing the right thing, sorry for my misunderstanding before.
Good luck and have fun!
Sent from DarkStone's iPhone
> 在 2013年11月25日，5:15，Maurice Amsellem <ma...@systar.com> 写道：
>
> Hi,
>
>> so the ScrollableStageText itself won’t need a border skin.
>
> I don't get you.
> This is already the case: The border is defined is the ScrollableStageTextInputSkin.
>
>> We could write fxg code (like <s:Rect>) in TextInputSkin.mxml to design the border, which wraps the ScrollableStageText skin part around.
>
> Once again, this is also already the case.
> ScrollableStageTextInputSkin, wich derives from StageTextSkinBase and MobileSkin is merely a rewriting of TextInputSkin (which derives from SparkSkin) in optimized ActionScript.
> This was done mainly for performance reasons.
>
>> I agree most of your say, your thought is as good as mine : )
> Glad that you do ;-)
>
> Regards,
>
> Maurice
>
> -----Message d'origine-----
> De : 周 戈 [mailto:darkstone@163.com]
> Envoyé : dimanche 24 novembre 2013 21:54
> À : Apache
> Objet : Re: Mobile TextInput swipe
>
> Hi Maurice,
>
> I agree most of your say, your thought is as good as mine : )
>
> The only idea I want to clarify is:
>
> I think the key point is to use StageText to develop a RichEditableText alternative. In other words, the ScrollableStageText should ultimately works like a RichEditableText (of course it would be much less powerful than RichEditableText), so the ScrollableStageText itself won’t need a border skin. We could write fxg code (like <s:Rect>) in TextInputSkin.mxml to design the border, which wraps the ScrollableStageText skin part around.
>
> Good luck!
>
>
> DarkStone
> 2013-11-25
>
>
> 在 2013-11-25，04:05，Maurice Amsellem <ma...@systar.com> 写道：
>
>>> And why you develop ScrollingStageTextInput and ScrollingStageTextArea and their skins (ScrollingStageTextInputSkin and ScrollingStageTextAreaSkin)? I don’t think that’s >necessary.
>>
>> There is not ScrollingStageTextInput and ScrollingStageTextArea.
>>
>> The class involved are the following:
>> - spark TextInput and TextArea =>these are the regular TextInput and TextArea, that you use in mxml. No other other classes are needed.
>>
>> - ScrollingStageTextInputSkin / ScrollingStageTextAreaSkin => these are the specific Flex4 skins for mobile, which derive from MobileSkin.
>> => the skins are necessary for example to draw the round rect border, as StageText does not have one itself. But you could also design borderless skins if desired.
>>
>> - ScrollableStageText => the internal wrapper for StageText that is used by both skins above.
>>
>> And of course StageText, with is the low-level native AIR Text Input
>>
>> I don't see how you can use less classes than that without either breaking the spark architecture, breaking existing SDK classes, or duplicating code.
>>
>> -----------------------
>>
>> Side note:
>> I had to significantly modify core class to adapt them to the new mobile TI behavior (mainly for the focusing behavior).
>> - SkinnableTextBase (which is the parent of TextInput and TextArea)
>> - Adding new Interfaces ( IStylableEditableText and IProxiedStageTexTWrapper) so that TextInput and TextArea (which are in spark) can call methods of classes that exists in mobile components.swc.
>>
>> So you can't (and you shouldn't) implement the new behavior solely in the skin classes.
>>
>> _________________
>>
>>
>> Maurice
>>
>> -----Message d'origine-----
>> De : 周 戈 [mailto:darkstone@163.com]
>> Envoyé : dimanche 24 novembre 2013 18:43 À : Apache Objet : Re: Mobile
>> TextInput swipe
>>
>> Hi all,
>>
>>> Maybe the whole framework in mobile-mode should ignore mouseDown and
>>> determine if the gesture is a tap or not before assigning focus.
>> Please don’t do that, current framework’s FocusManager is doing fine, if Flex team makes any serious upgrades to it, it will impact a lot of things already done for mobile!
>>
>>> You don't need to show to StageText to make a bitmap of it, it works even when not visible.
>> Haven’t tried that yet, thanks for the tip, I’ll give it a shot.
>>
>>> This is also how ScrollableStageText works. It derives from UIComponent, and can be used as part in ScrollingStageTextInputSkin / ScrollingStageTextAreaSkin mxml skins.
>>> It's the textDisplay skin part.
>>
>> I highly recommend you extends SpriteVisualElement rather than UIComponent. UIComponent has a lot of stuff you probably will never use, and it’s a bit heavy for mobile text component.
>> The SpriteVisualElement class helps you implemented IVisualElement interface in a quite lighter way than UIComponent, and it supports mxml as well.
>>
>> And why you develop ScrollingStageTextInput and ScrollingStageTextArea and their skins (ScrollingStageTextInputSkin and ScrollingStageTextAreaSkin)? I don’t think that’s necessary.
>>
>> Just extends VisualElement and implements the IEditableText, it will work the way like a RichEditableText (but less powerful than RichEditableText), you can use it in Spark TextInputSkin / TextAreaSkin as a skin part.
>>
>> You don’t have to develop ScrollingStageTextInput and ScrollingStageTextArea and their skins, just use the Spark TextInput and TextArea, they are doing fine.
>>
>>
>> DarkStone
>> 2013-11-25
>>
>>
>>
>>> 在 2013-11-24，23:44，Alex Harui <ah...@adobe.com> 写道：
>>>
>>> All this reminded me that I don't think there were any serious
>>> upgrades to FocusManager for mobile, and it is quite possible that there should be.
>>> Maybe the whole framework in mobile-mode should ignore mouseDown and
>>> determine if the gesture is a tap or not before assigning focus.
>>>
>>> In FlexJS with the plug-ins, it allows for a possibility of a
>>> touch-oriented FocusManager if one is needed.
>>>
>>> -Alex
>>>
>>> On 11/24/13 2:40 AM, "Maurice Amsellem" <ma...@systar.com>
>>> wrote:
>>>
>>>>
>>>>> BTW, I haven't tried any versions of your code, but I'm still
>>>>> surprised that text selection works. I would think that trying to
>>>>> swipe-select a word or placing the insertion cursor >at an exact
>>>>> spot would also be problematic with the bitmap proxy in the way.
>>>>
>>>> You must put the focus on the text before doing any selection (that
>>>> usual on mobile). So when you focus, the proxy is hidden and the
>>>> StageText shown, that's why it works.
>>>>
>>>>> Let's step back a bit. Why is it too late to detect scrolling on
>>>>> mousedown? The MX DataGrid tears down its item editors when
>>>>> scrolling starts. Isn't that similar?
>>>> The diifrence is that on Desktop, you scroll with the scroll bar,
>>>> whereas on mobile, you scroll by "swiping" directly on the content.
>>>> This causes issue for focusing text, but also for selecting an item
>>>> in a list, etc...
>>>> So there is a general mechanism that is implemented in
>>>> TouchScrollingHelp
>>>> (IIUC) that detects such behavior based on timers and movement
>>>> thresholds and will trigger touchInteractionStart.
>>>>
>>>> As DarkStone says, touchInteractionStart is triggered after
>>>> mousedown, so if the focus in bound to mouseDown, it's too late.
>>>>
>>>>> Does there really need to be more than one StageText instance in play?
>>>>> When TI1 loses focus can TI2 use that same StageText instance?
>>>>
>>>> Actually, it does: ScrollingStageText uses an internal pool, that
>>>> will reuse the same instance if it has the same properties
>>>> (multiline, font size, etc).
>>>>
>>>> -----Message d'origine-----
>>>> De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 24
>>>> novembre 2013 06:38 À : dev@flex.apache.org Objet : Re: Mobile
>>>> TextInput swipe
>>>>
>>>> BTW, I haven't tried any versions of your code, but I'm still
>>>> surprised that text selection works. I would think that trying to
>>>> swipe-select a word or placing the insertion cursor at an exact spot
>>>> would also be problematic with the bitmap proxy in the way.
>>>>
>>>> Let's step back a bit. Why is it too late to detect scrolling on
>>>> mousedown? The MX DataGrid tears down its item editors when
>>>> scrolling starts. Isn't that similar?
>>>>
>>>> Does there really need to be more than one StageText instance in play?
>>>> When TI1 loses focus can TI2 use that same StageText instance?
>>>>
>>>>
>>>> -Alex
>>>>
>>>> On 11/23/13 5:22 PM, "Maurice Amsellem"
>>>> <ma...@systar.com>
>>>> wrote:
>>>>
>>>>> Hi Team,
>>>>>
>>>>> I am currently working on the swipe issue with ScrollableStageText
>>>>> on mobile and would like your advice / help
>>>>>
>>>>> The issue is the following: you cannot initiate a scroll/swipe by
>>>>> touching inside a TextInput or TextArea.
>>>>>
>>>>> 1) current situation:
>>>>>
>>>>> - in ScrollableStageText, the StageText is only shown when TI is in
>>>>> focus, and is replaced by a proxy when out of focus.
>>>>> - when scrolling, only the proxies are scrolled, so it works well.
>>>>>
>>>>> - when editing TI2 after TI1:
>>>>> - TI1 receives focus out => TI1 stageText is hidden, proxy shown
>>>>> - TI2 receives the focus on mouse down => TI2 stage text is
>>>>> focused
>>>>> - stageText for TI2 is displayed (and proxy hidden)
>>>>>
>>>>> => the problem, is that since focus is set on mousedown, it's too
>>>>> late to detect scrolling, so I had to prevent it, by calling
>>>>> event.preventDefautl() in touchInteractionStarting handler.
>>>>>
>>>>> 2) proposed solution
>>>>> To overcome that issue, I changed the focus to be set on MOUSE UP,
>>>>> instead of mouse down, so that I can detection touch scroll, and
>>>>> prevent editing.
>>>>>
>>>>> It works pretty well but has the following side effect :
>>>>> When editing TI1 after TI2, the soft keyboard (which was visible),
>>>>> lowers when pressing TI2, and raises back when releasing your finger.
>>>>>
>>>>> The reason for that is that is when pressing TI2:
>>>>> - TI1 has received focus out, so its StageText it's not visible
>>>>> anymore
>>>>> - TI2 did not receive focus yet, so its stageText is not visible
>>>>> yet => no stageText, no SoftKeyboard.
>>>>> TI2 stage text is assigned focus only when finger is released.
>>>>>
>>>>> 3) proposed solution to the side effect:
>>>>> Since the only way of having a soft keyboard visible is to have an
>>>>> active StageText, and call assingFocus() on it, I added a dummy
>>>>> static StageText to the stage, with no text and a viewport extent of 0,0.
>>>>> This stageText is assigned focus between the time finger is
>>>>> pressed, so
>>>>> TI1 and TI2 stage texts are not visible, and the finger is
>>>>> released, where TI2 stage text is displayed.
>>>>> That way, the soft keyboard does not disappear.
>>>>> ______________
>>>>>
>>>>> It works well, but I consider the dummy StageText as a HORRIBLE HACK.
>>>>> So if someone has a better solution that also meets the
>>>>> requirements, I will be happy to take it.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Maurice
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>> Envoyé : vendredi 22 novembre 2013 11:37 À : dev@flex.apache.org
>>>>> Objet
>>>>> : RE: Mobile TextInput Implementation status
>>>>>
>>>>> Hi,
>>>>> I fixed the two issues that were reported in the JIRA ticket by
>>>>> Colins Childs.
>>>>>
>>>>> fixed two issues reported above:
>>>>> - two focused text inputs
>>>>> - stage text floating above content.
>>>>>
>>>>>
>>>>> Committed and pushed to develop branch
>>>>> https://git-wip-us.apache.org/repos/asf?p=flex-sdk.git;a=commit;h=9
>>>>> e
>>>>> 4bf
>>>>> 21f
>>>>>
>>>>> Mobile Mustella test pass:
>>>>> - mobile/components/TextInput
>>>>> - mobile/compoents/TextArea
>>>>> - mobile/Softkeyboard
>>>>>
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>> Envoyé : mardi 19 novembre 2013 18:18 À : dev@flex.apache.org Objet
>>>>> : RE: Mobile TextInput Implementation status
>>>>>
>>>>> Sure. You need mobilecomponents and mobiletheme
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>>>> OmPrakash Muppirala Envoyé : mardi 19 novembre 2013 18:14 À :
>>>>> dev@flex.apache.org Objet : RE: Mobile TextInput Implementation
>>>>> status
>>>>>
>>>>> On Nov 19, 2013 9:05 AM, "Maurice Amsellem"
>>>>> <ma...@systar.com>
>>>>> wrote:
>>>>>>
>>>>>> Since jenkins is down, do you need the updated swc ?
>>>>>
>>>>> Which project is it? I can just compile it and drop it in the sdk
>>>>> directory.
>>>>>
>>>>> Thanks,
>>>>> Om
>>>>>
>>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>>>>> OmPrakash
>>>>> Muppirala
>>>>>> Envoyé : mardi 19 novembre 2013 17:55 À : dev@flex.apache.org Objet :
>>>>>> RE: Mobile TextInput Implementation status
>>>>>>
>>>>>> On Nov 19, 2013 4:53 AM, "Maurice Amsellem"
>>>>>> <ma...@systar.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Fixed a few other issues
>>>>>>> (see https://issues.apache.org/jira/browse/FLEX-33166)
>>>>>>>> FIXED : Soft keyboard partially closes/opens when moving the
>>>>>>>> focus
>>>>>> from one TI to another.
>>>>>>>> to fix the issue above, had to trigger TI edition on mousedown
>>>>>>>> instead
>>>>>> of mouse click (like in StyleableStageText)
>>>>>>>> fixed bug caused by the above.
>>>>>>>
>>>>>>> All related mustella test pass. ( mobile/TextInput,
>>>>>>> mobile/TextArea,
>>>>>> mobile/SoftKeyboard)
>>>>>>>
>>>>>>> Om, can you please make a last test run on Android, so I can
>>>>>>> close the
>>>>>> ticket.
>>>>>>
>>>>>> Will do, later in the night for me.
>>>>>>
>>>>>> Thanks,
>>>>>> Om
>>>>>>
>>>>>>> Maurice
>>>>>>>
>>>>>>> -----Message d'origine-----
>>>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>>>> Envoyé : mardi 19 novembre 2013 00:36 À : dev@flex.apache.org
>>>>>>> Objet
>>>>>>> : RE: Mobile TextInput Implementation status
>>>>>>>
>>>>>>> Just received results of Om testing on Android (Tested on Samsung
>>>>>>> Galaxy
>>>>>> SIII (Android 4.1.2) and Samsung Galaxy Tab 2 (Android 4.2.2)).
>>>>>>> It's working fine.
>>>>>>> Thanks you Om for the quick testing, that's really good news.
>>>>>>>
>>>>>>> Maurice
>>>>>>> -----Message d'origine-----
>>>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>>>> Envoyé : lundi 18 novembre 2013 16:49 À : dev@flex.apache.org
>>>>>>> Objet
>>>>>>> : Mobile TextInput Implementation status
>>>>>>>
>>>>>>> Memory profiling of the new skins:
>>>>>>>
>>>>>>> It's as expected: alloc memory = pixel width x pixel height x
>>>>>>> 4bytes
>>>>>> per pixel.
>>>>>>>
>>>>>>> First figure is for iPad , second is for iPad retina.
>>>>>>>
>>>>>>> - 25KB / 100 KB of bitmap memory allocated for a single line TI
>>>>>>> with
>>>>>> default size
>>>>>>> - ~500KB / ~ 2 MB for a pages stuffed with text inputs / text
>>>>>>> Areas
>>>>>>> - 3 MB / 12 MB for a full-page TA => in this case, it's better to
>>>>>>> use the
>>>>>> old skins.
>>>>>>>
>>>>>>> The bitmap is allocated while the TI is added to the stage, and
>>>>>>> disposed
>>>>>> when it's removed from the stage
>>>>>>>
>>>>>>> Maurice
>>>>>>>
>>>>>>> -----Message d'origine-----
>>>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>>>> Envoyé : lundi 18 novembre 2013 02:10 À : dev@flex.apache.org
>>>>>>> Objet
>>>>>>> : RE: Mobile TextInput Implementation status
>>>>>>>
>>>>>>>
>>>>>>> 1) to help debug if something goes wrong on Android, you can set
>>>>>>> the
>>>>>> following mx_internal flag:
>>>>>>> ScrollableStageText.debugProxyImage = true;
>>>>>>>
>>>>>>> It will display the proxy bitmaps in magenta background.
>>>>>>>
>>>>>>> 2) proxy methods in ScrollableStageText has been abstracted on
>>>>>>> purpose to
>>>>>> DisplayObject instead of Bitmap.
>>>>>>> This is so that one could override the class to use another
>>>>>>> proxy
>>>>>> (eg.
>>>>>> StyleableTextField) which is less memory consuming than bitmaps.
>>>>>>> In wich case, you will have to override:
>>>>>>> createProxy
>>>>>>> updateProxy
>>>>>>> disposeProxy
>>>>>>>
>>>>>>> 3) StageTextSkinBase inner textDisplay creation method is
>>>>>>> externalized so
>>>>>> that it can be customized.
>>>>>>>
>>>>>>> Example for ScrollableStageTextInputSkin:
>>>>>>> override protected function
>>>>> createTextDisplay():IStyleableEditableText
>>>>>>> {
>>>>>>> return new ScrollableStageText(multiline);
>>>>>>> }
>>>>>>>
>>>>>>> That way, you can derive from existing skins, instead of monkey
>>>>>>> patching
>>>>>> the default skin, if you only need to change the internal editable
>>>>>> text
>>>>> class.
>>>>>>>
>>>>>>> Note also that displayText is now of type IStyleableEditableText,
>>>>>>> instead
>>>>>> of StyleableStageText, for the same purpose.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Maurice
>>>>>>>
>>>>>>> -----Message d'origine-----
>>>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>>>> Envoyé : lundi 18 novembre 2013 01:49 À : dev@flex.apache.org
>>>>>>> Objet
>>>>>>> : RE: Mobile TextInput Implementation status
>>>>>>>
>>>>>>> Run mustella tests:
>>>>>>> Mobile/Components/TextInput
>>>>>>> Mobile/components/TextArea
>>>>>>> Mobile/StageText
>>>>>>>
>>>>>>> All pass.
>>>>>>>
>>>>>>> Maurice
>>>>>>>
>>>>>>> -----Message d'origine-----
>>>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>>>> Envoyé : lundi 18 novembre 2013 01:11 À : dev@flex.apache.org
>>>>>>> Objet
>>>>>>> : RE: Mobile TextInput Implementation status
>>>>>>>
>>>>>>> Hi, I have committed and pushed tentative fix for
>>>>>> https://issues.apache.org/jira/browse/FLEX-33166
>>>>>>>
>>>>>>> Tested on iPad 2 / 3.
>>>>>>> Not tested on Android.
>>>>>>> I couldn't run mustella mobile tests. For some reason, they are
>>>>>>> broken
>>>>>> on my machine ( says: Passes: 0 / Fails: 0).
>>>>>>>
>>>>>>> The new skins are now the defaults for TextInput and TextArea on
>>>>>> mobile:
>>>>>>>
>>>>>>> TextInput skinClass =
>>>>>>> spark.skins.mobile.ScrollingStageTextInputSkin
>>>>>>> TextArea skinClass =
>>>>>>> spark.skins.mobile.ScrollingStageTextAreaSkin
>>>>>>>
>>>>>>> The old skins are still there, under the same name.
>>>>>>>
>>>>>>> Please review and tests, and this is a sensitive change...
>>>>>>>
>>>>>>> Your comments and feedback are welcome.
>>>>>>>
>>>>>>> Maurice
>>>>>>>
>>>>>>> -----Message d'origine-----
>>>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>>>> Envoyé : lundi 18 novembre 2013 00:08 À : dev@flex.apache.org
>>>>>>> Objet
>>>>>>> : RE: Mobile TextInput Implementation status
>>>>>>>
>>>>>>> Founds some bugs, so I won't commit until they are fixed...
>>>>>>>
>>>>>>> Maurice
>>>>>>>
>>>>>>> -----Message d'origine-----
>>>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>>>> Envoyé : dimanche 17 novembre 2013 21:18 À : dev@flex.apache.org
>>>>>> Objet :
>>>>>> RE: Mobile TextInput Implementation status
>>>>>>>
>>>>>>>> I can help out with Android testing.
>>>>>>> Thanks
>>>>>>>
>>>>>>>> Should I wait for the nightly or are these fixes on a branch?
>>>>>>>> Nightly
>>>>>> would be preferable so as to allow more people to test the fix.
>>>>>>> I will push to the develop/ so that they be in the nightly
>>>>>>>
>>>>>>>> It would be better to keep the old one around with the same name.
>>>>>>>> Folks
>>>>>> might have subclassed it to build their own implementations.
>>>>>>>
>>>>>>> What about :
>>>>>>> ScrollableStageText
>>>>>>> ScrollableStageTextInputSkin
>>>>>>>
>>>>>>> For the new classes ?
>>>>>>>
>>>>>>> Maurice
>>>>>>>
>>>>>>> -----Message d'origine-----
>>>>>>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>>>>>> OmPrakash
>>>>>> Muppirala Envoyé : dimanche 17 novembre 2013 20:27 À :
>>>>>> dev@flex.apache.orgObjet : Re: Mobile TextInput Implementation
>>>>>> status
>>>>>>>
>>>>>>> On Nov 17, 2013 10:56 AM, "Maurice Amsellem"
>>>>>>> <ma...@systar.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Here is a brief status of the implementation of Mobile Text
>>>>>>>> Input, along
>>>>>>> with some questions:
>>>>>>>>
>>>>>>>> Implementation overview:
>>>>>>>> The change is mainly on the class StyleableStageText, which now
>>>>>>>> takes the
>>>>>>> opposite approach than the previous one:
>>>>>>>> - display proxy image bitmap by default
>>>>>>>> - display StageText only when editing
>>>>>>>> StageTextInputSkin/StageTextAreaSkin has been modified to use
>>>>>>>> this class
>>>>>>>>
>>>>>>>> - to make it easier to change StageTextInputSkin internal
>>>>>>> StyleableStageText component, the variable textDisplay is now of
>>>>>>> type
>>>>>> IStyleableEditText
>>>>>>>>
>>>>>>>> Behavior changes:
>>>>>>>> - scrolling and overlapping of text is well managed , as it
>>>>>>>> always uses
>>>>>>> the bitmap proxy, which is a Flex component: all the text inputs
>>>>>>> are
>>>>>> scrolling
>>>>>>>> - text occluding while editing is not managed yet, which means
>>>>>>>> the
>>>>>>> edited text may overlap other UIs. (TO BE DONE)
>>>>>>>>
>>>>>>>> Testing:
>>>>>>>> - tested on iPad 2 and iPad 3: TI in scrolling forms, TI in
>>>>> callouts
>>>>>>>> - *NEEDS TO BE TESTED ON ANDROID*
>>>>>>>> - memory consumption tests yet to be done
>>>>>>>> - mustella test yet to be run
>>>>>>>>
>>>>>>>>
>>>>>>>> Questions:
>>>>>>>> - Can someone please test on Android ?
>>>>>>>
>>>>>>> I can help out with Android testing. Should I wait for the
>>>>>>> nightly or
>>>>>> are these fixes on a branch? Nightly would be preferable so as
>>>>>> to allow
>>>>> more people to test the fix.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Om
>>>>>>>
>>>>>>>> - I have chosen to directly replace StyleableStageText.
>>>>>>>> Maybe I can also leave the old StyleableStageText with a
>>>>>>>> different name,
>>>>>>> so that it can be used in case there is an issue with the new one ?
>>>>>>> or
>>>>>> the other way?
>>>>>>>
>>>>>>> It would be better to keep the old one around with the same name.
>>>>>>> Folks
>>>>>> might have subclassed it to build their own implementations.
>>>>>>>
>>>>>>>> Now that it is an interface, it's easy to subclass the
>>>>>>> StageTextInputSkin, and override createTextDisplay() to use
>>>>>>> another
>>>>> class.
>>>>>>>>
>>>>>>>>
>>>>>>>> Maurice
>
>
RE: Mobile TextInput swipe
Posted by Maurice Amsellem <ma...@systar.com>.
Hi,
>so the ScrollableStageText itself won’t need a border skin.
I don't get you.
This is already the case: The border is defined is the ScrollableStageTextInputSkin.
>We could write fxg code (like <s:Rect>) in TextInputSkin.mxml to design the border, which wraps the ScrollableStageText skin part around.
Once again, this is also already the case.
ScrollableStageTextInputSkin, wich derives from StageTextSkinBase and MobileSkin is merely a rewriting of TextInputSkin (which derives from SparkSkin) in optimized ActionScript.
This was done mainly for performance reasons.
>I agree most of your say, your thought is as good as mine : )
Glad that you do ;-)
Regards,
Maurice
-----Message d'origine-----
De : 周 戈 [mailto:darkstone@163.com]
Envoyé : dimanche 24 novembre 2013 21:54
À : Apache
Objet : Re: Mobile TextInput swipe
Hi Maurice,
I agree most of your say, your thought is as good as mine : )
The only idea I want to clarify is:
I think the key point is to use StageText to develop a RichEditableText alternative. In other words, the ScrollableStageText should ultimately works like a RichEditableText (of course it would be much less powerful than RichEditableText), so the ScrollableStageText itself won’t need a border skin. We could write fxg code (like <s:Rect>) in TextInputSkin.mxml to design the border, which wraps the ScrollableStageText skin part around.
Good luck!
DarkStone
2013-11-25
在 2013-11-25，04:05，Maurice Amsellem <ma...@systar.com> 写道：
>> And why you develop ScrollingStageTextInput and ScrollingStageTextArea and their skins (ScrollingStageTextInputSkin and ScrollingStageTextAreaSkin)? I don’t think that’s >necessary.
>
> There is not ScrollingStageTextInput and ScrollingStageTextArea.
>
> The class involved are the following:
> - spark TextInput and TextArea =>these are the regular TextInput and TextArea, that you use in mxml. No other other classes are needed.
>
> - ScrollingStageTextInputSkin / ScrollingStageTextAreaSkin => these are the specific Flex4 skins for mobile, which derive from MobileSkin.
> => the skins are necessary for example to draw the round rect border, as StageText does not have one itself. But you could also design borderless skins if desired.
>
> - ScrollableStageText => the internal wrapper for StageText that is used by both skins above.
>
> And of course StageText, with is the low-level native AIR Text Input
>
> I don't see how you can use less classes than that without either breaking the spark architecture, breaking existing SDK classes, or duplicating code.
>
> -----------------------
>
> Side note:
> I had to significantly modify core class to adapt them to the new mobile TI behavior (mainly for the focusing behavior).
> - SkinnableTextBase (which is the parent of TextInput and TextArea)
> - Adding new Interfaces ( IStylableEditableText and IProxiedStageTexTWrapper) so that TextInput and TextArea (which are in spark) can call methods of classes that exists in mobile components.swc.
>
> So you can't (and you shouldn't) implement the new behavior solely in the skin classes.
>
> _________________
>
>
> Maurice
>
> -----Message d'origine-----
> De : 周 戈 [mailto:darkstone@163.com]
> Envoyé : dimanche 24 novembre 2013 18:43 À : Apache Objet : Re: Mobile
> TextInput swipe
>
> Hi all,
>
>> Maybe the whole framework in mobile-mode should ignore mouseDown and
>> determine if the gesture is a tap or not before assigning focus.
> Please don’t do that, current framework’s FocusManager is doing fine, if Flex team makes any serious upgrades to it, it will impact a lot of things already done for mobile!
>
>> You don't need to show to StageText to make a bitmap of it, it works even when not visible.
> Haven’t tried that yet, thanks for the tip, I’ll give it a shot.
>
>> This is also how ScrollableStageText works. It derives from UIComponent, and can be used as part in ScrollingStageTextInputSkin / ScrollingStageTextAreaSkin mxml skins.
>> It's the textDisplay skin part.
>
> I highly recommend you extends SpriteVisualElement rather than UIComponent. UIComponent has a lot of stuff you probably will never use, and it’s a bit heavy for mobile text component.
> The SpriteVisualElement class helps you implemented IVisualElement interface in a quite lighter way than UIComponent, and it supports mxml as well.
>
> And why you develop ScrollingStageTextInput and ScrollingStageTextArea and their skins (ScrollingStageTextInputSkin and ScrollingStageTextAreaSkin)? I don’t think that’s necessary.
>
> Just extends VisualElement and implements the IEditableText, it will work the way like a RichEditableText (but less powerful than RichEditableText), you can use it in Spark TextInputSkin / TextAreaSkin as a skin part.
>
> You don’t have to develop ScrollingStageTextInput and ScrollingStageTextArea and their skins, just use the Spark TextInput and TextArea, they are doing fine.
>
>
> DarkStone
> 2013-11-25
>
>
>
> 在 2013-11-24，23:44，Alex Harui <ah...@adobe.com> 写道：
>
>> All this reminded me that I don't think there were any serious
>> upgrades to FocusManager for mobile, and it is quite possible that there should be.
>> Maybe the whole framework in mobile-mode should ignore mouseDown and
>> determine if the gesture is a tap or not before assigning focus.
>>
>> In FlexJS with the plug-ins, it allows for a possibility of a
>> touch-oriented FocusManager if one is needed.
>>
>> -Alex
>>
>> On 11/24/13 2:40 AM, "Maurice Amsellem" <ma...@systar.com>
>> wrote:
>>
>>>
>>>> BTW, I haven't tried any versions of your code, but I'm still
>>>> surprised that text selection works. I would think that trying to
>>>> swipe-select a word or placing the insertion cursor >at an exact
>>>> spot would also be problematic with the bitmap proxy in the way.
>>>
>>> You must put the focus on the text before doing any selection (that
>>> usual on mobile). So when you focus, the proxy is hidden and the
>>> StageText shown, that's why it works.
>>>
>>>> Let's step back a bit. Why is it too late to detect scrolling on
>>>> mousedown? The MX DataGrid tears down its item editors when
>>>> scrolling starts. Isn't that similar?
>>> The diifrence is that on Desktop, you scroll with the scroll bar,
>>> whereas on mobile, you scroll by "swiping" directly on the content.
>>> This causes issue for focusing text, but also for selecting an item
>>> in a list, etc...
>>> So there is a general mechanism that is implemented in
>>> TouchScrollingHelp
>>> (IIUC) that detects such behavior based on timers and movement
>>> thresholds and will trigger touchInteractionStart.
>>>
>>> As DarkStone says, touchInteractionStart is triggered after
>>> mousedown, so if the focus in bound to mouseDown, it's too late.
>>>
>>>> Does there really need to be more than one StageText instance in play?
>>>> When TI1 loses focus can TI2 use that same StageText instance?
>>>
>>> Actually, it does: ScrollingStageText uses an internal pool, that
>>> will reuse the same instance if it has the same properties
>>> (multiline, font size, etc).
>>>
>>> -----Message d'origine-----
>>> De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 24
>>> novembre 2013 06:38 À : dev@flex.apache.org Objet : Re: Mobile
>>> TextInput swipe
>>>
>>> BTW, I haven't tried any versions of your code, but I'm still
>>> surprised that text selection works. I would think that trying to
>>> swipe-select a word or placing the insertion cursor at an exact spot
>>> would also be problematic with the bitmap proxy in the way.
>>>
>>> Let's step back a bit. Why is it too late to detect scrolling on
>>> mousedown? The MX DataGrid tears down its item editors when
>>> scrolling starts. Isn't that similar?
>>>
>>> Does there really need to be more than one StageText instance in play?
>>> When TI1 loses focus can TI2 use that same StageText instance?
>>>
>>>
>>> -Alex
>>>
>>> On 11/23/13 5:22 PM, "Maurice Amsellem"
>>> <ma...@systar.com>
>>> wrote:
>>>
>>>> Hi Team,
>>>>
>>>> I am currently working on the swipe issue with ScrollableStageText
>>>> on mobile and would like your advice / help
>>>>
>>>> The issue is the following: you cannot initiate a scroll/swipe by
>>>> touching inside a TextInput or TextArea.
>>>>
>>>> 1) current situation:
>>>>
>>>> - in ScrollableStageText, the StageText is only shown when TI is in
>>>> focus, and is replaced by a proxy when out of focus.
>>>> - when scrolling, only the proxies are scrolled, so it works well.
>>>>
>>>> - when editing TI2 after TI1:
>>>> - TI1 receives focus out => TI1 stageText is hidden, proxy shown
>>>> - TI2 receives the focus on mouse down => TI2 stage text is
>>>> focused
>>>> - stageText for TI2 is displayed (and proxy hidden)
>>>>
>>>> => the problem, is that since focus is set on mousedown, it's too
>>>> late to detect scrolling, so I had to prevent it, by calling
>>>> event.preventDefautl() in touchInteractionStarting handler.
>>>>
>>>> 2) proposed solution
>>>> To overcome that issue, I changed the focus to be set on MOUSE UP,
>>>> instead of mouse down, so that I can detection touch scroll, and
>>>> prevent editing.
>>>>
>>>> It works pretty well but has the following side effect :
>>>> When editing TI1 after TI2, the soft keyboard (which was visible),
>>>> lowers when pressing TI2, and raises back when releasing your finger.
>>>>
>>>> The reason for that is that is when pressing TI2:
>>>> - TI1 has received focus out, so its StageText it's not visible
>>>> anymore
>>>> - TI2 did not receive focus yet, so its stageText is not visible
>>>> yet => no stageText, no SoftKeyboard.
>>>> TI2 stage text is assigned focus only when finger is released.
>>>>
>>>> 3) proposed solution to the side effect:
>>>> Since the only way of having a soft keyboard visible is to have an
>>>> active StageText, and call assingFocus() on it, I added a dummy
>>>> static StageText to the stage, with no text and a viewport extent of 0,0.
>>>> This stageText is assigned focus between the time finger is
>>>> pressed, so
>>>> TI1 and TI2 stage texts are not visible, and the finger is
>>>> released, where TI2 stage text is displayed.
>>>> That way, the soft keyboard does not disappear.
>>>> ______________
>>>>
>>>> It works well, but I consider the dummy StageText as a HORRIBLE HACK.
>>>> So if someone has a better solution that also meets the
>>>> requirements, I will be happy to take it.
>>>>
>>>> Regards,
>>>>
>>>> Maurice
>>>>
>>>> -----Message d'origine-----
>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> Envoyé : vendredi 22 novembre 2013 11:37 À : dev@flex.apache.org
>>>> Objet
>>>> : RE: Mobile TextInput Implementation status
>>>>
>>>> Hi,
>>>> I fixed the two issues that were reported in the JIRA ticket by
>>>> Colins Childs.
>>>>
>>>> fixed two issues reported above:
>>>> - two focused text inputs
>>>> - stage text floating above content.
>>>>
>>>>
>>>> Committed and pushed to develop branch
>>>> https://git-wip-us.apache.org/repos/asf?p=flex-sdk.git;a=commit;h=9
>>>> e
>>>> 4bf
>>>> 21f
>>>>
>>>> Mobile Mustella test pass:
>>>> - mobile/components/TextInput
>>>> - mobile/compoents/TextArea
>>>> - mobile/Softkeyboard
>>>>
>>>>
>>>> -----Message d'origine-----
>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> Envoyé : mardi 19 novembre 2013 18:18 À : dev@flex.apache.org Objet
>>>> : RE: Mobile TextInput Implementation status
>>>>
>>>> Sure. You need mobilecomponents and mobiletheme
>>>>
>>>> -----Message d'origine-----
>>>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>>> OmPrakash Muppirala Envoyé : mardi 19 novembre 2013 18:14 À :
>>>> dev@flex.apache.org Objet : RE: Mobile TextInput Implementation
>>>> status
>>>>
>>>> On Nov 19, 2013 9:05 AM, "Maurice Amsellem"
>>>> <ma...@systar.com>
>>>> wrote:
>>>>>
>>>>> Since jenkins is down, do you need the updated swc ?
>>>>
>>>> Which project is it? I can just compile it and drop it in the sdk
>>>> directory.
>>>>
>>>> Thanks,
>>>> Om
>>>>
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>>>> OmPrakash
>>>> Muppirala
>>>>> Envoyé : mardi 19 novembre 2013 17:55 À : dev@flex.apache.org Objet :
>>>>> RE: Mobile TextInput Implementation status
>>>>>
>>>>> On Nov 19, 2013 4:53 AM, "Maurice Amsellem"
>>>>> <ma...@systar.com>
>>>>> wrote:
>>>>>>
>>>>>> Fixed a few other issues
>>>>>> (see https://issues.apache.org/jira/browse/FLEX-33166)
>>>>>>> FIXED : Soft keyboard partially closes/opens when moving the
>>>>>>> focus
>>>>> from one TI to another.
>>>>>>> to fix the issue above, had to trigger TI edition on mousedown
>>>>>>> instead
>>>>> of mouse click (like in StyleableStageText)
>>>>>>> fixed bug caused by the above.
>>>>>>
>>>>>> All related mustella test pass. ( mobile/TextInput,
>>>>>> mobile/TextArea,
>>>>> mobile/SoftKeyboard)
>>>>>>
>>>>>> Om, can you please make a last test run on Android, so I can
>>>>>> close the
>>>>> ticket.
>>>>>>
>>>>>
>>>>> Will do, later in the night for me.
>>>>>
>>>>> Thanks,
>>>>> Om
>>>>>
>>>>>> Maurice
>>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>>> Envoyé : mardi 19 novembre 2013 00:36 À : dev@flex.apache.org
>>>>>> Objet
>>>>>> : RE: Mobile TextInput Implementation status
>>>>>>
>>>>>> Just received results of Om testing on Android (Tested on Samsung
>>>>>> Galaxy
>>>>> SIII (Android 4.1.2) and Samsung Galaxy Tab 2 (Android 4.2.2)).
>>>>>> It's working fine.
>>>>>> Thanks you Om for the quick testing, that's really good news.
>>>>>>
>>>>>> Maurice
>>>>>> -----Message d'origine-----
>>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>>> Envoyé : lundi 18 novembre 2013 16:49 À : dev@flex.apache.org
>>>>>> Objet
>>>>>> : Mobile TextInput Implementation status
>>>>>>
>>>>>> Memory profiling of the new skins:
>>>>>>
>>>>>> It's as expected: alloc memory = pixel width x pixel height x
>>>>>> 4bytes
>>>>> per pixel.
>>>>>>
>>>>>> First figure is for iPad , second is for iPad retina.
>>>>>>
>>>>>> - 25KB / 100 KB of bitmap memory allocated for a single line TI
>>>>>> with
>>>>> default size
>>>>>> - ~500KB / ~ 2 MB for a pages stuffed with text inputs / text
>>>>>> Areas
>>>>>> - 3 MB / 12 MB for a full-page TA => in this case, it's better to
>>>>>> use the
>>>>> old skins.
>>>>>>
>>>>>> The bitmap is allocated while the TI is added to the stage, and
>>>>>> disposed
>>>>> when it's removed from the stage
>>>>>>
>>>>>> Maurice
>>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>>> Envoyé : lundi 18 novembre 2013 02:10 À : dev@flex.apache.org
>>>>>> Objet
>>>>>> : RE: Mobile TextInput Implementation status
>>>>>>
>>>>>>
>>>>>> 1) to help debug if something goes wrong on Android, you can set
>>>>>> the
>>>>> following mx_internal flag:
>>>>>> ScrollableStageText.debugProxyImage = true;
>>>>>>
>>>>>> It will display the proxy bitmaps in magenta background.
>>>>>>
>>>>>> 2) proxy methods in ScrollableStageText has been abstracted on
>>>>>> purpose to
>>>>> DisplayObject instead of Bitmap.
>>>>>> This is so that one could override the class to use another
>>>>>> proxy
>>>>> (eg.
>>>>> StyleableTextField) which is less memory consuming than bitmaps.
>>>>>> In wich case, you will have to override:
>>>>>> createProxy
>>>>>> updateProxy
>>>>>> disposeProxy
>>>>>>
>>>>>> 3) StageTextSkinBase inner textDisplay creation method is
>>>>>> externalized so
>>>>> that it can be customized.
>>>>>>
>>>>>> Example for ScrollableStageTextInputSkin:
>>>>>> override protected function
>>>> createTextDisplay():IStyleableEditableText
>>>>>> {
>>>>>> return new ScrollableStageText(multiline);
>>>>>> }
>>>>>>
>>>>>> That way, you can derive from existing skins, instead of monkey
>>>>>> patching
>>>>> the default skin, if you only need to change the internal editable
>>>>> text
>>>> class.
>>>>>>
>>>>>> Note also that displayText is now of type IStyleableEditableText,
>>>>>> instead
>>>>> of StyleableStageText, for the same purpose.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Maurice
>>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>>> Envoyé : lundi 18 novembre 2013 01:49 À : dev@flex.apache.org
>>>>>> Objet
>>>>>> : RE: Mobile TextInput Implementation status
>>>>>>
>>>>>> Run mustella tests:
>>>>>> Mobile/Components/TextInput
>>>>>> Mobile/components/TextArea
>>>>>> Mobile/StageText
>>>>>>
>>>>>> All pass.
>>>>>>
>>>>>> Maurice
>>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>>> Envoyé : lundi 18 novembre 2013 01:11 À : dev@flex.apache.org
>>>>>> Objet
>>>>>> : RE: Mobile TextInput Implementation status
>>>>>>
>>>>>> Hi, I have committed and pushed tentative fix for
>>>>> https://issues.apache.org/jira/browse/FLEX-33166
>>>>>>
>>>>>> Tested on iPad 2 / 3.
>>>>>> Not tested on Android.
>>>>>> I couldn't run mustella mobile tests. For some reason, they are
>>>>>> broken
>>>>> on my machine ( says: Passes: 0 / Fails: 0).
>>>>>>
>>>>>> The new skins are now the defaults for TextInput and TextArea on
>>>>> mobile:
>>>>>>
>>>>>> TextInput skinClass =
>>>>>> spark.skins.mobile.ScrollingStageTextInputSkin
>>>>>> TextArea skinClass =
>>>>>> spark.skins.mobile.ScrollingStageTextAreaSkin
>>>>>>
>>>>>> The old skins are still there, under the same name.
>>>>>>
>>>>>> Please review and tests, and this is a sensitive change...
>>>>>>
>>>>>> Your comments and feedback are welcome.
>>>>>>
>>>>>> Maurice
>>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>>> Envoyé : lundi 18 novembre 2013 00:08 À : dev@flex.apache.org
>>>>>> Objet
>>>>>> : RE: Mobile TextInput Implementation status
>>>>>>
>>>>>> Founds some bugs, so I won't commit until they are fixed...
>>>>>>
>>>>>> Maurice
>>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>>> Envoyé : dimanche 17 novembre 2013 21:18 À : dev@flex.apache.org
>>>>> Objet :
>>>>> RE: Mobile TextInput Implementation status
>>>>>>
>>>>>>> I can help out with Android testing.
>>>>>> Thanks
>>>>>>
>>>>>>> Should I wait for the nightly or are these fixes on a branch?
>>>>>>> Nightly
>>>>> would be preferable so as to allow more people to test the fix.
>>>>>> I will push to the develop/ so that they be in the nightly
>>>>>>
>>>>>>> It would be better to keep the old one around with the same name.
>>>>>>> Folks
>>>>> might have subclassed it to build their own implementations.
>>>>>>
>>>>>> What about :
>>>>>> ScrollableStageText
>>>>>> ScrollableStageTextInputSkin
>>>>>>
>>>>>> For the new classes ?
>>>>>>
>>>>>> Maurice
>>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>>>>> OmPrakash
>>>>> Muppirala Envoyé : dimanche 17 novembre 2013 20:27 À :
>>>>> dev@flex.apache.orgObjet : Re: Mobile TextInput Implementation
>>>>> status
>>>>>>
>>>>>> On Nov 17, 2013 10:56 AM, "Maurice Amsellem"
>>>>>> <ma...@systar.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Here is a brief status of the implementation of Mobile Text
>>>>>>> Input, along
>>>>>> with some questions:
>>>>>>>
>>>>>>> Implementation overview:
>>>>>>> The change is mainly on the class StyleableStageText, which now
>>>>>>> takes the
>>>>>> opposite approach than the previous one:
>>>>>>> - display proxy image bitmap by default
>>>>>>> - display StageText only when editing
>>>>>>> StageTextInputSkin/StageTextAreaSkin has been modified to use
>>>>>>> this class
>>>>>>>
>>>>>>> - to make it easier to change StageTextInputSkin internal
>>>>>> StyleableStageText component, the variable textDisplay is now of
>>>>>> type
>>>>> IStyleableEditText
>>>>>>>
>>>>>>> Behavior changes:
>>>>>>> - scrolling and overlapping of text is well managed , as it
>>>>>>> always uses
>>>>>> the bitmap proxy, which is a Flex component: all the text inputs
>>>>>> are
>>>>> scrolling
>>>>>>> - text occluding while editing is not managed yet, which means
>>>>>>> the
>>>>>> edited text may overlap other UIs. (TO BE DONE)
>>>>>>>
>>>>>>> Testing:
>>>>>>> - tested on iPad 2 and iPad 3: TI in scrolling forms, TI in
>>>> callouts
>>>>>>> - *NEEDS TO BE TESTED ON ANDROID*
>>>>>>> - memory consumption tests yet to be done
>>>>>>> - mustella test yet to be run
>>>>>>>
>>>>>>>
>>>>>>> Questions:
>>>>>>> - Can someone please test on Android ?
>>>>>>
>>>>>> I can help out with Android testing. Should I wait for the
>>>>>> nightly or
>>>>> are these fixes on a branch? Nightly would be preferable so as
>>>>> to allow
>>>> more people to test the fix.
>>>>>>
>>>>>> Thanks,
>>>>>> Om
>>>>>>
>>>>>>> - I have chosen to directly replace StyleableStageText.
>>>>>>> Maybe I can also leave the old StyleableStageText with a
>>>>>>> different name,
>>>>>> so that it can be used in case there is an issue with the new one ?
>>>>>> or
>>>>> the other way?
>>>>>>
>>>>>> It would be better to keep the old one around with the same name.
>>>>>> Folks
>>>>> might have subclassed it to build their own implementations.
>>>>>>
>>>>>>> Now that it is an interface, it's easy to subclass the
>>>>>> StageTextInputSkin, and override createTextDisplay() to use
>>>>>> another
>>>> class.
>>>>>>>
>>>>>>>
>>>>>>> Maurice
>>>>>>>
>>>
>>
>
>
Re: Mobile TextInput swipe
Posted by 周 戈 <da...@163.com>.
Hi Maurice,
I agree most of your say, your thought is as good as mine : )
The only idea I want to clarify is:
I think the key point is to use StageText to develop a RichEditableText alternative. In other words, the ScrollableStageText should ultimately works like a RichEditableText (of course it would be much less powerful than RichEditableText), so the ScrollableStageText itself won’t need a border skin. We could write fxg code (like <s:Rect>) in TextInputSkin.mxml to design the border, which wraps the ScrollableStageText skin part around.
Good luck!
DarkStone
2013-11-25
在 2013-11-25，04:05，Maurice Amsellem <ma...@systar.com> 写道：
>> And why you develop ScrollingStageTextInput and ScrollingStageTextArea and their skins (ScrollingStageTextInputSkin and ScrollingStageTextAreaSkin)? I don’t think that’s >necessary.
>
> There is not ScrollingStageTextInput and ScrollingStageTextArea.
>
> The class involved are the following:
> - spark TextInput and TextArea =>these are the regular TextInput and TextArea, that you use in mxml. No other other classes are needed.
>
> - ScrollingStageTextInputSkin / ScrollingStageTextAreaSkin => these are the specific Flex4 skins for mobile, which derive from MobileSkin.
> => the skins are necessary for example to draw the round rect border, as StageText does not have one itself. But you could also design borderless skins if desired.
>
> - ScrollableStageText => the internal wrapper for StageText that is used by both skins above.
>
> And of course StageText, with is the low-level native AIR Text Input
>
> I don't see how you can use less classes than that without either breaking the spark architecture, breaking existing SDK classes, or duplicating code.
>
> -----------------------
>
> Side note:
> I had to significantly modify core class to adapt them to the new mobile TI behavior (mainly for the focusing behavior).
> - SkinnableTextBase (which is the parent of TextInput and TextArea)
> - Adding new Interfaces ( IStylableEditableText and IProxiedStageTexTWrapper) so that TextInput and TextArea (which are in spark) can call methods of classes that exists in mobile components.swc.
>
> So you can't (and you shouldn't) implement the new behavior solely in the skin classes.
>
> _________________
>
>
> Maurice
>
> -----Message d'origine-----
> De : 周 戈 [mailto:darkstone@163.com]
> Envoyé : dimanche 24 novembre 2013 18:43
> À : Apache
> Objet : Re: Mobile TextInput swipe
>
> Hi all,
>
>> Maybe the whole framework in mobile-mode should ignore mouseDown and
>> determine if the gesture is a tap or not before assigning focus.
> Please don’t do that, current framework’s FocusManager is doing fine, if Flex team makes any serious upgrades to it, it will impact a lot of things already done for mobile!
>
>> You don't need to show to StageText to make a bitmap of it, it works even when not visible.
> Haven’t tried that yet, thanks for the tip, I’ll give it a shot.
>
>> This is also how ScrollableStageText works. It derives from UIComponent, and can be used as part in ScrollingStageTextInputSkin / ScrollingStageTextAreaSkin mxml skins.
>> It's the textDisplay skin part.
>
> I highly recommend you extends SpriteVisualElement rather than UIComponent. UIComponent has a lot of stuff you probably will never use, and it’s a bit heavy for mobile text component.
> The SpriteVisualElement class helps you implemented IVisualElement interface in a quite lighter way than UIComponent, and it supports mxml as well.
>
> And why you develop ScrollingStageTextInput and ScrollingStageTextArea and their skins (ScrollingStageTextInputSkin and ScrollingStageTextAreaSkin)? I don’t think that’s necessary.
>
> Just extends VisualElement and implements the IEditableText, it will work the way like a RichEditableText (but less powerful than RichEditableText), you can use it in Spark TextInputSkin / TextAreaSkin as a skin part.
>
> You don’t have to develop ScrollingStageTextInput and ScrollingStageTextArea and their skins, just use the Spark TextInput and TextArea, they are doing fine.
>
>
> DarkStone
> 2013-11-25
>
>
>
> 在 2013-11-24，23:44，Alex Harui <ah...@adobe.com> 写道：
>
>> All this reminded me that I don't think there were any serious
>> upgrades to FocusManager for mobile, and it is quite possible that there should be.
>> Maybe the whole framework in mobile-mode should ignore mouseDown and
>> determine if the gesture is a tap or not before assigning focus.
>>
>> In FlexJS with the plug-ins, it allows for a possibility of a
>> touch-oriented FocusManager if one is needed.
>>
>> -Alex
>>
>> On 11/24/13 2:40 AM, "Maurice Amsellem" <ma...@systar.com>
>> wrote:
>>
>>>
>>>> BTW, I haven't tried any versions of your code, but I'm still
>>>> surprised that text selection works. I would think that trying to
>>>> swipe-select a word or placing the insertion cursor >at an exact
>>>> spot would also be problematic with the bitmap proxy in the way.
>>>
>>> You must put the focus on the text before doing any selection (that
>>> usual on mobile). So when you focus, the proxy is hidden and the
>>> StageText shown, that's why it works.
>>>
>>>> Let's step back a bit. Why is it too late to detect scrolling on
>>>> mousedown? The MX DataGrid tears down its item editors when
>>>> scrolling starts. Isn't that similar?
>>> The diifrence is that on Desktop, you scroll with the scroll bar,
>>> whereas on mobile, you scroll by "swiping" directly on the content.
>>> This causes issue for focusing text, but also for selecting an item
>>> in a list, etc...
>>> So there is a general mechanism that is implemented in
>>> TouchScrollingHelp
>>> (IIUC) that detects such behavior based on timers and movement
>>> thresholds and will trigger touchInteractionStart.
>>>
>>> As DarkStone says, touchInteractionStart is triggered after
>>> mousedown, so if the focus in bound to mouseDown, it's too late.
>>>
>>>> Does there really need to be more than one StageText instance in play?
>>>> When TI1 loses focus can TI2 use that same StageText instance?
>>>
>>> Actually, it does: ScrollingStageText uses an internal pool, that
>>> will reuse the same instance if it has the same properties
>>> (multiline, font size, etc).
>>>
>>> -----Message d'origine-----
>>> De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 24
>>> novembre 2013 06:38 À : dev@flex.apache.org Objet : Re: Mobile
>>> TextInput swipe
>>>
>>> BTW, I haven't tried any versions of your code, but I'm still
>>> surprised that text selection works. I would think that trying to
>>> swipe-select a word or placing the insertion cursor at an exact spot
>>> would also be problematic with the bitmap proxy in the way.
>>>
>>> Let's step back a bit. Why is it too late to detect scrolling on
>>> mousedown? The MX DataGrid tears down its item editors when
>>> scrolling starts. Isn't that similar?
>>>
>>> Does there really need to be more than one StageText instance in play?
>>> When TI1 loses focus can TI2 use that same StageText instance?
>>>
>>>
>>> -Alex
>>>
>>> On 11/23/13 5:22 PM, "Maurice Amsellem" <ma...@systar.com>
>>> wrote:
>>>
>>>> Hi Team,
>>>>
>>>> I am currently working on the swipe issue with ScrollableStageText
>>>> on mobile and would like your advice / help
>>>>
>>>> The issue is the following: you cannot initiate a scroll/swipe by
>>>> touching inside a TextInput or TextArea.
>>>>
>>>> 1) current situation:
>>>>
>>>> - in ScrollableStageText, the StageText is only shown when TI is in
>>>> focus, and is replaced by a proxy when out of focus.
>>>> - when scrolling, only the proxies are scrolled, so it works well.
>>>>
>>>> - when editing TI2 after TI1:
>>>> - TI1 receives focus out => TI1 stageText is hidden, proxy shown
>>>> - TI2 receives the focus on mouse down => TI2 stage text is focused
>>>> - stageText for TI2 is displayed (and proxy hidden)
>>>>
>>>> => the problem, is that since focus is set on mousedown, it's too
>>>> late to detect scrolling, so I had to prevent it, by calling
>>>> event.preventDefautl() in touchInteractionStarting handler.
>>>>
>>>> 2) proposed solution
>>>> To overcome that issue, I changed the focus to be set on MOUSE UP,
>>>> instead of mouse down, so that I can detection touch scroll, and
>>>> prevent editing.
>>>>
>>>> It works pretty well but has the following side effect :
>>>> When editing TI1 after TI2, the soft keyboard (which was visible),
>>>> lowers when pressing TI2, and raises back when releasing your finger.
>>>>
>>>> The reason for that is that is when pressing TI2:
>>>> - TI1 has received focus out, so its StageText it's not visible
>>>> anymore
>>>> - TI2 did not receive focus yet, so its stageText is not visible yet
>>>> => no stageText, no SoftKeyboard.
>>>> TI2 stage text is assigned focus only when finger is released.
>>>>
>>>> 3) proposed solution to the side effect:
>>>> Since the only way of having a soft keyboard visible is to have an
>>>> active StageText, and call assingFocus() on it, I added a dummy
>>>> static StageText to the stage, with no text and a viewport extent of 0,0.
>>>> This stageText is assigned focus between the time finger is pressed,
>>>> so
>>>> TI1 and TI2 stage texts are not visible, and the finger is released,
>>>> where TI2 stage text is displayed.
>>>> That way, the soft keyboard does not disappear.
>>>> ______________
>>>>
>>>> It works well, but I consider the dummy StageText as a HORRIBLE HACK.
>>>> So if someone has a better solution that also meets the
>>>> requirements, I will be happy to take it.
>>>>
>>>> Regards,
>>>>
>>>> Maurice
>>>>
>>>> -----Message d'origine-----
>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> Envoyé : vendredi 22 novembre 2013 11:37 À : dev@flex.apache.org
>>>> Objet
>>>> : RE: Mobile TextInput Implementation status
>>>>
>>>> Hi,
>>>> I fixed the two issues that were reported in the JIRA ticket by
>>>> Colins Childs.
>>>>
>>>> fixed two issues reported above:
>>>> - two focused text inputs
>>>> - stage text floating above content.
>>>>
>>>>
>>>> Committed and pushed to develop branch
>>>> https://git-wip-us.apache.org/repos/asf?p=flex-sdk.git;a=commit;h=9e
>>>> 4bf
>>>> 21f
>>>>
>>>> Mobile Mustella test pass:
>>>> - mobile/components/TextInput
>>>> - mobile/compoents/TextArea
>>>> - mobile/Softkeyboard
>>>>
>>>>
>>>> -----Message d'origine-----
>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> Envoyé : mardi 19 novembre 2013 18:18 À : dev@flex.apache.org Objet
>>>> : RE: Mobile TextInput Implementation status
>>>>
>>>> Sure. You need mobilecomponents and mobiletheme
>>>>
>>>> -----Message d'origine-----
>>>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>>> OmPrakash Muppirala Envoyé : mardi 19 novembre 2013 18:14 À :
>>>> dev@flex.apache.org Objet : RE: Mobile TextInput Implementation
>>>> status
>>>>
>>>> On Nov 19, 2013 9:05 AM, "Maurice Amsellem"
>>>> <ma...@systar.com>
>>>> wrote:
>>>>>
>>>>> Since jenkins is down, do you need the updated swc ?
>>>>
>>>> Which project is it? I can just compile it and drop it in the sdk
>>>> directory.
>>>>
>>>> Thanks,
>>>> Om
>>>>
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>>>> OmPrakash
>>>> Muppirala
>>>>> Envoyé : mardi 19 novembre 2013 17:55 À : dev@flex.apache.org Objet :
>>>>> RE: Mobile TextInput Implementation status
>>>>>
>>>>> On Nov 19, 2013 4:53 AM, "Maurice Amsellem"
>>>>> <ma...@systar.com>
>>>>> wrote:
>>>>>>
>>>>>> Fixed a few other issues
>>>>>> (see https://issues.apache.org/jira/browse/FLEX-33166)
>>>>>>> FIXED : Soft keyboard partially closes/opens when moving the
>>>>>>> focus
>>>>> from one TI to another.
>>>>>>> to fix the issue above, had to trigger TI edition on mousedown
>>>>>>> instead
>>>>> of mouse click (like in StyleableStageText)
>>>>>>> fixed bug caused by the above.
>>>>>>
>>>>>> All related mustella test pass. ( mobile/TextInput,
>>>>>> mobile/TextArea,
>>>>> mobile/SoftKeyboard)
>>>>>>
>>>>>> Om, can you please make a last test run on Android, so I can close
>>>>>> the
>>>>> ticket.
>>>>>>
>>>>>
>>>>> Will do, later in the night for me.
>>>>>
>>>>> Thanks,
>>>>> Om
>>>>>
>>>>>> Maurice
>>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>>> Envoyé : mardi 19 novembre 2013 00:36 À : dev@flex.apache.org
>>>>>> Objet
>>>>>> : RE: Mobile TextInput Implementation status
>>>>>>
>>>>>> Just received results of Om testing on Android (Tested on Samsung
>>>>>> Galaxy
>>>>> SIII (Android 4.1.2) and Samsung Galaxy Tab 2 (Android 4.2.2)).
>>>>>> It's working fine.
>>>>>> Thanks you Om for the quick testing, that's really good news.
>>>>>>
>>>>>> Maurice
>>>>>> -----Message d'origine-----
>>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>>> Envoyé : lundi 18 novembre 2013 16:49 À : dev@flex.apache.org
>>>>>> Objet
>>>>>> : Mobile TextInput Implementation status
>>>>>>
>>>>>> Memory profiling of the new skins:
>>>>>>
>>>>>> It's as expected: alloc memory = pixel width x pixel height x
>>>>>> 4bytes
>>>>> per pixel.
>>>>>>
>>>>>> First figure is for iPad , second is for iPad retina.
>>>>>>
>>>>>> - 25KB / 100 KB of bitmap memory allocated for a single line TI
>>>>>> with
>>>>> default size
>>>>>> - ~500KB / ~ 2 MB for a pages stuffed with text inputs / text
>>>>>> Areas
>>>>>> - 3 MB / 12 MB for a full-page TA => in this case, it's better to
>>>>>> use the
>>>>> old skins.
>>>>>>
>>>>>> The bitmap is allocated while the TI is added to the stage, and
>>>>>> disposed
>>>>> when it's removed from the stage
>>>>>>
>>>>>> Maurice
>>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>>> Envoyé : lundi 18 novembre 2013 02:10 À : dev@flex.apache.org
>>>>>> Objet
>>>>>> : RE: Mobile TextInput Implementation status
>>>>>>
>>>>>>
>>>>>> 1) to help debug if something goes wrong on Android, you can set
>>>>>> the
>>>>> following mx_internal flag:
>>>>>> ScrollableStageText.debugProxyImage = true;
>>>>>>
>>>>>> It will display the proxy bitmaps in magenta background.
>>>>>>
>>>>>> 2) proxy methods in ScrollableStageText has been abstracted on
>>>>>> purpose to
>>>>> DisplayObject instead of Bitmap.
>>>>>> This is so that one could override the class to use another proxy
>>>>> (eg.
>>>>> StyleableTextField) which is less memory consuming than bitmaps.
>>>>>> In wich case, you will have to override:
>>>>>> createProxy
>>>>>> updateProxy
>>>>>> disposeProxy
>>>>>>
>>>>>> 3) StageTextSkinBase inner textDisplay creation method is
>>>>>> externalized so
>>>>> that it can be customized.
>>>>>>
>>>>>> Example for ScrollableStageTextInputSkin:
>>>>>> override protected function
>>>> createTextDisplay():IStyleableEditableText
>>>>>> {
>>>>>> return new ScrollableStageText(multiline);
>>>>>> }
>>>>>>
>>>>>> That way, you can derive from existing skins, instead of monkey
>>>>>> patching
>>>>> the default skin, if you only need to change the internal editable
>>>>> text
>>>> class.
>>>>>>
>>>>>> Note also that displayText is now of type IStyleableEditableText,
>>>>>> instead
>>>>> of StyleableStageText, for the same purpose.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Maurice
>>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>>> Envoyé : lundi 18 novembre 2013 01:49 À : dev@flex.apache.org
>>>>>> Objet
>>>>>> : RE: Mobile TextInput Implementation status
>>>>>>
>>>>>> Run mustella tests:
>>>>>> Mobile/Components/TextInput
>>>>>> Mobile/components/TextArea
>>>>>> Mobile/StageText
>>>>>>
>>>>>> All pass.
>>>>>>
>>>>>> Maurice
>>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>>> Envoyé : lundi 18 novembre 2013 01:11 À : dev@flex.apache.org
>>>>>> Objet
>>>>>> : RE: Mobile TextInput Implementation status
>>>>>>
>>>>>> Hi, I have committed and pushed tentative fix for
>>>>> https://issues.apache.org/jira/browse/FLEX-33166
>>>>>>
>>>>>> Tested on iPad 2 / 3.
>>>>>> Not tested on Android.
>>>>>> I couldn't run mustella mobile tests. For some reason, they are
>>>>>> broken
>>>>> on my machine ( says: Passes: 0 / Fails: 0).
>>>>>>
>>>>>> The new skins are now the defaults for TextInput and TextArea on
>>>>> mobile:
>>>>>>
>>>>>> TextInput skinClass =
>>>>>> spark.skins.mobile.ScrollingStageTextInputSkin
>>>>>> TextArea skinClass = spark.skins.mobile.ScrollingStageTextAreaSkin
>>>>>>
>>>>>> The old skins are still there, under the same name.
>>>>>>
>>>>>> Please review and tests, and this is a sensitive change...
>>>>>>
>>>>>> Your comments and feedback are welcome.
>>>>>>
>>>>>> Maurice
>>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>>> Envoyé : lundi 18 novembre 2013 00:08 À : dev@flex.apache.org
>>>>>> Objet
>>>>>> : RE: Mobile TextInput Implementation status
>>>>>>
>>>>>> Founds some bugs, so I won't commit until they are fixed...
>>>>>>
>>>>>> Maurice
>>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>>> Envoyé : dimanche 17 novembre 2013 21:18 À : dev@flex.apache.org
>>>>> Objet :
>>>>> RE: Mobile TextInput Implementation status
>>>>>>
>>>>>>> I can help out with Android testing.
>>>>>> Thanks
>>>>>>
>>>>>>> Should I wait for the nightly or are these fixes on a branch?
>>>>>>> Nightly
>>>>> would be preferable so as to allow more people to test the fix.
>>>>>> I will push to the develop/ so that they be in the nightly
>>>>>>
>>>>>>> It would be better to keep the old one around with the same name.
>>>>>>> Folks
>>>>> might have subclassed it to build their own implementations.
>>>>>>
>>>>>> What about :
>>>>>> ScrollableStageText
>>>>>> ScrollableStageTextInputSkin
>>>>>>
>>>>>> For the new classes ?
>>>>>>
>>>>>> Maurice
>>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>>>>> OmPrakash
>>>>> Muppirala Envoyé : dimanche 17 novembre 2013 20:27 À :
>>>>> dev@flex.apache.orgObjet : Re: Mobile TextInput Implementation
>>>>> status
>>>>>>
>>>>>> On Nov 17, 2013 10:56 AM, "Maurice Amsellem"
>>>>>> <ma...@systar.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Here is a brief status of the implementation of Mobile Text
>>>>>>> Input, along
>>>>>> with some questions:
>>>>>>>
>>>>>>> Implementation overview:
>>>>>>> The change is mainly on the class StyleableStageText, which now
>>>>>>> takes the
>>>>>> opposite approach than the previous one:
>>>>>>> - display proxy image bitmap by default
>>>>>>> - display StageText only when editing
>>>>>>> StageTextInputSkin/StageTextAreaSkin has been modified to use
>>>>>>> this class
>>>>>>>
>>>>>>> - to make it easier to change StageTextInputSkin internal
>>>>>> StyleableStageText component, the variable textDisplay is now of
>>>>>> type
>>>>> IStyleableEditText
>>>>>>>
>>>>>>> Behavior changes:
>>>>>>> - scrolling and overlapping of text is well managed , as it
>>>>>>> always uses
>>>>>> the bitmap proxy, which is a Flex component: all the text inputs
>>>>>> are
>>>>> scrolling
>>>>>>> - text occluding while editing is not managed yet, which means
>>>>>>> the
>>>>>> edited text may overlap other UIs. (TO BE DONE)
>>>>>>>
>>>>>>> Testing:
>>>>>>> - tested on iPad 2 and iPad 3: TI in scrolling forms, TI in
>>>> callouts
>>>>>>> - *NEEDS TO BE TESTED ON ANDROID*
>>>>>>> - memory consumption tests yet to be done
>>>>>>> - mustella test yet to be run
>>>>>>>
>>>>>>>
>>>>>>> Questions:
>>>>>>> - Can someone please test on Android ?
>>>>>>
>>>>>> I can help out with Android testing. Should I wait for the
>>>>>> nightly or
>>>>> are these fixes on a branch? Nightly would be preferable so as to
>>>>> allow
>>>> more people to test the fix.
>>>>>>
>>>>>> Thanks,
>>>>>> Om
>>>>>>
>>>>>>> - I have chosen to directly replace StyleableStageText.
>>>>>>> Maybe I can also leave the old StyleableStageText with a
>>>>>>> different name,
>>>>>> so that it can be used in case there is an issue with the new one ?
>>>>>> or
>>>>> the other way?
>>>>>>
>>>>>> It would be better to keep the old one around with the same name.
>>>>>> Folks
>>>>> might have subclassed it to build their own implementations.
>>>>>>
>>>>>>> Now that it is an interface, it's easy to subclass the
>>>>>> StageTextInputSkin, and override createTextDisplay() to use
>>>>>> another
>>>> class.
>>>>>>>
>>>>>>>
>>>>>>> Maurice
>>>>>>>
>>>
>>
>
>
RE: Mobile TextInput swipe
Posted by Maurice Amsellem <ma...@systar.com>.
>And why you develop ScrollingStageTextInput and ScrollingStageTextArea and their skins (ScrollingStageTextInputSkin and ScrollingStageTextAreaSkin)? I don’t think that’s >necessary.
There is not ScrollingStageTextInput and ScrollingStageTextArea.
The class involved are the following:
- spark TextInput and TextArea =>these are the regular TextInput and TextArea, that you use in mxml. No other other classes are needed.
- ScrollingStageTextInputSkin / ScrollingStageTextAreaSkin => these are the specific Flex4 skins for mobile, which derive from MobileSkin.
=> the skins are necessary for example to draw the round rect border, as StageText does not have one itself. But you could also design borderless skins if desired.
- ScrollableStageText => the internal wrapper for StageText that is used by both skins above.
And of course StageText, with is the low-level native AIR Text Input
I don't see how you can use less classes than that without either breaking the spark architecture, breaking existing SDK classes, or duplicating code.
-----------------------
Side note:
I had to significantly modify core class to adapt them to the new mobile TI behavior (mainly for the focusing behavior).
- SkinnableTextBase (which is the parent of TextInput and TextArea)
- Adding new Interfaces ( IStylableEditableText and IProxiedStageTexTWrapper) so that TextInput and TextArea (which are in spark) can call methods of classes that exists in mobile components.swc.
So you can't (and you shouldn't) implement the new behavior solely in the skin classes.
_________________
Maurice
-----Message d'origine-----
De : 周 戈 [mailto:darkstone@163.com]
Envoyé : dimanche 24 novembre 2013 18:43
À : Apache
Objet : Re: Mobile TextInput swipe
Hi all,
> Maybe the whole framework in mobile-mode should ignore mouseDown and
> determine if the gesture is a tap or not before assigning focus.
Please don’t do that, current framework’s FocusManager is doing fine, if Flex team makes any serious upgrades to it, it will impact a lot of things already done for mobile!
> You don't need to show to StageText to make a bitmap of it, it works even when not visible.
Haven’t tried that yet, thanks for the tip, I’ll give it a shot.
> This is also how ScrollableStageText works. It derives from UIComponent, and can be used as part in ScrollingStageTextInputSkin / ScrollingStageTextAreaSkin mxml skins.
> It's the textDisplay skin part.
I highly recommend you extends SpriteVisualElement rather than UIComponent. UIComponent has a lot of stuff you probably will never use, and it’s a bit heavy for mobile text component.
The SpriteVisualElement class helps you implemented IVisualElement interface in a quite lighter way than UIComponent, and it supports mxml as well.
And why you develop ScrollingStageTextInput and ScrollingStageTextArea and their skins (ScrollingStageTextInputSkin and ScrollingStageTextAreaSkin)? I don’t think that’s necessary.
Just extends VisualElement and implements the IEditableText, it will work the way like a RichEditableText (but less powerful than RichEditableText), you can use it in Spark TextInputSkin / TextAreaSkin as a skin part.
You don’t have to develop ScrollingStageTextInput and ScrollingStageTextArea and their skins, just use the Spark TextInput and TextArea, they are doing fine.
DarkStone
2013-11-25
在 2013-11-24，23:44，Alex Harui <ah...@adobe.com> 写道：
> All this reminded me that I don't think there were any serious
> upgrades to FocusManager for mobile, and it is quite possible that there should be.
> Maybe the whole framework in mobile-mode should ignore mouseDown and
> determine if the gesture is a tap or not before assigning focus.
>
> In FlexJS with the plug-ins, it allows for a possibility of a
> touch-oriented FocusManager if one is needed.
>
> -Alex
>
> On 11/24/13 2:40 AM, "Maurice Amsellem" <ma...@systar.com>
> wrote:
>
>>
>>> BTW, I haven't tried any versions of your code, but I'm still
>>> surprised that text selection works. I would think that trying to
>>> swipe-select a word or placing the insertion cursor >at an exact
>>> spot would also be problematic with the bitmap proxy in the way.
>>
>> You must put the focus on the text before doing any selection (that
>> usual on mobile). So when you focus, the proxy is hidden and the
>> StageText shown, that's why it works.
>>
>>> Let's step back a bit. Why is it too late to detect scrolling on
>>> mousedown? The MX DataGrid tears down its item editors when
>>> scrolling starts. Isn't that similar?
>> The diifrence is that on Desktop, you scroll with the scroll bar,
>> whereas on mobile, you scroll by "swiping" directly on the content.
>> This causes issue for focusing text, but also for selecting an item
>> in a list, etc...
>> So there is a general mechanism that is implemented in
>> TouchScrollingHelp
>> (IIUC) that detects such behavior based on timers and movement
>> thresholds and will trigger touchInteractionStart.
>>
>> As DarkStone says, touchInteractionStart is triggered after
>> mousedown, so if the focus in bound to mouseDown, it's too late.
>>
>>> Does there really need to be more than one StageText instance in play?
>>> When TI1 loses focus can TI2 use that same StageText instance?
>>
>> Actually, it does: ScrollingStageText uses an internal pool, that
>> will reuse the same instance if it has the same properties
>> (multiline, font size, etc).
>>
>> -----Message d'origine-----
>> De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 24
>> novembre 2013 06:38 À : dev@flex.apache.org Objet : Re: Mobile
>> TextInput swipe
>>
>> BTW, I haven't tried any versions of your code, but I'm still
>> surprised that text selection works. I would think that trying to
>> swipe-select a word or placing the insertion cursor at an exact spot
>> would also be problematic with the bitmap proxy in the way.
>>
>> Let's step back a bit. Why is it too late to detect scrolling on
>> mousedown? The MX DataGrid tears down its item editors when
>> scrolling starts. Isn't that similar?
>>
>> Does there really need to be more than one StageText instance in play?
>> When TI1 loses focus can TI2 use that same StageText instance?
>>
>>
>> -Alex
>>
>> On 11/23/13 5:22 PM, "Maurice Amsellem" <ma...@systar.com>
>> wrote:
>>
>>> Hi Team,
>>>
>>> I am currently working on the swipe issue with ScrollableStageText
>>> on mobile and would like your advice / help
>>>
>>> The issue is the following: you cannot initiate a scroll/swipe by
>>> touching inside a TextInput or TextArea.
>>>
>>> 1) current situation:
>>>
>>> - in ScrollableStageText, the StageText is only shown when TI is in
>>> focus, and is replaced by a proxy when out of focus.
>>> - when scrolling, only the proxies are scrolled, so it works well.
>>>
>>> - when editing TI2 after TI1:
>>> - TI1 receives focus out => TI1 stageText is hidden, proxy shown
>>> - TI2 receives the focus on mouse down => TI2 stage text is focused
>>> - stageText for TI2 is displayed (and proxy hidden)
>>>
>>> => the problem, is that since focus is set on mousedown, it's too
>>> late to detect scrolling, so I had to prevent it, by calling
>>> event.preventDefautl() in touchInteractionStarting handler.
>>>
>>> 2) proposed solution
>>> To overcome that issue, I changed the focus to be set on MOUSE UP,
>>> instead of mouse down, so that I can detection touch scroll, and
>>> prevent editing.
>>>
>>> It works pretty well but has the following side effect :
>>> When editing TI1 after TI2, the soft keyboard (which was visible),
>>> lowers when pressing TI2, and raises back when releasing your finger.
>>>
>>> The reason for that is that is when pressing TI2:
>>> - TI1 has received focus out, so its StageText it's not visible
>>> anymore
>>> - TI2 did not receive focus yet, so its stageText is not visible yet
>>> => no stageText, no SoftKeyboard.
>>> TI2 stage text is assigned focus only when finger is released.
>>>
>>> 3) proposed solution to the side effect:
>>> Since the only way of having a soft keyboard visible is to have an
>>> active StageText, and call assingFocus() on it, I added a dummy
>>> static StageText to the stage, with no text and a viewport extent of 0,0.
>>> This stageText is assigned focus between the time finger is pressed,
>>> so
>>> TI1 and TI2 stage texts are not visible, and the finger is released,
>>> where TI2 stage text is displayed.
>>> That way, the soft keyboard does not disappear.
>>> ______________
>>>
>>> It works well, but I consider the dummy StageText as a HORRIBLE HACK.
>>> So if someone has a better solution that also meets the
>>> requirements, I will be happy to take it.
>>>
>>> Regards,
>>>
>>> Maurice
>>>
>>> -----Message d'origine-----
>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>> Envoyé : vendredi 22 novembre 2013 11:37 À : dev@flex.apache.org
>>> Objet
>>> : RE: Mobile TextInput Implementation status
>>>
>>> Hi,
>>> I fixed the two issues that were reported in the JIRA ticket by
>>> Colins Childs.
>>>
>>> fixed two issues reported above:
>>> - two focused text inputs
>>> - stage text floating above content.
>>>
>>>
>>> Committed and pushed to develop branch
>>> https://git-wip-us.apache.org/repos/asf?p=flex-sdk.git;a=commit;h=9e
>>> 4bf
>>> 21f
>>>
>>> Mobile Mustella test pass:
>>> - mobile/components/TextInput
>>> - mobile/compoents/TextArea
>>> - mobile/Softkeyboard
>>>
>>>
>>> -----Message d'origine-----
>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>> Envoyé : mardi 19 novembre 2013 18:18 À : dev@flex.apache.org Objet
>>> : RE: Mobile TextInput Implementation status
>>>
>>> Sure. You need mobilecomponents and mobiletheme
>>>
>>> -----Message d'origine-----
>>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>> OmPrakash Muppirala Envoyé : mardi 19 novembre 2013 18:14 À :
>>> dev@flex.apache.org Objet : RE: Mobile TextInput Implementation
>>> status
>>>
>>> On Nov 19, 2013 9:05 AM, "Maurice Amsellem"
>>> <ma...@systar.com>
>>> wrote:
>>>>
>>>> Since jenkins is down, do you need the updated swc ?
>>>
>>> Which project is it? I can just compile it and drop it in the sdk
>>> directory.
>>>
>>> Thanks,
>>> Om
>>>
>>>>
>>>> -----Message d'origine-----
>>>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>>> OmPrakash
>>> Muppirala
>>>> Envoyé : mardi 19 novembre 2013 17:55 À : dev@flex.apache.org Objet :
>>>> RE: Mobile TextInput Implementation status
>>>>
>>>> On Nov 19, 2013 4:53 AM, "Maurice Amsellem"
>>>> <ma...@systar.com>
>>>> wrote:
>>>>>
>>>>> Fixed a few other issues
>>>>> (see https://issues.apache.org/jira/browse/FLEX-33166)
>>>>>> FIXED : Soft keyboard partially closes/opens when moving the
>>>>>> focus
>>>> from one TI to another.
>>>>>> to fix the issue above, had to trigger TI edition on mousedown
>>>>>> instead
>>>> of mouse click (like in StyleableStageText)
>>>>>> fixed bug caused by the above.
>>>>>
>>>>> All related mustella test pass. ( mobile/TextInput,
>>>>> mobile/TextArea,
>>>> mobile/SoftKeyboard)
>>>>>
>>>>> Om, can you please make a last test run on Android, so I can close
>>>>> the
>>>> ticket.
>>>>>
>>>>
>>>> Will do, later in the night for me.
>>>>
>>>> Thanks,
>>>> Om
>>>>
>>>>> Maurice
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>> Envoyé : mardi 19 novembre 2013 00:36 À : dev@flex.apache.org
>>>>> Objet
>>>>> : RE: Mobile TextInput Implementation status
>>>>>
>>>>> Just received results of Om testing on Android (Tested on Samsung
>>>>> Galaxy
>>>> SIII (Android 4.1.2) and Samsung Galaxy Tab 2 (Android 4.2.2)).
>>>>> It's working fine.
>>>>> Thanks you Om for the quick testing, that's really good news.
>>>>>
>>>>> Maurice
>>>>> -----Message d'origine-----
>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>> Envoyé : lundi 18 novembre 2013 16:49 À : dev@flex.apache.org
>>>>> Objet
>>>>> : Mobile TextInput Implementation status
>>>>>
>>>>> Memory profiling of the new skins:
>>>>>
>>>>> It's as expected: alloc memory = pixel width x pixel height x
>>>>> 4bytes
>>>> per pixel.
>>>>>
>>>>> First figure is for iPad , second is for iPad retina.
>>>>>
>>>>> - 25KB / 100 KB of bitmap memory allocated for a single line TI
>>>>> with
>>>> default size
>>>>> - ~500KB / ~ 2 MB for a pages stuffed with text inputs / text
>>>>> Areas
>>>>> - 3 MB / 12 MB for a full-page TA => in this case, it's better to
>>>>> use the
>>>> old skins.
>>>>>
>>>>> The bitmap is allocated while the TI is added to the stage, and
>>>>> disposed
>>>> when it's removed from the stage
>>>>>
>>>>> Maurice
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>> Envoyé : lundi 18 novembre 2013 02:10 À : dev@flex.apache.org
>>>>> Objet
>>>>> : RE: Mobile TextInput Implementation status
>>>>>
>>>>>
>>>>> 1) to help debug if something goes wrong on Android, you can set
>>>>> the
>>>> following mx_internal flag:
>>>>> ScrollableStageText.debugProxyImage = true;
>>>>>
>>>>> It will display the proxy bitmaps in magenta background.
>>>>>
>>>>> 2) proxy methods in ScrollableStageText has been abstracted on
>>>>> purpose to
>>>> DisplayObject instead of Bitmap.
>>>>> This is so that one could override the class to use another proxy
>>>> (eg.
>>>> StyleableTextField) which is less memory consuming than bitmaps.
>>>>> In wich case, you will have to override:
>>>>> createProxy
>>>>> updateProxy
>>>>> disposeProxy
>>>>>
>>>>> 3) StageTextSkinBase inner textDisplay creation method is
>>>>> externalized so
>>>> that it can be customized.
>>>>>
>>>>> Example for ScrollableStageTextInputSkin:
>>>>> override protected function
>>> createTextDisplay():IStyleableEditableText
>>>>> {
>>>>> return new ScrollableStageText(multiline);
>>>>> }
>>>>>
>>>>> That way, you can derive from existing skins, instead of monkey
>>>>> patching
>>>> the default skin, if you only need to change the internal editable
>>>> text
>>> class.
>>>>>
>>>>> Note also that displayText is now of type IStyleableEditableText,
>>>>> instead
>>>> of StyleableStageText, for the same purpose.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Maurice
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>> Envoyé : lundi 18 novembre 2013 01:49 À : dev@flex.apache.org
>>>>> Objet
>>>>> : RE: Mobile TextInput Implementation status
>>>>>
>>>>> Run mustella tests:
>>>>> Mobile/Components/TextInput
>>>>> Mobile/components/TextArea
>>>>> Mobile/StageText
>>>>>
>>>>> All pass.
>>>>>
>>>>> Maurice
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>> Envoyé : lundi 18 novembre 2013 01:11 À : dev@flex.apache.org
>>>>> Objet
>>>>> : RE: Mobile TextInput Implementation status
>>>>>
>>>>> Hi, I have committed and pushed tentative fix for
>>>> https://issues.apache.org/jira/browse/FLEX-33166
>>>>>
>>>>> Tested on iPad 2 / 3.
>>>>> Not tested on Android.
>>>>> I couldn't run mustella mobile tests. For some reason, they are
>>>>> broken
>>>> on my machine ( says: Passes: 0 / Fails: 0).
>>>>>
>>>>> The new skins are now the defaults for TextInput and TextArea on
>>>> mobile:
>>>>>
>>>>> TextInput skinClass =
>>>>> spark.skins.mobile.ScrollingStageTextInputSkin
>>>>> TextArea skinClass = spark.skins.mobile.ScrollingStageTextAreaSkin
>>>>>
>>>>> The old skins are still there, under the same name.
>>>>>
>>>>> Please review and tests, and this is a sensitive change...
>>>>>
>>>>> Your comments and feedback are welcome.
>>>>>
>>>>> Maurice
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>> Envoyé : lundi 18 novembre 2013 00:08 À : dev@flex.apache.org
>>>>> Objet
>>>>> : RE: Mobile TextInput Implementation status
>>>>>
>>>>> Founds some bugs, so I won't commit until they are fixed...
>>>>>
>>>>> Maurice
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>> Envoyé : dimanche 17 novembre 2013 21:18 À : dev@flex.apache.org
>>>> Objet :
>>>> RE: Mobile TextInput Implementation status
>>>>>
>>>>>> I can help out with Android testing.
>>>>> Thanks
>>>>>
>>>>>> Should I wait for the nightly or are these fixes on a branch?
>>>>>> Nightly
>>>> would be preferable so as to allow more people to test the fix.
>>>>> I will push to the develop/ so that they be in the nightly
>>>>>
>>>>>> It would be better to keep the old one around with the same name.
>>>>>> Folks
>>>> might have subclassed it to build their own implementations.
>>>>>
>>>>> What about :
>>>>> ScrollableStageText
>>>>> ScrollableStageTextInputSkin
>>>>>
>>>>> For the new classes ?
>>>>>
>>>>> Maurice
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>>>> OmPrakash
>>>> Muppirala Envoyé : dimanche 17 novembre 2013 20:27 À :
>>>> dev@flex.apache.orgObjet : Re: Mobile TextInput Implementation
>>>> status
>>>>>
>>>>> On Nov 17, 2013 10:56 AM, "Maurice Amsellem"
>>>>> <ma...@systar.com>
>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Here is a brief status of the implementation of Mobile Text
>>>>>> Input, along
>>>>> with some questions:
>>>>>>
>>>>>> Implementation overview:
>>>>>> The change is mainly on the class StyleableStageText, which now
>>>>>> takes the
>>>>> opposite approach than the previous one:
>>>>>> - display proxy image bitmap by default
>>>>>> - display StageText only when editing
>>>>>> StageTextInputSkin/StageTextAreaSkin has been modified to use
>>>>>> this class
>>>>>>
>>>>>> - to make it easier to change StageTextInputSkin internal
>>>>> StyleableStageText component, the variable textDisplay is now of
>>>>> type
>>>> IStyleableEditText
>>>>>>
>>>>>> Behavior changes:
>>>>>> - scrolling and overlapping of text is well managed , as it
>>>>>> always uses
>>>>> the bitmap proxy, which is a Flex component: all the text inputs
>>>>> are
>>>> scrolling
>>>>>> - text occluding while editing is not managed yet, which means
>>>>>> the
>>>>> edited text may overlap other UIs. (TO BE DONE)
>>>>>>
>>>>>> Testing:
>>>>>> - tested on iPad 2 and iPad 3: TI in scrolling forms, TI in
>>> callouts
>>>>>> - *NEEDS TO BE TESTED ON ANDROID*
>>>>>> - memory consumption tests yet to be done
>>>>>> - mustella test yet to be run
>>>>>>
>>>>>>
>>>>>> Questions:
>>>>>> - Can someone please test on Android ?
>>>>>
>>>>> I can help out with Android testing. Should I wait for the
>>>>> nightly or
>>>> are these fixes on a branch? Nightly would be preferable so as to
>>>> allow
>>> more people to test the fix.
>>>>>
>>>>> Thanks,
>>>>> Om
>>>>>
>>>>>> - I have chosen to directly replace StyleableStageText.
>>>>>> Maybe I can also leave the old StyleableStageText with a
>>>>>> different name,
>>>>> so that it can be used in case there is an issue with the new one ?
>>>>> or
>>>> the other way?
>>>>>
>>>>> It would be better to keep the old one around with the same name.
>>>>> Folks
>>>> might have subclassed it to build their own implementations.
>>>>>
>>>>>> Now that it is an interface, it's easy to subclass the
>>>>> StageTextInputSkin, and override createTextDisplay() to use
>>>>> another
>>> class.
>>>>>>
>>>>>>
>>>>>> Maurice
>>>>>>
>>
>
Re: Mobile TextInput swipe
Posted by 周 戈 <da...@163.com>.
> Just extends VisualElement and implements the IEditableText, it will work the way like a RichEditableText (but less powerful than RichEditableText), you can use it in Spark TextInputSkin / TextAreaSkin as a skin part.
Sorry for my typo, what I mean is “Just extends the SpriteVisualElement class and ..."
DarkStone
2013-11-25
在 2013-11-25，01:42，周 戈 <Da...@163.com> 写道：
> Hi all,
>
>> Maybe the whole framework in mobile-mode should ignore mouseDown and
>> determine if the gesture is a tap or not before assigning focus.
> Please don’t do that, current framework’s FocusManager is doing fine, if Flex team makes any serious upgrades to it, it will impact a lot of things already done for mobile!
>
>> You don't need to show to StageText to make a bitmap of it, it works even when not visible.
> Haven’t tried that yet, thanks for the tip, I’ll give it a shot.
>
>> This is also how ScrollableStageText works. It derives from UIComponent, and can be used as part in ScrollingStageTextInputSkin / ScrollingStageTextAreaSkin mxml skins.
>> It's the textDisplay skin part.
>
> I highly recommend you extends SpriteVisualElement rather than UIComponent. UIComponent has a lot of stuff you probably will never use, and it’s a bit heavy for mobile text component.
> The SpriteVisualElement class helps you implemented IVisualElement interface in a quite lighter way than UIComponent, and it supports mxml as well.
>
> And why you develop ScrollingStageTextInput and ScrollingStageTextArea and their skins (ScrollingStageTextInputSkin and ScrollingStageTextAreaSkin)? I don’t think that’s necessary.
>
> Just extends VisualElement and implements the IEditableText, it will work the way like a RichEditableText (but less powerful than RichEditableText), you can use it in Spark TextInputSkin / TextAreaSkin as a skin part.
>
> You don’t have to develop ScrollingStageTextInput and ScrollingStageTextArea and their skins, just use the Spark TextInput and TextArea, they are doing fine.
>
>
> DarkStone
> 2013-11-25
>
>
>
> 在 2013-11-24，23:44，Alex Harui <ah...@adobe.com> 写道：
>
>> All this reminded me that I don't think there were any serious upgrades to
>> FocusManager for mobile, and it is quite possible that there should be.
>> Maybe the whole framework in mobile-mode should ignore mouseDown and
>> determine if the gesture is a tap or not before assigning focus.
>>
>> In FlexJS with the plug-ins, it allows for a possibility of a
>> touch-oriented FocusManager if one is needed.
>>
>> -Alex
>>
>> On 11/24/13 2:40 AM, "Maurice Amsellem" <ma...@systar.com>
>> wrote:
>>
>>>
>>>> BTW, I haven't tried any versions of your code, but I'm still surprised
>>>> that text selection works. I would think that trying to swipe-select a
>>>> word or placing the insertion cursor >at an exact spot would also be
>>>> problematic with the bitmap proxy in the way.
>>>
>>> You must put the focus on the text before doing any selection (that usual
>>> on mobile). So when you focus, the proxy is hidden and the StageText
>>> shown, that's why it works.
>>>
>>>> Let's step back a bit. Why is it too late to detect scrolling on
>>>> mousedown? The MX DataGrid tears down its item editors when scrolling
>>>> starts. Isn't that similar?
>>> The diifrence is that on Desktop, you scroll with the scroll bar, whereas
>>> on mobile, you scroll by "swiping" directly on the content.
>>> This causes issue for focusing text, but also for selecting an item in a
>>> list, etc...
>>> So there is a general mechanism that is implemented in TouchScrollingHelp
>>> (IIUC) that detects such behavior based on timers and movement thresholds
>>> and will trigger touchInteractionStart.
>>>
>>> As DarkStone says, touchInteractionStart is triggered after mousedown, so
>>> if the focus in bound to mouseDown, it's too late.
>>>
>>>> Does there really need to be more than one StageText instance in play?
>>>> When TI1 loses focus can TI2 use that same StageText instance?
>>>
>>> Actually, it does: ScrollingStageText uses an internal pool, that will
>>> reuse the same instance if it has the same properties (multiline, font
>>> size, etc).
>>>
>>> -----Message d'origine-----
>>> De : Alex Harui [mailto:aharui@adobe.com]
>>> Envoyé : dimanche 24 novembre 2013 06:38
>>> À : dev@flex.apache.org
>>> Objet : Re: Mobile TextInput swipe
>>>
>>> BTW, I haven't tried any versions of your code, but I'm still surprised
>>> that text selection works. I would think that trying to swipe-select a
>>> word or placing the insertion cursor at an exact spot would also be
>>> problematic with the bitmap proxy in the way.
>>>
>>> Let's step back a bit. Why is it too late to detect scrolling on
>>> mousedown? The MX DataGrid tears down its item editors when scrolling
>>> starts. Isn't that similar?
>>>
>>> Does there really need to be more than one StageText instance in play?
>>> When TI1 loses focus can TI2 use that same StageText instance?
>>>
>>>
>>> -Alex
>>>
>>> On 11/23/13 5:22 PM, "Maurice Amsellem" <ma...@systar.com>
>>> wrote:
>>>
>>>> Hi Team,
>>>>
>>>> I am currently working on the swipe issue with ScrollableStageText on
>>>> mobile and would like your advice / help
>>>>
>>>> The issue is the following: you cannot initiate a scroll/swipe by
>>>> touching inside a TextInput or TextArea.
>>>>
>>>> 1) current situation:
>>>>
>>>> - in ScrollableStageText, the StageText is only shown when TI is in
>>>> focus, and is replaced by a proxy when out of focus.
>>>> - when scrolling, only the proxies are scrolled, so it works well.
>>>>
>>>> - when editing TI2 after TI1:
>>>> - TI1 receives focus out => TI1 stageText is hidden, proxy shown
>>>> - TI2 receives the focus on mouse down => TI2 stage text is focused
>>>> - stageText for TI2 is displayed (and proxy hidden)
>>>>
>>>> => the problem, is that since focus is set on mousedown, it's too late
>>>> to detect scrolling, so I had to prevent it, by calling
>>>> event.preventDefautl() in touchInteractionStarting handler.
>>>>
>>>> 2) proposed solution
>>>> To overcome that issue, I changed the focus to be set on MOUSE UP,
>>>> instead of mouse down, so that I can detection touch scroll, and
>>>> prevent editing.
>>>>
>>>> It works pretty well but has the following side effect :
>>>> When editing TI1 after TI2, the soft keyboard (which was visible),
>>>> lowers when pressing TI2, and raises back when releasing your finger.
>>>>
>>>> The reason for that is that is when pressing TI2:
>>>> - TI1 has received focus out, so its StageText it's not visible anymore
>>>> - TI2 did not receive focus yet, so its stageText is not visible yet =>
>>>> no stageText, no SoftKeyboard.
>>>> TI2 stage text is assigned focus only when finger is released.
>>>>
>>>> 3) proposed solution to the side effect:
>>>> Since the only way of having a soft keyboard visible is to have an
>>>> active StageText, and call assingFocus() on it, I added a dummy static
>>>> StageText to the stage, with no text and a viewport extent of 0,0.
>>>> This stageText is assigned focus between the time finger is pressed, so
>>>> TI1 and TI2 stage texts are not visible, and the finger is released,
>>>> where TI2 stage text is displayed.
>>>> That way, the soft keyboard does not disappear.
>>>> ______________
>>>>
>>>> It works well, but I consider the dummy StageText as a HORRIBLE HACK.
>>>> So if someone has a better solution that also meets the requirements, I
>>>> will be happy to take it.
>>>>
>>>> Regards,
>>>>
>>>> Maurice
>>>>
>>>> -----Message d'origine-----
>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> Envoyé : vendredi 22 novembre 2013 11:37 À : dev@flex.apache.org Objet
>>>> : RE: Mobile TextInput Implementation status
>>>>
>>>> Hi,
>>>> I fixed the two issues that were reported in the JIRA ticket by Colins
>>>> Childs.
>>>>
>>>> fixed two issues reported above:
>>>> - two focused text inputs
>>>> - stage text floating above content.
>>>>
>>>>
>>>> Committed and pushed to develop branch
>>>> https://git-wip-us.apache.org/repos/asf?p=flex-sdk.git;a=commit;h=9e4bf
>>>> 21f
>>>>
>>>> Mobile Mustella test pass:
>>>> - mobile/components/TextInput
>>>> - mobile/compoents/TextArea
>>>> - mobile/Softkeyboard
>>>>
>>>>
>>>> -----Message d'origine-----
>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> Envoyé : mardi 19 novembre 2013 18:18
>>>> À : dev@flex.apache.org
>>>> Objet : RE: Mobile TextInput Implementation status
>>>>
>>>> Sure. You need mobilecomponents and mobiletheme
>>>>
>>>> -----Message d'origine-----
>>>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>>> OmPrakash Muppirala Envoyé : mardi 19 novembre 2013 18:14 À :
>>>> dev@flex.apache.org Objet : RE: Mobile TextInput Implementation status
>>>>
>>>> On Nov 19, 2013 9:05 AM, "Maurice Amsellem"
>>>> <ma...@systar.com>
>>>> wrote:
>>>>>
>>>>> Since jenkins is down, do you need the updated swc ?
>>>>
>>>> Which project is it? I can just compile it and drop it in the sdk
>>>> directory.
>>>>
>>>> Thanks,
>>>> Om
>>>>
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>>>> OmPrakash
>>>> Muppirala
>>>>> Envoyé : mardi 19 novembre 2013 17:55 À : dev@flex.apache.org Objet :
>>>>> RE: Mobile TextInput Implementation status
>>>>>
>>>>> On Nov 19, 2013 4:53 AM, "Maurice Amsellem"
>>>>> <ma...@systar.com>
>>>>> wrote:
>>>>>>
>>>>>> Fixed a few other issues
>>>>>> (see https://issues.apache.org/jira/browse/FLEX-33166)
>>>>>>> FIXED : Soft keyboard partially closes/opens when moving the
>>>>>>> focus
>>>>> from one TI to another.
>>>>>>> to fix the issue above, had to trigger TI edition on mousedown
>>>>>>> instead
>>>>> of mouse click (like in StyleableStageText)
>>>>>>> fixed bug caused by the above.
>>>>>>
>>>>>> All related mustella test pass. ( mobile/TextInput,
>>>>>> mobile/TextArea,
>>>>> mobile/SoftKeyboard)
>>>>>>
>>>>>> Om, can you please make a last test run on Android, so I can close
>>>>>> the
>>>>> ticket.
>>>>>>
>>>>>
>>>>> Will do, later in the night for me.
>>>>>
>>>>> Thanks,
>>>>> Om
>>>>>
>>>>>> Maurice
>>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>>> Envoyé : mardi 19 novembre 2013 00:36 À : dev@flex.apache.org Objet
>>>>>> : RE: Mobile TextInput Implementation status
>>>>>>
>>>>>> Just received results of Om testing on Android (Tested on Samsung
>>>>>> Galaxy
>>>>> SIII (Android 4.1.2) and Samsung Galaxy Tab 2 (Android 4.2.2)).
>>>>>> It's working fine.
>>>>>> Thanks you Om for the quick testing, that's really good news.
>>>>>>
>>>>>> Maurice
>>>>>> -----Message d'origine-----
>>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>>> Envoyé : lundi 18 novembre 2013 16:49 À : dev@flex.apache.org Objet
>>>>>> : Mobile TextInput Implementation status
>>>>>>
>>>>>> Memory profiling of the new skins:
>>>>>>
>>>>>> It's as expected: alloc memory = pixel width x pixel height x
>>>>>> 4bytes
>>>>> per pixel.
>>>>>>
>>>>>> First figure is for iPad , second is for iPad retina.
>>>>>>
>>>>>> - 25KB / 100 KB of bitmap memory allocated for a single line TI
>>>>>> with
>>>>> default size
>>>>>> - ~500KB / ~ 2 MB for a pages stuffed with text inputs / text Areas
>>>>>> - 3 MB / 12 MB for a full-page TA => in this case, it's better to
>>>>>> use the
>>>>> old skins.
>>>>>>
>>>>>> The bitmap is allocated while the TI is added to the stage, and
>>>>>> disposed
>>>>> when it's removed from the stage
>>>>>>
>>>>>> Maurice
>>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>>> Envoyé : lundi 18 novembre 2013 02:10 À : dev@flex.apache.org Objet
>>>>>> : RE: Mobile TextInput Implementation status
>>>>>>
>>>>>>
>>>>>> 1) to help debug if something goes wrong on Android, you can set
>>>>>> the
>>>>> following mx_internal flag:
>>>>>> ScrollableStageText.debugProxyImage = true;
>>>>>>
>>>>>> It will display the proxy bitmaps in magenta background.
>>>>>>
>>>>>> 2) proxy methods in ScrollableStageText has been abstracted on
>>>>>> purpose to
>>>>> DisplayObject instead of Bitmap.
>>>>>> This is so that one could override the class to use another proxy
>>>>> (eg.
>>>>> StyleableTextField) which is less memory consuming than bitmaps.
>>>>>> In wich case, you will have to override:
>>>>>> createProxy
>>>>>> updateProxy
>>>>>> disposeProxy
>>>>>>
>>>>>> 3) StageTextSkinBase inner textDisplay creation method is
>>>>>> externalized so
>>>>> that it can be customized.
>>>>>>
>>>>>> Example for ScrollableStageTextInputSkin:
>>>>>> override protected function
>>>> createTextDisplay():IStyleableEditableText
>>>>>> {
>>>>>> return new ScrollableStageText(multiline);
>>>>>> }
>>>>>>
>>>>>> That way, you can derive from existing skins, instead of monkey
>>>>>> patching
>>>>> the default skin, if you only need to change the internal editable
>>>>> text
>>>> class.
>>>>>>
>>>>>> Note also that displayText is now of type IStyleableEditableText,
>>>>>> instead
>>>>> of StyleableStageText, for the same purpose.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Maurice
>>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>>> Envoyé : lundi 18 novembre 2013 01:49 À : dev@flex.apache.org Objet
>>>>>> : RE: Mobile TextInput Implementation status
>>>>>>
>>>>>> Run mustella tests:
>>>>>> Mobile/Components/TextInput
>>>>>> Mobile/components/TextArea
>>>>>> Mobile/StageText
>>>>>>
>>>>>> All pass.
>>>>>>
>>>>>> Maurice
>>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>>> Envoyé : lundi 18 novembre 2013 01:11 À : dev@flex.apache.org Objet
>>>>>> : RE: Mobile TextInput Implementation status
>>>>>>
>>>>>> Hi, I have committed and pushed tentative fix for
>>>>> https://issues.apache.org/jira/browse/FLEX-33166
>>>>>>
>>>>>> Tested on iPad 2 / 3.
>>>>>> Not tested on Android.
>>>>>> I couldn't run mustella mobile tests. For some reason, they are
>>>>>> broken
>>>>> on my machine ( says: Passes: 0 / Fails: 0).
>>>>>>
>>>>>> The new skins are now the defaults for TextInput and TextArea on
>>>>> mobile:
>>>>>>
>>>>>> TextInput skinClass =
>>>>>> spark.skins.mobile.ScrollingStageTextInputSkin
>>>>>> TextArea skinClass = spark.skins.mobile.ScrollingStageTextAreaSkin
>>>>>>
>>>>>> The old skins are still there, under the same name.
>>>>>>
>>>>>> Please review and tests, and this is a sensitive change...
>>>>>>
>>>>>> Your comments and feedback are welcome.
>>>>>>
>>>>>> Maurice
>>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>>> Envoyé : lundi 18 novembre 2013 00:08 À : dev@flex.apache.org Objet
>>>>>> : RE: Mobile TextInput Implementation status
>>>>>>
>>>>>> Founds some bugs, so I won't commit until they are fixed...
>>>>>>
>>>>>> Maurice
>>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>>> Envoyé : dimanche 17 novembre 2013 21:18 À : dev@flex.apache.org
>>>>> Objet :
>>>>> RE: Mobile TextInput Implementation status
>>>>>>
>>>>>>> I can help out with Android testing.
>>>>>> Thanks
>>>>>>
>>>>>>> Should I wait for the nightly or are these fixes on a branch?
>>>>>>> Nightly
>>>>> would be preferable so as to allow more people to test the fix.
>>>>>> I will push to the develop/ so that they be in the nightly
>>>>>>
>>>>>>> It would be better to keep the old one around with the same name.
>>>>>>> Folks
>>>>> might have subclassed it to build their own implementations.
>>>>>>
>>>>>> What about :
>>>>>> ScrollableStageText
>>>>>> ScrollableStageTextInputSkin
>>>>>>
>>>>>> For the new classes ?
>>>>>>
>>>>>> Maurice
>>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>>>>> OmPrakash
>>>>> Muppirala Envoyé : dimanche 17 novembre 2013 20:27 À :
>>>>> dev@flex.apache.orgObjet : Re: Mobile TextInput Implementation status
>>>>>>
>>>>>> On Nov 17, 2013 10:56 AM, "Maurice Amsellem"
>>>>>> <ma...@systar.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Here is a brief status of the implementation of Mobile Text
>>>>>>> Input, along
>>>>>> with some questions:
>>>>>>>
>>>>>>> Implementation overview:
>>>>>>> The change is mainly on the class StyleableStageText, which now
>>>>>>> takes the
>>>>>> opposite approach than the previous one:
>>>>>>> - display proxy image bitmap by default
>>>>>>> - display StageText only when editing
>>>>>>> StageTextInputSkin/StageTextAreaSkin has been modified to use
>>>>>>> this class
>>>>>>>
>>>>>>> - to make it easier to change StageTextInputSkin internal
>>>>>> StyleableStageText component, the variable textDisplay is now of
>>>>>> type
>>>>> IStyleableEditText
>>>>>>>
>>>>>>> Behavior changes:
>>>>>>> - scrolling and overlapping of text is well managed , as it
>>>>>>> always uses
>>>>>> the bitmap proxy, which is a Flex component: all the text inputs
>>>>>> are
>>>>> scrolling
>>>>>>> - text occluding while editing is not managed yet, which means
>>>>>>> the
>>>>>> edited text may overlap other UIs. (TO BE DONE)
>>>>>>>
>>>>>>> Testing:
>>>>>>> - tested on iPad 2 and iPad 3: TI in scrolling forms, TI in
>>>> callouts
>>>>>>> - *NEEDS TO BE TESTED ON ANDROID*
>>>>>>> - memory consumption tests yet to be done
>>>>>>> - mustella test yet to be run
>>>>>>>
>>>>>>>
>>>>>>> Questions:
>>>>>>> - Can someone please test on Android ?
>>>>>>
>>>>>> I can help out with Android testing. Should I wait for the nightly
>>>>>> or
>>>>> are these fixes on a branch? Nightly would be preferable so as to
>>>>> allow
>>>> more people to test the fix.
>>>>>>
>>>>>> Thanks,
>>>>>> Om
>>>>>>
>>>>>>> - I have chosen to directly replace StyleableStageText.
>>>>>>> Maybe I can also leave the old StyleableStageText with a
>>>>>>> different name,
>>>>>> so that it can be used in case there is an issue with the new one ?
>>>>>> or
>>>>> the other way?
>>>>>>
>>>>>> It would be better to keep the old one around with the same name.
>>>>>> Folks
>>>>> might have subclassed it to build their own implementations.
>>>>>>
>>>>>>> Now that it is an interface, it's easy to subclass the
>>>>>> StageTextInputSkin, and override createTextDisplay() to use another
>>>> class.
>>>>>>>
>>>>>>>
>>>>>>> Maurice
>>>>>>>
>>>
>>
>
>
Re: Mobile TextInput swipe
Posted by 周 戈 <da...@163.com>.
Hi all,
> Maybe the whole framework in mobile-mode should ignore mouseDown and
> determine if the gesture is a tap or not before assigning focus.
Please don’t do that, current framework’s FocusManager is doing fine, if Flex team makes any serious upgrades to it, it will impact a lot of things already done for mobile!
> You don't need to show to StageText to make a bitmap of it, it works even when not visible.
Haven’t tried that yet, thanks for the tip, I’ll give it a shot.
> This is also how ScrollableStageText works. It derives from UIComponent, and can be used as part in ScrollingStageTextInputSkin / ScrollingStageTextAreaSkin mxml skins.
> It's the textDisplay skin part.
I highly recommend you extends SpriteVisualElement rather than UIComponent. UIComponent has a lot of stuff you probably will never use, and it’s a bit heavy for mobile text component.
The SpriteVisualElement class helps you implemented IVisualElement interface in a quite lighter way than UIComponent, and it supports mxml as well.
And why you develop ScrollingStageTextInput and ScrollingStageTextArea and their skins (ScrollingStageTextInputSkin and ScrollingStageTextAreaSkin)? I don’t think that’s necessary.
Just extends VisualElement and implements the IEditableText, it will work the way like a RichEditableText (but less powerful than RichEditableText), you can use it in Spark TextInputSkin / TextAreaSkin as a skin part.
You don’t have to develop ScrollingStageTextInput and ScrollingStageTextArea and their skins, just use the Spark TextInput and TextArea, they are doing fine.
DarkStone
2013-11-25
在 2013-11-24，23:44，Alex Harui <ah...@adobe.com> 写道：
> All this reminded me that I don't think there were any serious upgrades to
> FocusManager for mobile, and it is quite possible that there should be.
> Maybe the whole framework in mobile-mode should ignore mouseDown and
> determine if the gesture is a tap or not before assigning focus.
>
> In FlexJS with the plug-ins, it allows for a possibility of a
> touch-oriented FocusManager if one is needed.
>
> -Alex
>
> On 11/24/13 2:40 AM, "Maurice Amsellem" <ma...@systar.com>
> wrote:
>
>>
>>> BTW, I haven't tried any versions of your code, but I'm still surprised
>>> that text selection works. I would think that trying to swipe-select a
>>> word or placing the insertion cursor >at an exact spot would also be
>>> problematic with the bitmap proxy in the way.
>>
>> You must put the focus on the text before doing any selection (that usual
>> on mobile). So when you focus, the proxy is hidden and the StageText
>> shown, that's why it works.
>>
>>> Let's step back a bit. Why is it too late to detect scrolling on
>>> mousedown? The MX DataGrid tears down its item editors when scrolling
>>> starts. Isn't that similar?
>> The diifrence is that on Desktop, you scroll with the scroll bar, whereas
>> on mobile, you scroll by "swiping" directly on the content.
>> This causes issue for focusing text, but also for selecting an item in a
>> list, etc...
>> So there is a general mechanism that is implemented in TouchScrollingHelp
>> (IIUC) that detects such behavior based on timers and movement thresholds
>> and will trigger touchInteractionStart.
>>
>> As DarkStone says, touchInteractionStart is triggered after mousedown, so
>> if the focus in bound to mouseDown, it's too late.
>>
>>> Does there really need to be more than one StageText instance in play?
>>> When TI1 loses focus can TI2 use that same StageText instance?
>>
>> Actually, it does: ScrollingStageText uses an internal pool, that will
>> reuse the same instance if it has the same properties (multiline, font
>> size, etc).
>>
>> -----Message d'origine-----
>> De : Alex Harui [mailto:aharui@adobe.com]
>> Envoyé : dimanche 24 novembre 2013 06:38
>> À : dev@flex.apache.org
>> Objet : Re: Mobile TextInput swipe
>>
>> BTW, I haven't tried any versions of your code, but I'm still surprised
>> that text selection works. I would think that trying to swipe-select a
>> word or placing the insertion cursor at an exact spot would also be
>> problematic with the bitmap proxy in the way.
>>
>> Let's step back a bit. Why is it too late to detect scrolling on
>> mousedown? The MX DataGrid tears down its item editors when scrolling
>> starts. Isn't that similar?
>>
>> Does there really need to be more than one StageText instance in play?
>> When TI1 loses focus can TI2 use that same StageText instance?
>>
>>
>> -Alex
>>
>> On 11/23/13 5:22 PM, "Maurice Amsellem" <ma...@systar.com>
>> wrote:
>>
>>> Hi Team,
>>>
>>> I am currently working on the swipe issue with ScrollableStageText on
>>> mobile and would like your advice / help
>>>
>>> The issue is the following: you cannot initiate a scroll/swipe by
>>> touching inside a TextInput or TextArea.
>>>
>>> 1) current situation:
>>>
>>> - in ScrollableStageText, the StageText is only shown when TI is in
>>> focus, and is replaced by a proxy when out of focus.
>>> - when scrolling, only the proxies are scrolled, so it works well.
>>>
>>> - when editing TI2 after TI1:
>>> - TI1 receives focus out => TI1 stageText is hidden, proxy shown
>>> - TI2 receives the focus on mouse down => TI2 stage text is focused
>>> - stageText for TI2 is displayed (and proxy hidden)
>>>
>>> => the problem, is that since focus is set on mousedown, it's too late
>>> to detect scrolling, so I had to prevent it, by calling
>>> event.preventDefautl() in touchInteractionStarting handler.
>>>
>>> 2) proposed solution
>>> To overcome that issue, I changed the focus to be set on MOUSE UP,
>>> instead of mouse down, so that I can detection touch scroll, and
>>> prevent editing.
>>>
>>> It works pretty well but has the following side effect :
>>> When editing TI1 after TI2, the soft keyboard (which was visible),
>>> lowers when pressing TI2, and raises back when releasing your finger.
>>>
>>> The reason for that is that is when pressing TI2:
>>> - TI1 has received focus out, so its StageText it's not visible anymore
>>> - TI2 did not receive focus yet, so its stageText is not visible yet =>
>>> no stageText, no SoftKeyboard.
>>> TI2 stage text is assigned focus only when finger is released.
>>>
>>> 3) proposed solution to the side effect:
>>> Since the only way of having a soft keyboard visible is to have an
>>> active StageText, and call assingFocus() on it, I added a dummy static
>>> StageText to the stage, with no text and a viewport extent of 0,0.
>>> This stageText is assigned focus between the time finger is pressed, so
>>> TI1 and TI2 stage texts are not visible, and the finger is released,
>>> where TI2 stage text is displayed.
>>> That way, the soft keyboard does not disappear.
>>> ______________
>>>
>>> It works well, but I consider the dummy StageText as a HORRIBLE HACK.
>>> So if someone has a better solution that also meets the requirements, I
>>> will be happy to take it.
>>>
>>> Regards,
>>>
>>> Maurice
>>>
>>> -----Message d'origine-----
>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>> Envoyé : vendredi 22 novembre 2013 11:37 À : dev@flex.apache.org Objet
>>> : RE: Mobile TextInput Implementation status
>>>
>>> Hi,
>>> I fixed the two issues that were reported in the JIRA ticket by Colins
>>> Childs.
>>>
>>> fixed two issues reported above:
>>> - two focused text inputs
>>> - stage text floating above content.
>>>
>>>
>>> Committed and pushed to develop branch
>>> https://git-wip-us.apache.org/repos/asf?p=flex-sdk.git;a=commit;h=9e4bf
>>> 21f
>>>
>>> Mobile Mustella test pass:
>>> - mobile/components/TextInput
>>> - mobile/compoents/TextArea
>>> - mobile/Softkeyboard
>>>
>>>
>>> -----Message d'origine-----
>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>> Envoyé : mardi 19 novembre 2013 18:18
>>> À : dev@flex.apache.org
>>> Objet : RE: Mobile TextInput Implementation status
>>>
>>> Sure. You need mobilecomponents and mobiletheme
>>>
>>> -----Message d'origine-----
>>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>> OmPrakash Muppirala Envoyé : mardi 19 novembre 2013 18:14 À :
>>> dev@flex.apache.org Objet : RE: Mobile TextInput Implementation status
>>>
>>> On Nov 19, 2013 9:05 AM, "Maurice Amsellem"
>>> <ma...@systar.com>
>>> wrote:
>>>>
>>>> Since jenkins is down, do you need the updated swc ?
>>>
>>> Which project is it? I can just compile it and drop it in the sdk
>>> directory.
>>>
>>> Thanks,
>>> Om
>>>
>>>>
>>>> -----Message d'origine-----
>>>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>>> OmPrakash
>>> Muppirala
>>>> Envoyé : mardi 19 novembre 2013 17:55 À : dev@flex.apache.org Objet :
>>>> RE: Mobile TextInput Implementation status
>>>>
>>>> On Nov 19, 2013 4:53 AM, "Maurice Amsellem"
>>>> <ma...@systar.com>
>>>> wrote:
>>>>>
>>>>> Fixed a few other issues
>>>>> (see https://issues.apache.org/jira/browse/FLEX-33166)
>>>>>> FIXED : Soft keyboard partially closes/opens when moving the
>>>>>> focus
>>>> from one TI to another.
>>>>>> to fix the issue above, had to trigger TI edition on mousedown
>>>>>> instead
>>>> of mouse click (like in StyleableStageText)
>>>>>> fixed bug caused by the above.
>>>>>
>>>>> All related mustella test pass. ( mobile/TextInput,
>>>>> mobile/TextArea,
>>>> mobile/SoftKeyboard)
>>>>>
>>>>> Om, can you please make a last test run on Android, so I can close
>>>>> the
>>>> ticket.
>>>>>
>>>>
>>>> Will do, later in the night for me.
>>>>
>>>> Thanks,
>>>> Om
>>>>
>>>>> Maurice
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>> Envoyé : mardi 19 novembre 2013 00:36 À : dev@flex.apache.org Objet
>>>>> : RE: Mobile TextInput Implementation status
>>>>>
>>>>> Just received results of Om testing on Android (Tested on Samsung
>>>>> Galaxy
>>>> SIII (Android 4.1.2) and Samsung Galaxy Tab 2 (Android 4.2.2)).
>>>>> It's working fine.
>>>>> Thanks you Om for the quick testing, that's really good news.
>>>>>
>>>>> Maurice
>>>>> -----Message d'origine-----
>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>> Envoyé : lundi 18 novembre 2013 16:49 À : dev@flex.apache.org Objet
>>>>> : Mobile TextInput Implementation status
>>>>>
>>>>> Memory profiling of the new skins:
>>>>>
>>>>> It's as expected: alloc memory = pixel width x pixel height x
>>>>> 4bytes
>>>> per pixel.
>>>>>
>>>>> First figure is for iPad , second is for iPad retina.
>>>>>
>>>>> - 25KB / 100 KB of bitmap memory allocated for a single line TI
>>>>> with
>>>> default size
>>>>> - ~500KB / ~ 2 MB for a pages stuffed with text inputs / text Areas
>>>>> - 3 MB / 12 MB for a full-page TA => in this case, it's better to
>>>>> use the
>>>> old skins.
>>>>>
>>>>> The bitmap is allocated while the TI is added to the stage, and
>>>>> disposed
>>>> when it's removed from the stage
>>>>>
>>>>> Maurice
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>> Envoyé : lundi 18 novembre 2013 02:10 À : dev@flex.apache.org Objet
>>>>> : RE: Mobile TextInput Implementation status
>>>>>
>>>>>
>>>>> 1) to help debug if something goes wrong on Android, you can set
>>>>> the
>>>> following mx_internal flag:
>>>>> ScrollableStageText.debugProxyImage = true;
>>>>>
>>>>> It will display the proxy bitmaps in magenta background.
>>>>>
>>>>> 2) proxy methods in ScrollableStageText has been abstracted on
>>>>> purpose to
>>>> DisplayObject instead of Bitmap.
>>>>> This is so that one could override the class to use another proxy
>>>> (eg.
>>>> StyleableTextField) which is less memory consuming than bitmaps.
>>>>> In wich case, you will have to override:
>>>>> createProxy
>>>>> updateProxy
>>>>> disposeProxy
>>>>>
>>>>> 3) StageTextSkinBase inner textDisplay creation method is
>>>>> externalized so
>>>> that it can be customized.
>>>>>
>>>>> Example for ScrollableStageTextInputSkin:
>>>>> override protected function
>>> createTextDisplay():IStyleableEditableText
>>>>> {
>>>>> return new ScrollableStageText(multiline);
>>>>> }
>>>>>
>>>>> That way, you can derive from existing skins, instead of monkey
>>>>> patching
>>>> the default skin, if you only need to change the internal editable
>>>> text
>>> class.
>>>>>
>>>>> Note also that displayText is now of type IStyleableEditableText,
>>>>> instead
>>>> of StyleableStageText, for the same purpose.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Maurice
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>> Envoyé : lundi 18 novembre 2013 01:49 À : dev@flex.apache.org Objet
>>>>> : RE: Mobile TextInput Implementation status
>>>>>
>>>>> Run mustella tests:
>>>>> Mobile/Components/TextInput
>>>>> Mobile/components/TextArea
>>>>> Mobile/StageText
>>>>>
>>>>> All pass.
>>>>>
>>>>> Maurice
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>> Envoyé : lundi 18 novembre 2013 01:11 À : dev@flex.apache.org Objet
>>>>> : RE: Mobile TextInput Implementation status
>>>>>
>>>>> Hi, I have committed and pushed tentative fix for
>>>> https://issues.apache.org/jira/browse/FLEX-33166
>>>>>
>>>>> Tested on iPad 2 / 3.
>>>>> Not tested on Android.
>>>>> I couldn't run mustella mobile tests. For some reason, they are
>>>>> broken
>>>> on my machine ( says: Passes: 0 / Fails: 0).
>>>>>
>>>>> The new skins are now the defaults for TextInput and TextArea on
>>>> mobile:
>>>>>
>>>>> TextInput skinClass =
>>>>> spark.skins.mobile.ScrollingStageTextInputSkin
>>>>> TextArea skinClass = spark.skins.mobile.ScrollingStageTextAreaSkin
>>>>>
>>>>> The old skins are still there, under the same name.
>>>>>
>>>>> Please review and tests, and this is a sensitive change...
>>>>>
>>>>> Your comments and feedback are welcome.
>>>>>
>>>>> Maurice
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>> Envoyé : lundi 18 novembre 2013 00:08 À : dev@flex.apache.org Objet
>>>>> : RE: Mobile TextInput Implementation status
>>>>>
>>>>> Founds some bugs, so I won't commit until they are fixed...
>>>>>
>>>>> Maurice
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>>> Envoyé : dimanche 17 novembre 2013 21:18 À : dev@flex.apache.org
>>>> Objet :
>>>> RE: Mobile TextInput Implementation status
>>>>>
>>>>>> I can help out with Android testing.
>>>>> Thanks
>>>>>
>>>>>> Should I wait for the nightly or are these fixes on a branch?
>>>>>> Nightly
>>>> would be preferable so as to allow more people to test the fix.
>>>>> I will push to the develop/ so that they be in the nightly
>>>>>
>>>>>> It would be better to keep the old one around with the same name.
>>>>>> Folks
>>>> might have subclassed it to build their own implementations.
>>>>>
>>>>> What about :
>>>>> ScrollableStageText
>>>>> ScrollableStageTextInputSkin
>>>>>
>>>>> For the new classes ?
>>>>>
>>>>> Maurice
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>>>> OmPrakash
>>>> Muppirala Envoyé : dimanche 17 novembre 2013 20:27 À :
>>>> dev@flex.apache.orgObjet : Re: Mobile TextInput Implementation status
>>>>>
>>>>> On Nov 17, 2013 10:56 AM, "Maurice Amsellem"
>>>>> <ma...@systar.com>
>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Here is a brief status of the implementation of Mobile Text
>>>>>> Input, along
>>>>> with some questions:
>>>>>>
>>>>>> Implementation overview:
>>>>>> The change is mainly on the class StyleableStageText, which now
>>>>>> takes the
>>>>> opposite approach than the previous one:
>>>>>> - display proxy image bitmap by default
>>>>>> - display StageText only when editing
>>>>>> StageTextInputSkin/StageTextAreaSkin has been modified to use
>>>>>> this class
>>>>>>
>>>>>> - to make it easier to change StageTextInputSkin internal
>>>>> StyleableStageText component, the variable textDisplay is now of
>>>>> type
>>>> IStyleableEditText
>>>>>>
>>>>>> Behavior changes:
>>>>>> - scrolling and overlapping of text is well managed , as it
>>>>>> always uses
>>>>> the bitmap proxy, which is a Flex component: all the text inputs
>>>>> are
>>>> scrolling
>>>>>> - text occluding while editing is not managed yet, which means
>>>>>> the
>>>>> edited text may overlap other UIs. (TO BE DONE)
>>>>>>
>>>>>> Testing:
>>>>>> - tested on iPad 2 and iPad 3: TI in scrolling forms, TI in
>>> callouts
>>>>>> - *NEEDS TO BE TESTED ON ANDROID*
>>>>>> - memory consumption tests yet to be done
>>>>>> - mustella test yet to be run
>>>>>>
>>>>>>
>>>>>> Questions:
>>>>>> - Can someone please test on Android ?
>>>>>
>>>>> I can help out with Android testing. Should I wait for the nightly
>>>>> or
>>>> are these fixes on a branch? Nightly would be preferable so as to
>>>> allow
>>> more people to test the fix.
>>>>>
>>>>> Thanks,
>>>>> Om
>>>>>
>>>>>> - I have chosen to directly replace StyleableStageText.
>>>>>> Maybe I can also leave the old StyleableStageText with a
>>>>>> different name,
>>>>> so that it can be used in case there is an issue with the new one ?
>>>>> or
>>>> the other way?
>>>>>
>>>>> It would be better to keep the old one around with the same name.
>>>>> Folks
>>>> might have subclassed it to build their own implementations.
>>>>>
>>>>>> Now that it is an interface, it's easy to subclass the
>>>>> StageTextInputSkin, and override createTextDisplay() to use another
>>> class.
>>>>>>
>>>>>>
>>>>>> Maurice
>>>>>>
>>
>
Re: Mobile TextInput swipe
Posted by Alex Harui <ah...@adobe.com>.
All this reminded me that I don't think there were any serious upgrades to
FocusManager for mobile, and it is quite possible that there should be.
Maybe the whole framework in mobile-mode should ignore mouseDown and
determine if the gesture is a tap or not before assigning focus.
In FlexJS with the plug-ins, it allows for a possibility of a
touch-oriented FocusManager if one is needed.
-Alex
On 11/24/13 2:40 AM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>
>>BTW, I haven't tried any versions of your code, but I'm still surprised
>>that text selection works. I would think that trying to swipe-select a
>>word or placing the insertion cursor >at an exact spot would also be
>>problematic with the bitmap proxy in the way.
>
>You must put the focus on the text before doing any selection (that usual
>on mobile). So when you focus, the proxy is hidden and the StageText
>shown, that's why it works.
>
>>Let's step back a bit. Why is it too late to detect scrolling on
>>mousedown? The MX DataGrid tears down its item editors when scrolling
>>starts. Isn't that similar?
>The diifrence is that on Desktop, you scroll with the scroll bar, whereas
>on mobile, you scroll by "swiping" directly on the content.
>This causes issue for focusing text, but also for selecting an item in a
>list, etc...
>So there is a general mechanism that is implemented in TouchScrollingHelp
>(IIUC) that detects such behavior based on timers and movement thresholds
>and will trigger touchInteractionStart.
>
>As DarkStone says, touchInteractionStart is triggered after mousedown, so
>if the focus in bound to mouseDown, it's too late.
>
>>Does there really need to be more than one StageText instance in play?
>>When TI1 loses focus can TI2 use that same StageText instance?
>
>Actually, it does: ScrollingStageText uses an internal pool, that will
>reuse the same instance if it has the same properties (multiline, font
>size, etc).
>
>-----Message d'origine-----
>De : Alex Harui [mailto:aharui@adobe.com]
>Envoyé : dimanche 24 novembre 2013 06:38
>À : dev@flex.apache.org
>Objet : Re: Mobile TextInput swipe
>
>BTW, I haven't tried any versions of your code, but I'm still surprised
>that text selection works. I would think that trying to swipe-select a
>word or placing the insertion cursor at an exact spot would also be
>problematic with the bitmap proxy in the way.
>
>Let's step back a bit. Why is it too late to detect scrolling on
>mousedown? The MX DataGrid tears down its item editors when scrolling
>starts. Isn't that similar?
>
>Does there really need to be more than one StageText instance in play?
>When TI1 loses focus can TI2 use that same StageText instance?
>
>
>-Alex
>
>On 11/23/13 5:22 PM, "Maurice Amsellem" <ma...@systar.com>
>wrote:
>
>>Hi Team,
>>
>>I am currently working on the swipe issue with ScrollableStageText on
>>mobile and would like your advice / help
>>
>>The issue is the following: you cannot initiate a scroll/swipe by
>>touching inside a TextInput or TextArea.
>>
>>1) current situation:
>>
>>- in ScrollableStageText, the StageText is only shown when TI is in
>>focus, and is replaced by a proxy when out of focus.
>>- when scrolling, only the proxies are scrolled, so it works well.
>>
>>- when editing TI2 after TI1:
>> - TI1 receives focus out => TI1 stageText is hidden, proxy shown
>> - TI2 receives the focus on mouse down => TI2 stage text is focused
>> - stageText for TI2 is displayed (and proxy hidden)
>>
>>=> the problem, is that since focus is set on mousedown, it's too late
>>to detect scrolling, so I had to prevent it, by calling
>>event.preventDefautl() in touchInteractionStarting handler.
>>
>>2) proposed solution
>>To overcome that issue, I changed the focus to be set on MOUSE UP,
>>instead of mouse down, so that I can detection touch scroll, and
>>prevent editing.
>>
>>It works pretty well but has the following side effect :
>>When editing TI1 after TI2, the soft keyboard (which was visible),
>>lowers when pressing TI2, and raises back when releasing your finger.
>>
>>The reason for that is that is when pressing TI2:
>>- TI1 has received focus out, so its StageText it's not visible anymore
>>- TI2 did not receive focus yet, so its stageText is not visible yet =>
>>no stageText, no SoftKeyboard.
>>TI2 stage text is assigned focus only when finger is released.
>>
>>3) proposed solution to the side effect:
>>Since the only way of having a soft keyboard visible is to have an
>>active StageText, and call assingFocus() on it, I added a dummy static
>>StageText to the stage, with no text and a viewport extent of 0,0.
>>This stageText is assigned focus between the time finger is pressed, so
>>TI1 and TI2 stage texts are not visible, and the finger is released,
>>where TI2 stage text is displayed.
>>That way, the soft keyboard does not disappear.
>> ______________
>>
>>It works well, but I consider the dummy StageText as a HORRIBLE HACK.
>>So if someone has a better solution that also meets the requirements, I
>>will be happy to take it.
>>
>>Regards,
>>
>>Maurice
>>
>>-----Message d'origine-----
>>De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>Envoyé : vendredi 22 novembre 2013 11:37 À : dev@flex.apache.org Objet
>>: RE: Mobile TextInput Implementation status
>>
>>Hi,
>>I fixed the two issues that were reported in the JIRA ticket by Colins
>>Childs.
>>
>>fixed two issues reported above:
>>- two focused text inputs
>>- stage text floating above content.
>>
>>
>>Committed and pushed to develop branch
>>https://git-wip-us.apache.org/repos/asf?p=flex-sdk.git;a=commit;h=9e4bf
>>21f
>>
>>Mobile Mustella test pass:
>>- mobile/components/TextInput
>>- mobile/compoents/TextArea
>>- mobile/Softkeyboard
>>
>>
>>-----Message d'origine-----
>>De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>Envoyé : mardi 19 novembre 2013 18:18
>>À : dev@flex.apache.org
>>Objet : RE: Mobile TextInput Implementation status
>>
>>Sure. You need mobilecomponents and mobiletheme
>>
>>-----Message d'origine-----
>>De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>OmPrakash Muppirala Envoyé : mardi 19 novembre 2013 18:14 À :
>>dev@flex.apache.org Objet : RE: Mobile TextInput Implementation status
>>
>>On Nov 19, 2013 9:05 AM, "Maurice Amsellem"
>><ma...@systar.com>
>>wrote:
>>>
>>> Since jenkins is down, do you need the updated swc ?
>>
>>Which project is it? I can just compile it and drop it in the sdk
>>directory.
>>
>>Thanks,
>>Om
>>
>>>
>>> -----Message d'origine-----
>>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>> OmPrakash
>>Muppirala
>>> Envoyé : mardi 19 novembre 2013 17:55 À : dev@flex.apache.org Objet :
>>> RE: Mobile TextInput Implementation status
>>>
>>> On Nov 19, 2013 4:53 AM, "Maurice Amsellem"
>>> <ma...@systar.com>
>>> wrote:
>>> >
>>> > Fixed a few other issues
>>> > (see https://issues.apache.org/jira/browse/FLEX-33166)
>>> > > FIXED : Soft keyboard partially closes/opens when moving the
>>> > > focus
>>> from one TI to another.
>>> > > to fix the issue above, had to trigger TI edition on mousedown
>>> > > instead
>>> of mouse click (like in StyleableStageText)
>>> > > fixed bug caused by the above.
>>> >
>>> > All related mustella test pass. ( mobile/TextInput,
>>> > mobile/TextArea,
>>> mobile/SoftKeyboard)
>>> >
>>> > Om, can you please make a last test run on Android, so I can close
>>> > the
>>> ticket.
>>> >
>>>
>>> Will do, later in the night for me.
>>>
>>> Thanks,
>>> Om
>>>
>>> > Maurice
>>> >
>>> > -----Message d'origine-----
>>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>> > Envoyé : mardi 19 novembre 2013 00:36 À : dev@flex.apache.org Objet
>>> > : RE: Mobile TextInput Implementation status
>>> >
>>> > Just received results of Om testing on Android (Tested on Samsung
>>> > Galaxy
>>> SIII (Android 4.1.2) and Samsung Galaxy Tab 2 (Android 4.2.2)).
>>> > It's working fine.
>>> > Thanks you Om for the quick testing, that's really good news.
>>> >
>>> > Maurice
>>> > -----Message d'origine-----
>>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>> > Envoyé : lundi 18 novembre 2013 16:49 À : dev@flex.apache.org Objet
>>> > : Mobile TextInput Implementation status
>>> >
>>> > Memory profiling of the new skins:
>>> >
>>> > It's as expected: alloc memory = pixel width x pixel height x
>>> > 4bytes
>>> per pixel.
>>> >
>>> > First figure is for iPad , second is for iPad retina.
>>> >
>>> > - 25KB / 100 KB of bitmap memory allocated for a single line TI
>>> > with
>>> default size
>>> > - ~500KB / ~ 2 MB for a pages stuffed with text inputs / text Areas
>>> > - 3 MB / 12 MB for a full-page TA => in this case, it's better to
>>> > use the
>>> old skins.
>>> >
>>> > The bitmap is allocated while the TI is added to the stage, and
>>> > disposed
>>> when it's removed from the stage
>>> >
>>> > Maurice
>>> >
>>> > -----Message d'origine-----
>>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>> > Envoyé : lundi 18 novembre 2013 02:10 À : dev@flex.apache.org Objet
>>> > : RE: Mobile TextInput Implementation status
>>> >
>>> >
>>> > 1) to help debug if something goes wrong on Android, you can set
>>> > the
>>> following mx_internal flag:
>>> > ScrollableStageText.debugProxyImage = true;
>>> >
>>> > It will display the proxy bitmaps in magenta background.
>>> >
>>> > 2) proxy methods in ScrollableStageText has been abstracted on
>>> > purpose to
>>> DisplayObject instead of Bitmap.
>>> > This is so that one could override the class to use another proxy
>>>(eg.
>>> StyleableTextField) which is less memory consuming than bitmaps.
>>> > In wich case, you will have to override:
>>> > createProxy
>>> > updateProxy
>>> > disposeProxy
>>> >
>>> > 3) StageTextSkinBase inner textDisplay creation method is
>>> > externalized so
>>> that it can be customized.
>>> >
>>> > Example for ScrollableStageTextInputSkin:
>>> > override protected function
>>createTextDisplay():IStyleableEditableText
>>> > {
>>> > return new ScrollableStageText(multiline);
>>> > }
>>> >
>>> > That way, you can derive from existing skins, instead of monkey
>>> > patching
>>> the default skin, if you only need to change the internal editable
>>> text
>>class.
>>> >
>>> > Note also that displayText is now of type IStyleableEditableText,
>>> > instead
>>> of StyleableStageText, for the same purpose.
>>> >
>>> > Regards,
>>> >
>>> > Maurice
>>> >
>>> > -----Message d'origine-----
>>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>> > Envoyé : lundi 18 novembre 2013 01:49 À : dev@flex.apache.org Objet
>>> > : RE: Mobile TextInput Implementation status
>>> >
>>> > Run mustella tests:
>>> > Mobile/Components/TextInput
>>> > Mobile/components/TextArea
>>> > Mobile/StageText
>>> >
>>> > All pass.
>>> >
>>> > Maurice
>>> >
>>> > -----Message d'origine-----
>>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>> > Envoyé : lundi 18 novembre 2013 01:11 À : dev@flex.apache.org Objet
>>> > : RE: Mobile TextInput Implementation status
>>> >
>>> > Hi, I have committed and pushed tentative fix for
>>> https://issues.apache.org/jira/browse/FLEX-33166
>>> >
>>> > Tested on iPad 2 / 3.
>>> > Not tested on Android.
>>> > I couldn't run mustella mobile tests. For some reason, they are
>>> > broken
>>> on my machine ( says: Passes: 0 / Fails: 0).
>>> >
>>> > The new skins are now the defaults for TextInput and TextArea on
>>>mobile:
>>> >
>>> > TextInput skinClass =
>>> > spark.skins.mobile.ScrollingStageTextInputSkin
>>> > TextArea skinClass = spark.skins.mobile.ScrollingStageTextAreaSkin
>>> >
>>> > The old skins are still there, under the same name.
>>> >
>>> > Please review and tests, and this is a sensitive change...
>>> >
>>> > Your comments and feedback are welcome.
>>> >
>>> > Maurice
>>> >
>>> > -----Message d'origine-----
>>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>> > Envoyé : lundi 18 novembre 2013 00:08 À : dev@flex.apache.org Objet
>>> > : RE: Mobile TextInput Implementation status
>>> >
>>> > Founds some bugs, so I won't commit until they are fixed...
>>> >
>>> > Maurice
>>> >
>>> > -----Message d'origine-----
>>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>> > Envoyé : dimanche 17 novembre 2013 21:18 À : dev@flex.apache.org
>>>Objet :
>>> RE: Mobile TextInput Implementation status
>>> >
>>> > >I can help out with Android testing.
>>> > Thanks
>>> >
>>> > >Should I wait for the nightly or are these fixes on a branch?
>>> > >Nightly
>>> would be preferable so as to allow more people to test the fix.
>>> > I will push to the develop/ so that they be in the nightly
>>> >
>>> > >It would be better to keep the old one around with the same name.
>>> > >Folks
>>> might have subclassed it to build their own implementations.
>>> >
>>> > What about :
>>> > ScrollableStageText
>>> > ScrollableStageTextInputSkin
>>> >
>>> > For the new classes ?
>>> >
>>> > Maurice
>>> >
>>> > -----Message d'origine-----
>>> > De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>> > OmPrakash
>>> Muppirala Envoyé : dimanche 17 novembre 2013 20:27 À :
>>> dev@flex.apache.orgObjet : Re: Mobile TextInput Implementation status
>>> >
>>> > On Nov 17, 2013 10:56 AM, "Maurice Amsellem"
>>> > <ma...@systar.com>
>>> > wrote:
>>> > >
>>> > > Hi,
>>> > >
>>> > > Here is a brief status of the implementation of Mobile Text
>>> > > Input, along
>>> > with some questions:
>>> > >
>>> > > Implementation overview:
>>> > > The change is mainly on the class StyleableStageText, which now
>>> > > takes the
>>> > opposite approach than the previous one:
>>> > > - display proxy image bitmap by default
>>> > > - display StageText only when editing
>>> > > StageTextInputSkin/StageTextAreaSkin has been modified to use
>>> > > this class
>>> > >
>>> > > - to make it easier to change StageTextInputSkin internal
>>> > StyleableStageText component, the variable textDisplay is now of
>>> > type
>>> IStyleableEditText
>>> > >
>>> > > Behavior changes:
>>> > > - scrolling and overlapping of text is well managed , as it
>>> > > always uses
>>> > the bitmap proxy, which is a Flex component: all the text inputs
>>> > are
>>> scrolling
>>> > > - text occluding while editing is not managed yet, which means
>>> > > the
>>> > edited text may overlap other UIs. (TO BE DONE)
>>> > >
>>> > > Testing:
>>> > > - tested on iPad 2 and iPad 3: TI in scrolling forms, TI in
>>callouts
>>> > > - *NEEDS TO BE TESTED ON ANDROID*
>>> > > - memory consumption tests yet to be done
>>> > > - mustella test yet to be run
>>> > >
>>> > >
>>> > > Questions:
>>> > > - Can someone please test on Android ?
>>> >
>>> > I can help out with Android testing. Should I wait for the nightly
>>> > or
>>> are these fixes on a branch? Nightly would be preferable so as to
>>> allow
>>more people to test the fix.
>>> >
>>> > Thanks,
>>> > Om
>>> >
>>> > > - I have chosen to directly replace StyleableStageText.
>>> > > Maybe I can also leave the old StyleableStageText with a
>>> > > different name,
>>> > so that it can be used in case there is an issue with the new one ?
>>> > or
>>> the other way?
>>> >
>>> > It would be better to keep the old one around with the same name.
>>> > Folks
>>> might have subclassed it to build their own implementations.
>>> >
>>> > > Now that it is an interface, it's easy to subclass the
>>> > StageTextInputSkin, and override createTextDisplay() to use another
>>class.
>>> > >
>>> > >
>>> > > Maurice
>>> > >
>
RE: Mobile TextInput swipe
Posted by Maurice Amsellem <ma...@systar.com>.
>BTW, I haven't tried any versions of your code, but I'm still surprised that text selection works. I would think that trying to swipe-select a word or placing the insertion cursor >at an exact spot would also be problematic with the bitmap proxy in the way.
You must put the focus on the text before doing any selection (that usual on mobile). So when you focus, the proxy is hidden and the StageText shown, that's why it works.
>Let's step back a bit. Why is it too late to detect scrolling on mousedown? The MX DataGrid tears down its item editors when scrolling starts. Isn't that similar?
The diifrence is that on Desktop, you scroll with the scroll bar, whereas on mobile, you scroll by "swiping" directly on the content.
This causes issue for focusing text, but also for selecting an item in a list, etc...
So there is a general mechanism that is implemented in TouchScrollingHelp (IIUC) that detects such behavior based on timers and movement thresholds and will trigger touchInteractionStart.
As DarkStone says, touchInteractionStart is triggered after mousedown, so if the focus in bound to mouseDown, it's too late.
>Does there really need to be more than one StageText instance in play?
>When TI1 loses focus can TI2 use that same StageText instance?
Actually, it does: ScrollingStageText uses an internal pool, that will reuse the same instance if it has the same properties (multiline, font size, etc).
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com]
Envoyé : dimanche 24 novembre 2013 06:38
À : dev@flex.apache.org
Objet : Re: Mobile TextInput swipe
BTW, I haven't tried any versions of your code, but I'm still surprised that text selection works. I would think that trying to swipe-select a word or placing the insertion cursor at an exact spot would also be problematic with the bitmap proxy in the way.
Let's step back a bit. Why is it too late to detect scrolling on mousedown? The MX DataGrid tears down its item editors when scrolling starts. Isn't that similar?
Does there really need to be more than one StageText instance in play?
When TI1 loses focus can TI2 use that same StageText instance?
-Alex
On 11/23/13 5:22 PM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>Hi Team,
>
>I am currently working on the swipe issue with ScrollableStageText on
>mobile and would like your advice / help
>
>The issue is the following: you cannot initiate a scroll/swipe by
>touching inside a TextInput or TextArea.
>
>1) current situation:
>
>- in ScrollableStageText, the StageText is only shown when TI is in
>focus, and is replaced by a proxy when out of focus.
>- when scrolling, only the proxies are scrolled, so it works well.
>
>- when editing TI2 after TI1:
> - TI1 receives focus out => TI1 stageText is hidden, proxy shown
> - TI2 receives the focus on mouse down => TI2 stage text is focused
> - stageText for TI2 is displayed (and proxy hidden)
>
>=> the problem, is that since focus is set on mousedown, it's too late
>to detect scrolling, so I had to prevent it, by calling
>event.preventDefautl() in touchInteractionStarting handler.
>
>2) proposed solution
>To overcome that issue, I changed the focus to be set on MOUSE UP,
>instead of mouse down, so that I can detection touch scroll, and
>prevent editing.
>
>It works pretty well but has the following side effect :
>When editing TI1 after TI2, the soft keyboard (which was visible),
>lowers when pressing TI2, and raises back when releasing your finger.
>
>The reason for that is that is when pressing TI2:
>- TI1 has received focus out, so its StageText it's not visible anymore
>- TI2 did not receive focus yet, so its stageText is not visible yet =>
>no stageText, no SoftKeyboard.
>TI2 stage text is assigned focus only when finger is released.
>
>3) proposed solution to the side effect:
>Since the only way of having a soft keyboard visible is to have an
>active StageText, and call assingFocus() on it, I added a dummy static
>StageText to the stage, with no text and a viewport extent of 0,0.
>This stageText is assigned focus between the time finger is pressed, so
>TI1 and TI2 stage texts are not visible, and the finger is released,
>where TI2 stage text is displayed.
>That way, the soft keyboard does not disappear.
> ______________
>
>It works well, but I consider the dummy StageText as a HORRIBLE HACK.
>So if someone has a better solution that also meets the requirements, I
>will be happy to take it.
>
>Regards,
>
>Maurice
>
>-----Message d'origine-----
>De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>Envoyé : vendredi 22 novembre 2013 11:37 À : dev@flex.apache.org Objet
>: RE: Mobile TextInput Implementation status
>
>Hi,
>I fixed the two issues that were reported in the JIRA ticket by Colins
>Childs.
>
>fixed two issues reported above:
>- two focused text inputs
>- stage text floating above content.
>
>
>Committed and pushed to develop branch
>https://git-wip-us.apache.org/repos/asf?p=flex-sdk.git;a=commit;h=9e4bf
>21f
>
>Mobile Mustella test pass:
>- mobile/components/TextInput
>- mobile/compoents/TextArea
>- mobile/Softkeyboard
>
>
>-----Message d'origine-----
>De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>Envoyé : mardi 19 novembre 2013 18:18
>À : dev@flex.apache.org
>Objet : RE: Mobile TextInput Implementation status
>
>Sure. You need mobilecomponents and mobiletheme
>
>-----Message d'origine-----
>De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>OmPrakash Muppirala Envoyé : mardi 19 novembre 2013 18:14 À :
>dev@flex.apache.org Objet : RE: Mobile TextInput Implementation status
>
>On Nov 19, 2013 9:05 AM, "Maurice Amsellem"
><ma...@systar.com>
>wrote:
>>
>> Since jenkins is down, do you need the updated swc ?
>
>Which project is it? I can just compile it and drop it in the sdk
>directory.
>
>Thanks,
>Om
>
>>
>> -----Message d'origine-----
>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>> OmPrakash
>Muppirala
>> Envoyé : mardi 19 novembre 2013 17:55 À : dev@flex.apache.org Objet :
>> RE: Mobile TextInput Implementation status
>>
>> On Nov 19, 2013 4:53 AM, "Maurice Amsellem"
>> <ma...@systar.com>
>> wrote:
>> >
>> > Fixed a few other issues
>> > (see https://issues.apache.org/jira/browse/FLEX-33166)
>> > > FIXED : Soft keyboard partially closes/opens when moving the
>> > > focus
>> from one TI to another.
>> > > to fix the issue above, had to trigger TI edition on mousedown
>> > > instead
>> of mouse click (like in StyleableStageText)
>> > > fixed bug caused by the above.
>> >
>> > All related mustella test pass. ( mobile/TextInput,
>> > mobile/TextArea,
>> mobile/SoftKeyboard)
>> >
>> > Om, can you please make a last test run on Android, so I can close
>> > the
>> ticket.
>> >
>>
>> Will do, later in the night for me.
>>
>> Thanks,
>> Om
>>
>> > Maurice
>> >
>> > -----Message d'origine-----
>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>> > Envoyé : mardi 19 novembre 2013 00:36 À : dev@flex.apache.org Objet
>> > : RE: Mobile TextInput Implementation status
>> >
>> > Just received results of Om testing on Android (Tested on Samsung
>> > Galaxy
>> SIII (Android 4.1.2) and Samsung Galaxy Tab 2 (Android 4.2.2)).
>> > It's working fine.
>> > Thanks you Om for the quick testing, that's really good news.
>> >
>> > Maurice
>> > -----Message d'origine-----
>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>> > Envoyé : lundi 18 novembre 2013 16:49 À : dev@flex.apache.org Objet
>> > : Mobile TextInput Implementation status
>> >
>> > Memory profiling of the new skins:
>> >
>> > It's as expected: alloc memory = pixel width x pixel height x
>> > 4bytes
>> per pixel.
>> >
>> > First figure is for iPad , second is for iPad retina.
>> >
>> > - 25KB / 100 KB of bitmap memory allocated for a single line TI
>> > with
>> default size
>> > - ~500KB / ~ 2 MB for a pages stuffed with text inputs / text Areas
>> > - 3 MB / 12 MB for a full-page TA => in this case, it's better to
>> > use the
>> old skins.
>> >
>> > The bitmap is allocated while the TI is added to the stage, and
>> > disposed
>> when it's removed from the stage
>> >
>> > Maurice
>> >
>> > -----Message d'origine-----
>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>> > Envoyé : lundi 18 novembre 2013 02:10 À : dev@flex.apache.org Objet
>> > : RE: Mobile TextInput Implementation status
>> >
>> >
>> > 1) to help debug if something goes wrong on Android, you can set
>> > the
>> following mx_internal flag:
>> > ScrollableStageText.debugProxyImage = true;
>> >
>> > It will display the proxy bitmaps in magenta background.
>> >
>> > 2) proxy methods in ScrollableStageText has been abstracted on
>> > purpose to
>> DisplayObject instead of Bitmap.
>> > This is so that one could override the class to use another proxy
>>(eg.
>> StyleableTextField) which is less memory consuming than bitmaps.
>> > In wich case, you will have to override:
>> > createProxy
>> > updateProxy
>> > disposeProxy
>> >
>> > 3) StageTextSkinBase inner textDisplay creation method is
>> > externalized so
>> that it can be customized.
>> >
>> > Example for ScrollableStageTextInputSkin:
>> > override protected function
>createTextDisplay():IStyleableEditableText
>> > {
>> > return new ScrollableStageText(multiline);
>> > }
>> >
>> > That way, you can derive from existing skins, instead of monkey
>> > patching
>> the default skin, if you only need to change the internal editable
>> text
>class.
>> >
>> > Note also that displayText is now of type IStyleableEditableText,
>> > instead
>> of StyleableStageText, for the same purpose.
>> >
>> > Regards,
>> >
>> > Maurice
>> >
>> > -----Message d'origine-----
>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>> > Envoyé : lundi 18 novembre 2013 01:49 À : dev@flex.apache.org Objet
>> > : RE: Mobile TextInput Implementation status
>> >
>> > Run mustella tests:
>> > Mobile/Components/TextInput
>> > Mobile/components/TextArea
>> > Mobile/StageText
>> >
>> > All pass.
>> >
>> > Maurice
>> >
>> > -----Message d'origine-----
>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>> > Envoyé : lundi 18 novembre 2013 01:11 À : dev@flex.apache.org Objet
>> > : RE: Mobile TextInput Implementation status
>> >
>> > Hi, I have committed and pushed tentative fix for
>> https://issues.apache.org/jira/browse/FLEX-33166
>> >
>> > Tested on iPad 2 / 3.
>> > Not tested on Android.
>> > I couldn't run mustella mobile tests. For some reason, they are
>> > broken
>> on my machine ( says: Passes: 0 / Fails: 0).
>> >
>> > The new skins are now the defaults for TextInput and TextArea on
>>mobile:
>> >
>> > TextInput skinClass =
>> > spark.skins.mobile.ScrollingStageTextInputSkin
>> > TextArea skinClass = spark.skins.mobile.ScrollingStageTextAreaSkin
>> >
>> > The old skins are still there, under the same name.
>> >
>> > Please review and tests, and this is a sensitive change...
>> >
>> > Your comments and feedback are welcome.
>> >
>> > Maurice
>> >
>> > -----Message d'origine-----
>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>> > Envoyé : lundi 18 novembre 2013 00:08 À : dev@flex.apache.org Objet
>> > : RE: Mobile TextInput Implementation status
>> >
>> > Founds some bugs, so I won't commit until they are fixed...
>> >
>> > Maurice
>> >
>> > -----Message d'origine-----
>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>> > Envoyé : dimanche 17 novembre 2013 21:18 À : dev@flex.apache.org
>>Objet :
>> RE: Mobile TextInput Implementation status
>> >
>> > >I can help out with Android testing.
>> > Thanks
>> >
>> > >Should I wait for the nightly or are these fixes on a branch?
>> > >Nightly
>> would be preferable so as to allow more people to test the fix.
>> > I will push to the develop/ so that they be in the nightly
>> >
>> > >It would be better to keep the old one around with the same name.
>> > >Folks
>> might have subclassed it to build their own implementations.
>> >
>> > What about :
>> > ScrollableStageText
>> > ScrollableStageTextInputSkin
>> >
>> > For the new classes ?
>> >
>> > Maurice
>> >
>> > -----Message d'origine-----
>> > De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>> > OmPrakash
>> Muppirala Envoyé : dimanche 17 novembre 2013 20:27 À :
>> dev@flex.apache.orgObjet : Re: Mobile TextInput Implementation status
>> >
>> > On Nov 17, 2013 10:56 AM, "Maurice Amsellem"
>> > <ma...@systar.com>
>> > wrote:
>> > >
>> > > Hi,
>> > >
>> > > Here is a brief status of the implementation of Mobile Text
>> > > Input, along
>> > with some questions:
>> > >
>> > > Implementation overview:
>> > > The change is mainly on the class StyleableStageText, which now
>> > > takes the
>> > opposite approach than the previous one:
>> > > - display proxy image bitmap by default
>> > > - display StageText only when editing
>> > > StageTextInputSkin/StageTextAreaSkin has been modified to use
>> > > this class
>> > >
>> > > - to make it easier to change StageTextInputSkin internal
>> > StyleableStageText component, the variable textDisplay is now of
>> > type
>> IStyleableEditText
>> > >
>> > > Behavior changes:
>> > > - scrolling and overlapping of text is well managed , as it
>> > > always uses
>> > the bitmap proxy, which is a Flex component: all the text inputs
>> > are
>> scrolling
>> > > - text occluding while editing is not managed yet, which means
>> > > the
>> > edited text may overlap other UIs. (TO BE DONE)
>> > >
>> > > Testing:
>> > > - tested on iPad 2 and iPad 3: TI in scrolling forms, TI in
>callouts
>> > > - *NEEDS TO BE TESTED ON ANDROID*
>> > > - memory consumption tests yet to be done
>> > > - mustella test yet to be run
>> > >
>> > >
>> > > Questions:
>> > > - Can someone please test on Android ?
>> >
>> > I can help out with Android testing. Should I wait for the nightly
>> > or
>> are these fixes on a branch? Nightly would be preferable so as to
>> allow
>more people to test the fix.
>> >
>> > Thanks,
>> > Om
>> >
>> > > - I have chosen to directly replace StyleableStageText.
>> > > Maybe I can also leave the old StyleableStageText with a
>> > > different name,
>> > so that it can be used in case there is an issue with the new one ?
>> > or
>> the other way?
>> >
>> > It would be better to keep the old one around with the same name.
>> > Folks
>> might have subclassed it to build their own implementations.
>> >
>> > > Now that it is an interface, it's easy to subclass the
>> > StageTextInputSkin, and override createTextDisplay() to use another
>class.
>> > >
>> > >
>> > > Maurice
>> > >
RE: Mobile TextInput swipe
Posted by Maurice Amsellem <ma...@systar.com>.
>1. touchInteractionStart dispatched before mouseDown, so it's better to listen for mouseUp to show StageText instance, otherwise it will definitely interrupt scrolling of the >flash display list.
Agree.
>2. Use only one StageText instance sounds like a brilliant idea, but if you put 10 ScrollableStageText on a screen, all in a same viewport, every ScrollableStageText has a long >text and require multiline displaying, the rendering problem will occur:
>Cuz you need to show the StageText instance first to help you layout the text, and then use bitmap proxy to replace it, if you use only one StageText instance to go for 10 >ScrollableStageText, rendering has to be slower than use 10 StageText instance.
This is already how it works, SST maintains a pool of ST and will reuse the same instance if it has the same characteristics (font, multiline, etc...).
You don't need to show to StageText to make a bitmap of it, it works even when not visible.
I didn't notice any performance issue related to that yet.
>3. Anyway, I'm currently working on the StageText issue too, mine is called "VisualStageText"(VST), it extends SpriteVisualElement and implements IEditableText, has a >private var stageText:StageText.
>My VST will not only solve the scrolling issues, but also support MXML layout, you can use it as a skin part for the MXML skin of the Spark version TextInput or TextArea.
This is also how ScrollableStageText works. It derives from UIComponent, and can be used as part in ScrollingStageTextInputSkin / ScrollingStageTextAreaSkin mxml skins.
It's the textDisplay skin part.
You can check / test the code in github, except for the part we are talking about, which is not committed yet.
Will you be able to share your code as well?
Maurice
-----Message d'origine-----
De : DarkStone [mailto:DarkStone@163.com]
Envoyé : dimanche 24 novembre 2013 09:35
À : dev@flex.apache.org
Objet : Re: Mobile TextInput swipe
Hi all,
1. touchInteractionStart dispatched before mouseDown, so it's better to listen for mouseUp to show StageText instance, otherwise it will definitely interrupt scrolling of the flash display list.
2. Use only one StageText instance sounds like a brilliant idea, but if you put 10 ScrollableStageText on a screen, all in a same viewport, every ScrollableStageText has a long text and require multiline displaying, the rendering problem will occur:
Cuz you need to show the StageText instance first to help you layout the text, and then use bitmap proxy to replace it, if you use only one StageText instance to go for 10 ScrollableStageText, rendering has to be slower than use 10 StageText instance.
Anyway, I'm currently working on the StageText issue too, mine is called "VisualStageText"(VST), it extends SpriteVisualElement and implements IEditableText, has a private var stageText:StageText.
My VST will not only solve the scrolling issues, but also support MXML layout, you can use it as a skin part for the MXML skin of the Spark version TextInput or TextArea. My VST is half way to finish, I'll keep you guys posted :)
Sent from DarkStone's iPhone
2013-11-24
> 在 2013年11月24日，13:37，Alex Harui <ah...@adobe.com> 写道：
>
> BTW, I haven't tried any versions of your code, but I'm still
> surprised that text selection works. I would think that trying to
> swipe-select a word or placing the insertion cursor at an exact spot
> would also be problematic with the bitmap proxy in the way.
>
> Let's step back a bit. Why is it too late to detect scrolling on
> mousedown? The MX DataGrid tears down its item editors when scrolling
> starts. Isn't that similar?
>
> Does there really need to be more than one StageText instance in play?
> When TI1 loses focus can TI2 use that same StageText instance?
>
>
> -Alex
>
> On 11/23/13 5:22 PM, "Maurice Amsellem" <ma...@systar.com>
> wrote:
>
>> Hi Team,
>>
>> I am currently working on the swipe issue with ScrollableStageText on
>> mobile and would like your advice / help
>>
>> The issue is the following: you cannot initiate a scroll/swipe by
>> touching inside a TextInput or TextArea.
>>
>> 1) current situation:
>>
>> - in ScrollableStageText, the StageText is only shown when TI is in
>> focus, and is replaced by a proxy when out of focus.
>> - when scrolling, only the proxies are scrolled, so it works well.
>>
>> - when editing TI2 after TI1:
>> - TI1 receives focus out => TI1 stageText is hidden, proxy shown
>> - TI2 receives the focus on mouse down => TI2 stage text is focused
>> - stageText for TI2 is displayed (and proxy hidden)
>>
>> => the problem, is that since focus is set on mousedown, it's too
>> late to detect scrolling, so I had to prevent it, by calling
>> event.preventDefautl() in touchInteractionStarting handler.
>>
>> 2) proposed solution
>> To overcome that issue, I changed the focus to be set on MOUSE UP,
>> instead of mouse down, so that I can detection touch scroll, and
>> prevent editing.
>>
>> It works pretty well but has the following side effect :
>> When editing TI1 after TI2, the soft keyboard (which was visible),
>> lowers when pressing TI2, and raises back when releasing your finger.
>>
>> The reason for that is that is when pressing TI2:
>> - TI1 has received focus out, so its StageText it's not visible
>> anymore
>> - TI2 did not receive focus yet, so its stageText is not visible yet
>> => no stageText, no SoftKeyboard.
>> TI2 stage text is assigned focus only when finger is released.
>>
>> 3) proposed solution to the side effect:
>> Since the only way of having a soft keyboard visible is to have an
>> active StageText, and call assingFocus() on it, I added a dummy
>> static StageText to the stage, with no text and a viewport extent of
>> 0,0.
>> This stageText is assigned focus between the time finger is pressed,
>> so
>> TI1 and TI2 stage texts are not visible, and the finger is released,
>> where TI2 stage text is displayed.
>> That way, the soft keyboard does not disappear.
>> ______________
>>
>> It works well, but I consider the dummy StageText as a HORRIBLE HACK.
>> So if someone has a better solution that also meets the requirements,
>> I will be happy to take it.
>>
>> Regards,
>>
>> Maurice
>>
>> -----Message d'origine-----
>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>> Envoyé : vendredi 22 novembre 2013 11:37 À : dev@flex.apache.org
>> Objet : RE: Mobile TextInput Implementation status
>>
>> Hi,
>> I fixed the two issues that were reported in the JIRA ticket by
>> Colins Childs.
>>
>> fixed two issues reported above:
>> - two focused text inputs
>> - stage text floating above content.
>>
>>
>> Committed and pushed to develop branch
>> https://git-wip-us.apache.org/repos/asf?p=flex-sdk.git;a=commit;h=9e4
>> bf21f
>>
>> Mobile Mustella test pass:
>> - mobile/components/TextInput
>> - mobile/compoents/TextArea
>> - mobile/Softkeyboard
>>
>>
>> -----Message d'origine-----
>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>> Envoyé : mardi 19 novembre 2013 18:18 À : dev@flex.apache.org Objet :
>> RE: Mobile TextInput Implementation status
>>
>> Sure. You need mobilecomponents and mobiletheme
>>
>> -----Message d'origine-----
>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>> OmPrakash Muppirala Envoyé : mardi 19 novembre 2013 18:14 À :
>> dev@flex.apache.org Objet : RE: Mobile TextInput Implementation
>> status
>>
>> On Nov 19, 2013 9:05 AM, "Maurice Amsellem"
>> <ma...@systar.com>
>> wrote:
>>>
>>> Since jenkins is down, do you need the updated swc ?
>>
>> Which project is it? I can just compile it and drop it in the sdk
>> directory.
>>
>> Thanks,
>> Om
>>
>>>
>>> -----Message d'origine-----
>>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>> OmPrakash
>> Muppirala
>>> Envoyé : mardi 19 novembre 2013 17:55 À : dev@flex.apache.org Objet
>>> : RE: Mobile TextInput Implementation status
>>>
>>> On Nov 19, 2013 4:53 AM, "Maurice Amsellem"
>>> <ma...@systar.com>
>>> wrote:
>>>>
>>>> Fixed a few other issues
>>>> (see https://issues.apache.org/jira/browse/FLEX-33166)
>>>>> FIXED : Soft keyboard partially closes/opens when moving the
>>>>> focus
>>> from one TI to another.
>>>>> to fix the issue above, had to trigger TI edition on mousedown
>>>>> instead
>>> of mouse click (like in StyleableStageText)
>>>>> fixed bug caused by the above.
>>>>
>>>> All related mustella test pass. ( mobile/TextInput,
>>>> mobile/TextArea,
>>> mobile/SoftKeyboard)
>>>>
>>>> Om, can you please make a last test run on Android, so I can close
>>>> the
>>> ticket.
>>>
>>> Will do, later in the night for me.
>>>
>>> Thanks,
>>> Om
>>>
>>>> Maurice
>>>>
>>>> -----Message d'origine-----
>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> Envoyé : mardi 19 novembre 2013 00:36 À : dev@flex.apache.org Objet
>>>> : RE: Mobile TextInput Implementation status
>>>>
>>>> Just received results of Om testing on Android (Tested on Samsung
>>>> Galaxy
>>> SIII (Android 4.1.2) and Samsung Galaxy Tab 2 (Android 4.2.2)).
>>>> It's working fine.
>>>> Thanks you Om for the quick testing, that's really good news.
>>>>
>>>> Maurice
>>>> -----Message d'origine-----
>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> Envoyé : lundi 18 novembre 2013 16:49 À : dev@flex.apache.org Objet
>>>> : Mobile TextInput Implementation status
>>>>
>>>> Memory profiling of the new skins:
>>>>
>>>> It's as expected: alloc memory = pixel width x pixel height x
>>>> 4bytes
>>> per pixel.
>>>>
>>>> First figure is for iPad , second is for iPad retina.
>>>>
>>>> - 25KB / 100 KB of bitmap memory allocated for a single line TI
>>>> with
>>> default size
>>>> - ~500KB / ~ 2 MB for a pages stuffed with text inputs / text Areas
>>>> - 3 MB / 12 MB for a full-page TA => in this case, it's better to
>>>> use the
>>> old skins.
>>>>
>>>> The bitmap is allocated while the TI is added to the stage, and
>>>> disposed
>>> when it's removed from the stage
>>>>
>>>> Maurice
>>>>
>>>> -----Message d'origine-----
>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> Envoyé : lundi 18 novembre 2013 02:10 À : dev@flex.apache.org Objet
>>>> : RE: Mobile TextInput Implementation status
>>>>
>>>>
>>>> 1) to help debug if something goes wrong on Android, you can set
>>>> the
>>> following mx_internal flag:
>>>> ScrollableStageText.debugProxyImage = true;
>>>>
>>>> It will display the proxy bitmaps in magenta background.
>>>>
>>>> 2) proxy methods in ScrollableStageText has been abstracted on
>>>> purpose to
>>> DisplayObject instead of Bitmap.
>>>> This is so that one could override the class to use another proxy
>>> (eg.
>>> StyleableTextField) which is less memory consuming than bitmaps.
>>>> In wich case, you will have to override:
>>>> createProxy
>>>> updateProxy
>>>> disposeProxy
>>>>
>>>> 3) StageTextSkinBase inner textDisplay creation method is
>>>> externalized so
>>> that it can be customized.
>>>>
>>>> Example for ScrollableStageTextInputSkin:
>>>> override protected function
>> createTextDisplay():IStyleableEditableText
>>>> {
>>>> return new ScrollableStageText(multiline);
>>>> }
>>>>
>>>> That way, you can derive from existing skins, instead of monkey
>>>> patching
>>> the default skin, if you only need to change the internal editable
>>> text
>> class.
>>>>
>>>> Note also that displayText is now of type IStyleableEditableText,
>>>> instead
>>> of StyleableStageText, for the same purpose.
>>>>
>>>> Regards,
>>>>
>>>> Maurice
>>>>
>>>> -----Message d'origine-----
>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> Envoyé : lundi 18 novembre 2013 01:49 À : dev@flex.apache.org Objet
>>>> : RE: Mobile TextInput Implementation status
>>>>
>>>> Run mustella tests:
>>>> Mobile/Components/TextInput
>>>> Mobile/components/TextArea
>>>> Mobile/StageText
>>>>
>>>> All pass.
>>>>
>>>> Maurice
>>>>
>>>> -----Message d'origine-----
>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> Envoyé : lundi 18 novembre 2013 01:11 À : dev@flex.apache.org Objet
>>>> : RE: Mobile TextInput Implementation status
>>>>
>>>> Hi, I have committed and pushed tentative fix for
>>> https://issues.apache.org/jira/browse/FLEX-33166
>>>>
>>>> Tested on iPad 2 / 3.
>>>> Not tested on Android.
>>>> I couldn't run mustella mobile tests. For some reason, they are
>>>> broken
>>> on my machine ( says: Passes: 0 / Fails: 0).
>>>>
>>>> The new skins are now the defaults for TextInput and TextArea on
>>> mobile:
>>>>
>>>> TextInput skinClass =
>>>> spark.skins.mobile.ScrollingStageTextInputSkin
>>>> TextArea skinClass = spark.skins.mobile.ScrollingStageTextAreaSkin
>>>>
>>>> The old skins are still there, under the same name.
>>>>
>>>> Please review and tests, and this is a sensitive change...
>>>>
>>>> Your comments and feedback are welcome.
>>>>
>>>> Maurice
>>>>
>>>> -----Message d'origine-----
>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> Envoyé : lundi 18 novembre 2013 00:08 À : dev@flex.apache.org Objet
>>>> : RE: Mobile TextInput Implementation status
>>>>
>>>> Founds some bugs, so I won't commit until they are fixed...
>>>>
>>>> Maurice
>>>>
>>>> -----Message d'origine-----
>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> Envoyé : dimanche 17 novembre 2013 21:18 À : dev@flex.apache.org
>>> Objet :
>>> RE: Mobile TextInput Implementation status
>>>>
>>>>> I can help out with Android testing.
>>>> Thanks
>>>>
>>>>> Should I wait for the nightly or are these fixes on a branch?
>>>>> Nightly
>>> would be preferable so as to allow more people to test the fix.
>>>> I will push to the develop/ so that they be in the nightly
>>>>
>>>>> It would be better to keep the old one around with the same name.
>>>>> Folks
>>> might have subclassed it to build their own implementations.
>>>>
>>>> What about :
>>>> ScrollableStageText
>>>> ScrollableStageTextInputSkin
>>>>
>>>> For the new classes ?
>>>>
>>>> Maurice
>>>>
>>>> -----Message d'origine-----
>>>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>>> OmPrakash
>>> Muppirala Envoyé : dimanche 17 novembre 2013 20:27 À :
>>> dev@flex.apache.orgObjet : Re: Mobile TextInput Implementation
>>> status
>>>>
>>>> On Nov 17, 2013 10:56 AM, "Maurice Amsellem"
>>>> <ma...@systar.com>
>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Here is a brief status of the implementation of Mobile Text Input,
>>>>> along
>>>> with some questions:
>>>>>
>>>>> Implementation overview:
>>>>> The change is mainly on the class StyleableStageText, which now
>>>>> takes the
>>>> opposite approach than the previous one:
>>>>> - display proxy image bitmap by default
>>>>> - display StageText only when editing
>>>>> StageTextInputSkin/StageTextAreaSkin has been modified to use this
>>>>> class
>>>>>
>>>>> - to make it easier to change StageTextInputSkin internal
>>>> StyleableStageText component, the variable textDisplay is now of
>>>> type
>>> IStyleableEditText
>>>>>
>>>>> Behavior changes:
>>>>> - scrolling and overlapping of text is well managed , as it
>>>>> always uses
>>>> the bitmap proxy, which is a Flex component: all the text inputs
>>>> are
>>> scrolling
>>>>> - text occluding while editing is not managed yet, which means
>>>>> the
>>>> edited text may overlap other UIs. (TO BE DONE)
>>>>>
>>>>> Testing:
>>>>> - tested on iPad 2 and iPad 3: TI in scrolling forms, TI in
>> callouts
>>>>> - *NEEDS TO BE TESTED ON ANDROID*
>>>>> - memory consumption tests yet to be done
>>>>> - mustella test yet to be run
>>>>>
>>>>>
>>>>> Questions:
>>>>> - Can someone please test on Android ?
>>>>
>>>> I can help out with Android testing. Should I wait for the nightly
>>>> or
>>> are these fixes on a branch? Nightly would be preferable so as to
>>> allow
>> more people to test the fix.
>>>>
>>>> Thanks,
>>>> Om
>>>>
>>>>> - I have chosen to directly replace StyleableStageText.
>>>>> Maybe I can also leave the old StyleableStageText with a different
>>>>> name,
>>>> so that it can be used in case there is an issue with the new one ?
>>>> or
>>> the other way?
>>>>
>>>> It would be better to keep the old one around with the same name.
>>>> Folks
>>> might have subclassed it to build their own implementations.
>>>>
>>>>> Now that it is an interface, it's easy to subclass the
>>>> StageTextInputSkin, and override createTextDisplay() to use another
>> class.
>>>>>
>>>>>
>>>>> Maurice
>
Re: Mobile TextInput swipe
Posted by DarkStone <Da...@163.com>.
Hi all,
1. touchInteractionStart dispatched before mouseDown, so it's better to listen for mouseUp to show StageText instance, otherwise it will definitely interrupt scrolling of the flash display list.
2. Use only one StageText instance sounds like a brilliant idea, but if you put 10 ScrollableStageText on a screen, all in a same viewport, every ScrollableStageText has a long text and require multiline displaying, the rendering problem will occur:
Cuz you need to show the StageText instance first to help you layout the text, and then use bitmap proxy to replace it, if you use only one StageText instance to go for 10 ScrollableStageText, rendering has to be slower than use 10 StageText instance.
Anyway, I'm currently working on the StageText issue too, mine is called "VisualStageText"(VST), it extends SpriteVisualElement and implements IEditableText, has a private var stageText:StageText.
My VST will not only solve the scrolling issues, but also support MXML layout, you can use it as a skin part for the MXML skin of the Spark version TextInput or TextArea. My VST is half way to finish, I'll keep you guys posted :)
Sent from DarkStone's iPhone
2013-11-24
> 在 2013年11月24日，13:37，Alex Harui <ah...@adobe.com> 写道：
>
> BTW, I haven't tried any versions of your code, but I'm still surprised
> that text selection works. I would think that trying to swipe-select a
> word or placing the insertion cursor at an exact spot would also be
> problematic with the bitmap proxy in the way.
>
> Let's step back a bit. Why is it too late to detect scrolling on
> mousedown? The MX DataGrid tears down its item editors when scrolling
> starts. Isn't that similar?
>
> Does there really need to be more than one StageText instance in play?
> When TI1 loses focus can TI2 use that same StageText instance?
>
>
> -Alex
>
> On 11/23/13 5:22 PM, "Maurice Amsellem" <ma...@systar.com>
> wrote:
>
>> Hi Team,
>>
>> I am currently working on the swipe issue with ScrollableStageText on
>> mobile and would like your advice / help
>>
>> The issue is the following: you cannot initiate a scroll/swipe by
>> touching inside a TextInput or TextArea.
>>
>> 1) current situation:
>>
>> - in ScrollableStageText, the StageText is only shown when TI is in
>> focus, and is replaced by a proxy when out of focus.
>> - when scrolling, only the proxies are scrolled, so it works well.
>>
>> - when editing TI2 after TI1:
>> - TI1 receives focus out => TI1 stageText is hidden, proxy shown
>> - TI2 receives the focus on mouse down => TI2 stage text is focused
>> - stageText for TI2 is displayed (and proxy hidden)
>>
>> => the problem, is that since focus is set on mousedown, it's too late to
>> detect scrolling,
>> so I had to prevent it, by calling event.preventDefautl() in
>> touchInteractionStarting handler.
>>
>> 2) proposed solution
>> To overcome that issue, I changed the focus to be set on MOUSE UP,
>> instead of mouse down, so that I can detection touch scroll, and prevent
>> editing.
>>
>> It works pretty well but has the following side effect :
>> When editing TI1 after TI2, the soft keyboard (which was visible), lowers
>> when pressing TI2, and raises back when releasing your finger.
>>
>> The reason for that is that is when pressing TI2:
>> - TI1 has received focus out, so its StageText it's not visible anymore
>> - TI2 did not receive focus yet, so its stageText is not visible yet
>> => no stageText, no SoftKeyboard.
>> TI2 stage text is assigned focus only when finger is released.
>>
>> 3) proposed solution to the side effect:
>> Since the only way of having a soft keyboard visible is to have an active
>> StageText, and call assingFocus() on it,
>> I added a dummy static StageText to the stage, with no text and a
>> viewport extent of 0,0.
>> This stageText is assigned focus between the time finger is pressed, so
>> TI1 and TI2 stage texts are not visible, and the finger is released,
>> where TI2 stage text is displayed.
>> That way, the soft keyboard does not disappear.
>> ______________
>>
>> It works well, but I consider the dummy StageText as a HORRIBLE HACK.
>> So if someone has a better solution that also meets the requirements, I
>> will be happy to take it.
>>
>> Regards,
>>
>> Maurice
>>
>> -----Message d'origine-----
>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>> Envoyé : vendredi 22 novembre 2013 11:37
>> À : dev@flex.apache.org
>> Objet : RE: Mobile TextInput Implementation status
>>
>> Hi,
>> I fixed the two issues that were reported in the JIRA ticket by Colins
>> Childs.
>>
>> fixed two issues reported above:
>> - two focused text inputs
>> - stage text floating above content.
>>
>>
>> Committed and pushed to develop branch
>> https://git-wip-us.apache.org/repos/asf?p=flex-sdk.git;a=commit;h=9e4bf21f
>>
>> Mobile Mustella test pass:
>> - mobile/components/TextInput
>> - mobile/compoents/TextArea
>> - mobile/Softkeyboard
>>
>>
>> -----Message d'origine-----
>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>> Envoyé : mardi 19 novembre 2013 18:18
>> À : dev@flex.apache.org
>> Objet : RE: Mobile TextInput Implementation status
>>
>> Sure. You need mobilecomponents and mobiletheme
>>
>> -----Message d'origine-----
>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de OmPrakash
>> Muppirala Envoyé : mardi 19 novembre 2013 18:14 À : dev@flex.apache.org
>> Objet : RE: Mobile TextInput Implementation status
>>
>> On Nov 19, 2013 9:05 AM, "Maurice Amsellem" <ma...@systar.com>
>> wrote:
>>>
>>> Since jenkins is down, do you need the updated swc ?
>>
>> Which project is it? I can just compile it and drop it in the sdk
>> directory.
>>
>> Thanks,
>> Om
>>
>>>
>>> -----Message d'origine-----
>>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>> OmPrakash
>> Muppirala
>>> Envoyé : mardi 19 novembre 2013 17:55
>>> À : dev@flex.apache.org
>>> Objet : RE: Mobile TextInput Implementation status
>>>
>>> On Nov 19, 2013 4:53 AM, "Maurice Amsellem"
>>> <ma...@systar.com>
>>> wrote:
>>>>
>>>> Fixed a few other issues
>>>> (see https://issues.apache.org/jira/browse/FLEX-33166)
>>>>> FIXED : Soft keyboard partially closes/opens when moving the
>>>>> focus
>>> from one TI to another.
>>>>> to fix the issue above, had to trigger TI edition on mousedown
>>>>> instead
>>> of mouse click (like in StyleableStageText)
>>>>> fixed bug caused by the above.
>>>>
>>>> All related mustella test pass. ( mobile/TextInput, mobile/TextArea,
>>> mobile/SoftKeyboard)
>>>>
>>>> Om, can you please make a last test run on Android, so I can close
>>>> the
>>> ticket.
>>>
>>> Will do, later in the night for me.
>>>
>>> Thanks,
>>> Om
>>>
>>>> Maurice
>>>>
>>>> -----Message d'origine-----
>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> Envoyé : mardi 19 novembre 2013 00:36 À : dev@flex.apache.org Objet
>>>> : RE: Mobile TextInput Implementation status
>>>>
>>>> Just received results of Om testing on Android (Tested on Samsung
>>>> Galaxy
>>> SIII (Android 4.1.2) and Samsung Galaxy Tab 2 (Android 4.2.2)).
>>>> It's working fine.
>>>> Thanks you Om for the quick testing, that's really good news.
>>>>
>>>> Maurice
>>>> -----Message d'origine-----
>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> Envoyé : lundi 18 novembre 2013 16:49 À : dev@flex.apache.org Objet
>>>> : Mobile TextInput Implementation status
>>>>
>>>> Memory profiling of the new skins:
>>>>
>>>> It's as expected: alloc memory = pixel width x pixel height x
>>>> 4bytes
>>> per pixel.
>>>>
>>>> First figure is for iPad , second is for iPad retina.
>>>>
>>>> - 25KB / 100 KB of bitmap memory allocated for a single line TI with
>>> default size
>>>> - ~500KB / ~ 2 MB for a pages stuffed with text inputs / text Areas
>>>> - 3 MB / 12 MB for a full-page TA => in this case, it's better to
>>>> use the
>>> old skins.
>>>>
>>>> The bitmap is allocated while the TI is added to the stage, and
>>>> disposed
>>> when it's removed from the stage
>>>>
>>>> Maurice
>>>>
>>>> -----Message d'origine-----
>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> Envoyé : lundi 18 novembre 2013 02:10 À : dev@flex.apache.org Objet
>>>> : RE: Mobile TextInput Implementation status
>>>>
>>>>
>>>> 1) to help debug if something goes wrong on Android, you can set the
>>> following mx_internal flag:
>>>> ScrollableStageText.debugProxyImage = true;
>>>>
>>>> It will display the proxy bitmaps in magenta background.
>>>>
>>>> 2) proxy methods in ScrollableStageText has been abstracted on
>>>> purpose to
>>> DisplayObject instead of Bitmap.
>>>> This is so that one could override the class to use another proxy
>>> (eg.
>>> StyleableTextField) which is less memory consuming than bitmaps.
>>>> In wich case, you will have to override:
>>>> createProxy
>>>> updateProxy
>>>> disposeProxy
>>>>
>>>> 3) StageTextSkinBase inner textDisplay creation method is
>>>> externalized so
>>> that it can be customized.
>>>>
>>>> Example for ScrollableStageTextInputSkin:
>>>> override protected function
>> createTextDisplay():IStyleableEditableText
>>>> {
>>>> return new ScrollableStageText(multiline);
>>>> }
>>>>
>>>> That way, you can derive from existing skins, instead of monkey
>>>> patching
>>> the default skin, if you only need to change the internal editable
>>> text
>> class.
>>>>
>>>> Note also that displayText is now of type IStyleableEditableText,
>>>> instead
>>> of StyleableStageText, for the same purpose.
>>>>
>>>> Regards,
>>>>
>>>> Maurice
>>>>
>>>> -----Message d'origine-----
>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> Envoyé : lundi 18 novembre 2013 01:49 À : dev@flex.apache.org Objet
>>>> : RE: Mobile TextInput Implementation status
>>>>
>>>> Run mustella tests:
>>>> Mobile/Components/TextInput
>>>> Mobile/components/TextArea
>>>> Mobile/StageText
>>>>
>>>> All pass.
>>>>
>>>> Maurice
>>>>
>>>> -----Message d'origine-----
>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> Envoyé : lundi 18 novembre 2013 01:11 À : dev@flex.apache.org Objet
>>>> : RE: Mobile TextInput Implementation status
>>>>
>>>> Hi, I have committed and pushed tentative fix for
>>> https://issues.apache.org/jira/browse/FLEX-33166
>>>>
>>>> Tested on iPad 2 / 3.
>>>> Not tested on Android.
>>>> I couldn't run mustella mobile tests. For some reason, they are
>>>> broken
>>> on my machine ( says: Passes: 0 / Fails: 0).
>>>>
>>>> The new skins are now the defaults for TextInput and TextArea on
>>> mobile:
>>>>
>>>> TextInput skinClass =
>>>> spark.skins.mobile.ScrollingStageTextInputSkin
>>>> TextArea skinClass = spark.skins.mobile.ScrollingStageTextAreaSkin
>>>>
>>>> The old skins are still there, under the same name.
>>>>
>>>> Please review and tests, and this is a sensitive change...
>>>>
>>>> Your comments and feedback are welcome.
>>>>
>>>> Maurice
>>>>
>>>> -----Message d'origine-----
>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> Envoyé : lundi 18 novembre 2013 00:08 À : dev@flex.apache.org Objet
>>>> : RE: Mobile TextInput Implementation status
>>>>
>>>> Founds some bugs, so I won't commit until they are fixed...
>>>>
>>>> Maurice
>>>>
>>>> -----Message d'origine-----
>>>> De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>>>> Envoyé : dimanche 17 novembre 2013 21:18 À : dev@flex.apache.org
>>> Objet :
>>> RE: Mobile TextInput Implementation status
>>>>
>>>>> I can help out with Android testing.
>>>> Thanks
>>>>
>>>>> Should I wait for the nightly or are these fixes on a branch?
>>>>> Nightly
>>> would be preferable so as to allow more people to test the fix.
>>>> I will push to the develop/ so that they be in the nightly
>>>>
>>>>> It would be better to keep the old one around with the same name.
>>>>> Folks
>>> might have subclassed it to build their own implementations.
>>>>
>>>> What about :
>>>> ScrollableStageText
>>>> ScrollableStageTextInputSkin
>>>>
>>>> For the new classes ?
>>>>
>>>> Maurice
>>>>
>>>> -----Message d'origine-----
>>>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>>>> OmPrakash
>>> Muppirala Envoyé : dimanche 17 novembre 2013 20:27 À :
>>> dev@flex.apache.orgObjet : Re: Mobile TextInput Implementation status
>>>>
>>>> On Nov 17, 2013 10:56 AM, "Maurice Amsellem"
>>>> <ma...@systar.com>
>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Here is a brief status of the implementation of Mobile Text Input,
>>>>> along
>>>> with some questions:
>>>>>
>>>>> Implementation overview:
>>>>> The change is mainly on the class StyleableStageText, which now
>>>>> takes the
>>>> opposite approach than the previous one:
>>>>> - display proxy image bitmap by default
>>>>> - display StageText only when editing
>>>>> StageTextInputSkin/StageTextAreaSkin has been modified to use this
>>>>> class
>>>>>
>>>>> - to make it easier to change StageTextInputSkin internal
>>>> StyleableStageText component, the variable textDisplay is now of
>>>> type
>>> IStyleableEditText
>>>>>
>>>>> Behavior changes:
>>>>> - scrolling and overlapping of text is well managed , as it
>>>>> always uses
>>>> the bitmap proxy, which is a Flex component: all the text inputs
>>>> are
>>> scrolling
>>>>> - text occluding while editing is not managed yet, which means
>>>>> the
>>>> edited text may overlap other UIs. (TO BE DONE)
>>>>>
>>>>> Testing:
>>>>> - tested on iPad 2 and iPad 3: TI in scrolling forms, TI in
>> callouts
>>>>> - *NEEDS TO BE TESTED ON ANDROID*
>>>>> - memory consumption tests yet to be done
>>>>> - mustella test yet to be run
>>>>>
>>>>>
>>>>> Questions:
>>>>> - Can someone please test on Android ?
>>>>
>>>> I can help out with Android testing. Should I wait for the nightly
>>>> or
>>> are these fixes on a branch? Nightly would be preferable so as to
>>> allow
>> more people to test the fix.
>>>>
>>>> Thanks,
>>>> Om
>>>>
>>>>> - I have chosen to directly replace StyleableStageText.
>>>>> Maybe I can also leave the old StyleableStageText with a different
>>>>> name,
>>>> so that it can be used in case there is an issue with the new one ?
>>>> or
>>> the other way?
>>>>
>>>> It would be better to keep the old one around with the same name.
>>>> Folks
>>> might have subclassed it to build their own implementations.
>>>>
>>>>> Now that it is an interface, it's easy to subclass the
>>>> StageTextInputSkin, and override createTextDisplay() to use another
>> class.
>>>>>
>>>>>
>>>>> Maurice
>
Re: Mobile TextInput swipe
Posted by Alex Harui <ah...@adobe.com>.
BTW, I haven't tried any versions of your code, but I'm still surprised
that text selection works. I would think that trying to swipe-select a
word or placing the insertion cursor at an exact spot would also be
problematic with the bitmap proxy in the way.
Let's step back a bit. Why is it too late to detect scrolling on
mousedown? The MX DataGrid tears down its item editors when scrolling
starts. Isn't that similar?
Does there really need to be more than one StageText instance in play?
When TI1 loses focus can TI2 use that same StageText instance?
-Alex
On 11/23/13 5:22 PM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>Hi Team,
>
>I am currently working on the swipe issue with ScrollableStageText on
>mobile and would like your advice / help
>
>The issue is the following: you cannot initiate a scroll/swipe by
>touching inside a TextInput or TextArea.
>
>1) current situation:
>
>- in ScrollableStageText, the StageText is only shown when TI is in
>focus, and is replaced by a proxy when out of focus.
>- when scrolling, only the proxies are scrolled, so it works well.
>
>- when editing TI2 after TI1:
> - TI1 receives focus out => TI1 stageText is hidden, proxy shown
> - TI2 receives the focus on mouse down => TI2 stage text is focused
> - stageText for TI2 is displayed (and proxy hidden)
>
>=> the problem, is that since focus is set on mousedown, it's too late to
>detect scrolling,
> so I had to prevent it, by calling event.preventDefautl() in
>touchInteractionStarting handler.
>
>2) proposed solution
>To overcome that issue, I changed the focus to be set on MOUSE UP,
>instead of mouse down, so that I can detection touch scroll, and prevent
>editing.
>
>It works pretty well but has the following side effect :
>When editing TI1 after TI2, the soft keyboard (which was visible), lowers
>when pressing TI2, and raises back when releasing your finger.
>
>The reason for that is that is when pressing TI2:
>- TI1 has received focus out, so its StageText it's not visible anymore
>- TI2 did not receive focus yet, so its stageText is not visible yet
>=> no stageText, no SoftKeyboard.
>TI2 stage text is assigned focus only when finger is released.
>
>3) proposed solution to the side effect:
>Since the only way of having a soft keyboard visible is to have an active
>StageText, and call assingFocus() on it,
>I added a dummy static StageText to the stage, with no text and a
>viewport extent of 0,0.
>This stageText is assigned focus between the time finger is pressed, so
>TI1 and TI2 stage texts are not visible, and the finger is released,
>where TI2 stage text is displayed.
>That way, the soft keyboard does not disappear.
> ______________
>
>It works well, but I consider the dummy StageText as a HORRIBLE HACK.
>So if someone has a better solution that also meets the requirements, I
>will be happy to take it.
>
>Regards,
>
>Maurice
>
>-----Message d'origine-----
>De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>Envoyé : vendredi 22 novembre 2013 11:37
>À : dev@flex.apache.org
>Objet : RE: Mobile TextInput Implementation status
>
>Hi,
>I fixed the two issues that were reported in the JIRA ticket by Colins
>Childs.
>
>fixed two issues reported above:
>- two focused text inputs
>- stage text floating above content.
>
>
>Committed and pushed to develop branch
>https://git-wip-us.apache.org/repos/asf?p=flex-sdk.git;a=commit;h=9e4bf21f
>
>Mobile Mustella test pass:
>- mobile/components/TextInput
>- mobile/compoents/TextArea
>- mobile/Softkeyboard
>
>
>-----Message d'origine-----
>De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>Envoyé : mardi 19 novembre 2013 18:18
>À : dev@flex.apache.org
>Objet : RE: Mobile TextInput Implementation status
>
>Sure. You need mobilecomponents and mobiletheme
>
>-----Message d'origine-----
>De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de OmPrakash
>Muppirala Envoyé : mardi 19 novembre 2013 18:14 À : dev@flex.apache.org
>Objet : RE: Mobile TextInput Implementation status
>
>On Nov 19, 2013 9:05 AM, "Maurice Amsellem" <ma...@systar.com>
>wrote:
>>
>> Since jenkins is down, do you need the updated swc ?
>
>Which project is it? I can just compile it and drop it in the sdk
>directory.
>
>Thanks,
>Om
>
>>
>> -----Message d'origine-----
>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>> OmPrakash
>Muppirala
>> Envoyé : mardi 19 novembre 2013 17:55
>> À : dev@flex.apache.org
>> Objet : RE: Mobile TextInput Implementation status
>>
>> On Nov 19, 2013 4:53 AM, "Maurice Amsellem"
>> <ma...@systar.com>
>> wrote:
>> >
>> > Fixed a few other issues
>> > (see https://issues.apache.org/jira/browse/FLEX-33166)
>> > > FIXED : Soft keyboard partially closes/opens when moving the
>> > > focus
>> from one TI to another.
>> > > to fix the issue above, had to trigger TI edition on mousedown
>> > > instead
>> of mouse click (like in StyleableStageText)
>> > > fixed bug caused by the above.
>> >
>> > All related mustella test pass. ( mobile/TextInput, mobile/TextArea,
>> mobile/SoftKeyboard)
>> >
>> > Om, can you please make a last test run on Android, so I can close
>> > the
>> ticket.
>> >
>>
>> Will do, later in the night for me.
>>
>> Thanks,
>> Om
>>
>> > Maurice
>> >
>> > -----Message d'origine-----
>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>> > Envoyé : mardi 19 novembre 2013 00:36 À : dev@flex.apache.org Objet
>> > : RE: Mobile TextInput Implementation status
>> >
>> > Just received results of Om testing on Android (Tested on Samsung
>> > Galaxy
>> SIII (Android 4.1.2) and Samsung Galaxy Tab 2 (Android 4.2.2)).
>> > It's working fine.
>> > Thanks you Om for the quick testing, that's really good news.
>> >
>> > Maurice
>> > -----Message d'origine-----
>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>> > Envoyé : lundi 18 novembre 2013 16:49 À : dev@flex.apache.org Objet
>> > : Mobile TextInput Implementation status
>> >
>> > Memory profiling of the new skins:
>> >
>> > It's as expected: alloc memory = pixel width x pixel height x
>> > 4bytes
>> per pixel.
>> >
>> > First figure is for iPad , second is for iPad retina.
>> >
>> > - 25KB / 100 KB of bitmap memory allocated for a single line TI with
>> default size
>> > - ~500KB / ~ 2 MB for a pages stuffed with text inputs / text Areas
>> > - 3 MB / 12 MB for a full-page TA => in this case, it's better to
>> > use the
>> old skins.
>> >
>> > The bitmap is allocated while the TI is added to the stage, and
>> > disposed
>> when it's removed from the stage
>> >
>> > Maurice
>> >
>> > -----Message d'origine-----
>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>> > Envoyé : lundi 18 novembre 2013 02:10 À : dev@flex.apache.org Objet
>> > : RE: Mobile TextInput Implementation status
>> >
>> >
>> > 1) to help debug if something goes wrong on Android, you can set the
>> following mx_internal flag:
>> > ScrollableStageText.debugProxyImage = true;
>> >
>> > It will display the proxy bitmaps in magenta background.
>> >
>> > 2) proxy methods in ScrollableStageText has been abstracted on
>> > purpose to
>> DisplayObject instead of Bitmap.
>> > This is so that one could override the class to use another proxy
>>(eg.
>> StyleableTextField) which is less memory consuming than bitmaps.
>> > In wich case, you will have to override:
>> > createProxy
>> > updateProxy
>> > disposeProxy
>> >
>> > 3) StageTextSkinBase inner textDisplay creation method is
>> > externalized so
>> that it can be customized.
>> >
>> > Example for ScrollableStageTextInputSkin:
>> > override protected function
>createTextDisplay():IStyleableEditableText
>> > {
>> > return new ScrollableStageText(multiline);
>> > }
>> >
>> > That way, you can derive from existing skins, instead of monkey
>> > patching
>> the default skin, if you only need to change the internal editable
>> text
>class.
>> >
>> > Note also that displayText is now of type IStyleableEditableText,
>> > instead
>> of StyleableStageText, for the same purpose.
>> >
>> > Regards,
>> >
>> > Maurice
>> >
>> > -----Message d'origine-----
>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>> > Envoyé : lundi 18 novembre 2013 01:49 À : dev@flex.apache.org Objet
>> > : RE: Mobile TextInput Implementation status
>> >
>> > Run mustella tests:
>> > Mobile/Components/TextInput
>> > Mobile/components/TextArea
>> > Mobile/StageText
>> >
>> > All pass.
>> >
>> > Maurice
>> >
>> > -----Message d'origine-----
>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>> > Envoyé : lundi 18 novembre 2013 01:11 À : dev@flex.apache.org Objet
>> > : RE: Mobile TextInput Implementation status
>> >
>> > Hi, I have committed and pushed tentative fix for
>> https://issues.apache.org/jira/browse/FLEX-33166
>> >
>> > Tested on iPad 2 / 3.
>> > Not tested on Android.
>> > I couldn't run mustella mobile tests. For some reason, they are
>> > broken
>> on my machine ( says: Passes: 0 / Fails: 0).
>> >
>> > The new skins are now the defaults for TextInput and TextArea on
>>mobile:
>> >
>> > TextInput skinClass =
>> > spark.skins.mobile.ScrollingStageTextInputSkin
>> > TextArea skinClass = spark.skins.mobile.ScrollingStageTextAreaSkin
>> >
>> > The old skins are still there, under the same name.
>> >
>> > Please review and tests, and this is a sensitive change...
>> >
>> > Your comments and feedback are welcome.
>> >
>> > Maurice
>> >
>> > -----Message d'origine-----
>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>> > Envoyé : lundi 18 novembre 2013 00:08 À : dev@flex.apache.org Objet
>> > : RE: Mobile TextInput Implementation status
>> >
>> > Founds some bugs, so I won't commit until they are fixed...
>> >
>> > Maurice
>> >
>> > -----Message d'origine-----
>> > De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>> > Envoyé : dimanche 17 novembre 2013 21:18 À : dev@flex.apache.org
>>Objet :
>> RE: Mobile TextInput Implementation status
>> >
>> > >I can help out with Android testing.
>> > Thanks
>> >
>> > >Should I wait for the nightly or are these fixes on a branch?
>> > >Nightly
>> would be preferable so as to allow more people to test the fix.
>> > I will push to the develop/ so that they be in the nightly
>> >
>> > >It would be better to keep the old one around with the same name.
>> > >Folks
>> might have subclassed it to build their own implementations.
>> >
>> > What about :
>> > ScrollableStageText
>> > ScrollableStageTextInputSkin
>> >
>> > For the new classes ?
>> >
>> > Maurice
>> >
>> > -----Message d'origine-----
>> > De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de
>> > OmPrakash
>> Muppirala Envoyé : dimanche 17 novembre 2013 20:27 À :
>> dev@flex.apache.orgObjet : Re: Mobile TextInput Implementation status
>> >
>> > On Nov 17, 2013 10:56 AM, "Maurice Amsellem"
>> > <ma...@systar.com>
>> > wrote:
>> > >
>> > > Hi,
>> > >
>> > > Here is a brief status of the implementation of Mobile Text Input,
>> > > along
>> > with some questions:
>> > >
>> > > Implementation overview:
>> > > The change is mainly on the class StyleableStageText, which now
>> > > takes the
>> > opposite approach than the previous one:
>> > > - display proxy image bitmap by default
>> > > - display StageText only when editing
>> > > StageTextInputSkin/StageTextAreaSkin has been modified to use this
>> > > class
>> > >
>> > > - to make it easier to change StageTextInputSkin internal
>> > StyleableStageText component, the variable textDisplay is now of
>> > type
>> IStyleableEditText
>> > >
>> > > Behavior changes:
>> > > - scrolling and overlapping of text is well managed , as it
>> > > always uses
>> > the bitmap proxy, which is a Flex component: all the text inputs
>> > are
>> scrolling
>> > > - text occluding while editing is not managed yet, which means
>> > > the
>> > edited text may overlap other UIs. (TO BE DONE)
>> > >
>> > > Testing:
>> > > - tested on iPad 2 and iPad 3: TI in scrolling forms, TI in
>callouts
>> > > - *NEEDS TO BE TESTED ON ANDROID*
>> > > - memory consumption tests yet to be done
>> > > - mustella test yet to be run
>> > >
>> > >
>> > > Questions:
>> > > - Can someone please test on Android ?
>> >
>> > I can help out with Android testing. Should I wait for the nightly
>> > or
>> are these fixes on a branch? Nightly would be preferable so as to
>> allow
>more people to test the fix.
>> >
>> > Thanks,
>> > Om
>> >
>> > > - I have chosen to directly replace StyleableStageText.
>> > > Maybe I can also leave the old StyleableStageText with a different
>> > > name,
>> > so that it can be used in case there is an issue with the new one ?
>> > or
>> the other way?
>> >
>> > It would be better to keep the old one around with the same name.
>> > Folks
>> might have subclassed it to build their own implementations.
>> >
>> > > Now that it is an interface, it's easy to subclass the
>> > StageTextInputSkin, and override createTextDisplay() to use another
>class.
>> > >
>> > >
>> > > Maurice
>> > >