Why Adobe AIR ? Let me tell you why


#1

Today in 2018, after Flash EOL been announced, when we can say the community of ActionScript developers have shrunk quite a lot, and tons of hammering from flash haters who love to repeat that Flash is dead and so ActionScript must be dead too …

If you look around you may be under the impression that something like Adobe AIR is doomed and anybody using it, or more exactly still using it, would be flat out of their mind, right ?

Not so fast.


OK, so here I could start to make a very long list of all the great features of Adobe AIR, but I’m not gonna do that.

First, if you’re here reading that you probably already know those features or at least some of it.

Second, even if you don’t know Adobe AIR at all it is quite easy to pick it up and build a prototype of your app with it.

Just by following the documentation and reference from Adobe, looking into what is available in the API you can get started and progress a lot.

So why should use Adobe AIR if it’s not for a long list of features ?

Well … let’s look around and see what kind of problems those other dev using other tech stack still have, and let’s compare to what we have with Adobe AIR.


JavaScript is the Hype but Everyone Want Something Like TypeScript

Does the JavaScript popularity should make you drop ActionScript 3 ? humm let’s see …

During the last few years, almost everyone have tried to improve JavaScript by creating their own superset of the language, here a list (maybe not complete):

And one among the first to have tried that ?!?
ActionScript 3 off course

in the specification you can read

2 Design perspective

It is sometimes difficult to understand design decisions without understanding the perspective of the designers. Here are the major viewpoints that have grounded the design changes introduced in ActionScript 3.0 and ECMA-262 edition 4.

2.1 Compatibility with existing programs

ECMAScript was originally designed for and used by consumers of host object models. Because ECMAScript is one of the most widely used programming languages, it is important that existing ECMAScript-compliant programs continue to work in systems that are updated to support the new definition of the language.

Therefore, programs written for ECMA-262 edition 3, compact profile, or ECMAScript for XML (ECMA-357 edition 2, also known as E4X) must continue to behave the same way in both ActionScript 3.0 and ECMA-262 edition 4.

and

21 Compatibility with ECMAScript edition 3

While we have made this edition as compatible as possible with the ECMAScript (ECMA-262) edition 3 language specification, there are certain behaviors for which there is no clear use case and keeping them as-is would have been placed an unneeded heavy burden on the new features of the language. In such cases, we have made small and calculated changes to allow the new definition to be simpler and easier to use.

In the same logic as TypeScript and others, ActionScript 3.0 specification improved on ECMAScript 3rd edition, introducing the concept of types, classes, interfaces, namespaces, etc.

The difference is that something like TypeScript will import and export to ES3, while the ActionScript compilers only import and do not export to ES3.

But, as everything else, compilers evolve over time, and Apache Royale is something that can export your AS3 to ES3.

As ActionScript 3 developers you have access to this superset of ECMAScript 3 since 2006, and in the following decade all those others supersets like TypeScript, Dart, etc. have popped up all over the place.

To me it looks like that TypeScript etc. are catching up to ActionScript, not the opposite.

In fact, what happened to AtScript is interesting

AtScript was originally intended to run on top of TypeScript, while including some features from Dart.
In October 2014, Google announced that Angular 2.0 would be written in AtScript.
In March 2015, Microsoft announced that many of AtScript’s features would be implemented in the TypeScript 1.5 release, and that Angular 2.0 would be built on pure TypeScript.

You could say that TypeScript killed AtScript, and to a certain extend TypeScript casted it shadow over Dart.

Dart is not dead and recently Google tried to revive it by releasing Dart 2,
On another thread (Microsoft Acquires GitHub) I commented

Look at Dart for example
in a recent video Ryan Dahl mention in 10 Things I Regret About Node.js at 20:20

euh … Dart!!
do you guys know Dart?
total failure
like … jesus
I mean … very good intentions and very cool
but obviously a failure at this point
and TypeScript took a totally different approach to the problem
and worked completely in JavaScript
and solved it in a way that is satisfying many people
so if you have not been using TypeScript, please check it out
I want this thing to do TypeScript because I like it

