problem with events and air application

Gerry Koh's Avatar

Gerry Koh

29 Jul, 2010 06:45 PM

Hi,

I am having a weird problem with my air application. everything works great when i debug it from flex builder, but when i export an air file and install it, one of the events is not caught. I have an alert in the view before the event is sent, and and alert in the method in the mediator that catches the event. The first one fires but the second one doesn't (when the app is exported and installed).

Can anyone give me insight into the robotlegs event bus? afaik the event doesn't need to bubble because the eventMap is mapping the view and the mediator to each other directly. I'm assuming that there are plenty of robotlegs air apps out there working just fine. I'm using the latest flash builder and air2 stuff. It seems like once packaged into an air application there is some failure going on in the eventmap.

maybe this is an error with the air packaging? i have both the robolegs and swiftsuspenders swcs in the libs folder. as a final bizarrity, trace statements from the air app aren't showing up in the flashlog.

help please, i don't want to deploy this app on a server!

thanks,

gerry

  1. 1 Posted by Stray on 29 Jul, 2010 07:02 PM

    Stray's Avatar

    Hi Gerry,

    robotlegs events get cloned and redispatched on the shared dispatcher but there's no obvious difference between debug and compiled Air in that regard. And the eventMap should be listening directly.

    I'm using RL in Air, but it's Air 1.5. But yes - there are Air robotlegs apps, it works just fine in air - not much difference except for the usual air-weirdnesses like not being able to use the stage from sandboxed content etc.

    So if you compile a debug air app, and then run it in adl with FDB running, nothing shows in the flashlog?

    That's freaky.

    One thing robotlegs makes it very easy to do - especially if you're using it from source - is to catch your events as they flow through the event dispatcher and then log them to screen in a textfield.

    A final thought that might be relevant or might not - race conditions? Everything executes faster in the Air app than in the debugger, so is it possible that your event is firing before the code to catch it has run?

    Sounds frustrating!

    What kind of event is it? Is it an app event or a flash / air native event?

  2. 2 Posted by Gerry Koh on 29 Jul, 2010 09:05 PM

    Gerry Koh's Avatar

    Hi Stray,

    I'm not sure what you mean by a debug air app (vs a release). If I debug from flash builder it does write both to the console and flashlog.txt. When I export the air file it doesn't write to flashlog.txt.

    I'd love any guidance from you on tracing stuff through the robotlegs dispatch system to an on screen textfield. that seems to be the next step in figuring out where the breakdown is.

    i doubt that its a race condition because the event is fired in response to a button click, so all the app setup stuff should be done by then.

    The event fired between the view class and the mediator is just a simple subclass of flash.events.Event that uses constants to define the event type.

    thanks,

    gerry

  3. 3 Posted by Stray on 29 Jul, 2010 09:23 PM

    Stray's Avatar

    Hi Gerry, when you compile the air file, you can set -debug = true or -debug = false (if you're using the command line). Choosing debug in flash builder (or flash IDE) compiles the swf with -debug = true AND then launches the ADL to pick up the trace.

    Are you familiar with using the command line for amxmlc / adl / fdb? If you are then I would try that approach first.

    On the logging to an onscreen textfield, it can be as simple as handling your event with a logAndDoThings() function, which then also dispatches a LogEvent.EVENT_LOGGED or whatever event on the shared event dispatcher. This LogEvent needs to have one other property - a message - to which you would pass the toString() of the event that triggered it.

    Create a view / mediator pairing which is just a textfield (in the view) with a public function like traceToScreen(message:String) which appends the message.

    In the mediator, listen for the LogEvent and pass the message to view.traceToScreen(message);

    Also make sure that you've overridden clone() in your custom event. That often catches people out (though that should be causing probs in FlashBuilder debug as well so I doubt it's that).

    If you're still stuck then I'm back in about 18 hours... maybe someone else will have some ideas too,

    Stray

  4. 4 Posted by Gerry Koh on 29 Jul, 2010 10:41 PM

    Gerry Koh's Avatar

    Thanks Stray,

    I'll try out your suggestions and report back.

    As far as the event cloning goes, I specifically didn't override the clone method because all the robotlegs demo projects don't, so i assumed that like bubbling its not necessary. I'll try that, although i'd think that wouldn't break the app only when exported and installed.

    thanks for all your help! i'm glad robotlegs has an active community, i think i made the right framework choice for my company's new project.

    g

  5. Support Staff 5 Posted by Shaun Smith on 30 Jul, 2010 10:32 AM

    Shaun Smith's Avatar

    Hi Gerry,

    If the Robotlegs demos don't override clone() in their events then it is due to an oversight on our part - it is considered best practice to always override clone(), even for non-bubbling events. The Flash Player does not allow one instance of an event to be dispatched more than once, so clone() must be overridden when re-dispatching (for example, when re-dispatching a view event along the event bus).

  6. 6 Posted by Gerry Koh on 30 Jul, 2010 06:23 PM

    Gerry Koh's Avatar

    Hi helpful support folks,

    I'm still working on tracking the event through the framework, but in the meantime I've created a simple project to reproduce the issue. its 1 view, 1 mediator, 1 event, and 1 context. the app is a single button. when you click it, it traces something out and alerts something and sends an event. when the event is caught in the mediator, the mediator traces something out and pops up an alert.

    if you import the fxp into flash builder 4.0.1 with the latest air stuff and debug it, you will see that the mediator catches the event and output is traced to flashlog.txt as well as the console.

    if you install the included air file you will see that the mediator never pops its alert, and no messages at all are written to flashlog.txt.

    i'll continue to try stuff, but i thought that you guys might be able to track this down in 5 minutes. This is starting to smell like either a dumb rookie mistake by me or an air bug.

    thanks,

    gerry

  7. 7 Posted by Stray on 30 Jul, 2010 06:52 PM

    Stray's Avatar

    Hi Gerry, I'd love to help but I use project sprouts / the sdk so I don't have flash builder.

  8. Support Staff 8 Posted by Shaun Smith on 30 Jul, 2010 09:13 PM

    Shaun Smith's Avatar

    Hi Gerry,

    The problem was that you were linking against the RL and SwiftSuspenders source without adding the required compiler arguments to keep the metadata from being stripped (the Flex compiler strips all non-standard metadata by default). The RL SWC file includes these compiler arguments for you, but when linking against the source, you need to add them yourself:

    Right-click your project, go to Flex Compiler, Additional compiler arguments, and add the following:

    -keep-as3-metadata+=Inject -keep-as3-metadata+=PostConstruct

    After doing so, the debug and release versions run the same for me. It's weird (and slightly annoying) that the compiler kept the metadata for the debug version in the first place.

  9. Support Staff 9 Posted by Shaun Smith on 30 Jul, 2010 09:14 PM

    Shaun Smith's Avatar

    By the way, trace statements are removed by the compiler when doing a release build.

  10. 10 Posted by Gerry Koh on 30 Jul, 2010 10:03 PM

    Gerry Koh's Avatar

    Thanks Shaun,

    That totally worked! BTW, is this kind of stuff captured anyway? As a robotlegs noob I'm sure I'll run into other things like this.

    You guys rock,

    g

  11. Support Staff 11 Posted by Shaun Smith on 30 Jul, 2010 10:12 PM

    Shaun Smith's Avatar

    It's a pleasure, glad you're back on track!

    Yes, all public issues are captured into this knowledgebase to help with future trouble shooting :)

  12. Gerry Koh closed this discussion on 22 Oct, 2010 10:27 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac