I'm aware of Cocoapods. However this isn't very useful for commercial use because we don't want to deliver source code.
We want to be able to deliver compiled libraries. But use them in our own (and client) projects, just like with Cocoapods. And just like maven does with jar files and the suchlike.
Is there anything which provides this (or similar) functionality. It seems very shortsighted of Apple not to include anything like this, or the ability to support anything like this, within XCode.
Thanks
Related
i am new to Unity and i am try to understand plugins. I have got the difference between a managed plugin and a native plugin, but what is not very clear to me is:
what is the difference between a plugin and a dll? what should i expect to find in an sdk to make it usable in my unity project?
Thanks a lot
To expand on #Everts comment instead of just copying it into an answer, I'll go a little into details here
What is a plugin?
It's a somewhat vague word for a third-party library that is somehow integrated with the rest of your game. It means that it neither is officialy supported by Unity, nor is it a part of your core code. It can be "plugged" in or out without altering its internals, so it must provide some kind of API that can be used by the game code.
For example, you'll find many plugins that handle external services like ads, notifications, analytics etc. You'll also find a couple of developer-tools that can also be called plugins, like tile-based map editors and such.
Plugins come in many forms - DLL files are one example but some plugins actually provide full source code for easier use. And of course, other plugins will provide native code for different platforms, like Objective-C for iOS or .jars for Android.
So to answer your first question:
DLL is simply a pre-compiled source file that can be a part of a plugin
A plugin is a whole library that can consist of multiple files with different formats (.cs, .dll, .jar, .m etc)
What do you need to use an sdk?
First of all - documentation. Like I said before, and like you noticed yourself, not all plugins give you access to the source code. And unfortunately, not many sdks have extensive and developer-friendly documentations so it can be a tough task to actually understand how to use a given sdk.
Secondly - the code. Many sdks give you some kind of "drag & drop" library, a single folder with all the neccessary files inside that you simply add to your Unity projects. I've also seen sdks that use Unity packages that you have to import via Assets > Import Package > Custom Package.
Once you have the code and documentation it's time to integrate it with your game. I strongly recommend using an abstract lyer in your game as, in my experience, you often have to change sdks for various reasons and you don't want to rewrite your game logic every time. So I suggest encapsulating sdk-related code in a single class so that you have to change only one class in your code when switching from, say, one ad provider to another (and keep the old class in case you need to switch back).
So you basically need three things:
Documentation (either a readme file or an online documentation)
The code (precompiled or source)
A versatile integration
How third-party libraries in Lua usually handled?
For example, I want to use the HUMP library for my LÖVE application.
What should I do then? Is there any popular package manager? Or should I just place libraries under "vendor" / "libs" directory in the project's root folder?
Lua uses a package manager called LuaRocks.
However, HUMP, and most other third party libraries for LOVE do not have a rock (package) for LuaRocks, and thus cannot be installed/handled that way. There is no definitive convention for including 3rd-party libraries in a LOVE project. It's usually up to the project developer. However, there is a Thread on the forum where people talk about how they organize their projects that should be of use to you.
We need to use some 3rd-party libraries in our iOS app project (which is an Xcode project). The 3rd-party libraries are either managed by Cocoapods or directly added in the project by importing source code files.
Sometimes we need to modify a library's source code in order to actually use it appropriately in our project. It's easy to make the modification since we have all the source code at our hand, but how can we maintain the modification when some time in the future we upgrade the version of the 3rd-party library? Is there any tools or best practice out there that can help with this? And after the upgrade of the 3rd-party library, it will be good if we could differentiate in the code history about which part is done by library upgrade and which part is done by our modification.
That depends entirely on what your change is...
The best option is to not change the external code. Instead, subclass the part you need to change and use only public API so you should find out early when updating if the subclass needs to change. Unit tests also help.
If you can't subclass then you should fork the external code, then you have to manually merge updates on top of your change when you want them. This is obviously significantly more effort both in terms of importing and managing the code.
I want to open libraries, because currently I want to see the algorithms used for drawing, modify them and implement them in my program. For example: I have tried to create an algorithm on my own for lines. But I failed. And even if I had succeeded, I fear that it might not give the same result as the algorithm in the libraries. And I don't want this to happen. That's why I want to copy the algorithms used for the methods in libraries. And I really hope that this will help me create the application I'm currently working on and with other applications in the future.
I tried to open the libraries with a code editor. But I had troubles finding the libraries- I don't really know where are they placed nor in what files are their codes stored.
How to open a Java library? Or is there a place in the Internet where the code is uploaded?
It sounds like what you want is to get inside the standard Java libraries (so you can see the code for methods like Graphics.drawLine()).
You can download the source files from the same place you got the JDK, if you are on Windows or Linux. For the Mac, see this question. You can even set up Eclipse so that you can debug into that source as if it were your own code.
However, you will probably not find line-drawing code in Java in these libraries - the Graphics implementation will almost certainly use native methods, and may just call existing methods in the OS.
If you are specifically looking for line drawing algorithms, another option would be to look at the Wikipedia page for the Bresenham (aliased) or Wu (antialiased) algorithm.
Edit:
The part of a Graphics2D call that actually puts pixels on the screen is probably inside a system call and therefore the source would not be available.
A java vector graphics library like Batik might have source for some of these algorithms, but probably relies on the Graphics2D calls for most of them. So, you might look for a comprehensive vector graphics library written in a language other than Java, where those graphics calls do not already exist by default.
Alternately, checking the table of contents for a computer graphics book might point you at a variety of algorithms that you could look up on Wikipedia.
For any given library:
Make sure to obey all licenses when using another's code
If you are referring to the Java SDK source code, you can find it here: http://grepcode.com/
If the project is open source, you can usually just get the source from the project website. No problem, though make sure to obey their license.
If the project is NOT open source, well, then you're in a pickle licensing wise, so I do NOT endorse this, however, you would need to use a Java Decompiler such as JD-Gui
As far as what drawing algorithms to use, there are so many different ones (obviously, people have been trying to draw quickly for many many years), your best bet is to figure out exactly what you need to do and then search for that specific need separately. There isn't really a good repository of ALL of them, except maybe wikipedia.
If you are using the libraries they are on your classpath. Check out how to figure out your classpath in whichever IDE you are using and you can find the JARs you depend on. If they are packaged with sources all you need to do it unjar them and look at the sources.
If you don't have access to the sources you can get the code using a Java Decompiler.
If you are trying to look at a standard Java library, see the other answers about getting the source to the JDK.
If you are interested in an open source library (such as something maintained by the Apache project), look on the site of the project for a 'source jar' which you can open with a standard zip utility.
If the library you want is not open source or you cannot find the source for it, you can try to decompile it. If you are using Eclipse, try this decompiler.
Let's say we have a team that works on many different projects. Each team member uses different set of visual/non-visual controls/components during it's development cycle. Since Delphi requires each component to be compiled and installed globally in the IDE, how to manage this situation while working with project which was started by the other team member?
It would be great if I could checkout the sources of a project from the version control and have the ability to compile it immediately. I don't care or sometimes don't know what visual or non-visual components are required for this project, I guess they all should be included in the project sources.
Maybe there are some tools which could read main project file or directory and compile/install all the needed components on project loading (and uninstall them when project is closed)?
How do you handle this issue in Delphi?
In our company, we have the same problem.
We solve this by forcing everyone to have all necessary library paths added to their delphi ide.
We are using an additional sdk/framwork repository which containins all components/sdks/frameworks of everyone .
We keep a single text file, listing all libs with its version, install infos, etc.
Everyone checks their wanted libraries, so we do not have double libraries or different versions.
Since we all work under Windows and since Delphi keeps its paths and (afaik) installed-components informations in the registry, we extracted these informations.
We store for each used delphi version a .reg file within the sdk repository trunk.
So, if someone changes a framework, he updates the informations for everyone in the .reg files and commits it.
now, if someone wants to setup their dev-machine, they check-out the sdk, adds the e.g. xe2.reg informations to their registry, then check out the project and ... tada. compiling.
We have not tried to extract the "installed components" packages. thats on our to-do list.
An alternative would be to keep a batch file for building and installing all sdk packages at once. But i do not know if installing components via commandline is possible in delphi.
Something like the JEDI installer would be nice. The installer detects installed Delphi versions and builds & installs everything nicely.
A freely configurable version would be nice, so add all sdks -> install on each version.. perfect.
Anyone who wants to compile a given project must first install any components that project is using. There is no getting around that, unless the project directly includes the components source code and instantiates the components in code instead of using a DFM. AFAIK, there is no IDE tool that will automated component (un)installation on a per-project basis for you.
It's very wise to constraint which components and libraries that will be used by your team. If each member decide which component they will use, your final executable or packages will grow a lot and you can have some incompatibilities between libraries.
Besides, you can have extra costs buying and updating libraries that are very similar. Remember that each time Delphi is updated, you should buy new licences from most of that libraries.
So the best approach is:
ask which libraries each developer are using and discuss with them the real need of each one;
catalog those library required and install them on the machine that you will compile your final code;