I have a well advanced project in Swift on Xcode. After a while I decided to add a custom property (to catch a UIColor) to UIButton Class by subclassing it. But I already have a whole bunch of buttons in my Interface Builder set and programmatically in my project itself.
Is there a clean way to change each instances of my old UIButton Class, in IB and in the project files, to my new one at once without messing everything ? Hope I have been clear... ;) Thanks a lot
I would do this outside of Xcode with the help of some shell scripting.
First, do a backup.
Then something like:
for f in `find . -name \*.storyboard -o -name \*.xib` ; do
cp $f $f.orig
sed 's/<button/<button customClass="MyButton" customModule="MyModule" customModuleProvider="target"/g' $f.orig > $f
done
Check if everything still works in Xcode (if not, you still have a backup in the .orig files)
Lastly you might also want to change some classes in your Code from UIButton to MyButton, but this cannot be automated since your code might reference some framework classes that sill will remain UIButtons.
Actually not pretty clear but note that if you looking for clean way to effect for all instances is using Type properties like static and class will be good idea
Related
I'm trying to keep my code as readable as it possible by keeping methods and files as short as I can and using nested classes for namespacing. It works fine except some really strange moment.
I have some class used for namespacing.
class Space { }
All classes used within that one are implemented in their own files as extensions.
extension Space {
class SomeClass {
// implementation
}
}
One of those SomeClasses have a number of quite sophisticated initialisers, so I have split them up to their own files as well and implemented it as follows:
extension Space.SomeClass {
convenience init(fromSomeSource source: SourceClass) {
self.init()
// other implementation
}
}
The problem is that some of those files works just fine, but some of them throwing 'SomeClass' is not a member type of 'Space' and I don't know why.
All of them are pretty similar. The only difference is implementation of an initialiser itself. All files are held in the same place and I have no idea why some of them works fine and some not.
I tried to move code from not working files into files that works fine and that works – Xcode agrees to see the code and said nothing against it. But when the very same code lies in its own file – Xcode or compiler doesn't want to understand that SomeClass is really a member of Space.
I tried to clean the build, including manual dumping of ~/Library/Developer/Xcode/DerivedData folder. Nothing helps.
Surely I can put it all in a single file and it will work fine, but what the reason why it so picky in my case?
I've tried to create a new file and move there all contents from one of the bad ones. It works, but only with certain file names. Some names gives the same error again, but it seems that if name is totally new and not similar to any of the existing ones - it works. Magic?
I've encountered similar issue, it seems like the complier is trying to process the file where you extend the nested class before the one where it's defined. Therefore you have this error saying that that Space has no member SomeClass.
The solution I've found is to go to your target settings, open Build Phases.
There, in Compile Sources section you should put the file where you define the nested class above files where you extend it.
This solution seems to even play well with your observation that when you recreate the file it sometimes compiles, because when you recreate the file its position in Compile Sources changes.
How can I automate setting a breakpoint on all methods in an Objective C class using lldb?
This is useful for learning the behavior of a complicated legacy class. I am using Xcode (includes lldb) for iOS development, and it is cumbersome to manually go through the (large) file in Xcode and click the gutter next to each method to set breakpoints.
One option is to use regex breakpoints.
breakpoint set -r '\[ClassName .*\]$'
You can play around with the regexp to suit your needs.
The command will create a breakpoint that stops on all methods implemented by that class. However, there will be no breakpoints on methods inherited from superclasses.
To get methods on the superclass, you'll have to use a conditional breakpoint. For example, if the superclass is UIViewController, you could do something like:
br s -r '\[UIViewController .*\]$' -c '(BOOL)[(id)$arg1 isKindOfClass:[CustomVC class]]'
For x86 change (id)$arg1 to *(id*)($ebp+8).
Finally, if you really want to learn about the control flow through various classes, check out dtrace. It's probably more suited to this than a debugger.
br se -f FooViewController.m -p '^#property|^ *- *\('
"br se" is short for "breakpoint set", pass your own filename to the -f argument, and the -p argument is a crude regex for properties and methods in Objective C.
Caveats: This doesn't seem to work for .h files, so if you have properties declared in the header that you want to watch then you may need to set watchpoints on their backing instance variables.
This is the best solution I have found so far, please post alternative solutions if you think they will be helpful.
Here is a quotation from the other post:
I'm working in a iOS project that includes a static library created by another company. The library include an old version of AFNeworking and I don't have any source files.
Now i need to use a more recent (and less bugged) version of afneworking, but i cannot include the same class twice in the project (of course) because all the "duplicate symbols"
My problem is that I'm preparing an iOS framework and I want to avoid this kind of situation in the future. I'm not talking about AFNetworking, but other quite popular iOS framework. In addition I applied some custom changes in the original framework code.
The one way to avoid "duplicate symbols" and "Class X is implemented in both Y and Z. One of the two will be used" that comes to my mind is to add some prefix to the original framework classes, but is this the right solution?
UPDATE 1:
I tried to apply John's solution but no joy. I have created a simplified project (here is the link to the repo) with two classes FrameworkClass which is present in framework target only, and SharedClass which is present in both framework and application targets, so maybe you can see if I'm doing something wrong. After application did launch I'm still getting:
objc[96426]: Class SharedClass is implemented in both .../TestFramework.framework/TestFramework and .../SymbolsVisibilityTest.app/SymbolsVisibilityTest. One of the two will be used. Which one is undefined
UPDATE 2:
Here is my output from nm based on the provided sample project's framework-output:
0000000000007e14 t -[FrameworkClass doFramework]
0000000000007e68 t -[SharedClass doShared]
U _NSLog
U _NSStringFromSelector
00000000000081f0 s _OBJC_CLASS_$_FrameworkClass
U _OBJC_CLASS_$_NSObject
0000000000008240 s _OBJC_CLASS_$_SharedClass
00000000000081c8 s _OBJC_METACLASS_$_FrameworkClass
U _OBJC_METACLASS_$_NSObject
0000000000008218 s _OBJC_METACLASS_$_SharedClass
0000000000007fb0 s _TestFrameworkVersionNumber
0000000000007f70 s _TestFrameworkVersionString
U ___CFConstantStringClassReference
U __objc_empty_cache
U _objc_release
U _objc_retainAutoreleasedReturnValue
U dyld_stub_binder`
UPDATE 3:
I did manage to "hide" SharedClass symbols by applying the solution by #bleater and my output from nm is now:
U _NSLog
U _NSStringFromSelector
00001114 S _OBJC_CLASS_$_FrameworkClass
U _OBJC_CLASS_$_NSObject
00001100 S _OBJC_METACLASS_$_FrameworkClass
U _OBJC_METACLASS_$_NSObject
U ___CFConstantStringClassReference
U __objc_empty_cache
U _objc_release
U _objc_retainAutoreleasedReturnValue
U dyld_stub_binder`
But I'm still getting double implementation warning in Xcode.
You should limit the visibility of symbols in any framework or library you are developing. Set the default visibility to hidden, and then explicitly mark all the functions in the public interface as visible.
This avoids all the problems you have described. You can then include any version of any public library (AFNetworking, SQLite, etc.), without fear of future conflict because anything linking to your framework or library won't be able to "see" those symbols.
To set the default visibility to hidden you can go into the project settings and set "Symbols Hidden by Default" to YES. It is set to NO unless you change it.
There are at least a couple of ways to mark the symbols from your public interface as "Visible". One is by using an exports file, another is to go through and explicitly mark certain functions as visible:
#define EXPORT __attribute__((visibility("default")))
EXPORT int MyFunction1();
The define is obviously just for convenience. You define EXPORT once and then just add EXPORT to all of your public symbols.
You can find official apple documentation on this here:
Runtime Environment Programming Guide
Update:
I took a look at your sample project, and it looks like I pointed you in the wrong direction. It appears that you can only truly hide C and C++ symbols. So if your were having this problem with a C lib (like sqlite), setting the default visibility to hidden would work. It looks like the nature of the Objective C runtime prevents you from truly making the symbols invisible. You CAN mark the visibility on these symbols, but with Objective-C it appears that is just a way to have the linker enforce what you should or shouldn't be able to use from the library (while still leaving them visible).
So if you redefine a Objective-C symbol in different compilation unit with the same name (by perhaps compiling in a new version of a popular open source library), then you will still have a conflict.
I think your only solution at this point is to do what you first suggested and prefix the symbols you are including into your framework with a unique identifier. It isn't a very elegant solution, but with the limits of the objective C runtime I believe it is probably the best solution available.
So the blog post by Kamil Burczyk was a good starting point, thanks for the hint Michał Ciuba! It has covered most of the symbols, but it didn't cope with categories and class clusters. You can see what category methods are still exposed without any change by invoking nm with parameter list sth like:
nm MyLibrary | grep \( | grep -v "\[LIBRARYPREFIX" | grep -v \(MyLibrary | grep -v ") prefix_"
When it comes to categories we have 3 groups of categories, and they all require a specific, different approach:
Categories on classes that has been renamed by NamespacedDependencies.h
Categories on classes not renamed by NamespacedDependencies.h
Categories on class clusters like NSString, NSArray...
Ad 1.
Everything is ok - class name will be prefixed so category will exist on prefixed sumbol in object file
Ad 2.
This problem occours whenever inside of the dependency we have category on a class like NSObject. It would be exposed without any change in object file, thus would cause a conflict. My approach was to internally rename NSObject to PREFIX_NSObject, this ofcourse requires me also to create and add the PREFIX_NSObject class implementation to the project (empty implementation, just a subclass of original NSObject)
#import "PREFIX_NSObject.h"
#ifndef NSValueTransformer
#define NSValueTransformer __NS_SYMBOL(NSObject)
#endif
Ad 3.
We cannot apply Ad 2. approach here. Actual objects created by let's say PREFIX_NSArray class methods are still of type that wont derive from my presumable PREFIX_NSArray class, so this doesn't make sense as category methods defined on PREFIX_NSArray won't be visible on NSArray derived objects. I ended up by manually prefixing methods of those categories in source code.
It's kind of crazy workflow, but at least gives warranty that everything will be 'invisible' and won't cause a conflict.
It's always good idea to run nm to check if all category symbols are hidden:
nm MyLibrary | grep \( | grep -v "\[LIBRARYPREFIX" | grep -v \(MyLibrary | grep -v ") prefix_"
I am using Base Internationalization for XIB/Storyboard files and the "Export for Localization" method using XLIFF files for translators.
I have some labels, buttons, etc. that have text that should be translated, but I also have labels where we use some placeholder text (like a full-name) so you can see what the view would look like when populated with data, but those labels always have their text come from an outlet programmatically.
Is there some way to mark this label's .text property that is set in the XIB as non-localizable so that it doesn't end up in the XLIFF (or resulting .strings) files.
I know that I can remove the text -- I also thought about having a prefix (like #"!DNL!") to mean that the translator shouldn't localize, but I am hoping that there is just a standard way to do this.
I add a note "DNL" to the "Comment for Localizer" field in the identity tab. Then, I run this command to automatically remove all of those elements from the XLIFF:
xmlstarlet ed -d "//*[contains(text(), 'Note = \"DNL\"')]/.." en.xliff > out.xliff
Basically, it's using xmlstarlet (which can be downloaded via homebrew) to find all elements that contain the text Note = "DNL", and then deleting the parent of that element from the XLIFF.
Combined with using xcodebuild -exportLocalizations, you can make a pretty simple script for generating your XLIFFs:
xcodebuild -exportLocalizations -localizationPath build -project ProjectName.xcodeproj
xmlstarlet ed -d "//*[contains(text(), 'Note = \"DNL\"')]/.." build/en.xliff > build/out.xliff
It turns out the localization export from Xcode ignores attributed strings in the storyboard.
So just set the type of text for every label/button you want to exclude to Attributed in the Attributes Inspector.
This will give you an attributed string rather than a plain string, which as far as I know has no implications, apart from the (empty) list of attributes that has to be kept in memory now.
UPDATE:
Check out ReMafoX, it's a Mac app that perfectly solves your problem. It can be easily installed and integrated within your project, watch this video for a detailed walkthrough.
To ignore specific Strings, simply add one of the customizable ignore flags from the "Interface Builder" pane in the "Comment for Localizer" field in your Storyboard/XIB files and the build-script you configured following the above linked video will exclude it on next build of your project (or press of the "Update" button in the config).
OLD ANSWER:
This is now possible using the BartyCrouch command line utility which I recently wrote to solve this problem (see installation instructions in my answer on that thread).
BartyCrouch runs ibtool for you and does additional processing on top of its resulting .strings file. It will exclude views from translation if you include #bc-ignore! into your value or comment within your base internationalized Storyboard/XIB file.
Please check out out the related section within the README on GitHub for detailed information.
If I use Xcode's "Find/Replace in workspace" it seems to skip any text contained in the UIViews in XIB files.
Anyway to do this in Xcode or do I need to use another tool?
Thanks!
XCode will successfully Refactor IBOutlet names even if they are connected up in the nib. So to answer you:
Before choosing Find/Replace on the text, first see if Xcode will Refactor it instead. It won't refactor certain things (such as enums and #defines). If it will Refactor your target text then choose that and it should be okay.
You can use find and sed from the command line
find . -name '*.xib' -type f -exec sed -i "" 's/OldText/NewText/g' {} \
For instance, I just had to find and replace all class prefixed from SC to MCSC and I used:
find . -name '*.xib' -type f -exec sed -i "" 's/[[:<:]]SC/MCSC/g' {} \
The [[:<:]] indicates a word boundary on OS X (see https://stackoverflow.com/a/5734237/456366).
Find and replace option of Xcode if for text/string replacement not for files.
If you want to do this you can have your shell script/ apple script.
If you really have a lot of this text you want to find/replace, you might find IBTool usefull.
It's usually used to export/import texts from/into .XIB for translation reasons, but it should fit your needs, too.
You can see example of IBTool usage on iPhone Applications Localization Guide. You'd be interested in points 2 and 5 of the guide.
you export the strings using IBTool
you do find/replace in any text editor
you reimport the string