I'm getting to the point in my Dart project where I need to start putting things in separate files/packages. My project has 2 generic areas of concern, so it seems like there needs to be 2 libraries, call them libA and libB, and then some generic code that draws on both of them. Ideally, I need something between one file and full-on separate projects.
I don't think I'm ever gonna want to export them as separate Pubs, but maybe... Does that mean they should be libraries and not packages? Is there even a difference between libraries and packages in Dart? Do I need 3 different full projects? I hope not.
I guess I'm looking for a way to have several local packages in the same project.
What's the SIMPLEST way to structure everything?
If your code will only be relevant to one project, use one package and multiple libraries. For instance, consider a tower defense game: there will be one package for the whole game, but multiple libraries each dealing with their own areas of concern (enemy lib, tower lib, etc.).
If your code will be relevant to multiple projects but only for your projects (and not the general public), split the code into multiple packages, use local or github pub dependencies, and do not publish them on Pub:
dependencies:
transmogrify:
path: /Users/me/transmogrify
See Pub Dependencies for more info.
Continuing the above tower defense example, this would be useful for something like a game studio splash/intro screen. You would want to reuse this across multiple games, but it is not useful for anyone but you.
Finally, if the code can be used for multiple projects, and is of interest to other developers, publish it as a Pub package. For instance, a game engine would be useful to other game developers.
Related
I like the way F# requires to organize files and code in order of dependency because it discourages mindless coupling.
I have flat list of source files atm (simplified):
Common.fs
Workflow1.fs
Workflow2.fs
And want to go one step beyond. First, organize files like this (VS 2017 can't move folders up and down, one needs to edit .fsproj but it is different story - at least it is possible):
Common.fs
Workflow1\Impl1.fs
Workflow2\Impl2.fs
I expected Impl1.fs and Impl2.fs to be fully isolated from each other because their folders are not in parent/child relationship, but Impl2.fs can easily see types and functions from Impl1.fs: just open module and they are available
Are there any techniques to keep them isolated? It's possible to split the project in three however I prefer to keep DLL as a unit of deployment: workflows are small and ideally I want to avoid to have many tiny DLL files.
It sounds like you have a good understanding of what your options are. You are not missing anything else. Consequently, the answer to your question is, "no."
You can't isolate the folders that way, as far as I know. However, if you want to keep them isolated at compile time but deployable as a single unit, you can create separate projects and use Fody or ILMerge to combine the assemblies post-compilation.
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
So I really cant understand how this work but late me explain. First, just in case you need it, I am running Ubuntu 12.04 64-bit on a laptop.
As a building tool am using CMake. I want to load in to my project OpenCV, MRPT (http://www.mrpt.org/) and libfreenect. All of them have a "source code". What I don't understand is when they say "build from source". How to I make a project with all of them?
Do I need to build each one individually and with some way but then in my project OR do I down load the source code and build them all together at ones? As you can see I'm really confused what I have to do... do I run the CMakeList.txt from each source code and the run one CMakeList.txt that has all the other CMakeList.txt?
In fewer world, if I want to build from source, two or more libraries, how do I do that?
I would like a general answer (how this "build from source" works) and an answer specifically on the the ones I mentioned (CMake, OpenCV, MRPT, libfreenect). I hope I made clear what I don't really understand.
It depends of the 'master' project. In general in the c/c++ universe your project must know how to invoke the build process of each subproject/library OR your project needs to know how to include&link the results after building each external project yourself.
You can also mix the two approaches if needed but I think it cleaner to try to use one if possible.
In the first case if all the subprojects offer cmake building files (CMakeLists.txt) you may try to add_subdirectory() each and see if there are any conflicts. For example google test can be easily included this way and it gives your project some global variables that easy linking later.
Alternatively or if the above approach gives problems or the sub project doesn't provide CMakeLists.txt you can use ExternalProject_add(). It takes more work and you have to handle includes/linking configurations with your project manually but it makes the subproject more independent. For example if there are conflicting targets with your project or the subproject doesn't provide CMakeLists.txt.
The last approach involves building and installing the sub projects separately, using configuration variables in your project to point the includes/libraries paths of the sub project. Check CMake:How To Find Libraries for details.
I have an app which I will call it the "base app". The app works with many brands.
I need now to separate those brands, and to make a distinct app for every brand.
Every app will have a slightly different design (including different images) and here and there maybe some specific-to-a-brand code.
All of the apps should also use the same base code from the "base app" that deals with logic.
I have some options I have thought, but I am not sure if any of them suit my needs. Will be happy for clarifying the difference among the options.
The options I have thought are:
1) Creating an app for each one of the brands and just copy-paste the class files from the "base app" as a reference, except the .xib files, which will be copied as a copy. The problem is that then I do not know how and where to write a brand specific code (because it will be shared among others).
2) Creating a workspace that will include the projects for each one of the brand. Not sure how this works and if this is correct, will be glad for help clarifying here.
3) Nest a "base app" project inside every brand's project. Any help clarifying what does it do will be appreciated.
3) Using the base app as a static library which will be linked in every brand's project. Not sure what will happen with the UI (shared, not shared). Will be glad for help clarifying here too.
4) Using a simple way of maintaining each one of the brand's project, including the shared code (which will be a disaster, I guess).
The simple solution in iOS is use targets.
For resources you can use different targets for each brand and then select different resources (images, xibs, etc) for each target.
Also if the changes in code are minimal you can then refactor some part of your code and create different classes with different implementation for each target (you can use some pattern like a Factory). Also you can simply use preprocessor macros.
It's not the better, but this is the simplest and quick approach, but if your code changes a lot it's better to create a core library like the other answers say.
A good approach would be to split your app up into the following components:
Core Model Library
Reusable views & view controllers. The views can be designed to support skinning and customization.
Any other reusable code that can be encapsulated as its own 'identity'.
These core projects should ideally have their own continuous integration (quality control) builds and tests.
And then use CoocaPods
Instead of manually performing all this complex integration, use CocoaPods. CocoaPods will create the Xcode workspace, build the libraries and link them into your project. You then create a custom build just by gluing the pieces together.
In addition to this, CocoaPods also performs tasks such as:
Resolving transitive dependencies - which just means building and fetching any libraries that your libraries themselves use.
Managing versions of the libraries being integrated.
Private Spec Repo is possible, or just use GitHub
The main CocoaPods repository is of course public and contains open-source and/or freely available libraries.
You can host your own CocoaPods spec repository, or simply set up a private GitHub account, and include a PodSpec in each project, then resolve as follows:
pod 'MyLibraryName', :git => 'https://github.com/myOrgName/MyLibrary.git'
this will install all of your libraries into your workspace. To update your project to include any changes to the core libraries, simply:
pod update
Advantages of this approach
You'll have a separate set of quality controls that gets applied to each core project.
There'll be much less reputation.
You can use more automation. More automation equals less waste equals more customer value.
As the team grows, you can split up core product devlopment and solution integration into separate roles/teams. A team working on an integration build, need not pull the latest library features, if that would disrupt them.
You can have two different customers on different builds of the core library. CocoaPods will manage this seamlessly. So you wouldn't necessarily have to update a build, until you get an enhancement request or scheduled maintenance. (Again reducing waste, thus increasing customer value).
Inspired by Piggly Wiggly (but lean through and through)
This approach is modeled after the production line style approach that was popularized in Japan after World War II. Its called Lean Methodology, and is all about having a fast, small inventory and reducing waste. (Delivering more with less). . Japanese execs got the inspiration for this when they went to America and visited Piggly Wiggly Supermarket stores.
This is often something you encounter creating cheap flash-games or apps.
These have very generic frameworks like: kicking a ball, shooting at the screen, or generating a list with some data downloaded from a specific server etc...
Everytime they want to create a new shootergame, they just load up their shooting framework, add a bunch of graphics and can release a crappy game within a day.
How do they do it?
They often create a framework which contains shared models, handlers, interfaces etc.
Put a lot of general utility functions like downloading files etc in a library.
And you can also create some default framework views and view-controllers.
When you want to create a similar app, just import the library and re-use the base framework. Containing base-views, base-models etc.
You can find a good example in the demo-examples delivered with the ios SDK or android SDK.
Good luck.
Maybe this applied to other Delphi's (I've only used 7). We've got our code broken up so that nearly every DLL in our fairly massive app is in a different folder.
99% of the open source stuff I've downloaded to plug into Delphi have had all their source munged into one folder.
It seems like this was an assumption that the developers of Delphi made about the coding practices of it's users that may be non-obvious.
I don't think so. In fact, In more recent versions they've added features to the project manager to make it easier to deal with the fact that code is spread around different directories (such as the flatten directories option), so I think it is accepted that this is how many people organize their code.
I suspect it's more to do with projects growing organically over time, and whether anyone takes the time to tidy up.
I for one definitely do not put all the sources into one directory but rather keep them in groups that have something in common. e.g. I use subversion externals quite extensively
(see http://www.dummzeuch.de/delphi/subversion/english.html , the section about externals).
I prefer different modules to be hosted on different folders, then have a common folder for units that is shared among different modules, makes management easy. e.g
myClientServerApp:(parent)
Client folder :(child)
server filder (child)
lib - (child)
Back in DELPHI 7 I also had all files in one folder. It has easy for small projects, but very hard for med to big one.
So I began to create a folder structure for all DELPHI projects small or big.
Over the year I am trying to improve, this folder structure, and every new project I make a small improvement so that it is simpler, logical, and more organized.
This day I am trying to make some parts of it sharable to several project. Its work in progress.
It would seem that having all the units in one folder would save you headaches in doubly named units. On the other hand, it might be handier to keep your projects in different folders when checking in and out of your version control. On the other hand it really doesn't promote code reuse to have them separated out like that.