that’s why Google is trying to reboot the language
Announcing Dart 2: Optimized for Client-Side Development see comments

and double down on Flutter (which use Dart)
Ready for Production Apps: Flutter Beta 3 see comments

Or when the creator of Node.js tell you that your JavaScript superset (Dart) is a failure … wow :stuck_out_tongue:

So yeah you could say that ActionScript 3 is old, that it had not been updated and will probably never be updated (Adobe announced they will not work on ActionScript 4), but does it make it dead?
certainly not.

At worst ActionScript 3 was a precursor and you can only target ActionScript runtimes (based on AVM2),
at best you can reuse all your AS3-fu and build a lot of stuff based just on Adobe AIR, probably a bit more based on things like Redtamarin and/or Apache Royale.


The Next Big Thing at Apple

It had been announced at the WWDC 2018 and posted in many places

On the Verge article you can see this tweet

yeah always à la mode to summon the death of Flash, I’ll comment later …

But let go with this article which imho is more developers oriented

Marzipan: What you need to know about Apple’s universal framework API
Apple is reportedly working on a new, cross-platform iOS and macOS development framework… but we won’t see it until 2019.

here the intro

Apple has a problem. The teams working on its apps increasingly have to develop and maintain features across iOS and macOS. Sometimes that causes work to go more slowly than anybody would like. Sometimes it causes a lack of feature parity that nobody likes.

That problem is echoed throughout the third-party developer community as well. It results in fewer Mac apps with fewer features updated less often. Or not at all.

So, what to do? The answer, it seems, is a universal framework that allows developers to port iOS to macOS.

Later in the article you will see this

Other companies were using web apps, Electron (Chrome packaged web apps), or progressive web apps to deploy cross-platform. But, like the Java and AIR apps before them, the ease they offered developers was paid for by users who had to put up with a worse experience.

Something I will also comment later …

Read the article and then watch the associated video
where you can listen to some Apple fanboys discussing about
Marzipan: Apple’s Next Big Software Thing!

The article conclude with

When will Apple release this universal framework?

For developers, as soon as WWDC 2019 next June. It will come to iOS 12 and macOS Mojave for us in the fall of 2019 in the form of four Apple built apps that are being ported from iOS to Mac.

  • News
  • Stocks
  • Voice Memos
  • Home

These apps are going to be identical to their mobile counterparts, but available on Mac! Once Apple feels confident that this testing phase is successful, we’ll probably see a developer update.

Euh … wait a minute, where did I already seen something similar to this?

I mean, a framework where you can share a lot of code, and have identical apps on desktop and mobile?

Oh yeah Adobe AIR is doing just that since 2011 (AIR v3.0).

Humm what do we learn here?

Marzipan replacing Electron marks the second time UIKit has killed flash.

So the first time UIKit killed Flash is when Steve Jobs wrote that famous Thoughts on Flash (which by the way has its own wikipedia page).

And so the second time it’s UIKit by killing Electron (that can run Flash in HTML on the desktop)
which would kill Flash again ?

Nope. That still the same error that most Flash haters and other misinformed developers are making, Flash is just a browser plugin, you can only kill it in the browser.

But when it come to desktop and mobile territories, there we have the very same Flash technology
and that is called Adobe AIR, and that one you can not kill it, because its sole purpose is to exists
outside the browser.

There you can not kill it.

and what about this

But, like the Java and AIR apps before them, the ease they offered developers was paid for by users who had to put up with a worse experience.

ORLY? You got a worse experience with Adobe AIR?

Bullshit :smiley:

Like any other technology it is possible to produce shitty apps with Adobe AIR, but it is also possible to produce great, tight, lean and mean wonderful apps, unless you completely don’t know Adobe AIR and so don’t know what is capable of.

