How to exclude files from compilation in flutter? - flutter

I have a project that builds several similar apps, different apps require different resources. I have folder assets/images_project1 and images/project2. How can I exclude e.g. images/project2 from the compilation? I don't want to manually replace the folders every time. If files still, they increase the app size

According to this there is no built-in solution as of right now.
But the easiest thing to do is just manually comment folder in pubspec.yaml under the assets section.
Optionally you can use script from the mentioned question.

Related

subfolders in iPhone localization folders

I would like to localize some images in my iPhone project. So I created files:
en.lproj/Images/iPad/btn-check-pressed~ipad.png
en.lproj/Images/iPadRetina/btn-check-pressed#2x~ipad.png
ru.lproj/Images/iPad/btn-check-pressed~ipad.png
ru.lproj/Images/iPadRetina/btn-check-pressed#2x~ipad.png
and so on and added them to my project. But Xcode shows "English 0 files localized", "Russian 0 files localized" in Localizations list.
It also shows a warning
Warning: Multiple build commands for output file /Users/User/Library/Developer/Xcode/DerivedData/TestLocalizationDefaultPNG-ckplzmcjurofxrccjuvyzjaqketc/Build/Products/Debug-iphonesimulator/TestLocalizationDefaultPNG.app/btn-check-pressed~ipad.png
for each of my files when I try to build the project. So, as far as I understand, it copies all files in one folder, and since my files have the same names - only one of them can survive. But, if I remove my subfolders:
en.lproj/btn-check-pressed~ipad.png
en.lproj/btn-check-pressed#2x~ipad.png
ru.lproj/btn-check-pressed~ipad.png
ru.lproj/btn-check-pressed#2x~ipad.png
everything works fine.
Is there is a way to keep subfolders? Here http://developer.apple.com/library/ios/#documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html in Listing 2-4 subfolder used for the audio files, so it should be.
It looks like the only way localization works in iOS is different. You base folders hierarchy should be by inverted: first goes actual folders structure and in each and every folder you want to localize, you put corresponding .lproj sub-folder with localized resources. So in your example it should be something like:
/Images
/iPad
/en.lproj
btn-check-pressed~ipad.png
/ru.lproj
btn-check-pressed~ipad.png
/iPadRetina
/en.lproj
btn-check-pressed#2x~ipad.png
/ru.lproj
btn-check-pressed#2x~ipad.png
This might be sub-optimal if you intended to have big hierarchy but this is the only way it works out of the box.
Of course you can always say that you don't need Xcode support and use some custom build rules to re-arrange files in you project in the way you like and then copy them into proper structure during build but I doubt it worths troubles.
Update: it looks like XCode (4.5) build script is the main villain.
According to my experiments build script should flattens resources structure at least for images. So the only way localized app can be inside is:
/YourApp
YouApp
info.plist
....
/en.lproj
btn-check-pressed~ipad.png
btn-check-pressed#2x~ipad.png
/ru.lproj
btn-check-pressed~ipad.png
btn-check-pressed#2x~ipad.png
The trick is that by default XCode (as of version 4.5) can flatten your project structure only if it is as described above and I don't see a standard way to change this behavior.
Of course, original comment about custom build scripts is still true.

Why in Xcode, Groups can be created, but not real folders?

When doing iOS programming, it is interesting that in Xcode (4.3.2), we can create groups, such as a group call Images, and add files to it (either as a link or choose "Copy items into group's folder"). So it looks like a real folder in the navigator, and it even mentions "copy into ... group's folder", but in fact there is no folder. All added files are in the same location as the .m and .h files.
Why would we want Groups, but not real folder? Is there advantage of Groups over the use of a folder?
This is a pet peeve of mine.
I recommend, making the folder in your file system, where you have your project files, then drag that folder into Xcode where you want the group. It will act like any other group, but now be linked to the folder on the file system. Adding files to that group in Xcode now adds them to the folder in the file system.
Much cleaner way of working and helps when locating files in big projects. Keeps git cleaner too.
Update for Xcode 9:
Once you have the groups in Xcode matching the directory structure on disk, moving a file from one group to another in Xcode will now move the file correctly on disk to match.
Note: In Xcode 10, the default behavior now creates a linked folder when you create a new group. The information below still applies otherwise.
The recommended way to organize files is via groups, because it's more flexible than creating directories, and allows you to create complex file hierarchies while maintaining a totally different file hierarchy on the file system. It's simply an organization tool. That said, it is possible to turn groups into folder references, or create them initially as folder references.
Furthermore, using groups instead of folder references gives you greater flexibility if you need to change where things are in the file system - say you have a common folder of code that you use in a bunch of different projects. Groups allow you to organize the files inside of projects as if they were in the projects, while still maintaining one copy of the code in a central location. And yes, you can do this with folder references as well, but groups are much more flexible if you later want to add other things to the same group but don't want them to be added to that common folder.
If you want to link a group to a folder, click on the group in the project file tree and hit command+option+1. Below the drop down that'll say something like "Path: Relative to Group" on the right, there's a little white square with a grey border around it kinda icon next to the word "none". Clicking on this and then selecting/creating a folder will bind the group to the folder.
Furthermore, when you drag a folder into Xcode, it will ask you if you want it to be a group or a folder reference:
There is a Command Line Tool - "synx"
available in github that do exactly what you need.
It reorganizes Xcode project folder in finder to match Xcode groups in project.
You can find it here:
https://github.com/venmo/synx
UPDATE: XCode 9 supports this feature by default. So, no need to use other tools anymore!

