R – the best way to share assets – icons/images – across multiple Flex applications

actionscript-3apache-flexswc

I am in the process of creating a new – "lite" – version of a Flex application I created a while ago. I have been porting over many of the Classes and Components to a Flex Library Project that compiles an SWC file. Because both are Cairngorm applications, I'm not able to completely eradicate duplicate code, but it seems logical that I should be able to share assets – such as icons (PNG files). What is the best way to do this? I have tried including them in the SWC, but I can't figure out how to access them in the application. If you can help me figure that out, then my question will be answered. Any thoughts?

Here is and example of how I currently embed icons/images in my Flex application:

<mx:Script>
    <![CDATA[
        [Bindable]
        [Embed(source="assets/icons/cancelIcon.png")]
        private var cancelIcon:Class;

        [Bindable]
        [Embed(source="assets/icons/saveIcon.png")]
        private var saveIcon:Class;
    ]]>
</mx:Script>

Thanks.

Best Answer

0) First, looking at the code above - I recommend some minor changes:

// Actionscript instead of MXML:
public class ResourceClasses
{
        Bindable]
        [Embed(source="assets/icons/cancelIcon.png")]
        public static var CancelIconClass:Class;

        // make your variable public and static without public no one 
        // outside the class can access AND bindable won't matter
}

---- Now, compile your library. ---- If the assets aren't in the right place the compiler will complain

1) In your application, you need to reference the library project / swc

---- You should be able to get code hints / intellisense in Flex Builder / eclipse from classes in your Application to classes in the library project

2) In your Application - Do some code like this:

var image:Image = new Image();
image.source = ResourceClasses.CancelIconClass;

// more image property setting... 

someCanvas.addChild(image);

3) This will get you going - using a Library project to hold images, etc...

*** DO NOTE: If the images need to be loaded multiple times, reused, etc -- There are other steps to take to squeeze out the best performance, etc...

Related Solutions

Php – the best way to stop people hacking the PHP-based highscore table of a Flash game

This is a classic problem with Internet games and contests. Your Flash code works with users to decide a score for a game. But users aren't trusted, and the Flash code runs on the user's computer. You're SOL. There is nothing you can do to prevent an attacker from forging high scores:

Flash is even easier to reverse engineer than you might think it is, since the bytecodes are well documented and describe a high-level language (Actionscript) --- when you publish a Flash game, you're publishing your source code, whether you know it or not.
Attackers control the runtime memory of the Flash interpreter, so that anyone who knows how to use a programmable debugger can alter any variable (including the current score) at any time, or alter the program itself.

The simplest possible attack against your system is to run the HTTP traffic for the game through a proxy, catch the high-score save, and replay it with a higher score.

You can try to block this attack by binding each high score save to a single instance of the game, for instance by sending an encrypted token to the client at game startup, which might look like:

hex-encoding( AES(secret-key-stored-only-on-server, timestamp, user-id, random-number))

(You could also use a session cookie to the same effect).

The game code echoes this token back to the server with the high-score save. But an attacker can still just launch the game again, get a token, and then immediately paste that token into a replayed high-score save.

So next you feed not only a token or session cookie, but also a high-score-encrypting session key. This will be a 128 bit AES key, itself encrypted with a key hardcoded into the Flash game:

hex-encoding( AES(key-hardcoded-in-flash-game, random-128-bit-key))

Now before the game posts the high score, it decrypts the high-score-encrypting-session key, which it can do because you hardcoded the high-score-encrypting-session-key-decrypting-key into the Flash binary. You encrypt the high score with this decrypted key, along with the SHA1 hash of the high score:

hex-encoding( AES(random-128-bit-key-from-above, high-score, SHA1(high-score)))

The PHP code on the server checks the token to make sure the request came from a valid game instance, then decrypts the encrypted high score, checking to make sure the high-score matches the SHA1 of the high-score (if you skip this step, decryption will simply produce random, likely very high, high scores).

So now the attacker decompiles your Flash code and quickly finds the AES code, which sticks out like a sore thumb, although even if it didn't it'd be tracked down in 15 minutes with a memory search and a tracer ("I know my score for this game is 666, so let's find 666 in memory, then catch any operation that touches that value --- oh look, the high score encryption code!"). With the session key, the attacker doesn't even have to run the Flash code; she grabs a game launch token and a session key and can send back an arbitrary high score.

You're now at the point where most developers just give up --- give or take a couple months of messing with attackers by:

Scrambling the AES keys with XOR operations
Replacing key byte arrays with functions that calculate the key
Scattering fake key encryptions and high score postings throughout the binary.

This is all mostly a waste of time. It goes without saying, SSL isn't going to help you either; SSL can't protect you when one of the two SSL endpoints is evil.

Here are some things that can actually reduce high score fraud:

Require a login to play the game, have the login produce a session cookie, and don't allow multiple outstanding game launches on the same session, or multiple concurrent sessions for the same user.
Reject high scores from game sessions that last less than the shortest real games ever played (for a more sophisticated approach, try "quarantining" high scores for game sessions that last less than 2 standard deviations below the mean game duration). Make sure you're tracking game durations serverside.
Reject or quarantine high scores from logins that have only played the game once or twice, so that attackers have to produce a "paper trail" of reasonable looking game play for each login they create.
"Heartbeat" scores during game play, so that your server sees the score growth over the lifetime of one game play. Reject high scores that don't follow reasonable score curves (for instance, jumping from 0 to 999999).
"Snapshot" game state during game play (for instance, amount of ammunition, position in the level, etc), which you can later reconcile against recorded interim scores. You don't even have to have a way to detect anomalies in this data to start with; you just have to collect it, and then you can go back and analyze it if things look fishy.
Disable the account of any user who fails one of your security checks (for instance, by ever submitting an encrypted high score that fails validation).

Remember though that you're only deterring high score fraud here. There's nothing you can do to prevent if. If there's money on the line in your game, someone is going to defeat any system you come up with. The objective isn't to stop this attack; it's to make the attack more expensive than just getting really good at the game and beating it.

R – the best way to architect extended Cairngorm classes to be shared across applications

All the options you propose will work. However I would suggest to leave the Cairngorm sources and SWC as is and just create a separate SWC with your classes. You don't want to patch the Cairngorm sources each time they release a new version.

You have 2 options for compiling your custom SWC (in the build path options of the referenced libraries):

Externally reference the Cairngorm lib: you'll then need to link both the Cairngorm SWC and your custom SWC into your projects.
Merge the Cairngorm lib into your SWC: you'll only need to reference your lib if you make sure all Cairngorm classes are also compiled into it. Only the Cairngorm classes that you reference (by extending them for instance) will be merged into your custom SWC. You can force an include of the other Cairngorm classes by referencing them somewhere in your code.

I personally prefer option 1 since this is the cleanest way of separating code libraries and it allows you to swap/upgrade versions of Cairngorm without having to recompile your library.

Best Answer

Related Solutions

Php – the best way to stop people hacking the PHP-based highscore table of a Flash game

R – the best way to architect extended Cairngorm classes to be shared across applications

Related Topic