I know that MonoTouch compiles code down to native machine code. Is there anyway to make a native (.a) class library using MonoTouch? Just to be clear, I'm not looking to share code between the two since I know that is not possible.
I believe it might be possible, but it would be hard work, and it's a long way from shrink-wrapped out-of-the-box functionality.
For reference, take a look through the answers on Is there a way to mix MonoTouch and Objective-C? - that question is about how to bootstrap and then call into mt from an obj-c application. I think the same approach would just about work for a .a library.
Related
I want to import a Swift framework called "Beethoven" into Objective-C project. I import this framework via cocoapods.
The problem is that framework is written in pure swift. Since the classes are not subclass of NSObject they can't be used directly in my objC classes.
I am newbie in Swift and intermediate in objC, but I think there may be 2 solutions for that:
1-Modifying the whole library: which is probably not an optimal solution.
2-Using a new class which behaves as an interface between swift framework and my objC code. I think second solution will be a better alternative in terms of time and effort needed.
Actually below given post explains modifying the pure swift classes but I don't know how to apply this in my case.
How to use Swift non-NSObject subclass in Objective-C
As I mentioned I am not a very capable programmer and there may be better solutions for that problem. I would be grateful if someone can help me and suggest the best solution for integrating pure Swift framework into my objC project.
NSObject is usually not the only problem. Swift has many features that are not supported by Objective-C. To name a few: swift value types (struct's), swift enums with attached values. If a library uses any of those, it will not be possible to auto-generate an Objective-C header (.h) for it.
Adapting the code of the library on the spot might work, but it is likely more work long term in case if you ever need to update that library again.
Your 2nd approach sounds better: create a layer that is compatible with Objective-C on top of the library which exports methods that need to be exported with #objc and adapts the types. If you go that way consider making a PR contribution to the original library so that everyone could use it in Objective-C projects, and you share responsibility of updating it when the swift code changes.
The 3rd approach would be actually to rewrite some parts of you app to Swift. That might or might not be easier depending on the size of the part of the app that is using the library and how well it is isolated from the rest of the app.
I've got an iOS dynamic framework written in Swift and would like to know what ways I can "export" the framework for use in external projects, while leaving the implementation unexposed.
The "best" solution I've come across so far is from this article, but for some reason autocompletion stops working when I'm trying to use classes from the framework in a project.
Right now I'm using a Xcode workspace to use the framework within a project. However, as mentioned I don't want to have the implementation exposed.
I understand that Swift doesn't have separate interface and implementation files found in Objective-C, but am just curious as to how other people approach this.
I am needing to use the widevine api in an ios app written in xamarin. From what I understand I need to make a wrapper for the library and such, but I have no idea where to start. Can anyone either explain in more detail what to do, or point me somewhere that explains it well?
Thanks, I am quite new to Xamarin, and rusty on C#
You definitely want to follow Jason's comment. In short, you need the .a (fat library) and the header files and then create a Xamarin.iOS binding project that exposes the native interface to C#. Access to the source code is not necessary.
I am very new to the field of ios programming and working with linker is just a whole new world to me. I would try my best to be precise about my question.
Context: Static library linking in an ios project using xcode.
Problem:
Problem members:
3 static libraries.
libTestLibA.a
libTestLibB.a
libTestLibB_mine.a -- same functionality as libTestLibB.a -- same classes/methods everything.
Problem description
I am making an app using libTestLibA.a.
libTestLibA has some classes that depend on some classes from libTestLibB. Hence libTestLibA.a has libTestLibB.a compiled in itself.
Now, I have my own library named libTestLibB_mine. It has the exact same functionality as that of libTestLibB. Same methods / classes for same functionality. I want libTestLibA to use libTestLibB_mine instead of libTestLibB. I just have compiled static libraries (.a) for each of the problem members , ie, libTestLibA, libTestLibB and libTestLibB_mine.
Question:
When I compile my application, can I force a static compiled library (libTestLibA.a) to make use of another library (libTestLibB_mine.a) instead of what it already contains (libTestLibB.a)? If yes, how? If not, is there some work around?
Much thanks.
If A has already been statically complied against B, then I don't think you can replace B with B_mine. But as a workaround, I think what you might be looking for here is "Method Swizzling". What it does is, at runtime, replace the method of a class with another method (intercept the message and direct it somewhere else).
The following links should be useful to you.
CocoaDev Method Swizzling
JRSwizzle - open source library to make swizzling easier
Be sure to read about the dangers of method swizzling too.
I apologize if this is a dumb question, or if it does not make sense. I've written some Objective-C code before, but I am not very familiar with writing code for OS X or iOS; I'm pretty much a novice. Currently, I'm trying to port a project from OS X into iOS. The project compiles into a Framework, that other OS X projects can use.
I'm trying to do something similar for iOS. I understand that iOS does not support Frameworks that contain dylibs and that the solution is to create a static library. However, the OS X Framework has several classes (in .m files) that the implementing code uses, extends, or implements. All the examples I've seen for static libraries seem to define a header-file with some functions that can be compiled into a static library.
Is it possible to have classes inside the static library, that iOS code can use? Also, how can I tell if the code is using dynamic libraries?
Yes, static libraries can contain Objective-C classes.
In some cases, you will need to pass options to the linker to force it to include all of the classes and categories defined in a static library. See http://developer.apple.com/library/mac/#qa/qa1490/_index.html