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" <maurice.amsel...@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: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 >>>> > > >> >
