It’s been nearly two years since ANELAB software has been at work. It has proofed many times that it is a useful software and makes ANE implementations an easy job.
An interesting ANELAB user experience is that users have been finding creative ways to use the software. Ways that we didn’t think of, when developing it but as it seems, users prefer to use ANELAB in this manner and not exactly how we had imagined. In this post I will be talking about how ANELAB users are making the most out of it.
ANELAB has been designed to be working within your main project files but in actual experiences, many users are creating dummy projects first (with the same app package name as their main project) and then create a new ANELAB project there. Then they use ANELAB to add their project’s required ANEs.
After adding the ANEs and hitting the “sync project” button, the software will start adding the ANEs to the dummy project. Now you will go through what has been changed in your dummy project and start mirroring the changes in your main project. Although this seems like an extra step and a waste of time, I personally approve it because while you are mirroring the changes, it gives you a better understanding of what has been changed in your app. It kinda gives you more control over your project and makes you aware of every little change that might be happening to your project files.
NOTICE: The dummy project package name and Version number must always be equal to your actual project version. Forgetting to do so will cause ANEs to show the “Demo Dialog Window” when the testing app starts.
Depending on ANEs, ANELAB might be doing all or some of the following jobs:
Adding ANE resources
Adding ANE files and their dependencies
Modifying the manifest .xml file
Adding .framework files to AIR SDK
Adding ANE Resources
Some ANEs like GoogleSignIn, MLKit or AR, need some files to be added to your project as file resources. These files must be implemented to your project manually and how you add them to your project is different based on what IDE you use. These files must be added to the root of your project and will be accessible through
File.applicationDirectory.resolvePath("resource.file"); When updating the ANEs, these resource files might change, new ones might be added or some might be removed or renamed. So, when you start mirroring them from the dummy project, you will surely know what is changed exactly and you will not miss them.
Adding ANE Files and Their Dependencies
When using ANELAB, all the .ane files being added to your project will have a file name in this format: firebase.core-V8.0.0.ane and whenever there’s an update for the ANEs, the version name also changes. For an IDE like IntelliJ, that’s not a problem because if you are using IntelliJ IDE, you can modify the settings so the IDE would add all the .ane files it can find in an specified directory. If ANE file names change, it doesn’t matter. But in AdobeAnimate IDE, changing the name of ANEs can cause problems because you have to manually add the ANEs inside AdobeAnimate IDE. Imagine what a mess it would become if ANELAB is renaming your main project’s ANE files each time there’s an update! So, when you do the update on the dummy project, at the time when you start mirroring the changes, you can just rename the ANE files so you don’t have to manually remove/update them from inside the AdobeAnimate. For example you can keep the file name as firebaseCore.ane in your main project.
Modifying The Manifest .xml File
When creating an ANELAB project, you will set your project’s manifest file and the software will use that .xml file to add ANE configurations for both Android and iOS. on IDEs like IntelliJ, this is not a problem because IntelliJ uses only one manifest file for both Android and iOS. But when you are building your project with AdobeAnimate IDE, you have two separate manifest .xml files. One for Android and one for iOS. So, when you use ANELAB on a dummy project and it modifies the .xml file, it will be a very easy job for you to copy the content of
<android> tag to your Android manifest file and then copy the content of
<iPhone> tag to your iOS manifest file instead of having to create two different ANELAB projects for each of your builds.
Adding .framework Files to AIR SDK
When using ANELAB, it will copy some iOS .framework files to your AIR SDK/lib/aot/stub directory. No matter if it is a dummy or main project, the required .framework files will be copied there and there’s nothing for me to add about this part 😀
The ultimate goal of ANELAB is to make ANE implementations easier. So, no matter how you use the software, as long as it makes you happy, then it’s the correct way 🙂
ANELAB User Experience
It’s been nearly two years since ANELAB software has been at work. It has proofed many times that it is a useful software and makes ANE implementations an easy job.
An interesting ANELAB user experience is that users have been finding creative ways to use the software. Ways that we didn’t think of, when developing it but as it seems, users prefer to use ANELAB in this manner and not exactly how we had imagined. In this post I will be talking about how ANELAB users are making the most out of it.
ANELAB has been designed to be working within your main project files but in actual experiences, many users are creating dummy projects first (with the same app package name as their main project) and then create a new ANELAB project there. Then they use ANELAB to add their project’s required ANEs.
After adding the ANEs and hitting the “sync project” button, the software will start adding the ANEs to the dummy project. Now you will go through what has been changed in your dummy project and start mirroring the changes in your main project. Although this seems like an extra step and a waste of time, I personally approve it because while you are mirroring the changes, it gives you a better understanding of what has been changed in your app. It kinda gives you more control over your project and makes you aware of every little change that might be happening to your project files.
Depending on ANEs, ANELAB might be doing all or some of the following jobs:
Adding ANE Resources
Some ANEs like GoogleSignIn, MLKit or AR, need some files to be added to your project as file resources. These files must be implemented to your project manually and how you add them to your project is different based on what IDE you use. These files must be added to the root of your project and will be accessible through File.applicationDirectory.resolvePath("resource.file"); When updating the ANEs, these resource files might change, new ones might be added or some might be removed or renamed. So, when you start mirroring them from the dummy project, you will surely know what is changed exactly and you will not miss them.
Adding ANE Files and Their Dependencies
When using ANELAB, all the .ane files being added to your project will have a file name in this format: firebase.core-V8.0.0.ane and whenever there’s an update for the ANEs, the version name also changes. For an IDE like IntelliJ, that’s not a problem because if you are using IntelliJ IDE, you can modify the settings so the IDE would add all the .ane files it can find in an specified directory. If ANE file names change, it doesn’t matter. But in AdobeAnimate IDE, changing the name of ANEs can cause problems because you have to manually add the ANEs inside AdobeAnimate IDE. Imagine what a mess it would become if ANELAB is renaming your main project’s ANE files each time there’s an update! So, when you do the update on the dummy project, at the time when you start mirroring the changes, you can just rename the ANE files so you don’t have to manually remove/update them from inside the AdobeAnimate. For example you can keep the file name as firebaseCore.ane in your main project.
Modifying The Manifest .xml File
When creating an ANELAB project, you will set your project’s manifest file and the software will use that .xml file to add ANE configurations for both Android and iOS. on IDEs like IntelliJ, this is not a problem because IntelliJ uses only one manifest file for both Android and iOS. But when you are building your project with AdobeAnimate IDE, you have two separate manifest .xml files. One for Android and one for iOS. So, when you use ANELAB on a dummy project and it modifies the .xml file, it will be a very easy job for you to copy the content of <android> tag to your Android manifest file and then copy the content of <iPhone> tag to your iOS manifest file instead of having to create two different ANELAB projects for each of your builds.
Adding .framework Files to AIR SDK
When using ANELAB, it will copy some iOS .framework files to your AIR SDK/lib/aot/stub directory. No matter if it is a dummy or main project, the required .framework files will be copied there and there’s nothing for me to add about this part 😀
The ultimate goal of ANELAB is to make ANE implementations easier. So, no matter how you use the software, as long as it makes you happy, then it’s the correct way 🙂
Share this:
Related