[Flashcoders] static const singleton & GC?

[ktu]

hey all!

I'm faced with an interesting question.

in my codebase, we made the decision to use a few singletons. to implement
those singletons we used the static const trick:

package com.example {
public static const API:AppAPI = new AppAPI();
}

package com.example {
public class AppAPI {
public function AppAPI () {
if (API) throw new Error();
}
}

this works fine in the normal environment we run in. that is, we run in a
scheduler system that loads the flash player, runs our swf, then shuts down
the flash player, doing that over and over again based off the schedule of
content. the problem now is that a new client uses a scheduler that is
built on AIR, so the flash player instance never shuts down. whenever our
app comes up in the scheduler, memory jumps and never goes down causing the
AIR app to crash every couple of hours. If, they load my application only
once, and leave it running, it lasts for days without any major memory
leaks.

any idea how i could test whether GC does pick this up or could? or any
known issues with this trick and GC? maybe you just have tricks in general
to finding out what GC isn't getting?

thanks!!!

--
Ktu;

The information contained in this message may or may not be privileged
and/or confidential. If you are NOT the intended recipient,
congratulations, you got mail!
_______________________________________________
Flashcoders mailing list
Flash...@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

[ktu]

anybody have any ideas?
this is still shaking my boots.

thanks :)

[Paul A.]

What if you make the const a var?

I don't build my singletons with an initialiser, but whether that makes
any difference, who knows?

I always make my singleton references explicit, ClassName.getInstance()
and instantiate the instance in getInstance().

[Ross P. Sclafani]

Singletons are a horrible design pattern and the fact that they're poorly implemented in as3 should steer you away from using them there.

Sent from my iPhone

[Peter Ginneberge]

That's not a singleton, as every time you call the public static constant, it creates a new instance.

The static var should be private and the class needs an access point method, usually called getInstance();

private static var INSTANCE:AppApi;

public function AppApi():void {
if (INSTANCE != null ) {
throw new Error("Only one instance allowed. " +
"To access the Singleton instance, use getInstance().");
}
}

public static function getInstance():AppApi{
if(!INSTANCE) INSTANCE = new AppApi();
return INSTANCE;
}


Then elsewhere in your app you refer to the singleton with:
AppApi.getInstance();

[Paul A.]

It's not exactly the greatest programming sin and they work fine in AS3.

If the OP has a project in place using them, he should continue to do so
once the issue is solved.

Singletons are hardly a maverick technique.

[Henrik Andersson]

There is no such thing as calling a constant. And static properties are
only initialized once.

Your approach only serves to delay the construction of the instance to
the moment it is first accessed, as opposed to when the runtime decides
to initialize the constant.

What OP needs is a singleton that can be destructed. The problem here is
that the constant that is holding a reference to the instance never
leaves scope and can't be changed not to point at the instance.

The way I would do it would be to either fix the scheduler to correctly
terminate the flash player or to reuse the flash player instead of
spawning a new one each time.

In fact, I doubt that OP actually means "flash player", but rather means
"a random swf file that I load every so often". That would be a prime
example of where reuse is the correct approach.

Peter Ginneberge skriver:

> That's not a singleton, as every time you call the public static
> constant, it creates a new instance.
>
> The static var should be private and the class needs an access point
> method, usually called getInstance();
>
> private static var INSTANCE:AppApi;
>
> public function AppApi():void {
> if (INSTANCE != null ) {
> throw new Error("Only one instance allowed. " +
> "To access the Singleton instance, use getInstance()."); }
> }
>
> public static function getInstance():AppApi{
> if(!INSTANCE) INSTANCE = new AppApi();
> return INSTANCE;
> }
>
>
> Then elsewhere in your app you refer to the singleton with:
> AppApi.getInstance();
>
>

[ktu]

first, i must apologize for an error in my code. you cannot make a static
package level var. the code should look like:

package com.example {
public const API:AppAPI = new AppAPI();
}

Peter, this crazy method i am using does indeed only instantiate the object
only once. i never get a runtime error in accessing the API through the
package level const.

thanks Paul. I made a simple test project and have determined that if i
make it a var instead of const, everything is just fine. Next is to test
whether loading a swf that uses it as a var versus const will allow garbage
collection to pick it up. man, i haven't used a profile in ages.

Henrik, you are right, but i don't think i am wrong about the "flash
player" referencing.

in this special case, the scheduler is built in flash on top of AIR. they
load my swf, then stopAndUnload my swf, show another swf, show an image,
then RELOAD my swf (and by reload i mean loader.loadBytes()), and so on...
so the flash player is never shutting down.

in normal cases, the scheduler is built outside of AIR, so when someone
wants to run our content, the scheduler boots up the flash player only to
play my swf, then shuts it down. even if the scheduler had two back to back
swfs, the flash player instance is always shut down before the new one
opens.

Thanks for your input everyone!

--
Ktu;

The information contained in this message may or may not be privileged
and/or confidential. If you are NOT the intended recipient,
congratulations, you got mail!

[Paul A.]

I'm working on a project that includes a number of panels upon which are
images.

These images have been imported from photoshop.

The images are basically cut out from a solid background and have a
crude border around them.

The panel background is a solid colour.

If you are looking well enough, the edges of the images can be seen.

Looking in the photoshop document, the edges of the images cannot be
seen against the background (which is on a seperate layer).

Colour sampling in photoshop of the solid panel background shows a solid
colour. Doing the same around the edges of the images shows that the
colour does vary.

Because of the variation in colour I would expect a bit of an edge to be
visible, but I can't detect it in photoshop.

It's possible that some of these assets were loaded into flash with some
compression - I'll need to investigate, but I'm wondering if I'm on a
hiding to nothing trying to eradicate this faint edge around the assets.

Anyone else come up against this? First time for it to be an issue for me.

[David Cohn]

The solid color may be because you're sampling the color of the layer in photoshop, rather than the anti-aliased image as in Flash.
Could you try exporting from photoshop as a jpeg-- that way you would at least see what's happening in the compression?

[Paul A.]

On 05/11/2013 19:13, David Cohn wrote:
> The solid color may be because you're sampling the color of the layer in photoshop, rather than the anti-aliased image as in Flash.
> Could you try exporting from photoshop as a jpeg-- that way you would at least see what's happening in the compression?

I had a chat with the designer and an alternative solution was proposed
( it's only possible because elements that sit on top of each other on
the panels can cover up the background without creating artifacts).

The solution is to create a single image of the panel with images in
situ. The items on the panel are dragged off, so a MC with a small
alpha, can be dragged and a covering graphic shown that hides the
original image.

So problem solved, but quite a bit of work redoing the app.

Paul