Ideas and suggestions for new roadmap

All I care about is supporting new hardware and operating systems as soon as legally possible.

Like, not crashing on the Android Q beta. And displaying properly on Samsung's Galaxy S10+ ON DAY ONE. I want HARMAN to work privately with Google, Apple and Samsung to preemptively fix compatibility issues on the OS side, before they even happen. If that isn't possible, I want an AIR update available to fix it as soon as I hear about any compatibility issue. If Apple or Google changes the way they handle icons or permissions, I don't want to be hacking open my APK to fix it with obscure advice from the forums, and I don't want to wait 3 months for the next update cycle. I want an official solution available immediately from HARMAN.

Adobe AIR for smatwatches (Samsung / Apple)

Widget for Android ?

Still comparing Unity to AIR...

It doesn't make sense.

They are used in different scenarios.

Taking in count that Harman is going to charge for AIR SDK, they will have to work hard to make it much more competitive, if they are comparing the possible pricing plans with Unity ones, they must make AIR technically comparable with Unity, this could be:

• 2D Editor, because Animate wont be included in the Harman price plans, unless be an AIR subscription included for Adobe CC subscribers. It would be logic and fair that the long time Adobe supporters are taking in count with some kind of priority, or at least a discount.
• 3D Editor, this has been a huge lack since Stage3D appearance, and if they want to compare AIR with Unity, they must implement one.
• GUI Editor, this is another feature of Unity that AIR must have to be comparable.
• Complete native access included and less ANE dependent, they must think on the developers costs balance points, right now most of them are paying a lot of money for almost every native functionality for each app on a subscription basis, monthly or yearly, and no matter if their apps are old, they must pay for their subscriptions or their apps will stop working. If the business is going to be on the SDK and building tools, the ANEs Market Place must be reduced to a just special or specific functionality, not for almost everything like now. AIR must include native access or implementation to: Social integration, IAP, Ads Networks, all sensors, ARCore, ARKit, server less P2P, robust multiplayer/user API, updated StageWebView and HTMLLoader, among a lot of other features. Developers can't still paying for Adobe CC, for ANEs subscriptions plus Adobe AIR SDK/Tools subscription fee, this will become AIR the most expensive pipeline on the market.
• Again, if they want to charge something similar to Unity, they MUST include all of the platforms Unity offer: Standalone Win,Mac and Linux, iOS, Android, UWP, tvOS, PS4, Xbox, WebGL/HTML5, Facebook.
• They MUST think on AR/VR/MR/XR, it is mandatory for today development, Unity offers a lot of solutions and integration possibilities to all of them.
• A real support channel, ticked based, realtime chat, email, among support forums, not only community forums like now.

StageWebView and HTMLLoader rendered with chromium on desktop and Android.  Would open the whole HTML5 world to be easily embedded in an AIR app.   iOS is already using the latest browser, it's a huge gap in the cross platform ability.

That's it.  All I dream about...

Yes I'm aware I can 'roll my own' to get this functionality with quite a bit of effort and separate advanced installers.

- Increased or uncapped (with desktop) texture memory limit.

- 8k x 8k image support.

- Updated media support: VP8/VP9/Vorbis/Opus
- VP8/VP9 with alpha.  FLV supports alpha.  Dropping FLV export from Adobe products back around 2012 has left us without a means to export video with alpha channel, something that has never been replaced!
- 4K camera support (desktop, but maybe mobile too?).
- Linux support again.

- Native serial communication (micro-controllers).

- Funding for projects like Starling, Feathers, perhaps even a re-awakening of Away3D if you're really serious about this.

Another thing, in term of new features to add
try to think in "points"

it is very easy to just throw a "oh just add a web target", "oh just target PS4 and XBOX", etc.
it is one line to write, but the development of such feature is extremely big and time consuming

I would say a fixed sound API would be along the 5 to 10 points
and a web target would be around the 500 points mark (if not more)

and "console support", let's say for just one console around the 2000 points (if not more)

whatever ratio/weight you decide to apply to those points
if 5 points is 2 month of development effort, then 500 points is 200 months

