When "mavenizing" a Flex SDK (convert the Flex SDK to Maven artifacts) you need to indicate the Flash Player version. Does it mean that I can only create Flex swf web (not air) applications which run on that version of the Flash Player or can I still target earlier versions?
I was wondering if I can simply select the most recent Flash Player version or if I should keep in mind that some of the users are still using an older version.
Actually the mavenizer creates artifacts for whatever it finds. Usually you installed a Flex version with the version you selected in the Installer. The Mavenizer can only create artifacts for what he finds. If you have multiple versions in your FDK, it will generate mutliple versions.
So if you want to target 9.0 for example, you have to have the playerglobal for that in the "FDK-home/frameworks/libs/player/9.0" directory and the Mavenizer will create artifacts for 9.0. You can then simply reference playerglobal in version 9.0 and as long as you only use parts of flex that don't need anything beyond 9.0 you should be good to go.
You can still target earlier versions. Just think of that version selection as the minimum required flash player version. Certain bits of functionality were exposed to the FlexSDK in certain versions of the flash player. For example feature X is available in Flash Player 10.0 but not in Flash Player 9.0, so if you use feature X then you will require at least Flash Player 10.
No you can target other versions. You can also change the target version after the fact (look at the scripts in the ide directory).
Newer versions of the Flash Player have security fixes and better performance, but it's not the version you compile the SDK has any effect on this, it's the version that you run the swf in that matters. Given that I'd compile for a older version of the Flash Player to give a wide user base, (for instance target 11.1) unless you need to use some of the very latest Flash Player features.
Each version of the SDK was tested with several versions of the FP but not all of them, so it may be possible (but unlikely) bugs exist on a version the Flash Player that the SDK wasn't tested with.
Related
The version compatibility of Vulkan SDK is documented in LunarG's whitepaper, but I'd like to know whether those extensions controlled by the flags listed below are following the same rule as well.
VK_USE_PLATFORM_DIRECTFB_EXT
VK_USE_PLATFORM_ANDROID_KHR
VK_USE_PLATFORM_FUCHSIA
VK_USE_PLATFORM_IOS_MVK
VK_USE_PLATFORM_MACOS_MVK
VK_USE_PLATFORM_METAL_EXT
VK_USE_PLATFORM_VI_NN
VK_USE_PLATFORM_WAYLAND_KHR
VK_USE_PLATFORM_WIN32_KHR
VK_USE_PLATFORM_XCB_KHR
VK_USE_PLATFORM_XLIB_KHR
VK_USE_PLATFORM_XLIB_XRANDR_EXT
VK_USE_PLATFORM_GGP
VK_USE_PLATFORM_SCREEN_QNX
VK_ENABLE_BETA_EXTENSIONS
I believe if the VK_ENABLE_BETA_EXTENSIONS is enabled, then the version compatibility is not guaranteed, but how about those platform extensions?
For the time being, SDK copies the versioning of the specification. If the SDK version is same or higher, the headers should include all the functionality published with a given spec version(and protected by an appropriate macro, as you listed them), and layers should not break (exept for an occasional bug).
Im developing an application that would detect the DirectX versions installed on my system. For example if DirectX 9 and DirectX 11 are installed on my system then my program must detect these installations and display the installed versions. But I've no idea on how to accomplish this
EDIT:
I dont want to use dxdiag UI to detect the versions, I want my program to detect the versions. And all installed versions must be detected not just the one that is pre-installed with the OS or the highest level supported by the OS
You'll most likely not be able to list all installed DirectX versions. I came across this interesting article in the support pages of the gaming platform called Steam:
Trying to manually check for the correct versions is extremely complicated because there are numerous files that must all be present and individual system configuration options like dll search paths complicate the situation. In addition, the dependencies and required checks may change in each new version of the D3DX runtime.
As mentioned by Hans Passant you can get the highest installed version by running dxdiag /x <output file> to generate an XML file containing various entries of your computer information, then parse or deserialize that file in your application.
Is Android Device defaultly support mono ? or
We need to install any thing on android device for supporting Mono(which the application developed by Xamarin).
Xamarin's mobile/Mac solutions use a different approach compared to Microsoft .NET. The rules are,
You don't need to install a .NET/Mono runtime on Mac or iOS or Android devices before installing an app.
When you build the deployment packages of your app (Mac/iOS/Android), Mono compiler tool chain automatically merges your binaries with Mono binaries so the final packages are self contained (they contain every bits needed without dependencies on external components). This is required by Mac App Store, iOS App Store, and various Android app stores.
Note that because that Mono bits are embedded in each packages built, those packages are slightly larger than the ones created using Objective C or Java.
I don't think it supports mono by default.
http://mono-project.com/Start
With the new firefox we are shipping more and more libraries as the XPom interfaces we interact with are changing. We are at 10 dlls and increasing, each with a size of almost 2M.
This size is a concern for some users.
While we look at restructuring the library to seperate the parts we can make common between them, we are thinking about how we might reduce space on the disk while supporting version upgrades.
For instance, user has FireFox 3.6 and 4.0 installed and when our product is installed we install a dll for each version. When Firefox is 4.0 upgraded (say to 6.0) how might we now install from the msi the missing dll for 6.0 support.
Any ideas on how we could achieve this?
Are we worrying for no reason?
My first thought was we 'AllowAdvertise' and when FF tries to load the dll as directed by chrome it will cause the install, it doesn't seem to work.
My first reaction is to suggest that you move away from XPCOM and towards js-ctypes. After all, this is the direction that Mozilla is pushing extension developers (see Wladimir Palant's comments for example). If there isn't anything in your binary code that absolutely positively requires use of XPCOM, you'll be much happier to ship a DLL that interfaces with JS when needed via js-ctypes.
I guess that your extension is Windows-only so supporting multiple platforms is not an issue. A possible short-term solution:
Have a separate extension package for each Firefox version, mark it as compatible with this Firefox version only (e.g. minVersion 4.0 and maxVersion 4.*).
When your extension is installed, install the version that is compatible with user's installed Firefox version.
Make sure that your extensions have an updateURL entry that is pointing to your server. It is important to have %APP_VERSION% in the URL.
Make sure to test Firefox betas and prepare a new extension version in time for the next Firefox release (releases are scheduled on Tuesdays every 6 weeks, next release being on September 27th).
Configure your server to indicate different packages as updates depending on the Firefox version used. So an update check with %APP_VERSION% 4.0.1 would be sent to extension-ff4.xpi while %APP_VERSION% 6.0 would get extension-ff6.xpi.
Firefox will always check for extension updates when the application is updated. If you can give it a compatible update it will install it. But preparing new packages every six weeks requires tons of effort and I guess that you want to refactor your code/move to js-ctypes ASAP. Oh, and I think that you need to ignore the unlikely scenario that some user has more than one Firefox version installed.
I use FlashDevelop as my code editor and the Flash CS4 IDE for publishing my AIR files (as well as asset control, animation creation etc...). The bonus of this is the Flash IDE handles all the crap of creating certificates and whatnot very easily as well.
Flash CS4 uses Adobe AIR 1.5, which is very old and I am wanting to update it to AIR 2.6, which as of current writing, is the latest version of AIR. Also, I don't know if this is of any significance, but I would like to publish AIR apps for Android now. I've successfully made an AIR app for PC in the past, using AIR 1.5.
I downloaded the AIR 2.6 SDK from the Adobe website and replaced all the files inside the "AIK1.5" folder of my Flash installation (the folder being still named 1.5 inherently annoys me).
Is there any other steps I must take? Because I'm not convinced I'm publishing AIR 2.6 apps as the application.xml file in my AIR project still reads:
<application xmlns="http://ns.adobe.com/air/application/1.5">
If I change the version in the .xml, Flash explodes (doesn't compile, gives me an error).
Furthermore, if I go File > Publish Settings, then the Flash tab, the player field reads as "Adobe AIR 1.5". Is this right? I'm assuming this will always be this way, even if you do successfully update the AIR version, since apparently Adobe is too lazy to update CS4 so that it can logically figure out it has the new version of AIR.
Also, if AIR is free, why the hell does Adobe not at the very least, release updates to CS4 that update the version of AIR it uses. This seems to be fully within their power, and it seems incredibly negligent that they don't do this for people who have bought their software.
Please, if you could provide clear step by step help, because I'm very ignorant when it comes to development configurations and stuff. I just want to write code and be off.
UPDATE
Once you've updated Flash's AIR library with AIR 2.6, and have compiled your AIR project, make sure you use the new application descriptor template from the AIR SDK. I originally thought it just required changing the version number from 1.5 to 2.6 or whatever new version you're using. As seen below.
<application xmlns="http://ns.adobe.com/air/application/1.5">
But the format as changed, and you really need to use the new template, otherwise it won't work. And when you compile you won't automatically get a preview of your compiled .swf. This will happen in FlashDevelop too if you've set-up your descriptor file incorrectly.
Bzzzzzzt wrong you can hack apart your CS IDE and get it working follow the concepts in this tutorial, they should get you going and you should be able to piece it together from there.
http://swfhead.com/blog/?p=16
If you have any problems just post a comment I'll help you sort it.
You will need to purchase the latest version of Creative Suite or Flash/Flash Builder to take advance of the latest versions of AIR.
Like any other software, releases are versioned with specific features and newer versions support newer features and integration into other newer technologies.
Its like Microsoft is well in their power to provide docx support in windows 2003, but that would just cause compatibilty, support and licensing issues.
These are the tutorial for Flash cs 5:
http://blog.prevail.co.nz/2011/06/21/overlaying-air2-7-in-flash-cs5/
These are the tutorial for Flash cs 5.5:
http://www.yeahbutisitflash.com/?p=2949
http://helpx.adobe.com/x-productkb/multi/overlay-air-sdk-flash-professional.html
This is the tutorial for Flash cs 6:
http://www.leebrimelow.com/?p=3335