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:59:03 GMT
To further extend: the AIR app suggested is a way to overcome that flash
limitation when running in the browser, having an AIR app running locally
that can exchange data with the app running in the browser (using a Flash
proprietary method called LocalConnection) and save it on disk.

This could be useful for your debugging sessions in a "production"
environment, i.e. without using the debug player, to have a way to collect
data from an app that is running in the browser and analyze it. However, it
is probably not suitable for collecting log data from actual users (they
should all install and keep this compaion app running all the time).

In some of my apps, I use the Flex logging framework providing a LogTarget
that keeps the log entries in memory, and I give access to the log of the
current session using the "About this app" window, also letting users save
it to disk as described before. You could extend this concept by providing
features to send back the log data (for example with an mail or through a
back-end service call) if required. This kind of technique is suitable both
for AIR applications running as desktop apps and Flash applications running
in the browser.


2013/10/22 Cosma Colanicchia <cosmacol@gmail.com>

> 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