also those points should ultimately be decided by HARMAN
they know how hard/easy such and such feature would be to develop

so even if you (asking for a new feature) estimate something at 2 points
but then HARMAN (investigating it) estimate it to 10 points, then 10 points it is

I would say the one who actually develop the features win in the estimate

we can not just ask anything and everything, eg. asking a lot of features requiring a lot of points

just gonna give the impression that "nothing is done" when in fact people are just asking for "too much too soon"

remember also that Adobe in their release schedule moved from 1year+ release to quarterly release
that also influence how much or how big can be shipped per release

Not sure this is the correct format to post ideas but for me AIR would be more attractive (not especially better) to new developers if it had:

- a fixed SoundAPI (since FP9 the AS3 SoundAPI has been the worse on the market, even HTML5 beats it in every way)

- a web target. (if this was NOT relevant I think flutter and Unity would NOT have it)

I would advise if people report things to spend the time investigating it and have a sample to demonstrate the problem

instead of just adding the so called problem to a pile of thing that only gonna get bigger with time.

Whatever the size of the HARMAN dev team, if you made them investigate "bugs" that are not really there,

you basically make them lose a lot of time they could have spent doing other things.

so my opinion is whoever report a bug, should have a sample, details on how to compile it,

pass it around to few other dev (not just 2, at least 3 or 5), so it can be confirmed,

and then you report the bug to HARMAN.

the "I heard someone had a bug so I report it", sorry I don't think this help at all.

So here is the code of the test that shows how much slower Windows 64bit captive is when compared to Windows 32bit captive:

package {     import flash.display.Sprite;     import flash.display.StageAlign;     import flash.display.StageScaleMode;     import flash.events.Event;     import flash.text.TextField;     import flash.text.TextFormat;     import flash.utils.getTimer;     import flash.utils.setTimeout;         [SWF(frameRate="60", width="1280", height="720", backgroundColor="0x000000")]     public class Windows64BitPerformanceTest extends Sprite     {         private static var i:int = 0;         private static var c:int = 0;         private static var m:int = 0;         private static var f:int = 0;                 private static const ITERATION_COUNT:uint = 500000000;         private var _logTextField:TextField;         private var _logTextFormat:TextFormat;                 public function Windows64BitPerformanceTest()         {             stage.align = StageAlign.TOP_LEFT;             stage.scaleMode = StageScaleMode.NO_SCALE;                         this.loaderInfo.addEventListener(Event.COMPLETE, this.loaderInfoLoadCompleteEventHandler);         }                 protected function loaderInfoLoadCompleteEventHandler(event:Event):void         {             _logTextFormat = new TextFormat('Verdana', 40, 0xFFFFFF, true, false, false, null, null, 'center');                         _logTextField = new TextField();             _logTextField.setTextFormat(_logTextFormat);             _logTextField.defaultTextFormat = _logTextFormat;             _logTextField.width = stage.stageWidth;             _logTextField.y = stage.stageHeight / 2;             addChild(_logTextField);                         setTimeout(runTest, 1000);         }                 private function runTest():void         {             var time:int = getTimer();                         for(i = 0; i <= ITERATION_COUNT; i++)             {                 f += incrementC();                 f += incrementM();             }                         _logTextField.appendText('Completed in ' + (getTimer() - time).toString() + ' milliseconds.');         }                 private function incrementC():int         {             if(isModule2(c) == 1)             {                 c += 1;             }             else             {                 c += 2;             }                         return c;         }                 private function incrementM():int         {             if(isModule2(m) == 1)             {                 m += 1;             }             else             {                 m += 2;             }                         return m;         }                 private function isModule2(v:int):int         {             if(v % 2 == 0)             {                 return 1;             }             else             {                 return 0;             }         }     } }

On my machine this test completes in around 15 seconds for 32bit but for 64bit it took 43 seconds so this difference is very huge. This test was run on Windows 10 with Intel i7 CPU. This was tested with latest AIR 32 SDK.

Also here are the download link for executable files of this test for both 32bit and 64bit so guys please test it if you have AMD CPU to see if there is difference:

http://bit.do/eUCzx