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=9e4bf >>> 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 >>>>>> >> >
