flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Mobile TextInput swipe
Date Mon, 25 Nov 2013 07:17:17 GMT
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.amsellem@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:aharui@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.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=9e4b
>>>f
>>>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