I am interested in RubyMotion, but would like to understand more about using 3rd party iOS frameworks before paying the license fee.
I see in section 2.2 here, it states:
"To vendor a 3rd-party library in a RubyMotion project, the source
code must be available somewhere on the filesystem."
My understanding of an iOS framework is essentially a static library (.a file) and a bunch of header files, with no source code - this seems to suggest to me that it is not possible to use a 3rd party iOS framework with RubyMotion.
However, reading this documentation further states that it is possible to supply the project type :static to the vendor_project method along with :products (an array of static library names) and :headers_dir (path to the directory that contains public headers files). This seems to contradict the assertion that the source code must be available.
So my question - is it possible to use a closed-source 3rd party iOS framework with RubyMotion where there is no access to the source code?
Yes it's totally possible. I think what the documentation means is just you need to include everything you use in the project.
You can either use a xcode project or as you said, a static library(.a file) with several header files (maybe some objective-c wrapper files too).
something like this in your Rakefile will do the job!
app.vendor_project('vendor/your-lib-name', :static,
:products => ['lib.a'],
:headers_dir => 'lib-header-path')
here is an article that I found really helpful, it explains well how to use 3rd party library in RubyMotion.
Other than including a library in your project manually, you can also use libraries available on Cocoapods. There is a RubyMotion wrapper - motioncocoapods for this, i recently done an article on this subject, you can have a look if you are interestd.
Related
I have an application Unity that uses the iOS static library. Then this application Unity is build in XCode. I found several utilities that allow you to obfuscate the library in the application. for example this - PPiOS-Rename.
I carefully read their documentation "Obfuscate Static Libraries", but at the time of building, the iOS static library are already "hidden in the root" of the Unity app, and XCode cannot obfuscate this.
So I need to first obfuscate the library and then add it to the application. or is it not possible?
In my understanding of the documentation PPiOS-Rename stays an external tool, just the files *.plist can be added into the releases, for being able to use the tool on the compiled releases.
I might be completely wrong about it, especially as without iOS I can't test it, but I'd check if my statement is right and if you can omit the step to include the library in your compiled releases.
About handling of *.plist files, follow the instructions on the linked page, I'm not sure if you have one or more in the end. As it doesn't seem relevant to the core of your question, I never verified it deeper.
Building Modern Frameworks says every app has its own copy of a custom framework. Now that Xcode supports iOS frameworks, is it still true that frameworks are static libraries but just more convenient? If that's true, then why choose the static library template? Otherwise, should I convert all my required custom frameworks to static libraries once Swift supports static libraries?
Frameworks serve the same purpose as static and dynamic shared
libraries, that is, they provide a library of routines that can be
called by an application to perform a specific task. For example, the
Application Kit and Foundation frameworks provide the programmatic
interfaces for the Cocoa classes and methods. Frameworks offer the
following advantages over static-linked libraries and other types of
dynamic shared libraries:
Frameworks group related, but separate, resources together. This grouping makes it easier to install, uninstall, and locate those
resources.
Frameworks can include a wider variety of resource types than libraries. For example, a framework can include any relevant header
files and documentation.
Multiple versions of a framework can be included in the same bundle. This makes it possible to be backward compatible with older
programs.
Only one copy of a frameworkâs read-only resources reside physically in-memory at any given time, regardless of how many
processes are using those resources. This sharing of resources reduces
the memory footprint of the system and helps improve performance.
This excerpt taken from here.
Excerpt taken from here.
How are Frameworks and Library Different from each other?
Inversion of Control is a key part which makes a framework different from a library. When we call a method from a library we are in control, but with the framework the control is inverted, the framework calls our code. (E.g a GUI framework calls our code through the event handlers)
A library is essentially a set of functions (well defined operations) that we can call (organized into classes). Each does some work and then returns the control to the client
A framework embodies some abstract design with more behavior built in. In order to use it, we need to insert our behavior into various places in the framework either by subclassing or by plugging in our code. The framework code then calls our code at these points.
A framework can also be considered as a skeleton where the application defines the meat of the operation by filling out the skeleton. The skeleton still has code to link up the parts
The use of dynamic frameworks is exclusively for swift from iOS 8 and later, i.e (you can't submit a build with iOS 7 and a dynamic framework)
If you want support for iOS 7 and before you can use a static library and objc
A dynamic framework and a static library are different things, a framework is a bundle where you have a directory and can include resources, views, classes, and also libraries
A static library is only executable code
Also you use the code in a static library inside your own code, in the case of a framework he use the code and handle the way it runs and what do
This link could help you
http://www.knowstack.com/framework-vs-library-cocoa-ios/
This is just an informational question, I have been examining several ways to make frameworks in iOS.
I made
Swift Pure frameworks:- There I got to know that, you have to include the xcodeproject to the application project to use the .framework included in .xocdeproject. So I thought this is not the secure way to giving code to third party and I also I did not find ways to include the third party frameworks to my own framework.
Objective Static Libraries:-
In this type libraries, the system is generated a .a file which is secure and the person gonna use does not know the implementation part however found out that if I want to include a third party framework to this, I will have to ask the end user to include that third party project to end application to compile it which will show the end user what all dependancies I have, which I don't want.
My issue is I wan to make a Framework which will consist of all the third party frameworks however, they would be hidden from end user although the codes from them can still be used by end user as required however, end user should not see them listing in my framework.
Is there a way out?
I have gone through many links and found out that many have this doubt as well
Like
Adding FacebookSDK.framework into my own Static library
In this post, one person is asked to get all header files and the framework file and then add that to static libraries to build to add the framework itself, I tried that too without success.
Do not do that.
There is literally no good outcome of what you're trying to do. This is very confusing and couples your library API with a different library's API, forcing the user to stick with your version of the 3rd party lib.
If the user will want to use a newer version of the 3rd party dependency, he won't be able to, because it will result in duplicate symbols.
You can't find any information about such practice on the internet, because nobody does this.
If you want to distribute an already compiled library, there's no other way than just compile all 3rd party code with it, without exposing the header files.
There's one very big important thing left: you have to make sure that users of your SDK will not end up with duplicate symbols if they also use the 3rd party library!
More here...
And here...
I'm working in a iOS project that includes a static library created by another company.
The library include an old version of AFNeworking and I don't have any source files.
Now i need to use a more recent (and less bugged) version of afneworking, but i cannot include the same class twice in the project (of course) because all the "duplicate symbols".
I understand that it's impossible replacing the version included in the library, but how can i include another version along the old one?
There is a (easy) way to refactor the entire framework before include in my project?
thanks
You'll have to repackage the static library to remove the embedded AFNetworking files.
Unpack the library with:
$ ar x libwhatever.a
And re-package it, including all files except the AFNetworking object files:
$ ar cr libwhatever.a file1.o ... fileN.o
You will then have to link your executable with the new AFNetworking static library and hope that there haven't been API changes which will break the code in libwhatever.a. If there are then I doubt there is much you can do.
I'm afraid this isn't easy to do. Very few environments allow you to link against two separate versions of the same framework at the same time, and Xcode / iOS is not one of them.
As I see it, you have three options:
1) Link against their library and use the same version of AFNetworking they use.
2) Link against their library, and manually load the newer version of AFNetworking and pull symbols from it. Be warned: this will get ugly fast and future maintainers will wonder what you were smoking.
3) Get them to update their library.
On a side note, I don't know the circumstances here, but in general they should be providing you with sources. It's a very backwards practice to provide only a static (static!) library and no way to know what it's doing inside. You'll have to sign a software license agreement and whatnot to protect their interests.
The best and most proper way of handling this would be to contact the the creator of the static library and get them to resolve the situation. They could resolve it either by updating the embedded version of AFNetworking, removing their dependence on AFNetworking, or adding a prefix for their embedded copy of AFNetworking. The last one is probably a good idea anyway when a third party library embeds a different library, because otherwise it would be impossible to use two libraries simultaneously that both include the same third party library.
You could also refactor the copy of AFNetworking that you include yourself to change the names of classes to have a prefix, although this should be unnecessary, as the static library vendor should have done this themselves already.
Lastly, you could find a different library that accomplishes the same thing as your current one but that doesn't embed AFNetworking.
I want to add add 3rd part library to my library (which will be used by other developers), so if I have for example this class SBJson do I prefix it with my two letter prefix to be EXSBJson also I saw somewhere somebody is using underscore EX_SBJson. What is the naming convention/style in this case?.
There is no general convention, but we have used the following approaches:
Use the same prefix as the library (so if we develop XYFunctionality, we would name it XYSBJson). A lot of source projects use this approach (e.g. Dropbox)
Talk to other devs, if possible. In most cases, it is enough to distribute the library separately from 3rd party libs (so we ship a .a binary file and a working source project of the 3rd party library so other devs can use it). This also allows other devs to upgrade the 3rd party library to get bugfixes as long as there aren't breaking API changes.
Btw. much of what SBJson does can also be done using NSJsonSerialization which comes with iOS 5+