I want to be able to add plugins for an application I am developing and as it is a development tool I want other people to be able to write their own plugins.
So my questions are what are the real differences between a framework and a loadable bundle? Which are more suited to being a plugin(accessing of headers, ect) ? And if I use loadable bundles how do I load them at runtime and access their functionality during development?
The plugins should not have to rely on other plugins.
Have you taken a look at NSBundle? It has all the methods you'll need to load the executable code at runtime. You'll want to define some sort of plugin interface to which any plugin will conform.
As for the difference between bundles and frameworks... Both bundles and frameworks are file structures that contain various resources that your app can use. A framework is like a library -- it's something your program links against when you build it. A bundle, on the other hand, is essentially a folder structure containing compiled code that you load at runtime.
Elaborating on the accepted answer, a bundle is more designed to be loaded and then potentially unloaded at a later time during program execution. Frameworks, once loaded are designed to stick around for the life of the process.
Frameworks are also designed to be self contained units of code where a caller calls into the APIs the frameworks exports. Bundles can be used when you want to have code call into the caller's public APIs. Check out ld64's man page. You can get hints for the intended usage of bundles with such options like -bundle_loader
Related
I am new to browser development, so I have no prior experience with AMD, CommonJS, UMD, Browserify, RequireJS, etc. I have been reading a lot about them and I believe I generally understand the JavaScript story but I am still very confused as to how to make everything work together.
I have a library written in TypeScript. It is a pure TypeScript library, it doesn't interact with a browser or any browser framework nor any node or NPM things.
I also have a TypeScript client application that leverages this library. The client application may leverages a web framework as well (e.g., jQuery).
Now when I compile my two TypeScript files (which we will assume are in separate projects, isolated from each other and built separately), each will generate a .js file. In Visual Studio I have to choose AMD or Common as my module loader.
This is where things fall apart. My research tells me that if I want to work on the web I either need to use Browserify or RequireJS. Browserify appears to require I first install Node on my machine and then use a command line tool as a post-build step to generate a file and as far as I can tell this isn't available as a NuGet package. Alternatively, I can use RequireJS but then all of the examples stop working. Something about not doing things on window load and instead doing them somewhere else, but nothing that I have found really explains that well.
So, what is the story here? I want to use TypeScript but at the moment it really feels like it is just a language, there aren't any compelling usage stories available to me as a developer as I have grown accustomed to in the Microsoft ecosystem.
TypeScript does support AMD and CommonJS just as JavaScript. But in addition it also supports internal modules. When using internal modules in conjunction with a decent build system like gulp-typescript you'll find that internal modules can cover lot of use cases where one would choose AMD/CommonJS in traditional JavaScript projects.
TypeScript gives you the freedom to decide yourself. If you need asynchronous module loading you are free to use AMD via external modules. You can also use CommonJS and/or use browserify to link together your code into a single file.
I've found that when you are a library developer - that is you ship your TypeScript compiled JS code to other developers - internal modules are a good compromise. You don't force your target audience (developers) to use any special module system like AMD/CommonJS, but instead ship isomorphic JS that runs in the browser as well as in node. Yet you still have a way of modularizing your code internally, just as AMD/CommonJS would allow you.
TL;DR: When you use TypeScript you get internal modules for free, and they provide you with a flexibility that would else only be achieved by AMD/CommonJS. Yet external modules still have their advantages. In the end, you should decide what is the best fit for your project.
TypeScript is a superset of JavaScript so its story is the story of JS, not of .NET or any other Microsoft product.
If you compile your TypeScript modules to AMD, then you load them through an AMD module loader like RequireJS (or Dojo, or curl) in your entrypoint HTML file, which can be as simple as this (using RequireJS):
<!DOCTYPE html>
<title>Application name</title>
<script src="scripts/require.js" data-main="scripts/client"></script>
(Assuming that your built TypeScript module is scripts/client.js.)
The Start page for RequireJS or the Dojo Introduction to AMD modules are both resources that can tell you more about how to load AMD-formatted modules in a browser.
You got a really good technical answer from C Snover, but the answer you're actually looking for is "don't use external modules". By external modules, I mean "AMD" or "CommonJS" modules.
If you actually need what external modules offer, they can be very useful, but they come at a significant cost in terms of build/deployment complexity and concepts that you need to understand.
Just because external modules are way more complicated doesn't mean they're better; the TypeScript compiler itself is written using internal modules.
You can convert an external module back to an internal module by omitting any export statements on the module itself (and by not having an export = statement at the end of the file either). For example, this is an internal module:
module MyLibrary {
export class MyClass {
public Foo = 1;
}
}
If you are using internal modules, all you have to do is reference them in the right order via script tags in your HTML files and they will work without having to deal with any sort of loader system.
<script src="MyLibrary.js"></script>
<script src="MyUICode.js"></script>
I have the following requirement.
I need to implement dll kind of thing on mac.I need to create a backend library which can be loaded dynamically.This backend library will contain the cocoa classes and c++ classes.
What is advantage/disadvantage of cocoa framework,I was googling so far,I was not able to figure out the best one.Please give me some suggestion.Is cocoa framework also loaded dynamically?
The main difference between a dynamic library and a framework is that a framework can contain resources (images, sound files, nibs, etcetera) and header files. When you use a dynamic library, these are separate.
Both a framework and a dynamic library are loaded at runtime. If your library will only be used on Mac OS X, I recommend creating a framework because it is easier to manage since everything is in one folder.
Bundles (the white LEGO bricks) are almost exclusively used as plug-ins. If you want to create a plug-in interface you should accept bundles and you should provide a framework the bundles can link against. Bundles are also loaded at runtime.
Here's a decent tutorial (PDF form) that goes a little more in depth explaining the differences between ordinary libraries and frameworks.
What is the difference between a LIB and DLL? I have read plenty of posts on here about it and there are some good, clear answers however I am writing to ask for clarity on one matter.
Is it better to use a LIB (static link library) when there is only one user e.g. for a administration application client installed locally on the PC? and is it better to use a DLL (Dynamic link library) when there are multiple concurrent users accessing a classic asp application that uses vb6 classes?
A LIB file generally corresponds to a static library, which means that all of the library code that your application uses is compiled directly into your application.
A DLL file represents a dynamic library that your application links to, and then when you want to use code from the library, you call into it dynamically while your application is running.
Of course, you'll frequently see a LIB file for a dynamically-linked library as well. That file contains "stubs" that the linker uses to implicitly link to the DLL.
The obvious benefit of a DLL (dynamic linking) is that one DLL with common functionality can be shared with multiple applications that use that same functionality. Bug fixes can be made in a single place, and only one component has to be updated in order for all of the apps to take advantage of those fixes.
If you only have a single application that uses your code, there's little reason to put it into a DLL. Multiple users on multiple computers are going to have to have their own copy of the DLL anyway, so there will be no code sharing going on in that situation.
All of that said, I have no idea what this question has to do with VB 6. To my knowledge, you can only use it to create ActiveX DLLs (which have a different use case) and it can't create static libraries at all.
I am realtivly new to the concept of dynamic loading and shared libraries. While I fully understand how dlopen() could be used to reference symbols in a shared library I have yet to fullt grasp what MacOS does behind the scenes when I don't statically link against something. When adding a framework to Xcode I have the option to load it into my project or I can just provide some form of symlink to it(the actual implementation is obfuscated be the easy to use interface).
There after all I seem to need to do is import the header files that porvide and API to these frameworks and I can just invoke their symbols free of hassle. Can someone explain to me what I am actually doing, because it make no sense to me.
The sheet you're referring to has nothing to do with the actual linking of the framework. The copy vs. link choice refers to how you want to include the framework in your Xcode project, not your app binary.
For system frameworks there really isn't anything you need to do but import the headers.
For custom frameworks (your own or third-party) the framework must reside at the load path directory when your app launches. Typically the load path will point to your app bundle's Frameworks (sub)directory, so you must add a Copy Files build phase that copies the framework to your app bundle's Frameworks directory.
Remember to check out Apple's Framework Programming Guide, especially the section on frameworks embedded in your app bundle.
I understand for non-iOS targets, using shared libraries can lead to lower memory usage, and also that some companies distribute a library and headers (like Superpin) and a static library allows them to not distribute the source of their product. But outside of those, what are the reasons you'd want to use a static library? I use git for all of my projects, and I usually add external libraries (open source ones) as a submodule. This means they take up disk space locally, but they do not clutter up the repo. Also since iOS doesn't support shared libraries, the benefits of building libraries to promote code reuse seems diminished.
Basically, is there any reason outside of selling closed source libraries that it makes sense to build/use static libraries for iOS?
organization, reuse, and easy integration into other programs.
if you have a library which is used by multiple apps or targets multiple platforms, then you will have to maintain the build for each app. with a library, you let the library maintainer set up the build correctly, then you just link to the result (if it's developed internally, then you'll want to add it as a dependency too).
it's like DRY, but for projects.
libraries become more useful as projects become more complex. you should try to identify what programs (functions, class hierarchies, etc) are reusable outside of your app's context, and put it in a library for easy reuse - like pattern recognition.
once your codebase has hundreds or thousands of files, you will want to minimize what you use, and you will not want to maintain the dependencies manually for each project.
Also since iOS doesn't support shared
libraries, the benefits of building
libraries to promote code reuse seems
diminished.
There's no reason you can't build your own static library to use across multiple projects.
Other than for that purpose and the ones you mentioned I don't think there's much else.
Static libraries allow you to have truly standalone executables. Since all library code is actually, physically present in the executable, you don't have to worry about the exec failing to run because there's a too-old version of some library, or a too-new one, or it's completely missing, etc. And you don't have to worry about your app suddenly breaking because some library got replaced. It cuts down on dependencies and lets your app be more encapsulated.