From the article and the video, here what those Apple devs are discussing

  • the building blocks could be the same, you could reuse a lot of code
  • the UI does not have to be exactly the same, but some UI elements could be shared
  • every company have limited amount of resources
  • why such framework as Electron are popular is because developers are lazy,
    because they don’t have the resources to dedicate teams to maintaining this things (native apps)
  • it would be nice to share more the “view” side of things
  • if you could have a “common view” on Mac and iOS it could save a lot of time,
    like fixing a bug in the model is like fixing a bug in two apps
  • by not having the layer to share more code kind of guarantee that it will be drifting away in term of consistency
  • it’s this all little death by a thousand cuts, there is no reason to not share the core logic, the basic stuff
  • what is the current situation for desktop apps in general? I feel like the heyday of a lot of native apps on desktop is over sadly
  • all of the big apps, the apps that I would consider world-changing on smaller or bigger scales recently, they’ve been mobile first, they’ve been things like or at least web first and mobile first yeah, like Instagram, things like Uber and Lyft
  • I mean there’s no reason I wouldn’t want to be on the Mac other than that I haven’t have the resources and the effrot required is it’s been prohibitive
  • I would love to see the good Gregg peers to ve able to do drafts for Mac, because I would kill for that
  • on the inverse side, in a perfect world, I also like to be able to say maybe you have some really good mac apps that have never come to mobile that might be able to come to iOS in better ways

and from the video here the best quote

I guess bottom line for me, my dream is that Craig Federighi would show up on stage at WWDC
2018 or 2019 and he would say we’ve had 20 years of AppKit we’ve had 10 years of UIKit
and today Apple takes the next step forward, today we announced a framework that let’s you
share your resources between iPhone and iPad and Mac much more easily, much more effectively,
and we call it Xkit or we call it AppleKit

So what do we learn ?

That we have all that since the beginning with Adobe AIR!!

Color me not impressed by Apple next big thing, because I can do the same but not only on iPhone, iPad and Mac, but also on Android and Windows and Android TV and Apple TV too, and to a certain extend with Linux desktop too.

It’s been close to 10 years that I’m thinking all my apps as multiple-screen and cross-platform thanks to Adobe AIR, and thanks to Flash legacy too.


Running Android Apps on the Desktop

If you search a little you can find many solutions to run Android apps and especially games on the desktop, see for example: 14 best Android emulators for PC and Mac of 2018.

Based on that here a little list

So yeah that is a thing, look at all those freaking 14 solutions
but why you may ask ?

  • it seems people who play Android games on mobile device
    also want to play them on their desktop

  • it seems most developers who publish Android games
    do not publish at the same time a desktop version

Here for example the bluestacks 3 video promo

Do you see?
There are some people that make that a platform, that make you think.

So it’s there and from the software developer it is far from ideal, someone else is making your app/game run on their simulator as a platform thingy, eg. the dev have no control over that.

In fact, for devs the only way to fight this kind of thing would be to publish their game themselves on the desktop, as such providing a better experience and cutting the grass under the feet of those Android emulators.

And guess what would be ideal, no!!, perfect to do that?
Adobe AIR yet again

Sure, it is a bit much more efforts, but if your game is already running on Android, porting it to desktop Windows and/or Mac would be quite easy because those are real desktop, not mobile, so you have access to much more resources for CPU and RAM and HDD etc.


Tango is Down

This is military slang for the “target is down”, and what is the target?

It is the web.

OK, so let’s not exaggerate too much, sure the web is as big as before and growing bigger, and sure you can decide to go web-first for your app, if the model fit it will probably work.

But I would say it is not because the web is growing that the other things are gone and dead, and mobile is proving that for almost a decade, as now you can also go mobile-first.

The desktop is still here and still used

  • why do you think people port their web app to Electron?
  • why do you think Apple think to help devs to publish their iOS apps to Mac?
  • why do you think people want to consume their Android games on the desktop?

The desktop is still a big platform, you can not completely replace it with web or mobile apps, you still want (if you can) publish a desktop app.

