Hi Justin,
I have cleaned up my code to prepare for the integration with the SDK, and
removed two classes in the process :-)
Following your request, I describe below the differences between core classes
and the ones I have used in MobileGrid, and make suggestions on how it could be
integrated to the core classes:
1) Spark.utils.MultiDPIBitmapSourceExt vs. Spark.utils.MultiDPIBitmapSource
a) differences
getSource(desiredDPI: Number)
(This is a copy/paste from a previous thread, 09/18/2013 21:47 CET)
MultiBitmapSource getSource(dpi) method is called 3 times in the SDK with
exactly the same code:
var app:Object = FlexGlobals.topLevelApplication;
var dpi:Number;
if ("runtimeDPI" in app)
dpi = app["runtimeDPI"];
else
dpi = DensityUtil.getRuntimeDPI();
var multiSource:Object =
MultiDPIBitmapSource(source).getSource(dpi);
So basically, MDPIBSExt does the above.
b) Proposed integration
* Move the implementation of MultiBitmapSourceExt.getSource(dpi) into the root
class MultiBitmapSource.getSource(dpi)
* Make the desiredDPI argument optional (desiredDPI:Number = NaN) , so that
when called with no argument, it has the default behavior.
-------------------------
2) spark.UIComponentUtils
=> I managed to remove all methods in this class by using equivalent SDK
methods, or inline code.
So I deleted the class
3) spark.components.supportClasses.ItemRendererBase vs.
spark.components.LabelItemRenderer
ItemRendererBase was the base class for MobileGridRowRenderer
=> I managed to make it inherit from LabelItemRenderer instead,
so I deleted the class
__________________________
4) spark.utils.DensityUtil2 vs spark.utils.DensityUtil
a) differences:
private static function dpiScale(value:Number, sourceDPI:Number =
DPIClassification.DPI_160):Number
And private static function getSetApplicationDPI():Number
Actually, this is very specific to MobileGrid and I don't know if it can be
extended to SDK.
Let me try to explain.
I wanted MobileGridColumn width to be set to either as fixed or percentage
value.
Then I needed to convert this value to actual pixels.
- when width is set as percentage value (using percentProxy), then all
computations are relative, so there is no density issue.
- when width is set as a fixed value, then there are two possibilities:
- if Application.applicationDPI has been set (eg. to 320 DPI) => width must
be interpreted in that authoring DPI, so basically, there is nothing to do as
scaling is already done in the transform matrix.
- if Application.applicationDPI has not been set => the width needs be
interpreted according to the second arg (sourceDPI) set arbitrarily by default
to 160 DPI.
=> basic conversion is done (return value * runDPI / sourceDPI)
Note: the SDK is not clear on whether one should use applicationDPI or the
@media css,
and the different blogs on the subject didn't help me much, so I needed to
handle both situations
You guys are more experienced on this, so maybe you know how this should be done
Any help is welcome.
b) Proposed integration:
- If other classes may need the same kind of dual behavior, move these methods
to DensityUtil
- Otherwise, keep it private, and give it another name (MobileGridUtils or
something)
Maurice
-----Message d'origine-----
De : Justin Mclean [mailto:[email protected]]
Envoyé : mercredi 2 octobre 2013 04:14
À : [email protected]
Objet : Re: New mobile grid classes
Hi,
> 1) The MDG classes package names are spark.components.*, like in other
> experimental compoents
OK - not 100% sure that's the way to go, but reasonable enough if other
components do that.
> 2) yes, that's the idea: these classes would eventually be merged with the
> root sdk classes.
OK I think we work on that next then merge this branch into the dev branch so
this can be in the next release.
Thanks,
Justin
