I am trying to understand Dart's recommended project structure and not seeing the "forest through the trees".
So, if my project is intended to be a reusable library, say, a logging framework of some sort, then if I understand the above link correctly, I want all of my development to be under a lib and lib/src directory.
But what if I am building a web app? Where do my Dart source files go? Under packages? Specifically:
Where do I place Dart source files for a web app (not a lib)?
Are my web app's "packages" just directories that are logically organized similar to Java packages?
Does Dart recommend a 1-class-per-file convention for its source code?
1)
your_app_package/web
your_app_package/web/src/xxx
static content like jpg, css go to
* your_app_package/asset
2) the packages directory is maintained automatically. You configure in the file pubspec.yaml which 3rd party libraries you want to use and then call pub get or pub upgrade and the packages directory is updated automatically (the Darteditor does this automatically when you update pubspec.yaml).
3) not that I know of.
I had some problems putting additional classed in the code file of a Polymer element though. But I guess this is just a temporary limitation of Polymer.
Related
Programmatically I want to get all dart files available to import.
How can I achievement this? (programmatically)
In which environment do you want that?
If it's for a single Pub package, ensure that dart pub get has been run, then parse the .dart_tool/package_config.json file and find the roots of all the packages. Then search through those directories for all dart files that are not part files (does not start with part of ...;). The rest should be Dart library files which can be imported.
If you only want the packages that can be imported from inside lib/, you may want to parse the pubspec.yaml file too, so you can ignore the dev_dependencies.
Then you may also want to list the available dart:... platform libraries. Which are available depends on which platform you compile for. You need to figure that out somehow, then you should just keep a list for each platform.
I have code for a VST plugin and need to port some of it to an iOS app.
I have tried building the OSX version and using the lib.a and it doesnt work. When I open the iOS version of it, Xcode shows that it is missing the tagret.
If I copy the code directly into Xcode with all the JUCE modules, and I set the header search paths, I get compilation errors on things like no such type for String
After this latest JUCE update, Xcode would give the same errors until I updated the JUCE file itself, so I think the JUCE build settings or configuration of the new version is doing something differently. How can I get this code into a different Xcode project, so that I can use it?
Can I compile it as a library and use the objects through the header?
JUCE is designed to be included in projects generated by the Introjucer / Projucer (the JUCE project management tool). Without this, the correct preprocessor definitions will not be set up.
If you really needed to include JUCE source code inside your program, you could manually set up these preprocessor definitions (take a look at the AppConfig.h header from a generated project to get an idea of how much work this will be), but you'd really be going against the normal "JUCE way".
Simply including the headers and linking against the library will not work without considerable effort, as the include structure is ... odd ... and there isn't any library to link against directly anyway (the generated projects contain all the JUCE source normally, so there's no need).
Adding the JUCE source files (i.e. .cpp and .mm) to be compiled in a project directly will result in compilation errors, as they need to be compiled in a very specific order which is mandated by the header file (the header files #include certain implementation files after setting up their dependencies).
In short, if you can at all I would advise generating the project with the Projucer and adding other source files in as you need them, rather than the other way around.
I'm currently working on a project which contains a number of components (polymer elements). All said and done, I'll probably be looking at around 10+ components for the application. At the moment, following Pub's Package Layout Conventions each .html and associated .dart file is in the web/ directory.
It would be nice to have them in lib/src/ of my application and only have the main files in web/ however at the moment <link ref="import" href="package:my_app/src/my_component.html"> will not work (See Issue 12867).
Are there currently any conventions in use to handle multiple (private) components for an app? Should I create a web/src/ directory to load imports/source files relative to the web/ directory? Would it even make sense to keep Polymer Element .html files in lib/src/ (assuming it was supported) as they're not pure dart files as traditionally recommended/expected in a pub package layout?
As far as I understand, package: works only for external components (dependencies declared in pubspec.yaml), and the default path is the packages folder (created by pub install). See the getting started section here: Dart Pub
I keep components in their own folders under the web directory so web/component1, web/component2 and so on and I use relative links to import across components. Not sure if this is the best practice but it works.
If I'm just getting started authoring and managing my client source code using dart within a PHP or Rails project (similar to haxe or coffeescript), what convention(s) should be used for project structure?
Does any of this change if I say I'm mainly going to be transpiling my code to JavaScrpt?
Dart package layout conventions:
http://pub.dartlang.org/doc/package-layout.html
The more relevant parts for a client side dart application:
http://pub.dartlang.org/doc/package-layout.html#public-libraries
http://pub.dartlang.org/doc/package-layout.html#implementation-files
http://pub.dartlang.org/doc/package-layout.html#web-files
Long story short, put your dart libraries in the lib/ folder. The Dart scripts in here define what other packages (including your web/) can import and use. Entry points--scripts with main()--cannot go in the lib folder.
Files in lib/ can me imported with import "package:project_name/file_name.dart".
Internal libraries that should only be imported and used inside of the package should be put in lib/src/.
I used to copy/paste my IOS plugin files inside Plugins/IOS folder on my Unity project, but it doesn't work for bundles (as it has directory structure).
I can't beleave there is no way to generate xcode project from unity with .bundle inside?
Any help appreciated
Unity3D will not contains folders in the Plugins/iOS to Xcode project. In fact Unity3D will only auto merge source file and .a library for you, as described by Unity3D's doc:
Automated plugin integration Unity iOS supports automated plugin
integration in a limited way. All files with extensions
.a,.m,.mm,.c,.cpp located in the Assets/Plugins/iOS folder will be
merged into the generated Xcode project automatically. However,
merging is done by symlinking files from Assets/Plugins/iOS to the
final destination, which might affect some workflows. The .h files are
not included in the Xcode project tree, but they appear on the
destination file system, thus allowing compilation of .m/.mm/.c/.cpp
files.
Note: subfolders are currently not supported.
But you can use the PostprocessBuildPlayer attribute to implement this yourself. I made a tool for this purpose called XUPorter, which can make exporting and libraries setting easier from Unity3D to Xcode. You may want to see it on GitHub. There is a demo in the package and you may set your bundle under the 'folders' tag.