I push this argument for a long time now with ActionScript, sure still being able to publish on the web as a SWF would be nice because less efforts, but technically you can simply and purely ignore the web for your apps publishing need.

I would almost say publish cross-platform first and Adobe AIR is just perfect for that.

It is a no brainer really, just structure and organise your app to be able to test and publish for the 4 main platforms supported by AIR: iOS, Android, Windows and macOS.

That is why you would chose Adobe AIR, because it allow you to do exactly that, and that cross-platform publishing is pretty damn competitive compared to just publishing for the web.

If you had a Flash game that was published on the web as a SWF you should be already porting it to AIR for mobile and desktop.

If you already have published a mobile app with AIR you should seriously consider publishing it also on the desktop.

And the inverse works too, if you had a somewhat “old” AIR app that was published for the desktop you should port and publish it on mobile already.

People will go mobile-first because it is hard to also build the app for the desktop, even worse they will go iOS-first or Android-first because it is also hard to publish the same mobile app on two different platforms, but with Adobe AIR? it is not hard.

Being able to target cross-platform, to support as well touch than mouse and keyboard, to customise the UI exactly as you want and better display the same UI on all those platforms, to be able to support multiple screens wether the size of an iPhone or iPad or multiple screens on desktop, to share a good 90% of your code base among all those platforms, and many more cross-platform thingy is a real strength.

This cross-platform strength is at the core of Adobe AIR.

When people decide to go web-first and then produce the app on the desktop with Electron, it is like an after-thought, they make it work but they did not really planed to do it cross-platform, they assumed that their web tech stack is cross-platform by default, not completely.

One argument that can be used against Adobe AIR is that it does not support native UI like a native app would and tons of criticism follow, but when it is a web app that is ported to the desktop and also does not use the native UI, there, it seems to not cause any problems … go figure.

Personally I’m 200% for pushing the UI boundaries outside of the default native UI widgets, your UI should be custom because your app is like a brand, the same way a logo shape and color is unique and make a brand instantly recognisable it should be the same for the UI, exactly like video games.

I’m talking about UI like this

Where the app has a strong visual identity, not the same template reused by 1000s of other apps (cough cough Bootstrap anyone?).

Being able to do that on one platform is already quite good, but being able to do that on multiple platform is priceless, it almost automatically put your app into another (and hopefully higher) category, users do notice.

This kind of UI, you can program it in ActionScript 3 and make it cross-platform with Adobe AIR, and I would argue much more efficiently and easily than with HTML/CSS/JavaScript or native UI widgets (also why AAA games used Flash for their HUD).

That is Why you would Adobe AIR.


Thoughts about ARM CPU on macOS
#2

“yeah always à la mode to summon the death of Flash”
genius…


split this topic #3

11 posts were split to a new topic: Angry at vertex, shaders and floats


Angry at vertex, shaders and floats
Angry at vertex, shaders and floats
#4

I just wanted to share this promotional video for Drum Pad Beats.

It is in the total vein of this conversation. Imagine what I am doing in that app… :slight_smile: I am on the AS3 level, Java level and C/C++ level and can run this on Windows and Android, (could do iOS).

I started Flash at version 5, around 2001-2002, why am I still using AS3? … Hmm.

Mike


#5

cool one :slight_smile:

I have few questions if you don’t mind:

  • did you have users feedback telling you how they love that the UI is the same on desktop and mobile?
  • is it a custom UI of your own? based on Starling/Feather?
    just curious if it is full display list or not
  • do you think you could have achieved the same level of UI with native or HTML/CSS/etc. ?
  • and if you could have used something else, how do you think the development time spent would have gone? more? or less?

Angry at vertex, shaders and floats
#6
  • Desktop was for development cycles. I don’t release those to the public.

  • Custom UI of course with Feathers SDK. I have years into this app framework UI wise.

do you think you could have achieved the same level of UI with native or HTML/CSS/etc

Heh, there is no way I could have done this using any sane layout manager in HTML. I understand CSS is for text and layout, but it’s NOT for this type of application layout.

