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.org 
Objet : 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
>

Reply via email to