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:aha...@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" <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=9e4b >>f >>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 >>> > > >
