Re: Future proof Flex/Flash apps.

[Greg Dove]

   'What is the level of difficulty of setting up "automatic" upgrade
deployment using AIR? I would like to have SWF files be recognized as being
out of date and automatically downloaded. '

I guess there are different ways to do that.
Making the installed application itself update-able is not an unusual goal.
This would usually be the pattern where the app contains all the current
versions of any swf assets it uses, bundled in the package, and the user
gets a message saying the app can be updated, and it is like an
installation update process for the app itself.
iirc the only option for AIR now might be via captive-runtime builds (that
is something to check). So the update process is something that has to be
supported specifically instead of this: - perhaps either via a 'store'
distribution or manually for the specific app. I have seen a an AIR lib for
this in the past (this: [1] may still be relevant, not sure), or there are
probably ways to do it with native installer wrappers as well I think (all
to be verified).

The pattern where the app downloads and saves various swf assets and uses
them is also possible but it would likely require extra code on the client
side and server side to support the versioning checks etc.
This is easier on desktop than mobile (android is not so bad, but iOS has
some restrictions). it is also possible of course to mix this with the
above approach.

In terms of difficulty, I guess both of the above approaches are not new,
and IMO reasonably routine, so I would not rate this part as 'difficult'. I
have not done either on desktop because I have only worked on a few desktop
apps in the past, but I have used the second approach before on android.

If you do want to continue to target the browser though, Royale is likely
your best option without massive re-writes.


1.
https://www.adobe.com/devnet/air/articles/updating-air-apps-native-installer.html



On Tue, Sep 10, 2019 at 7:30 AM Paul Stearns 
wrote:

> Greg:
>
> Thanks for taking the time to reply.
>
> The applications are as close to being a desktop self contained
> application as we could make them. The only reason for being a browser
> based app is that it made installs and deployment of changes & enhancements
> a non issue.
>
> AIR might be an option. What is the level of difficulty of setting up
> "automatic" upgrade deployment using AIR? I would like to have SWF files be
> recognized as being out of date and automatically downloaded. The current
> system uses ModuleLoader to place "programs" on the users "screen." When in
> the environment it looks very much like an old menu based .NET desktop
> application (only prettier).
>
> Paul
>
> 
> From: Greg Dove 
> Sent: 9/9/19 3:14 PM
> To: users@flex.apache.org
> Subject: Re: Future proof Flex/Flash apps.
> Hi Paul,
> ' The applications will continue to be desktop applications, with no
> portable/tablet interface required. '
>
> It was not entirely clear to me whether they will continue to be *web*
> 'desktop' applications? If not, one (relatively) quick option is to convert
> the existing code to installable desktop applications built with AIR.
>
> Otherwise if you are continuing to target the browser, the most direct way
> to get to where you want to be is via Apache Royale.
> Although I am not aware at this point of anyone using Apache Royale
> specifically with FlourineFX, AMF remoting works (in the imminent 0.9.6
> release) and it has been used in at least one app that has been in
> production use for a number of months already.
>
> In terms of support, one option is that Royale has page where you can
> contact directly with some companies or individual developers. [1]
>
> [1] https://royale.apache.org/royale-commercial-support/
>
> On Tue, Sep 10, 2019 at 5:35 AM Paul Stearns
> wrote:
>
> > Who would be able to help me assess which way to go to future proof Flex
> > apps?
> >
> > We have 4 Flex (currently compiled with 3.6 SDK) applications which are
> > fully integrated with a FluorineFX/VB middle tier and Oracle DB tier.
> They
> > currently run in browser based Flash with very little interaction with
> the
> > browser. The applications will continue to be desktop applications, with
> no
> > portable/tablet interface required.
> >
> > It appears we will need to do something prior to the end of 2020.
> >
> > One of the applications which uses the framework created in house is a
> > Time Accounting System (TAS) which we could make available to anyone
> > interested in helping us figure the easiest approach to maintain as much
> of
> > the user interface as possible while minimizing the conversion effort.
> >
> > The applications have the look and feel of a desktop application with the
> > flexibility of web deployment. A screenshot of the TAS system is
> attached.
> >
> >
> >
>
>
>

Re: Future proof Flex/Flash apps.

[Paul Stearns]

Greg:

Thanks for taking the time to reply.

The applications are as close to being a desktop self contained application as 
we could make them. The only reason for being a browser based app is that it 
made installs and deployment of changes & enhancements a non issue.

