Please remove me from this mailing list

On Sun, Nov 24, 2013 at 6:52 AM, 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=9e4bf21f
>
> 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.orgObjet 
> : 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.orgObjet :
> > 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
> > > >
>



-- 
Thanks,
Vijay Kumar

Reply via email to