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.amsel...@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:darkst...@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 <aha...@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.amsel...@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:aha...@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.amsel...@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.amsel...@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.amsel...@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 : omup...@gmail.com [mailto:omup...@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.amsel...@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 : omup...@gmail.com [mailto:omup...@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.amsel...@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.amsel...@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.amsel...@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.amsel...@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.amsel...@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.amsel...@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.amsel...@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.amsel...@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 : omup...@gmail.com [mailto:omup...@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.amsel...@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 >>>>>>> >>> >> > >