AIR might be an option. What is the level of difficulty of setting up 
"automatic" upgrade deployment using AIR? I would like to have SWF files be 
recognized as being out of date and automatically downloaded. The current 
system uses ModuleLoader to place "programs" on the users "screen." When in the 
environment it looks very much like an old menu based .NET desktop application 
(only prettier).

Paul


From: Greg Dove 
Sent: 9/9/19 3:14 PM
To: users@flex.apache.org
Subject: Re: Future proof Flex/Flash apps.
Hi Paul,
' The applications will continue to be desktop applications, with no
portable/tablet interface required. '

It was not entirely clear to me whether they will continue to be *web*
'desktop' applications? If not, one (relatively) quick option is to convert
the existing code to installable desktop applications built with AIR.

Otherwise if you are continuing to target the browser, the most direct way
to get to where you want to be is via Apache Royale.
Although I am not aware at this point of anyone using Apache Royale
specifically with FlourineFX, AMF remoting works (in the imminent 0.9.6
release) and it has been used in at least one app that has been in
production use for a number of months already.

In terms of support, one option is that Royale has page where you can
contact directly with some companies or individual developers. [1]

[1] https://royale.apache.org/royale-commercial-support/

On Tue, Sep 10, 2019 at 5:35 AM Paul Stearns
wrote:

> Who would be able to help me assess which way to go to future proof Flex
> apps?
>
> We have 4 Flex (currently compiled with 3.6 SDK) applications which are
> fully integrated with a FluorineFX/VB middle tier and Oracle DB tier. They
> currently run in browser based Flash with very little interaction with the
> browser. The applications will continue to be desktop applications, with no
> portable/tablet interface required.
>
> It appears we will need to do something prior to the end of 2020.
>
> One of the applications which uses the framework created in house is a
> Time Accounting System (TAS) which we could make available to anyone
> interested in helping us figure the easiest approach to maintain as much of
> the user interface as possible while minimizing the conversion effort.
>
> The applications have the look and feel of a desktop application with the
> flexibility of web deployment. A screenshot of the TAS system is attached.
>
>
>

Re: Future proof Flex/Flash apps.

[Greg Dove]

Hi Paul,
' The applications will continue to be desktop applications, with no
portable/tablet interface required. '

It was not entirely clear to me whether they will continue to be *web*
'desktop' applications? If not, one (relatively) quick option is to convert
the existing code to installable desktop applications built with AIR.

Otherwise if you are continuing to target the browser, the most direct way
to get to where you want to be is via Apache Royale.
Although I am not aware at this point of anyone using Apache Royale
specifically with FlourineFX, AMF remoting works (in the imminent 0.9.6
release) and it has been used in at least one app that has been in
production use for a number of months already.

In terms of support, one option is that Royale has page where you can
contact directly with some companies or individual developers. [1]

[1] https://royale.apache.org/royale-commercial-support/

On Tue, Sep 10, 2019 at 5:35 AM Paul Stearns 
wrote:

> Who would be able to help me assess which way to go to future proof Flex
> apps?
>
> We have 4 Flex (currently compiled with 3.6 SDK)  applications which are
> fully integrated with a FluorineFX/VB middle tier and Oracle DB tier. They
> currently run in browser based Flash with very little interaction with the
> browser. The applications will continue to be desktop applications, with no
> portable/tablet interface required.
>
> It appears we will need to do something prior to the end of 2020.
>
> One of the applications which uses the framework created in house is a
> Time Accounting System (TAS) which we could make available to anyone
> interested in helping us figure the easiest approach to maintain as much of
> the user interface as possible while minimizing the conversion effort.
>
> The applications have the look and feel of a desktop application with the
> flexibility of web deployment. A screenshot of the TAS system is attached.
>
>
>

Re: Future proof Flex/Flash apps.

[Paul Stearns]

Mark:

It seems to have been stripped.

I will get a working site up with dummy data soon, and send the link.

Paul


From: mark goldin 
Sent: 9/9/19 2:23 PM
To: pa...@compuace.com.invalid
Cc: "users@flex.apache.org" 
Subject: Re: Future proof Flex/Flash apps.
Dont see screenshot.

On Mon, Sep 9, 2019 at 12:35 PM Paul Stearns
wrote:

> Who would be able to help me assess which way to go to future proof Flex
> apps?
>
> We have 4 Flex (currently compiled with 3.6 SDK) applications which are
> fully integrated with a FluorineFX/VB middle tier and Oracle DB tier. They
> currently run in browser based Flash with very little interaction with the
> browser. The applications will continue to be desktop applications, with no
> portable/tablet interface required.
>
> It appears we will need to do something prior to the end of 2020.
>
> One of the applications which uses the framework created in house is a
> Time Accounting System (TAS) which we could make available to anyone
> interested in helping us figure the easiest approach to maintain as much of
> the user interface as possible while minimizing the conversion effort.
>
> The applications have the look and feel of a desktop application with the
> flexibility of web deployment. A screenshot of the TAS system is attached.
>
>
>

