Is there a way to add some uncompiled source code (in an NSString for example) and conditionally modify it and execute it at runtime?
Why not provide two frameworks or static libraries, one pre-compiled for use with CoreDate, and one for without?
Have you considered using the runtime methods to determine whether CoreData methods are available rather than using preprocessor macros?
Related
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/
I did quite a bit of googling for a definitive answer, but I could not find one.
We have cross-platform sources that need to be used by our iOS apps. I have already packaged them as static framework and got a test app to link successfully against and make a call into it.
The problem I am having is that it makes heavy use of global static constructors.
I am seeing erratic behavior with only a subset of objects getting instantiated but not all.
My questions:
Do static constructors even work within the context of an iOS static
lib?
How would one debug such a problem?
Thanks!
constructors in a static library get called erratically
The use of -all_load and -force_load does not make any difference in invocation of constructor attribute labeled functions
What you need to do is this:
make sure the constructors are global symbols. do this by exporting them via a symbols' file.
consider creating an init function and use the linker setting "initialization routine" to control the order of the instantiation of your global objects..
Do static constructors work within the context of an iOS static lib?
They only start to work once they're linked into an executable, but once that is accomplished they will work.
How do you debug such a problem
There are a few approaches
You have to presume no specific order of the invocation of the constructors.
Make sure the constructors are being linked into the executable (use nm to determine this)
You can try an -Wl,-all_load to get it to load all the components of all archives into the executable (or -Wl,-force_load,libstatic.a to just load for a specific static archive).
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.
Can you use macros defined in static libraries?
I have my own debug macro called TWDEBUG that I use in a static library I create for sharing.
If I import the static library to my new project and use it, the compiler does not seem to recognize it. I did set up preprocessor macros to TWDEBUG and Other C flags and Other C++ flags to -TWDEBUG, but when I ran the code the ifdef macro doesn't get executed.
Macros are evaluated at compile-time. So their values are frozen when you build the static library. For debugging statement, this usually means that they are omitted and not part of the built library.
If you later add the static library to a project, you can change the value of the macros. But it won't have any effect on the static library since it is not compiled anymore. The debugging statements are missing.
Update:
So to implement a debug option, I see two options:
Instead of macros and ifdefs, you use a global variable and proper ifs to turn debugging on and off. Other developers can use an API (global function) to set the debugging level so you can hide the global variable.
Create two static library from the same source code, one with debugging enabled for development purposes and the other with debugging disabled for production use. This option is probably only viable if XCode can automatically switch between the two libraries. And at the moment, I don't know how you would configure that.
I have written a few razor helpers and these helpers use functions that include the extension methods generated by T4MVC.
I now want to move these to a control library so that they can be used across multiple mvc applications.
The initial idea that I have used is that I can put a copy of the template into the control library, and this works, the downside is that the template used in the application then regenerates the same extension methods in the same namespace.
Because I am using some of the extension that require the interface for the ActionResult I do need that the namespace remains the same.
What I am wondering is, is there a known way to use the extensions in a control library as well as an application that references the library, or is a change to the template required such that the static extension methods can be either generated or not via a flag in the settings file?
I am also wondering if the static extensions could be included in a separate cs file that lives along side the template. So that we have 2 classes T4Extensions and DynamicT4Extensions?
This might force the use of the interface IT4MVCActionResult though,
This is similar but not quite the same as http://forums.asp.net/p/1510753/3603100.aspx.
I wonder if the solution might be to add a new switch in the settings file that would turn off the generation of those static methods. So if you know you're already getting them from some referenced assembly, you'd turn them off in the app.
Though that might still blow up if you have multiple unrelated libraries that each need to use the methods, as the app would then get an ambiguous reference.
Note that we can't make the methods internal, since some of them need to be called from views, which live in different assemblies.
And ideally, I'd prefer to avoid having those in yet a separate file, as some users may start complaining that T4MVC brings in too many files.
Sorry, not really a clear answer, but more thinking through possibilities. :)