flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From 周 戈 <darkst...@163.com>
Subject Re: Mobile TextInput swipe
Date Sun, 24 Nov 2013 20:54:22 GMT
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 <maurice.amsellem@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 <aharui@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" <maurice.amsellem@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" <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=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"
>>>> <maurice.amsellem@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"
>>>>> <maurice.amsellem@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"
>>>>>> <maurice.amsellem@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
>>>>>>> 
>>> 
>> 
> 
> 



Mime
View raw message