Look at Apache Royale (which most of the initial work was done my be on the compiler in 2013!), they are still struggling with decent 2005 app layouts with HTML/CSS.

This is not to say there are not some nice feeling UI that I have experienced latly, its called speed at which you can consistently create things like what I did without bugs.

See I know when I use Feathers, the UI just works, I only debug my app domain.

and if you could have used something else,

Yeah I always can adapt, it was torture staying with AIR the last 4 years because it seems dead (community). But I kept with what I felt was the best UI/Runtime that I could get things done fast with.

I already know because I tried LibGDX, native Android, for what I needed to do there is basically still no other option because of the deep C++ things I need coupled with a hella dynamic UI.


#7

thanks for the details :slight_smile:

Oh OK, I thought you were publishing it also on desktop.

Exactly, I see people have a tendency to say “oh look HTML5 can do everything Flash was doing” but they don’t really try to push the UI side really hard.

I’m not really bashing HTML, it’s just when you publish on the web and so in HTML you definitively end up being limited by the platform itself.

Com’on it’s not that bad (as torture), but yeah to develop with Adobe AIR you have to end up self-sufficient.

The thing is the community have shrinked so much that you now only see the bad parts: people complaining/ranting/hating, etc.

Make sense, in fact there is a whole “market” to just port C/C++ thing to ANE and provide a nice UI with AIR :stuck_out_tongue:

I also read more details in your thread on the Starling Forum
[RELEASE] Drum Pad Beats - Starling, Feathers SDK

for example

I did not even know you can control C++ lib code from AIR.

Well in a way you can’t but you can. :slight_smile:

I have the core C++ library, it uses externc to export my bootstrap and osc functions from C.

Then write bindings in Java JNI to call those exported C functions.

Then write the native extension to call those bindings.

quite interesting, that is the kind of “way of doing” that would be worth publishing somewhere :wink:

I don’t know all the details on how you communicate with the C++ layer, but you might be interested in that: Flash Player LocalConnection Shared Memory Native Code Library

yep shared memory messaging would work too to control C++ from AS3


#8

It works just fine on desktop, so it IS multi-platform. Could even run on MacOS if I wanted to do that.

Either am I it’s come a long way in 5 years (since I was working on FalconJX). I remember at that time I swear I have over 1000 hours in that Java code, I know I have 800 hours written down because of that failed Randori project. (Which had Hungry Heroes working (proto) in what 2013?

Well, when Flashcoders existed I was right at the top, I loved community and how it made you push the envelope, when you are programming in a black box, you really have to dig it out.

? I am confused.

Yeah, but who is listening, I remember my blog on Apache Flex when it first came out(2011-2012), what a waste of my life. :slight_smile:

What I learned with my C++ stuff is I needed straight access that I could easily debug, I couldn’t even get workers working on Android, so I stuck with what works, and that is the process you quoted.

Peace
Mike


#9

Yep no problem with that, I have many apps in this case too eg. they wanted only it to work on iPad but could have work on Android tablets too, the client just not wanted it so ¯\_(ツ)_/¯.

Still publishing on desktop is more work, having the Adobe AIR app running is no problem, but then packaging etc. can be quite daunting for some people, I guess that was also the genius of AIR without the captive runtime.

Well … that’s a long topic :wink:

the gist of it is basically you can find a hell lot of libraries/tools/etc. in C/C++ that are open source
but lack a decent UI, and AIR is perfect for that.

Think along the line of taking FFmpeg, making a desktop ANE for it, then release an AIR app to give a UI to it, simply because a lot of people can not or don’t want to use the CLI.

In fact that particular example already been done, see @tuarua AVANE library.

So I was just saying there is whole market of desktop AIR apps to be done and that could probably sell.

There are still some people listening :slight_smile:

No problem, I checked a bit more for SysV IPC on Android and well google intentionally made them not available in the NDK (Android does not support System V IPCs), so what you’re doing seems best.