how to add files with same name in different folders of xcode project

I want to have two files with the same name in different folders in a xcode project. These files are actually code files and not any resource files. How can I achieve this?
Thanks
Pankaj
Well if there .h/.m files you can't have them in the same project, even if they are in different directories.
C does not support namespaces, so every class has to have an unique name.
You can add, but when you load it, the system will pick the first one available.
So, really it will not work the way you expect.

Using resources with the same name in Xcode

Is there a way to add multiple resources with the same name to an Xcode project and have 1 of them take priority over the others?
Example:
I added 2 files, both called icon.png, to an Xcode project. They are on different folders in the file system (Folder1/icon.png and Folder2/icon.png) and on different groups in Xcode. Is there a way to tell Xcode to have Folder2/icon.png take priority over Folder1/icon.png? And if only 1 icon.png exists, then use that one.
Thanks.
EDIT (2010-12-23):
You can have multiple files with the same name in an Xcode project even if they are not in separate folder references, but they are in separate groups. Once compiled, the app bundle (which will be flat with no folders in it), will only have one copy of the file (icon.png). How do you pick which copy of the file to use?
I was told that you can do this for BlackBerry. It works something like this: The compiler will go down the list of files in the project and start adding them to the app bundle. If it sees a duplicate, it will overwrite it (or not), so the files at the bottom (or at the top) will have higher precedence and will be the final bundle.
This can better easily be solved by using folders within a resource bundle in your Xcode project. Take a look here: http://developer.apple.com/library/mac/#documentation/CoreFoundation/Conceptual/CFBundles/Introduction/Introduction.html
Wait a second, since you specifically mentioned icon.png, are you trying to supply different iDevices (iPad, iPhone4, iTouch3...) with different icon images?
If yes, check this out, http://d.pr/W2w0 , Apple has already provided a way for us to finish this task with convenience. All you need to do is following a specific naming convention.
What we do if we have a situation like this is:
We have several subfolders on the file system level of the project dir and add them to XCode into separate groups.
This works well. For actually building, we try to avoid Files with the same Name in one target. Icon.png and iTunesArtwork are only added once in every target.
It just proved to be a Maintainability Nightmare

Starteam shortcut file

Is it possible to create StarTeam shortcut, opening project and overriding working directory?
Is it possible to create one StarTeam shortcut, opening several projects at a time?
Problem is: I have several solutions, which use the same StarTeam project, and I have to manually change working folder very often (View -> Properties -> Working folder). It is not possible to share data between solutions: local view should be located in separate place for each solution.
You could create different views for each project. Different views can have different working folders; in fact, they do by default. Keep in mind, a view can be set to behave pretty much the same as the default view, with regards to which revisions of files you see. But they can have their own working folders. The downside of this technique is that Change Requests and the like will also be "in the view," so moving them will not necessarily affect other views. But given that you are working on an entirely separate projects, that might not be all such a bad thing. As usual, you should experiment with this in a test project, and make sure you're happy with the behavior, before using it on your "life" repository.
The override/alternate directory for each project and folder is maintained inside a local file - not on the server. The default working folder is kept on the server, and any time you update it the changes are propigating to all other users.
The shortcut xml has no place to specify a working folder.
If you don't need the StarTeam GUI, stcmd allows you to specify a new working folder for most operations with the -rp and -fp flags.
If the projects that need this common library code are in their own views, you could also share the common project into a new subfolder within those other projects. You can use a relative path for this new subfolder that includes .. to move it outside the containing project's folder. This lets you use common code in many projects while allowing you to specify the location of that common code per project.
Shares come with some overhead, so be aware, but other than that it would probably work for what you're trying to do.