You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@flex.apache.org by doug777 <do...@gmail.com> on 2016/11/28 02:01:39 UTC
Calls to superclass failing
I have a strange problem with all my skins that were previously working
correctly.
This causes all sorts of problems with the components using these skins.
Whenever I need to access the skin superclass I am getting warnings. For
example:
super.updateDisplayList(unscaledWidth, unscaledHeight);
generates the warning : Call to a possibly undefined method
updateDisplayList
Tracing the problem shows me that Flex is trying to find the superclass in
my project's skins folder and not in the sdk.
Here is a simple skin that has the warning.
<?xml version="1.0" encoding="utf-8"?>
<s:Skin xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark" alpha.disabled="0.5">
<fx:Metadata>[HostComponent("MainPage")]</fx:Metadata>
<fx:Script>
</fx:Script>
<s:states>
<s:State name="normal" />
<s:State name="disabled" />
</s:states>
<s:Rect id="backgroundRect" left="0" right="0" top="0" bottom="0" >
<s:fill>
<s:SolidColor id="bgRectFill" color="#FFFFFF"/>
</s:fill>
</s:Rect>
<s:Group id="contentGroup" width="100%" height="100%" minWidth="0"
minHeight="0" fontSize="14"/>
</s:Skin>
I guess I must have done something to cause the problem, but I can't work
out what it could be.
Can anyone give me any clue as to what might be wrong.
I am using sdk 4.15.0.
Doug
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Calls-to-superclass-failing-tp14230.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Calls to superclass failing
Posted by doug777 <do...@gmail.com>.
In the email, the CDATA section seems to have been eaten by the mailer. The
code inside this part is
override protected function updateDisplayList(unscaledWidth:Number,
unscaledHeight:Number) : void
{
bgRectFill.color = getStyle('backgroundColor');
super.updateDisplayList(unscaledWidth, unscaledHeight);
}
Doug
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Calls-to-superclass-failing-tp14230p14231.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Calls to superclass failing
Posted by doug777 <do...@gmail.com>.
I doubt digging in further will be off any general help to anyone. The main
thing is to recognize the problem and know what to do to solve it.
Many thanks for your help,
Doug
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Calls-to-superclass-failing-tp14230p14257.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Calls to superclass failing
Posted by Alex Harui <ah...@adobe.com>.
On 11/28/16, 8:28 PM, "doug777" <do...@gmail.com> wrote:
>That was the solution. Everything now works correctly.
>
>When I start to do some new work on an old project I always upgrade it to
>the latest sdk before starting.
>
>I never realized before that there can be hidden changes that affect
>things
>without showing errors or warnings in the Problems panel.
>
>Even the little orange warning markers are actually a red or perhaps I
>should say orange herring, because they are still there in the updated
>custom skin even though it now works correctly.
>
>So how do you find these things that are changed? Or is it just simply bad
>practice to update old projects to the most recent sdk?
Usually, if there are changes between versions you get an exception. It
sort of sounds like you are since you can't step into the
super.updateDisplayList, but it is strange that you don't end up in some
other code. We could dig into it more, but I'm not sure it is worth it.
There were significant changes to DataGrid in 4.10, but the last person
who got tripped up by this got an exception.
-Alex
Re: Calls to superclass failing
Posted by doug777 <do...@gmail.com>.
That was the solution. Everything now works correctly.
When I start to do some new work on an old project I always upgrade it to
the latest sdk before starting.
I never realized before that there can be hidden changes that affect things
without showing errors or warnings in the Problems panel.
Even the little orange warning markers are actually a red or perhaps I
should say orange herring, because they are still there in the updated
custom skin even though it now works correctly.
So how do you find these things that are changed? Or is it just simply bad
practice to update old projects to the most recent sdk?
Doug
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Calls-to-superclass-failing-tp14230p14255.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Calls to superclass failing
Posted by doug777 <do...@gmail.com>.
So I ran swfdump and have been studying the results. The module in which this
skin is used created a file with 200,000 lines. From the ABC2 tag to the end
of the section where newclass ViewListingsDataGridSkin is shown there are
about 3000 lines.
I can't see anything in there that looks odd, but then I'm not really sure
what I'm looking for.
Elsewhere in the dump file there are 9 InnerClass references to this skin
and a WatcherSetupUtil.
I should add that the warnings in the FlashBuilder IDE are little orange
question marks at the side of the line. Nothing shows up in the Problems
panel even though this is set to Show All.
I have done some further tests.
The skin is called when the module loads and there is a big difference
between the default skin and my skin.
The default skin creates the whole data grid with all the column headers
displayed. I then fill the dataProvider and it adds the data to the cells
already showing.
With ViewListingsDataGridSkin only the blank header row and blank first row
are created.
All my skins are based on skins from an earlier sdk and I've just noticed
that these skins are quite a bit different in 4.15.0 from the skin I
originally used.
I will update them all to the new skins and watch out for that when I
upgrade the sdks in future if that turns out to be the problem.
Doug
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Calls-to-superclass-failing-tp14230p14254.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Calls to superclass failing
Posted by doug777 <do...@gmail.com>.
> you could use the debugger to step into the super.updateDisplayList call
> to make sure no exception gets thrown at that point.
The first line with a warning that gets called in my skin is
super.initializationComplete and stepping into this shows it goes through
various components UIComponent - FlexEvent -etc and eventually ends up
setting up the listeners for the columnHeaderGroup in DataGrid partAdded().
When this is complete the next step is the super.updateDisplayList in my
skin. But when you step on from that, processing ends and the empty dg
appears. There is no error. It just ends at that point without doing
anything else.
>The next thing to try is to run swfdump on the swf.
I will try that now.
Doug
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Calls-to-superclass-failing-tp14230p14253.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Calls to superclass failing
Posted by Alex Harui <ah...@adobe.com>.
On 11/28/16, 1:27 AM, "doug777" <do...@gmail.com> wrote:
>It's so odd.
>
>This line in ViewListingsDataGridSkin -
>
>super.updateDisplayList(unscaledWidth, unscaledHeight);
>
>has the warning : Call to a possibly undefined method updateDisplayList
>
>How is that possible???
Don't know. Are you getting this error from an IDE or a build script?
Flash Builder sometimes has its compiler cache go funky, and a cleaning
the project and/or restarting Flash Builder clears those errors. Also,
you could use the debugger to step into the super.updateDisplayList call
to make sure no exception gets thrown at that point.
>
>I've done something to this project that has caused this fault - I was
>just
>looking for some clue as to where the fault might lie. The fault is passed
>onto the compiled Release Build as well.
>
>In the particular trace posted before, the error is caused by columnIndex
>=
>-1 as test case FLEX-35028. But the columns array in the DataGrid
>component
>are all set up correctly. And everything works correctly if I use the
>default DataGrid skin.
>
>only a blank header row and a blank first row with the correct
>background colour show up :
>
>
>
This makes me think some sort of exception is being thrown and caught
somewhere. If the skin is funky, even though your columns array is good,
the internal column width arrays may have bad values and then the
columnIndex calculation will end up as -1.
The next thing to try is to run swfdump on the swf. Swfdump is in the bin
folder of any Flex SDK. Run it as:
swfdump -abc foo.swf >foo.txt
Foo.txt will be a huge file. Search for your skin class name in the file.
It will show up several times, but one line should start with "newclass"
as in:
newclass :ViewListingsDataGridSkin
This line should be in an init() function and the surrounding code should
show you the class hierarchy that the compiler actually output. Then
chasing down that base class should show you the source-path for that base
class and sometimes provides a clue that you are accidentally picking up a
base class from somewhere unexpected.
HTH,
-Alex
Re: Calls to superclass failing
Posted by doug777 <do...@gmail.com>.
It's so odd.
This line in ViewListingsDataGridSkin -
super.updateDisplayList(unscaledWidth, unscaledHeight);
has the warning : Call to a possibly undefined method updateDisplayList
Yet if I control-click on super, SparkSkin pops up where updateDisplayList
is very obviously defined.
How is that possible???
Doug
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Calls-to-superclass-failing-tp14230p14242.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Calls to superclass failing
Posted by doug777 <do...@gmail.com>.
If I create a test case it all works - the skins work fine in all my other
projects.
I've done something to this project that has caused this fault - I was just
looking for some clue as to where the fault might lie. The fault is passed
onto the compiled Release Build as well.
In the particular trace posted before, the error is caused by columnIndex =
-1 as test case FLEX-35028. But the columns array in the DataGrid component
are all set up correctly. And everything works correctly if I use the
default DataGrid skin.
This works fine - whole data grid and all its contents show up :
<s:DataGrid id="dgListings" width="100%" fontSize="12"
requestedRowCount="20" contentBackgroundColor="0xe6aac4"
selectionChange="selectedRowHandler(event)">
This fails - only a blank header row and a blank first row with the correct
background colour show up :
<s:DataGrid id="dgListings" width="100%" fontSize="12"
requestedRowCount="20" contentBackgroundColor="0xe6aac4"
skinClass="com.mainds.ibe.skins.listing.ViewListingsDataGridSkin"
selectionChange="selectedRowHandler(event)">
Adding the custom skin class is the only thing that is changed.
The only clue is the warning messages in the custom skins.
There is no fault of any kind in the stack trace until I click the blank
header row.
Doug
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Calls-to-superclass-failing-tp14230p14241.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Calls to superclass failing
Posted by Alex Harui <ah...@adobe.com>.
On 11/27/16, 10:45 PM, "doug777" <do...@gmail.com> wrote:
>I don't think the stack traces help as they only relate to the error
>caused.
>For example here is the trace for a DataGrid that uses a custom skin.
>
>TypeError: Error #1009: Cannot access a property or method of a null
>object
>reference.
> at
>spark.components::GridColumnHeaderGroup/getHeaderRendererAt()[/Users/justi
>nmclean/Documents/ApacheFlex4.15/frameworks/projects/spark/src/spark/compo
>nents/GridColumnHeaderGroup.as:921]
> at
>spark.components::GridColumnHeaderGroup/dispatchGridEvent()[/Users/justinm
>clean/Documents/ApacheFlex4.15/frameworks/projects/spark/src/spark/compone
>nts/GridColumnHeaderGroup.as:1266]
> at
>spark.components::GridColumnHeaderGroup/gchg_mouseDownDragUpHandler()[/Use
>rs/justinmclean/Documents/ApacheFlex4.15/frameworks/projects/spark/src/spa
>rk/components/GridColumnHeaderGroup.as:1112]
> at
>Function/<anonymous>()[/Users/justinmclean/Documents/ApacheFlex4.15/framew
>orks/projects/spark/src/spark/utils/MouseEventUtil.as:104]
Hmm. The above stack trace looks like
https://issues.apache.org/jira/browse/FLEX-35028
>
>This is caused by clicking in the header row that should contain the
>header
>data, but doesn't because after the dataProvider is filled, presumably the
>skin can't update the display list.
I guess this still doesn't make sense to me. If the skin can't update the
display list, I would expect an error in that part of the code. Can you
attach a simple test case the FLEX-35028?
-Alex
Re: Compiler directive
Posted by Lane <la...@hotmail.com>.
That is exactly what I am looking for.
Thanks so much,
Lane.
-----Original Message-----
From: OmPrakash Muppirala
Sent: Tuesday, December 6, 2016 1:30 AM
To: users@flex.apache.org
Subject: Re: Compiler directive
I think this is what you are looking for
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=50856172
Thanks,
Om
On Dec 4, 2016 10:29 PM, "Lane" <la...@hotmail.com> wrote:
I've got a mobile Android Flex app that is skinned with older mobile
components. I recently updated the app with a newly compiled version and it
has newer skins. For instance, on the tabs there is now a horizontal line.
The spinner wheel has a much lighter shade. I don't like the new washed-out
look.
I think I used a compiler directive before to suppress this, but can't find
a record now of what I did. I'd be grateful if you could help remind me of
what is necessary to move back to the old look.
Thanks,
Lane.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Re: Compiler directive
Posted by OmPrakash Muppirala <bi...@gmail.com>.
I think this is what you are looking for
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=50856172
Thanks,
Om
On Dec 4, 2016 10:29 PM, "Lane" <la...@hotmail.com> wrote:
I've got a mobile Android Flex app that is skinned with older mobile
components. I recently updated the app with a newly compiled version and it
has newer skins. For instance, on the tabs there is now a horizontal line.
The spinner wheel has a much lighter shade. I don't like the new washed-out
look.
I think I used a compiler directive before to suppress this, but can't find
a record now of what I did. I'd be grateful if you could help remind me of
what is necessary to move back to the old look.
Thanks,
Lane.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Compiler directive
Posted by Lane <la...@hotmail.com>.
I've got a mobile Android Flex app that is skinned with older mobile
components. I recently updated the app with a newly compiled version and it
has newer skins. For instance, on the tabs there is now a horizontal line.
The spinner wheel has a much lighter shade. I don't like the new washed-out
look.
I think I used a compiler directive before to suppress this, but can't find
a record now of what I did. I'd be grateful if you could help remind me of
what is necessary to move back to the old look.
Thanks,
Lane.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Re: Creating Slider in FlexJS
Posted by Peter Ent <pe...@adobe.com>.
We made several bug fixes to the Slider in the FlexJS 0.8.0 version. Can
you grab a nightly build and try that?
Regards,
Peter Ent
Adobe Systems/Apache Flex Project
On 1/5/17, 11:22 PM, "Lane" <la...@hotmail.com> wrote:
>I'm working with Flashbuilder 4.7 and FlexJS 0.7.0 on Windows 10. The
>following code generates a slider on the Run command. However, it does
>not
>generate a slider when I do a release build. Is there something very
>obvious
>that I am missing?
>
><js:Slider id="circuitsSlider" width="800" x="20" y="200"
> minimum="0" maximum="242" snapInterval="1"
>mouseUp="sliderChange()"/>
>
>Thanks so much,
>
>Lane.
>
>
>---
>This email has been checked for viruses by Avast antivirus software.
>https://www.avast.com/antivirus
>
Creating Slider in FlexJS
Posted by Lane <la...@hotmail.com>.
I'm working with Flashbuilder 4.7 and FlexJS 0.7.0 on Windows 10. The
following code generates a slider on the Run command. However, it does not
generate a slider when I do a release build. Is there something very obvious
that I am missing?
<js:Slider id="circuitsSlider" width="800" x="20" y="200"
minimum="0" maximum="242" snapInterval="1"
mouseUp="sliderChange()"/>
Thanks so much,
Lane.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Re: reduce creation time of view in mobile app
Posted by Frank Dahmen <fr...@dahmenia.de>.
thanks Alex
I will try to figure out if and how I could apply it to this view
Am 28.11.2016 um 23:26 schrieb Alex Harui:
>
> On 11/28/16, 12:49 PM, "Frank Dahmen" <fr...@dahmenia.de> wrote:
>
>> this looks like magic :)
>>
>> I'll try to understand the concept
> In fact, it is based on the principles that most professional magicians
> use, such as illusion. There is probably no requirement in your app to
> create, say, 200 UI widgets at the same time, just to give the illusion
> that you did. So, once you understand the behavior of the end-user, you
> might be able to create an illusion of creating 200 UI widgets by creating
> the 50 or so that must be on-screen right away, then adding others "later".
>
> In some scenarios, if the user must read something before deciding whether
> to scroll to see the other widgets, you can use that "read" time to make
> the remaining widgets. In computer time, a human reading something
> usually takes quite a bit time. But there are other scenarios where the
> user is just as likely to flip to the bottom of the screen, and then you
> have to take that into account.
>
> Also, usually, user interaction takes very little of the frame time in
> Flash. But doing too much makes the UI poorly-responsive. So it is
> possible to do little bits of work when the user is interacting, but not
> so much that he/she notices.
>
> The implementation in this FlexStore example uses multiple view states.
> Think of any live theater you've watched where the sets are changing on
> one corner of the stage while the spotlight focuses your attention on two
> people talking in the opposite corner. The theater director has
> choreographed what backdrops get raised and lowered and when certain
> stagehands carry in some furniture and when the actors arrive at the edge
> of the stage. The FlexStore example just uses two states, but you could
> use many more if that is what you need to do in order to create all the
> widgets and not make the app unresponsive.
>
> FlexStore waits for a stylesheet to load, but you could wait for
> creationComplete or updateComplete of whatever needs to be on-screen right
> away, then use callLater to change to the next state, where more widgets
> are created, then on updateComplete of those, callLater could switch to
> yet another state. I use StateGroups so that widgets have an "includeIn"
> of all states after the one they are create in.
>
> FWIW, one of the cool things about FlexJS is that MXML is converted into
> data instead of code, so it would be possible to create a "smart"
> container that only instantiates as many components as it can within an
> interval, then creates more on subsequent intervals. The result would be
> sort of a "reveal effect" if the rate of creation falls behind the user's
> demands.
>
> HTH,
> -Alex
>
Re: reduce creation time of view in mobile app
Posted by Alex Harui <ah...@adobe.com>.
On 11/28/16, 12:49 PM, "Frank Dahmen" <fr...@dahmenia.de> wrote:
>this looks like magic :)
>
>I'll try to understand the concept
In fact, it is based on the principles that most professional magicians
use, such as illusion. There is probably no requirement in your app to
create, say, 200 UI widgets at the same time, just to give the illusion
that you did. So, once you understand the behavior of the end-user, you
might be able to create an illusion of creating 200 UI widgets by creating
the 50 or so that must be on-screen right away, then adding others "later".
In some scenarios, if the user must read something before deciding whether
to scroll to see the other widgets, you can use that "read" time to make
the remaining widgets. In computer time, a human reading something
usually takes quite a bit time. But there are other scenarios where the
user is just as likely to flip to the bottom of the screen, and then you
have to take that into account.
Also, usually, user interaction takes very little of the frame time in
Flash. But doing too much makes the UI poorly-responsive. So it is
possible to do little bits of work when the user is interacting, but not
so much that he/she notices.
The implementation in this FlexStore example uses multiple view states.
Think of any live theater you've watched where the sets are changing on
one corner of the stage while the spotlight focuses your attention on two
people talking in the opposite corner. The theater director has
choreographed what backdrops get raised and lowered and when certain
stagehands carry in some furniture and when the actors arrive at the edge
of the stage. The FlexStore example just uses two states, but you could
use many more if that is what you need to do in order to create all the
widgets and not make the app unresponsive.
FlexStore waits for a stylesheet to load, but you could wait for
creationComplete or updateComplete of whatever needs to be on-screen right
away, then use callLater to change to the next state, where more widgets
are created, then on updateComplete of those, callLater could switch to
yet another state. I use StateGroups so that widgets have an "includeIn"
of all states after the one they are create in.
FWIW, one of the cool things about FlexJS is that MXML is converted into
data instead of code, so it would be possible to create a "smart"
container that only instantiates as many components as it can within an
interval, then creates more on subsequent intervals. The result would be
sort of a "reveal effect" if the rate of creation falls behind the user's
demands.
HTH,
-Alex
Re: reduce creation time of view in mobile app
Posted by Frank Dahmen <fr...@dahmenia.de>.
this looks like magic :)
I'll try to understand the concept
thanks
Am 28.11.2016 um 17:29 schrieb Alex Harui:
>
> On 11/28/16, 5:57 AM, "Frank Dahmen" <fr...@dahmenia.de> wrote:
>
>> that's why I said "magic" not "unpleasant" :)
> Fundamentally, if it isn't visible on-screen, don't create it right away.
>
> If you look at the FlexStore example here [1]
>
> I've used states and a "prebake" trick to finish up initialization of
> off-screen stuff after the initial screen is visible.
>
> HTH,
> -Alex
>
> [1]
> https://git-wip-us.apache.org/repos/asf/flex-sdk/repo?p=flex-examples.git;a
> =blob_plain;f=FlexStore/spark/src/FlexStore.mxml;hb=refs/heads/develop
>
Re: reduce creation time of view in mobile app
Posted by Alex Harui <ah...@adobe.com>.
On 11/28/16, 5:57 AM, "Frank Dahmen" <fr...@dahmenia.de> wrote:
>that's why I said "magic" not "unpleasant" :)
Fundamentally, if it isn't visible on-screen, don't create it right away.
If you look at the FlexStore example here [1]
I've used states and a "prebake" trick to finish up initialization of
off-screen stuff after the initial screen is visible.
HTH,
-Alex
[1]
https://git-wip-us.apache.org/repos/asf/flex-sdk/repo?p=flex-examples.git;a
=blob_plain;f=FlexStore/spark/src/FlexStore.mxml;hb=refs/heads/develop
Re: reduce creation time of view in mobile app
Posted by Frank Dahmen <fr...@dahmenia.de>.
that's why I said "magic" not "unpleasant" :)
i measured in release mode:
creationcomplete is fired after ca. 3 - 3.5 sec
than the remote request is started and upon result the controls are
"configured"
this takes about 1 - 1.2 sec
I think I leave it as it is, and ask the customer if splitting in
several views would be an option (before diving in the "unpleasant"
stuff ;))
thanks
Am 28.11.2016 um 14:30 schrieb Vincent:
> It's always a question of requirements, if 5 s is ok for the use case,
> then may be it is not worth spending too much time on it.
>
> Unfortunately, the only magic technique than I know when it comes to
> increase performance on mobile (for complexes views a least) is to
> give up on some of the things that make flex for desktop so powerfull
> and pleasant to use : mxml, nested containers and data binding.
>
> if destructionpolicy=never didn't help the second time the view is
> pushed, it's probably a clue that a the invalidation process takes a
> lot of time.
>
>
>
>
> Le 28/11/2016 13:28, Frank Dahmen a crit :
>> would be over 10000px high ;)
>>
>> but 5 sec. (not in debug mode) is almost ok
>> it IS huge and there is a lot of stuff going on
>> I know, spending some days and revise all components (and make it
>> more complicated) i could lower it 1,2 seconds...... i guess
>> I thought there are some "magic" techniques, like offscreen rendering
>> or such.
>> (destructionpolicy=never did not help)
>>
>>
>>
>>
>>
>>
>> Am 28.11.2016 um 12:29 schrieb Vincent:
>>> I said not always ;-)
>>>
>>> can you show a screen capture of the view ?
>>>
>>>
>>> Le 28/11/2016 12:25, Frank Dahmen a crit :
>>>> thanks,
>>>>
>>>> yes, I know, but as you said, not easy
>>>>
>>>>
>>>>
>>>> Am 28.11.2016 um 11:46 schrieb Vincent:
>>>>> Hi,
>>>>>
>>>>> If it takes 2s on desktop, it is very likely that the process will
>>>>> cost at least twice more on mobile (and probably a lot more on low
>>>>> end devices)You can set the destructionPolicy property of the View
>>>>> to never, so the view is just created once, the downside is memory
>>>>> consumption.
>>>>>
>>>>> The only way to reduce creation time is to simplify the
>>>>> organization of the controls inside the view : dozens of nested
>>>>> groups hurts performance very badly. It's not always easy but you
>>>>> should work on a solution to make the view shallower.
>>>>>
>>>>> Le 28/11/2016 09:43, Frank Dahmen a crit :
>>>>>> Thanks,
>>>>>>
>>>>>> the view is really, really huge so 2 seconds would be perfect ok
>>>>>>
>>>>>> Yes seperate views would work I guess, but when the view is
>>>>>> loaded once its's very fast to use
>>>>>> (fast scrolling etc.)
>>>>>> and when switching between views, the overall "use-time"
>>>>>> wouldn't be better i think
>>>>>>
>>>>>> ........I am an idiot......just tested in test mode not in debug
>>>>>> mode (in FlashDevelop)
>>>>>> and now it only takes 5 seconds.......which is almost ok
>>>>>>
>>>>>> but what do you mean with the sections?
>>>>>> as i said, each time the view is created it fetches data from a
>>>>>> server and configures all controls
>>>>>> yes they are grouped in (visual) sections
>>>>>> so create and configure them but not show them?
>>>>>>
>>>>>> think of the view like a VGroup in a scroller
>>>>>> inside this VGroup are 10 other VGroups and each of them has 10
>>>>>> Buttons
>>>>>> on result of the remote request each buttons label is set
>>>>>> this is simplified, and sounds like i should use a DataGroup or
>>>>>> such,
>>>>>> but the controls are all custom, and some have complex functionality
>>>>>>
>>>>>> how to do this "section-lazy-loading"?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Am 28.11.2016 um 09:00 schrieb OmPrakash Muppirala:
>>>>>>> Hmm, 2 seconds on a desktop is quite slow :-( Perhaps you can
>>>>>>> create
>>>>>>> separate views and load them on demand? Or is the view completely
>>>>>>> customizable?
>>>>>>>
>>>>>>> Also, on your device, are you running the release build or debug
>>>>>>> build?
>>>>>>>
>>>>>>> You could also create sections in the View and as each section
>>>>>>> becomes
>>>>>>> visible, create those children only then.
>>>>>>>
>>>>>>> You can use Adobe Scout to get a better understanding of the
>>>>>>> bottlenecks in
>>>>>>> your code.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Om
>>>>>>>
>>>>>>> On Sun, Nov 27, 2016 at 11:46 PM, Frank Dahmen
>>>>>>> <fr...@dahmenia.de> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>> in my app i have a really huge View with lots...lots! of
>>>>>>>> (custom)controls.
>>>>>>>> When i push this view or pop back to this view it takes several
>>>>>>>> seconds.
>>>>>>>> On create it makes a remote request and on result it configures
>>>>>>>> the
>>>>>>>> controls (adds childs to control, changs states, sets data....)
>>>>>>>> The remote request itself takes about 700ms which is ok.
>>>>>>>>
>>>>>>>> When i run the app on the desktop creation time is quite fast,
>>>>>>>> 2 seconds
>>>>>>>> but on my htc it's 8-10 seconds
>>>>>>>> What strategies can//I apply to reduce this a bit (3-5 seconds)?
>>>>>>>> I tried to set destructionPolicy=never, but no real effect
>>>>>>>> Can I somehow measure what takes how long?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: reduce creation time of view in mobile app
Posted by Vincent <vi...@after24.net>.
It's always a question of requirements, if 5 s is ok for the use case,
then may be it is not worth spending too much time on it.
Unfortunately, the only magic technique than I know when it comes to
increase performance on mobile (for complexes views a least) is to give
up on some of the things that make flex for desktop so powerfull and
pleasant to use : mxml, nested containers and data binding.
if destructionpolicy=never didn't help the second time the view is
pushed, it's probably a clue that a the invalidation process takes a lot
of time.
Le 28/11/2016 13:28, Frank Dahmen a crit :
> would be over 10000px high ;)
>
> but 5 sec. (not in debug mode) is almost ok
> it IS huge and there is a lot of stuff going on
> I know, spending some days and revise all components (and make it more
> complicated) i could lower it 1,2 seconds...... i guess
> I thought there are some "magic" techniques, like offscreen rendering
> or such.
> (destructionpolicy=never did not help)
>
>
>
>
>
>
> Am 28.11.2016 um 12:29 schrieb Vincent:
>> I said not always ;-)
>>
>> can you show a screen capture of the view ?
>>
>>
>> Le 28/11/2016 12:25, Frank Dahmen a crit :
>>> thanks,
>>>
>>> yes, I know, but as you said, not easy
>>>
>>>
>>>
>>> Am 28.11.2016 um 11:46 schrieb Vincent:
>>>> Hi,
>>>>
>>>> If it takes 2s on desktop, it is very likely that the process will
>>>> cost at least twice more on mobile (and probably a lot more on low
>>>> end devices)You can set the destructionPolicy property of the View
>>>> to never, so the view is just created once, the downside is memory
>>>> consumption.
>>>>
>>>> The only way to reduce creation time is to simplify the
>>>> organization of the controls inside the view : dozens of nested
>>>> groups hurts performance very badly. It's not always easy but you
>>>> should work on a solution to make the view shallower.
>>>>
>>>> Le 28/11/2016 09:43, Frank Dahmen a crit :
>>>>> Thanks,
>>>>>
>>>>> the view is really, really huge so 2 seconds would be perfect ok
>>>>>
>>>>> Yes seperate views would work I guess, but when the view is loaded
>>>>> once its's very fast to use
>>>>> (fast scrolling etc.)
>>>>> and when switching between views, the overall "use-time" wouldn't
>>>>> be better i think
>>>>>
>>>>> ........I am an idiot......just tested in test mode not in debug
>>>>> mode (in FlashDevelop)
>>>>> and now it only takes 5 seconds.......which is almost ok
>>>>>
>>>>> but what do you mean with the sections?
>>>>> as i said, each time the view is created it fetches data from a
>>>>> server and configures all controls
>>>>> yes they are grouped in (visual) sections
>>>>> so create and configure them but not show them?
>>>>>
>>>>> think of the view like a VGroup in a scroller
>>>>> inside this VGroup are 10 other VGroups and each of them has 10
>>>>> Buttons
>>>>> on result of the remote request each buttons label is set
>>>>> this is simplified, and sounds like i should use a DataGroup or such,
>>>>> but the controls are all custom, and some have complex functionality
>>>>>
>>>>> how to do this "section-lazy-loading"?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Am 28.11.2016 um 09:00 schrieb OmPrakash Muppirala:
>>>>>> Hmm, 2 seconds on a desktop is quite slow :-( Perhaps you can
>>>>>> create
>>>>>> separate views and load them on demand? Or is the view completely
>>>>>> customizable?
>>>>>>
>>>>>> Also, on your device, are you running the release build or debug
>>>>>> build?
>>>>>>
>>>>>> You could also create sections in the View and as each section
>>>>>> becomes
>>>>>> visible, create those children only then.
>>>>>>
>>>>>> You can use Adobe Scout to get a better understanding of the
>>>>>> bottlenecks in
>>>>>> your code.
>>>>>>
>>>>>> Thanks,
>>>>>> Om
>>>>>>
>>>>>> On Sun, Nov 27, 2016 at 11:46 PM, Frank Dahmen
>>>>>> <fr...@dahmenia.de> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>> in my app i have a really huge View with lots...lots! of
>>>>>>> (custom)controls.
>>>>>>> When i push this view or pop back to this view it takes several
>>>>>>> seconds.
>>>>>>> On create it makes a remote request and on result it configures the
>>>>>>> controls (adds childs to control, changs states, sets data....)
>>>>>>> The remote request itself takes about 700ms which is ok.
>>>>>>>
>>>>>>> When i run the app on the desktop creation time is quite fast, 2
>>>>>>> seconds
>>>>>>> but on my htc it's 8-10 seconds
>>>>>>> What strategies can//I apply to reduce this a bit (3-5 seconds)?
>>>>>>> I tried to set destructionPolicy=never, but no real effect
>>>>>>> Can I somehow measure what takes how long?
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: reduce creation time of view in mobile app
Posted by Frank Dahmen <fr...@dahmenia.de>.
would be over 10000px high ;)
but 5 sec. (not in debug mode) is almost ok
it IS huge and there is a lot of stuff going on
I know, spending some days and revise all components (and make it more
complicated) i could lower it 1,2 seconds...... i guess
I thought there are some "magic" techniques, like offscreen rendering or
such.
(destructionpolicy=never did not help)
Am 28.11.2016 um 12:29 schrieb Vincent:
> I said not always ;-)
>
> can you show a screen capture of the view ?
>
>
> Le 28/11/2016 12:25, Frank Dahmen a crit :
>> thanks,
>>
>> yes, I know, but as you said, not easy
>>
>>
>>
>> Am 28.11.2016 um 11:46 schrieb Vincent:
>>> Hi,
>>>
>>> If it takes 2s on desktop, it is very likely that the process will
>>> cost at least twice more on mobile (and probably a lot more on low
>>> end devices)You can set the destructionPolicy property of the View
>>> to never, so the view is just created once, the downside is memory
>>> consumption.
>>>
>>> The only way to reduce creation time is to simplify the organization
>>> of the controls inside the view : dozens of nested groups hurts
>>> performance very badly. It's not always easy but you should work on
>>> a solution to make the view shallower.
>>>
>>> Le 28/11/2016 09:43, Frank Dahmen a crit :
>>>> Thanks,
>>>>
>>>> the view is really, really huge so 2 seconds would be perfect ok
>>>>
>>>> Yes seperate views would work I guess, but when the view is loaded
>>>> once its's very fast to use
>>>> (fast scrolling etc.)
>>>> and when switching between views, the overall "use-time" wouldn't
>>>> be better i think
>>>>
>>>> ........I am an idiot......just tested in test mode not in debug
>>>> mode (in FlashDevelop)
>>>> and now it only takes 5 seconds.......which is almost ok
>>>>
>>>> but what do you mean with the sections?
>>>> as i said, each time the view is created it fetches data from a
>>>> server and configures all controls
>>>> yes they are grouped in (visual) sections
>>>> so create and configure them but not show them?
>>>>
>>>> think of the view like a VGroup in a scroller
>>>> inside this VGroup are 10 other VGroups and each of them has 10
>>>> Buttons
>>>> on result of the remote request each buttons label is set
>>>> this is simplified, and sounds like i should use a DataGroup or such,
>>>> but the controls are all custom, and some have complex functionality
>>>>
>>>> how to do this "section-lazy-loading"?
>>>>
>>>>
>>>>
>>>>
>>>> Am 28.11.2016 um 09:00 schrieb OmPrakash Muppirala:
>>>>> Hmm, 2 seconds on a desktop is quite slow :-( Perhaps you can create
>>>>> separate views and load them on demand? Or is the view completely
>>>>> customizable?
>>>>>
>>>>> Also, on your device, are you running the release build or debug
>>>>> build?
>>>>>
>>>>> You could also create sections in the View and as each section
>>>>> becomes
>>>>> visible, create those children only then.
>>>>>
>>>>> You can use Adobe Scout to get a better understanding of the
>>>>> bottlenecks in
>>>>> your code.
>>>>>
>>>>> Thanks,
>>>>> Om
>>>>>
>>>>> On Sun, Nov 27, 2016 at 11:46 PM, Frank Dahmen <fr...@dahmenia.de>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>> in my app i have a really huge View with lots...lots! of
>>>>>> (custom)controls.
>>>>>> When i push this view or pop back to this view it takes several
>>>>>> seconds.
>>>>>> On create it makes a remote request and on result it configures the
>>>>>> controls (adds childs to control, changs states, sets data....)
>>>>>> The remote request itself takes about 700ms which is ok.
>>>>>>
>>>>>> When i run the app on the desktop creation time is quite fast, 2
>>>>>> seconds
>>>>>> but on my htc it's 8-10 seconds
>>>>>> What strategies can//I apply to reduce this a bit (3-5 seconds)?
>>>>>> I tried to set destructionPolicy=never, but no real effect
>>>>>> Can I somehow measure what takes how long?
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>
Re: reduce creation time of view in mobile app
Posted by Vincent <vi...@after24.net>.
I said not always ;-)
can you show a screen capture of the view ?
Le 28/11/2016 12:25, Frank Dahmen a crit :
> thanks,
>
> yes, I know, but as you said, not easy
>
>
>
> Am 28.11.2016 um 11:46 schrieb Vincent:
>> Hi,
>>
>> If it takes 2s on desktop, it is very likely that the process will
>> cost at least twice more on mobile (and probably a lot more on low
>> end devices)You can set the destructionPolicy property of the View to
>> never, so the view is just created once, the downside is memory
>> consumption.
>>
>> The only way to reduce creation time is to simplify the organization
>> of the controls inside the view : dozens of nested groups hurts
>> performance very badly. It's not always easy but you should work on a
>> solution to make the view shallower.
>>
>> Le 28/11/2016 09:43, Frank Dahmen a crit :
>>> Thanks,
>>>
>>> the view is really, really huge so 2 seconds would be perfect ok
>>>
>>> Yes seperate views would work I guess, but when the view is loaded
>>> once its's very fast to use
>>> (fast scrolling etc.)
>>> and when switching between views, the overall "use-time" wouldn't
>>> be better i think
>>>
>>> ........I am an idiot......just tested in test mode not in debug
>>> mode (in FlashDevelop)
>>> and now it only takes 5 seconds.......which is almost ok
>>>
>>> but what do you mean with the sections?
>>> as i said, each time the view is created it fetches data from a
>>> server and configures all controls
>>> yes they are grouped in (visual) sections
>>> so create and configure them but not show them?
>>>
>>> think of the view like a VGroup in a scroller
>>> inside this VGroup are 10 other VGroups and each of them has 10 Buttons
>>> on result of the remote request each buttons label is set
>>> this is simplified, and sounds like i should use a DataGroup or such,
>>> but the controls are all custom, and some have complex functionality
>>>
>>> how to do this "section-lazy-loading"?
>>>
>>>
>>>
>>>
>>> Am 28.11.2016 um 09:00 schrieb OmPrakash Muppirala:
>>>> Hmm, 2 seconds on a desktop is quite slow :-( Perhaps you can create
>>>> separate views and load them on demand? Or is the view completely
>>>> customizable?
>>>>
>>>> Also, on your device, are you running the release build or debug
>>>> build?
>>>>
>>>> You could also create sections in the View and as each section becomes
>>>> visible, create those children only then.
>>>>
>>>> You can use Adobe Scout to get a better understanding of the
>>>> bottlenecks in
>>>> your code.
>>>>
>>>> Thanks,
>>>> Om
>>>>
>>>> On Sun, Nov 27, 2016 at 11:46 PM, Frank Dahmen <fr...@dahmenia.de>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>> in my app i have a really huge View with lots...lots! of
>>>>> (custom)controls.
>>>>> When i push this view or pop back to this view it takes several
>>>>> seconds.
>>>>> On create it makes a remote request and on result it configures the
>>>>> controls (adds childs to control, changs states, sets data....)
>>>>> The remote request itself takes about 700ms which is ok.
>>>>>
>>>>> When i run the app on the desktop creation time is quite fast, 2
>>>>> seconds
>>>>> but on my htc it's 8-10 seconds
>>>>> What strategies can//I apply to reduce this a bit (3-5 seconds)?
>>>>> I tried to set destructionPolicy=never, but no real effect
>>>>> Can I somehow measure what takes how long?
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>>>
>>>
>>
>
Re: reduce creation time of view in mobile app
Posted by Frank Dahmen <fr...@dahmenia.de>.
thanks,
yes, I know, but as you said, not easy
Am 28.11.2016 um 11:46 schrieb Vincent:
> Hi,
>
> If it takes 2s on desktop, it is very likely that the process will
> cost at least twice more on mobile (and probably a lot more on low end
> devices)You can set the destructionPolicy property of the View to
> never, so the view is just created once, the downside is memory
> consumption.
>
> The only way to reduce creation time is to simplify the organization
> of the controls inside the view : dozens of nested groups hurts
> performance very badly. It's not always easy but you should work on a
> solution to make the view shallower.
>
> Le 28/11/2016 09:43, Frank Dahmen a crit :
>> Thanks,
>>
>> the view is really, really huge so 2 seconds would be perfect ok
>>
>> Yes seperate views would work I guess, but when the view is loaded
>> once its's very fast to use
>> (fast scrolling etc.)
>> and when switching between views, the overall "use-time" wouldn't be
>> better i think
>>
>> ........I am an idiot......just tested in test mode not in debug mode
>> (in FlashDevelop)
>> and now it only takes 5 seconds.......which is almost ok
>>
>> but what do you mean with the sections?
>> as i said, each time the view is created it fetches data from a
>> server and configures all controls
>> yes they are grouped in (visual) sections
>> so create and configure them but not show them?
>>
>> think of the view like a VGroup in a scroller
>> inside this VGroup are 10 other VGroups and each of them has 10 Buttons
>> on result of the remote request each buttons label is set
>> this is simplified, and sounds like i should use a DataGroup or such,
>> but the controls are all custom, and some have complex functionality
>>
>> how to do this "section-lazy-loading"?
>>
>>
>>
>>
>> Am 28.11.2016 um 09:00 schrieb OmPrakash Muppirala:
>>> Hmm, 2 seconds on a desktop is quite slow :-( Perhaps you can create
>>> separate views and load them on demand? Or is the view completely
>>> customizable?
>>>
>>> Also, on your device, are you running the release build or debug build?
>>>
>>> You could also create sections in the View and as each section becomes
>>> visible, create those children only then.
>>>
>>> You can use Adobe Scout to get a better understanding of the
>>> bottlenecks in
>>> your code.
>>>
>>> Thanks,
>>> Om
>>>
>>> On Sun, Nov 27, 2016 at 11:46 PM, Frank Dahmen <fr...@dahmenia.de>
>>> wrote:
>>>
>>>> Hi,
>>>> in my app i have a really huge View with lots...lots! of
>>>> (custom)controls.
>>>> When i push this view or pop back to this view it takes several
>>>> seconds.
>>>> On create it makes a remote request and on result it configures the
>>>> controls (adds childs to control, changs states, sets data....)
>>>> The remote request itself takes about 700ms which is ok.
>>>>
>>>> When i run the app on the desktop creation time is quite fast, 2
>>>> seconds
>>>> but on my htc it's 8-10 seconds
>>>> What strategies can//I apply to reduce this a bit (3-5 seconds)?
>>>> I tried to set destructionPolicy=never, but no real effect
>>>> Can I somehow measure what takes how long?
>>>>
>>>> Thanks
>>>>
>>>>
>>>>
>>
>
Re: reduce creation time of view in mobile app
Posted by Vincent <vi...@after24.net>.
Hi,
If it takes 2s on desktop, it is very likely that the process will cost
at least twice more on mobile (and probably a lot more on low end
devices)You can set the destructionPolicy property of the View to never,
so the view is just created once, the downside is memory consumption.
The only way to reduce creation time is to simplify the organization of
the controls inside the view : dozens of nested groups hurts performance
very badly. It's not always easy but you should work on a solution to
make the view shallower.
Le 28/11/2016 09:43, Frank Dahmen a crit :
> Thanks,
>
> the view is really, really huge so 2 seconds would be perfect ok
>
> Yes seperate views would work I guess, but when the view is loaded
> once its's very fast to use
> (fast scrolling etc.)
> and when switching between views, the overall "use-time" wouldn't be
> better i think
>
> ........I am an idiot......just tested in test mode not in debug mode
> (in FlashDevelop)
> and now it only takes 5 seconds.......which is almost ok
>
> but what do you mean with the sections?
> as i said, each time the view is created it fetches data from a server
> and configures all controls
> yes they are grouped in (visual) sections
> so create and configure them but not show them?
>
> think of the view like a VGroup in a scroller
> inside this VGroup are 10 other VGroups and each of them has 10 Buttons
> on result of the remote request each buttons label is set
> this is simplified, and sounds like i should use a DataGroup or such,
> but the controls are all custom, and some have complex functionality
>
> how to do this "section-lazy-loading"?
>
>
>
>
> Am 28.11.2016 um 09:00 schrieb OmPrakash Muppirala:
>> Hmm, 2 seconds on a desktop is quite slow :-( Perhaps you can create
>> separate views and load them on demand? Or is the view completely
>> customizable?
>>
>> Also, on your device, are you running the release build or debug build?
>>
>> You could also create sections in the View and as each section becomes
>> visible, create those children only then.
>>
>> You can use Adobe Scout to get a better understanding of the
>> bottlenecks in
>> your code.
>>
>> Thanks,
>> Om
>>
>> On Sun, Nov 27, 2016 at 11:46 PM, Frank Dahmen <fr...@dahmenia.de>
>> wrote:
>>
>>> Hi,
>>> in my app i have a really huge View with lots...lots! of
>>> (custom)controls.
>>> When i push this view or pop back to this view it takes several
>>> seconds.
>>> On create it makes a remote request and on result it configures the
>>> controls (adds childs to control, changs states, sets data....)
>>> The remote request itself takes about 700ms which is ok.
>>>
>>> When i run the app on the desktop creation time is quite fast, 2
>>> seconds
>>> but on my htc it's 8-10 seconds
>>> What strategies can//I apply to reduce this a bit (3-5 seconds)?
>>> I tried to set destructionPolicy=never, but no real effect
>>> Can I somehow measure what takes how long?
>>>
>>> Thanks
>>>
>>>
>>>
>
Re: reduce creation time of view in mobile app
Posted by Frank Dahmen <fr...@dahmenia.de>.
Thanks,
the view is really, really huge so 2 seconds would be perfect ok
Yes seperate views would work I guess, but when the view is loaded once
its's very fast to use
(fast scrolling etc.)
and when switching between views, the overall "use-time" wouldn't be
better i think
........I am an idiot......just tested in test mode not in debug mode
(in FlashDevelop)
and now it only takes 5 seconds.......which is almost ok
but what do you mean with the sections?
as i said, each time the view is created it fetches data from a server
and configures all controls
yes they are grouped in (visual) sections
so create and configure them but not show them?
think of the view like a VGroup in a scroller
inside this VGroup are 10 other VGroups and each of them has 10 Buttons
on result of the remote request each buttons label is set
this is simplified, and sounds like i should use a DataGroup or such,
but the controls are all custom, and some have complex functionality
how to do this "section-lazy-loading"?
Am 28.11.2016 um 09:00 schrieb OmPrakash Muppirala:
> Hmm, 2 seconds on a desktop is quite slow :-( Perhaps you can create
> separate views and load them on demand? Or is the view completely
> customizable?
>
> Also, on your device, are you running the release build or debug build?
>
> You could also create sections in the View and as each section becomes
> visible, create those children only then.
>
> You can use Adobe Scout to get a better understanding of the bottlenecks in
> your code.
>
> Thanks,
> Om
>
> On Sun, Nov 27, 2016 at 11:46 PM, Frank Dahmen <fr...@dahmenia.de> wrote:
>
>> Hi,
>> in my app i have a really huge View with lots...lots! of (custom)controls.
>> When i push this view or pop back to this view it takes several seconds.
>> On create it makes a remote request and on result it configures the
>> controls (adds childs to control, changs states, sets data....)
>> The remote request itself takes about 700ms which is ok.
>>
>> When i run the app on the desktop creation time is quite fast, 2 seconds
>> but on my htc it's 8-10 seconds
>> What strategies can//I apply to reduce this a bit (3-5 seconds)?
>> I tried to set destructionPolicy=never, but no real effect
>> Can I somehow measure what takes how long?
>>
>> Thanks
>>
>>
>>
Re: reduce creation time of view in mobile app
Posted by OmPrakash Muppirala <bi...@gmail.com>.
Hmm, 2 seconds on a desktop is quite slow :-( Perhaps you can create
separate views and load them on demand? Or is the view completely
customizable?
Also, on your device, are you running the release build or debug build?
You could also create sections in the View and as each section becomes
visible, create those children only then.
You can use Adobe Scout to get a better understanding of the bottlenecks in
your code.
Thanks,
Om
On Sun, Nov 27, 2016 at 11:46 PM, Frank Dahmen <fr...@dahmenia.de> wrote:
> Hi,
> in my app i have a really huge View with lots...lots! of (custom)controls.
> When i push this view or pop back to this view it takes several seconds.
> On create it makes a remote request and on result it configures the
> controls (adds childs to control, changs states, sets data....)
> The remote request itself takes about 700ms which is ok.
>
> When i run the app on the desktop creation time is quite fast, 2 seconds
> but on my htc it's 8-10 seconds
> What strategies can//I apply to reduce this a bit (3-5 seconds)?
> I tried to set destructionPolicy=never, but no real effect
> Can I somehow measure what takes how long?
>
> Thanks
>
>
>
reduce creation time of view in mobile app
Posted by Frank Dahmen <fr...@dahmenia.de>.
Hi,
in my app i have a really huge View with lots...lots! of (custom)controls.
When i push this view or pop back to this view it takes several seconds.
On create it makes a remote request and on result it configures the
controls (adds childs to control, changs states, sets data....)
The remote request itself takes about 700ms which is ok.
When i run the app on the desktop creation time is quite fast, 2 seconds
but on my htc it's 8-10 seconds
What strategies can//I apply to reduce this a bit (3-5 seconds)?
I tried to set destructionPolicy=never, but no real effect
Can I somehow measure what takes how long?
Thanks
Re: Calls to superclass failing
Posted by doug777 <do...@gmail.com>.
I don't think the stack traces help as they only relate to the error caused.
For example here is the trace for a DataGrid that uses a custom skin.
TypeError: Error #1009: Cannot access a property or method of a null object
reference.
at
spark.components::GridColumnHeaderGroup/getHeaderRendererAt()[/Users/justinmclean/Documents/ApacheFlex4.15/frameworks/projects/spark/src/spark/components/GridColumnHeaderGroup.as:921]
at
spark.components::GridColumnHeaderGroup/dispatchGridEvent()[/Users/justinmclean/Documents/ApacheFlex4.15/frameworks/projects/spark/src/spark/components/GridColumnHeaderGroup.as:1266]
at
spark.components::GridColumnHeaderGroup/gchg_mouseDownDragUpHandler()[/Users/justinmclean/Documents/ApacheFlex4.15/frameworks/projects/spark/src/spark/components/GridColumnHeaderGroup.as:1112]
at
Function/<anonymous>()[/Users/justinmclean/Documents/ApacheFlex4.15/frameworks/projects/spark/src/spark/utils/MouseEventUtil.as:104]
This is caused by clicking in the header row that should contain the header
data, but doesn't because after the dataProvider is filled, presumably the
skin can't update the display list.
If I delete the custom skin and just use the default skin, everything works
fine except it doesn't look the way I want it to.
This modified DataGridSkin looks like this - relevant part only -
<s:SparkSkin
xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/mx"
xmlns:fb="http://ns.adobe.com/flashbuilder/2009"
alpha.disabled="0.5" minWidth="89" minHeight="84"
xmlns:main="com.booxotel.ibe.skins.main.*">
override protected function initializationComplete():void
{
useChromeColor = true;
super.initializationComplete();
}
/**
* @private
*/
override protected function updateDisplayList(unscaledWidth:Number,
unscaledHeight:Number):void
{
if (getStyle("borderVisible") == true)
{
border.visible = true;
background.left = background.top = background.right =
background.bottom = 1;
scroller.minViewportInset = 1;
}
else
{
border.visible = false;
background.left = background.top = background.right =
background.bottom = 0;
scroller.minViewportInset = 0;
}
borderStroke.color = getStyle("borderColor");
borderStroke.alpha = getStyle("borderAlpha");
super.updateDisplayList(unscaledWidth, unscaledHeight);
}
</s:SparkSkin>
Both of the calls to super have the warning message, the same as my other
skins.
In other skins things like [Inspectable] , defaultSortIndicator also have
the warning.
Doug
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Calls-to-superclass-failing-tp14230p14236.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Calls to superclass failing
Posted by Alex Harui <ah...@adobe.com>.
On 11/27/16, 10:16 PM, "doug777" <do...@gmail.com> wrote:
>There is no Skin class in my project's folder. None of my skins have names
>that are the same as any sdk skin.
>
>Most of the components using the skins eventually fail with a null object
>error and in the debugger I can see that the ultimate cause of the problem
>seems to be that it can't find the Skin class and the address it's looking
>at is in my project's skins folder.
Are you getting a compile error or runtime error? If runtime, post the
stack trace.
-Alex
Re: Calls to superclass failing
Posted by doug777 <do...@gmail.com>.
There is no Skin class in my project's folder. None of my skins have names
that are the same as any sdk skin.
Most of the components using the skins eventually fail with a null object
error and in the debugger I can see that the ultimate cause of the problem
seems to be that it can't find the Skin class and the address it's looking
at is in my project's skins folder.
Doug
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Calls-to-superclass-failing-tp14230p14234.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Calls to superclass failing
Posted by Alex Harui <ah...@adobe.com>.
On 11/27/16, 6:01 PM, "doug777" <do...@gmail.com> wrote:
>
>Tracing the problem shows me that Flex is trying to find the superclass in
>my project's skins folder and not in the sdk.
How did you determine this?
Is there a Skin.as in your project's skin folder?
-ALex