Re: Future proof Flex/Flash apps.

[mark goldin]

Dont see screenshot.

On Mon, Sep 9, 2019 at 12:35 PM Paul Stearns 
wrote:

> Who would be able to help me assess which way to go to future proof Flex
> apps?
>
> We have 4 Flex (currently compiled with 3.6 SDK)  applications which are
> fully integrated with a FluorineFX/VB middle tier and Oracle DB tier. They
> currently run in browser based Flash with very little interaction with the
> browser. The applications will continue to be desktop applications, with no
> portable/tablet interface required.
>
> It appears we will need to do something prior to the end of 2020.
>
> One of the applications which uses the framework created in house is a
> Time Accounting System (TAS) which we could make available to anyone
> interested in helping us figure the easiest approach to maintain as much of
> the user interface as possible while minimizing the conversion effort.
>
> The applications have the look and feel of a desktop application with the
> flexibility of web deployment. A screenshot of the TAS system is attached.
>
>
>

Future proof Flex/Flash apps.

[Paul Stearns]

Who would be able to help me assess which way to go to future proof Flex 
apps?We have 4 Flex (currently compiled with 3.6 SDK)  applications which are 
fully integrated with a FluorineFX/VB middle tier and Oracle DB tier. They 
currently run in browser based Flash with very little interaction with the 
browser. The applications will continue to be desktop applications, with no 
portable/tablet interface required.It appears we will need to do something 
prior to the end of 2020.One of the applications which uses the framework 
created in house is a Time Accounting System (TAS) which we could make 
available to anyone interested in helping us figure the easiest approach to 
maintain as much of the user interface as possible while minimizing the 
conversion effort.The applications have the look and feel of a desktop 
application with the flexibility of web deployment. A screenshot of the TAS 
system is attached.

Re: SWFLoader not pulling through all sub SWF styles

[Alex Harui]

That thread I think is about loading a child SWF that was not a Flex 
Application.

Let's collect some information first:
-What version of Flex are you using for the browser version?
-Are you using the same version of Flex for the AIR version?
-What is the URL of the main SWF?
-What is the URL of the sub SWF?
-What does the SWFLoader MXML tag (or AS equivalent) look like in the browser 
version?

If you can't post your code as-is, anything sensitive can probably be 
obfuscated.

If you can create a simple test case that works in the browser but not in AIR 
that might help as well.

I can't immediately think of any constraints in AIR that don't allow it to 
duplicate loading subSWFs like Flash can, other than the default security 
rules.  IIRC, by default, in Flash, a SWF loaded from the same domain from some 
child folder is in the same security context and gets a child ApplicationDomain 
topology.  In AIR, a SWF loaded from a server or folder outside of the 
application folder are put in different security contexts (like cross-domain 
loading).  The loadBytes trick puts the SWF bytes in the same security context, 
but does not default to a child ApplicationDomain topology.  I think some 
aspects of Flex styles count on a child ApplicationDomain topology.

You can dump out the ApplicationDomain topology I think by accessing the 
systemManagers in SystemManagerGlobals.

HTH,
-Alex

On 9/9/19, 1:43 AM, "DarrenEvans"  wrote:

I played around with various of these techniques and they all present
different problems. Loading the child SWF into its own Application Domain
sorts out the styling problem but presents a different problem. Upon resize
nothing happens; the child SWF remain the same size or scales rather than
resizing (depending on SWFLoader settings).

I found this old post you commented on:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fforums.adobe.com%2Fthread%2F430250data=02%7C01%7Caharui%40adobe.com%7Cda33622635514146a84f08d73501bf12%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637036153961495380sdata=uDcpoeliFB0XKlN3PW6AYlYKk4D3Ns8f0IMRQwAfuao%3Dreserved=0


  

I'm not sure what you mean when you say "It might be worth it to implement
IFlexDisplayObject.". The child SWF is an mx:Application which already
implements that interface via its class hierarchy. Do you mean the launching
application? 



--
Sent from: 
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-flex-users.246.n4.nabble.com%2Fdata=02%7C01%7Caharui%40adobe.com%7Cda33622635514146a84f08d73501bf12%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637036153961505373sdata=W2S4fL9bqvtVRQNrZpc2nwKeRpghEmrQJFqbrUE1aTs%3Dreserved=0