flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cosma Colanicchia <cosma...@gmail.com>
Subject Re: Tracing in non debugging players
Date Tue, 22 Oct 2013 16:48:59 GMT
Is your application an SWF file loaded in the browser? If so, chances are
that you are serving it from an HTTP server, along with a wrapper HTML file
to correctly load and display the flash content.

If this is the case, the usual scenario is that your SWF will already
establish a connection back to the web server, in order to retrieve and
store application data (since disk access from an SWF running in the
browser is very limited, for security reasons). This conversation is
usually done using products such as BlazeDS, but you can implement your
favoring HTTP/REST/JSON/... technique to talk back with the server, where
the core business logic usually runs.

So, the suggestion is to use this same channel to send back to the server
the log entries, activating this action by user request (e.g. a "Send
report" menu item), or automatically when an error condition is detected,
or even periodically in background while the app is running.

If your application has no requirement to talk back with a server,
unfortunately it cannot freely write on disk while running inside a
browser. You could keep tracks of your log entries in memory (such as an
array of String objects) and you could provide a "Save log to disk"
functions, then use FileReference flash object to save the data as a text
file. Note that, for security reason, this action requires that the user
select the target file using the standard operating system "Save as…"
dialog - this is the reason because you cannot simply write to disk in
background while the app is running.






2013/10/22 mark goldin <markzolotoy@gmail.com>

> Yes, users will email me a file. It seems simpler then have them installing
> additional software. But when you say remote server what exactly do you
> mean? If they are running on the internal network how would I communicate
> with the remote server?
>
>
> On Tue, Oct 22, 2013 at 11:29 AM, Alex Harui <aharui@adobe.com> wrote:
>
> > Not exactly.  In the git repo, the file mustella/as3/ImageDiff.MXML is a
> > listener SWF and mustella/as3/CompareBitmap.as talks to it.  It uses
> > localconnection to communicate.  You'd have to add your own write-to-file
> > code to the listener.
> >
> > I think everyone is confused about how you plan to collect the data.  If
> > you store it locally on the user's machine, will they somehow send it
> back
> > to you?  I think others simply pass the data to a remote server and then
> > you don't need to have folks install a separate AIR app and have it
> > running.
> >
> > -Alex
> >
> > On 10/22/13 3:04 AM, "mark goldin" <markzolotoy@gmail.com> wrote:
> >
> > >Is there any code around for such AIR app to listen to the web app?
> > >
> > >
> > >On Mon, Oct 21, 2013 at 9:53 PM, Alex Harui <aharui@adobe.com> wrote:
> > >
> > >>
> > >>
> > >> On 10/21/13 5:57 PM, "mark goldin" <markzolotoy@gmail.com> wrote:
> > >>
> > >> >What I would really want is to write some info into a local file. Is
> > >>that
> > >> >possible?
> > >> It depends.  You can have folks install an AIR app that will listen to
> > >> your web-app and write data to the local file.  But without a helper
> > >>app,
> > >> the web-app does not have access because of security restrictions.
> > >>
> > >> >
> > >> >
> > >> >On Mon, Oct 21, 2013 at 4:46 PM, mark goldin <markzolotoy@gmail.com>
> > >> >wrote:
> > >> >
> > >> >> Just to make sure the users dont need to run the debugging version,
> > >> >> correct?
> > >> >>
> > >> >>
> > >> >> On Mon, Oct 21, 2013 at 4:29 PM, Alex Harui <aharui@adobe.com>
> > wrote:
> > >> >>
> > >> >>> mx.logging.*
> > >> >>>
> > >> >>> On 10/21/13 1:40 PM, "mark goldin" <markzolotoy@gmail.com>
wrote:
> > >> >>>
> > >> >>> >What are the ways of tracing problems if users not running
> > >>debugging
> > >> >>> >version of Flash Player?
> > >> >>> >
> > >> >>> >Thanks
> > >> >>>
> > >> >>>
> > >> >>
> > >>
> > >>
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message