I'm going to make a client server gui chat. I wanted to know what the difference between Module, Libraries and Artifacts are. They're new terms, and it be nice to have a condensed explanation of it.
In short:
Module - an application can have multiple composing parts. Imagine a car composed of engine, seats, tires, etc. Each such part is a module. Take a look at this maven multi-module app intro for an example
Libraries - the list of things (other jars, dlls, etc) your application depends on to be built. Other pieces of software you use in your application to avoid reinventing the wheel and make your life easier by reusing what's already been done by other people (or perhaps you). Imagine your car dealer's factory depends on an external partner which will deliver the multimedia system, which in this case can be consider a library
Artifacts - the output of your build process, whatever will be released to the customer, a jar, war, RPM package, you name it. In our example, the final product or artifact is the car itself. At the same time, all of the composing modules will have an artifact of their own: engine, tires, etc
Related
I'm new to objective-c & osx architecture. I started playing with building a framework and then using it. I followed this great tutorial.
During the tutorial, I had to set the framework's target's Dynamic Library Install Name to #rpath/MyFramework.framework/Versions/A/MyFramework. My understanding is that #rpath will expand to the loader's (consumer's) run-path search paths.
It seems as if the responsibility of loading the framework is split between the framework author and the consumer author. Could someone please explain why the author of the framework needs to be concerned with the consumer's run-path search path? For example, if the framework-author set the Dynamic Library Install Name to point to some random directory (instead of #rpath) how would the client be able to consume the framework?
Thanks in advance.
It depends a lot on how the framework is being used. And it's important to remember that the framework construct has existed for a long time on the platform.
For a system framework, such as the ones that Apple creates, you're going to be quite happy that they keep the frameworks in a known location. In those cases, the paths that they use are fixed for the OS, and it guarantees that you don't accidentally load the wrong one. Further, as indicated in the Framework documentation, these frameworks are loaded only once on the machine, regardless of how many times they are used (see Apple:What Are Frameworks) . The benefit here is performance and it is for both the code and the resources in many cases.
Due to the recent move to randomize framework locations,and Apple's comments in the release notes that "Mountain Lion randomly relocates the kernel, kexts, and system frameworks at system boot," it certainly appears they're still sharing these resources, and thus still gaining from this benefit.
For embedded frameworks, the situation is a lot more tedious, and Apple has moved through a variety of methods over the years to make it easier to find frameworks wherever they may be. Due, again, to the shared nature, it would make sense for Applications which share common library requirements to share them on the machine, both for purposes of efficiency, and to make sure they're at the same version if they're sharing data. So, for example, if you have two separate apps that use the same framework to work with shared data, you might put the shared framework in /Library/Frameworks and have both apps explicitly look for that, making sure that some other (possibly older) version of the framework, that has been loaded by another App, is not used instead.
In the end, there's a lot of flexibility for the Framework producer and consumer the way that it currently works. It means that the developer can decide to share a framework, include a private copy of the framework, or even do both, depending upon whether the framework exists on the machine or not. However, the price for that flexibility is the complexity that we have today.
Another example of a reason you might not want to use #rpath specifically is for tightly-linked embedded frameworks (yes, people embed frameworks within other frameworks). In these cases, you don't know where the first framework is loaded, but you want to put the embedded framework inside of it, so that they stay together. In this case #loader_path is relative to the code that is loading it, so that your plug-in's framework can find its resources correctly.
In answer to your specific example about somebody setting the Dynamic Library Install Name
to a "random" location. In this case, you'd have to know that location. There might be many reasons for somebody doing this, such as wanting to discourage reuse by other programs, or because there are large resources within the framework that should only be installed in a known shared location.
I'm fairly new to programming and wanted to start programming more efficiently. Try as I may I often find myself straying from the MVC model.
I was wondering are there any tips or methods in keeping your code organized when coding in xcode objc? To be more specific (I know you guys like that :) I want to
Be able to write libraries or self-containing code that can bring from one project to another
Share my code with others as open sourced projects
Prevent myself from writing messy code that does not follow proper structure
Use a high warning level. Build cleanly.
Remove all static analyzer issues.
Write some unit tests.
Keep the public interfaces small.
Specify your library's dependencies (e.g. minimum SDK versions and dependent libraries).
Compile against multiple/supported OS versions regularly.
Learn to create and manage static library targets. This is all you should need to support and reuse the library in another project (unless you drag external resources into the picture, which becomes a pain).
No global state (e.g. singletons, global variables).
Be precise about support in multithreaded contexts (more commonly, that concurrency shall be the client's responsibility).
Document your public interface (maybe your private one too…).
Define a precise and uniform error model.
You can never have enough error detection.
Set very high standards -- Build them for reuse as reference implementations.
Determine the granularity of the libraries early on. These should be very small and focused.
Consider using C or C++ implementations for your backend/core libraries (that stuff can be stripped).
Do establish and specify any prefixes for your library's objc classes and categories. Use good prefixes too.
Minimize visible dependencies (e.g. don't #import tons of frameworks which could be hidden).
Be sure it compiles without the client needing to add additional #imports.
Don't rely on clients putting things in specific places, or that resources will have specific names.
Be very conservative about memory consumption and execution costs.
No leaks.
No zombies.
No slow blocking operations on the main thread.
Don't publish something until it's been well tested, and has been stable for some time. Bugs break clients' code, then they are less likely to reuse your library if it keeps breaking their program.
Study, use, and learn from good libraries.
Ask somebody (ideally, who's more experienced than you) to review your code.
Do use/exercise the libraries wherever appropriate in your projects.
Fix bugs before adding features.
Don't let that scare you -- it can be really fun, and you can learn a lot in the process.
There are a number of ways you can reuse code:
Store the code in a common directory and include that directory in your projects. Simple, but can have versioning issues.
Create a separate project which builds a static iOS library and then create a framework. More complex to setup because it involves scripting to build the framework directory structure. But easy to use in other projects and can handle versioning and device/simulator combined libs.
Create a separate project which builds a static iOS library and then include this as a subproject in other projects. Avoids having to build frameworks and the results can be more optimised.
That's the basic 3, there are of course a number of variations on these and how you go about them. A lot of what you decide to do is going to come down to who you are going to do this for. For example I like sub projects for my own code, but for code I want to make available for others, I think frameworks are better. even if they are more work to create. Plus I can then wrap them up with docsets of the api documentation and upload the whole lot as a DMG to github for others to download.
I have two projects which share quite a portion of logic, localizations, properties and even views (Logindialog, Popovers etc.). I now want to put the intersecting set into a new project, which should be used as some sort of common library.
I want to keep the common project as a git submodule in my other projects:
Project A
- Classes
- Resources
- CommonLibrary (git submodule)
Project B
- Classes
- Resources
- SomeBSpecificFolder
- CommonLibrary (git submodule)
The CommonLibrary would now probably also be it's own Xcode project. I am not sure now how I should tackle this problem. I know of the following options:
Use a library (.a-file and .h file)
TestFlight e.g. does it like this. I quite like the fact that I can just compile against a binary and don't "see" the source. So just a clean API for doing things.
Include the whole project (Project dependency)
Three20 does it like this and I find it quite annoying to have some 6 subprojects in my project. However in my case it would only be one project, so this might be an option too.
Just have loose source files without a project inside the CommonLibrary folder and manually add them to both of the projects. The project would then compile the sources along with any project-specific sources. This looks a big like a workaround to me and I guess I would prefer to somehow bundle the common sources. Also if there are new files, I always have to add them to the other projects.
Can you guys give me some advice and tell me if there is another option or what you think are the advantages and disadvantages about these approaches?
Thanks a lot for your help!
From a clean, non-application specific perspective, you should be looking to create a library/ framework. This provides:
the reusability you want
without extending build time of dependent projects,
while maintaining consistency of the code base (maintainability),
keeping your API consistent across using projects and
managing dependencies between layers
In terms of Xcode, if I remember correctly from my OpenStep days, you should be looking to create a new Framework project which will provide the relevant makefiles for that type of project. A cursory surf produced:
http://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPFrameworks/Tasks/CreatingFrameworks.html
and the slightly more friendly:
http://atastypixel.com/blog/creating-applications-in-xcode-using-frameworks/
Furthermore, you might actually want to layer your frameworks to further improve reusability. That is, don't just create one framework, create one per tier: put common code in a Foundation framework, UI/ AppKit-based classes in a UI framework, etc. This way, your frameworks are relevant to whatever tier your using classes and projects live.
For instance, if you have a category on some foundation class, put it in a common/ foundation framework that can be reused by any other common/ foundation classes and projects you build. If you were to put it in a UI-tier framework with UI libraries and dependencies then it couldn't be reused by your foundation level projects (as these can't have UI-level dependencies).
Hope this helps...
I found a project called RestKit on github which seems to be a good example for a third-party framework, which can be included in an existing project.
The readme and the wiki describe nicely which steps need to be done in order to include the project. I guess this is a good starting point for someone who want to create a framework himself.
is there a code revision control software to handle cross platform projects?
I am talking about handling two platform-specific source code (for instance, one in Java and one in C) of the same conceptual software to do things like keeping track of the changes to the same conceptual part in both code base etc.
Any version control software (aka revision control software) can handle source code from different languages, for different platforms. (But the question isn't very clear, so I'm not entirely sure what's being asked.)
If you have a single project with some bits coded in C and others in Java, that's not a problem -- and it has nothing to do w/ the revision control software being used. Just organize your directories so that you build your C code w/ "make" (or cmake or whatever), and your Java app with maven (or ant or whatever), and (optionally) create a third project that packages/bundles your jars with your native libraries for distribution. Then use git (or svn or hg or whatever) to track changes to the project. Nothing special here; many projects do exactly this.
Simply put, if you're using maven, should you treat the maven layout as the gold standard, or should you convert your layout to fit your tooling (WASD, myEclipse, RAD, etc.)?
Realizing that maven is configurable and you can override the defaults in the Super POM, I'm attempting to determine if I should change the layout to support specific tools that are in house, or attempt to make those tools recognize the maven layout. One thing to consider is the eventual integration of continuous build tools, as well as the different IDEs in play. MyEclipse is currently being used, but word is that they are not going to renew licenses in 6 months.
The first question I asked regarding this sort of thing was a bit too specific and one-sided.
Maven is following the "Convention over Configuration" principle, which means that if you are following their conventions, then you do not need to redefine basic information, such as your project structure.
As far as I am concerned, I prefer to have the shortest pom.xml I can write, and I don't like to define the information like where to find the sources, the resources, and so on.
In addition to that, having the same structure for several projects is a evident benefit, especially if you have many applications to manage. It also helps new developers to understand the application if it follows some conventions...
Like all "best practices," take it for what it's worth. As you point out, IDEs may have a particular project structure that they like - since most of your development is actually done in the IDE, that's how developers will actually think about problems.
If you standardize your shop around a standard project structure, you can always define that common structure in a company wide parent POM file.
The default project structure works, so don't waste time debating and deciding on a different project structure and then configuring maven to use it.