I'm new to Adobe AIR development and have been developing a Native Extension.
Apparently, I need to include with the .ane file, a .swc file that is needed to build against the .ane. Why is this? Why can't the developer just build against the .ane? What is missing in the .ane that the .swc provides?
I'm trying to write internal documentation about the project and have gotten stuck on this question.
The SWC is totally unnecessary in most development situations.
There are two situations where the SWC may be required:
If you are using an older development environment, where ANE's weren't supported you may be required to use a SWC to successfully build your code and then package with adt from the command line
If you are trying to use an ANE in a library, you'll need to build the library against the SWC and then package your application with the library and the ANE
A decent ANE developer will actually include a SWC packaged inside the ANE. The default library should be included in every ANE to handle the situations where the platform isn't supported (returning isSupported false etc). So when distributing ANE's you don't need to include a SWC, as it can be obtained via the following:
unzip the ANE
browse to META-INF/ANE/default
use the SWC located in that directory
You do not necessarily have to use an SWC in combination with an ANE. The ANE does already work standalone. I have used a few ANEs (like Native Dialog, Vibration, AdMob) without the SWC. However, I cannot answer why most of the time an SWC exists.
When you developing your ANE - you must provide AS3 API wrapping classes that your AS3 editor will read and use it for code hints + compiler will know what to do when you compile your app.
ANE contain swc inside so you don't neet to provide eexternal swc. Just use 1 ANE. Buy SWC is required to ANE developing. Not for end user. But I know in some cases old software don't know how to parse ane correctly and you need to provide also swc.
But I don't use swc + ane. Just one ANE.
Related
I am a new guy in OC programming. Now I am involved in a framework development project.
I know the framework works as a library, which contains a group of methods. It's not an application that can run on devices.
Actually, our framework will work with customer's application. We want to investigate what happened inside our framework when customer's application crashed. So I want the 'DSYM' file of our framework, instead of an application.
As far as I know any iOS application does have corresponded 'DSYM', but I didn't find the 'DSYM' of our framework.
Does iOS framework project have 'DSYM'? If it does have, how can I obtain it?
By the way, I am using Xcode 8.1.
Thanks!
According to my observations, .dSYM files are generated for iOS dynamic framework built with Release configuration only.
After build succeeds, the debug symbols files can be found at these paths, for a device and simulator, respectively:
<Build_Root>/build/Release-iphoneos/<Product_Name>.framework.dSYM
<Build_Root>/build/Release-iphonesimulator/<Product_Name>.framework.dSYM
, where
<Build_Root> is usually a subdirectory within Derived Data directory;
<Product_Name>is the name of your framework.
Yes, you can generate dSYMs for dynamic frameworks. There are a few relevant build settings that control whether and where these files are generated:
DEBUG_INFORMATION_FORMAT = dwarf-with-dsym,
DWARF_DSYM_FOLDER_PATH = "$(CONFIGURATION_BUILD_DIR)",
DWARF_DSYM_FILE_NAME = "$(PRODUCT_NAME).dSYM"
Obviously, you can set these to whatever you want, either in your project's build settings in Xcode (the project.pbxproj file) or as arguments to xcodebuild (depending on how you generate your framework).
DSYM (Debugging SYMbols) files generally store the debugging symbols for your app. And if app crash any where symbols replaced with appropriate method name so that it could help developer in a readable form. And for that you can use the crash log and they can be find in the iPhone where the app is installed. Each app and device have their own crash log.
Also please check this link it might help you.
Read Crash Report
Upload Symbols for iOS Framework
Hopefully these might help you or guide in the right direction.
I have created a cocoa application primarily to run on OS 10.6.8. to convert certain types of proprietary legacy files. The app looks at the legacy files creator code and processes it accordingly if it is a known type. Once the file is identified, I call an external legacy app (which I have added to the project) using [NSWorkspace openFile: withApplication: ]to open the droplet and process the file conversion.
The application works just like it is supposed to until I archive it and try to run it from the application bundle. Actually, it will continue to work but it is using the converter app from the project. If I delete the converter in the project area, then the app in the app bundle can not open the external app in that location. One work around is to delete the external app from the bundle after its archived and replace it with a copy of the one in the project area.
I would appreciate any suggestions on resolving this. I'm not sure if the problem is in some Xcode build setting I can change to include an external apps resource fork when archiving, or if this is a launch services issue with apps hidden in packages, or , something I'm not even considering.
Thanks
Mike
Try setting the "Preserves HFS Data" (COPYING_PRESERVES_HFS_DATA) build setting.
This question will be easy for Xcode pros but for a MonoTouch developer it seems to be impossible to resolve. :-)
I'm using Xcode 4.5 and I want to target iOS 5.1 and above and iOS Simulator 5.1 and above.
I have a a library project here and it is coming with a prebuilt binary named "DemoLib" (no extension and it is 11MB in size). The library is a fat lib for Simulator and iOS 5.1+.
I can use that library without any problem.
However if I try to build the library myself, I end up with a "DemoLib.a" file (notice the extension and the size of 30MB). How can I get the same build result? What is a .a file compared to the file without extension?
I tried to build the project "for running", and "for archiving" in Xcode. Both results in the same 30MB .a file.
I was expecting some dropdown in Xcode where one could select "DEBUG" or "RELEASE" build and the latter one would create the smaller lib.
Of course I could never tell without seeing the framework's project file. Having said that, there is an excellent guide to creating and compiling iOS frameworks here: https://github.com/jverkoey/iOS-Framework
Using the above guide, you should be able to recreate your framework's project from scratch, add the files you have to it, and properly compile it.
Hope this helps! :)
Did it come with a Makefile? Create a new target, set the build settings of the target to what's in the Makefile, then set your project to depend on that new target.
A file with the .a is a static library, which means it depends on nothing external and all the code it needs is compiled inside it. I think no extension generally implies dynamic library, which means it'll depend on some dependencies being present on your system to link against. Maybe that's why the .a is so much bigger. I think Xcode will build static by default because iOS does not allow the use of dynamic libraries.
The dropdown for what to build is in your scheme. Command+shift+< to view your scheme. Within the scheme you can edit which environment each method of building will use.
For a project I am doing, I want the Mac application to accept plug-ins. I like the whole idea of just adding Bundles to the application to extend it's functionality.
Only I came across a small question, where I can't find the answer to:
I need to include a JSON parser in my application, for some functionality. Is it possible for a plug-in Bundle to also use that same parser? Or does every plug-in that uses a JSON parser, need to include the parser themselves?
What is the best way to do this for separate Bundles?
On OS X there are two types of loadable things, a dylib and a plugin. (These two terms have specialized technical meaning in the context of mach-o, the binary format OS X uses.)
A loaded dylib can't refer to the libraries in the executable, while a loaded plugin can. As a side effect, a dylib can be loaded to any executable, but a plugin can only be loaded into the executable you specify when you make the plugin.
So you want to make a plugin. There is a template in the XCode to do that. Don't forget to specify the target executable in the linker flag, which can be set somewhere in the inspector.
For more, read Code Loading Programming Topics.
How can I know, whether an external library can be compiled to work on a different platform? the library for instance is tesseract-ocr
And if it possible, how do I do this?? (Basically I would like to create a Qt application that uses this library)
To find out, try building the library yourself. At the moment your question is quite broad. Post new questions when you have something more specific to ask.
If building the library fails, it is most probably due to some unsupported dependencies that you need to port first yourself.
Porting to Maemo is probably straightforward as it is a Debian-based environment and supports all the build tools such as autotools.
Symbian doesn't have autotools. Perhaps the fastest way to get started there is to first configure and build the library on e.g. cygwin and then generate the required bld.inf and .mmp files to build it on Symbian.
You can link your Qt application to regular C/C++ libraries. Just include the necessary header files in your code and link to the library using LIBS += -lfoo in your .pro file.