FMDB doesn't output to UTF-8 encoding - objective-c

I'm new to FMDB and I'm following this tutorial. I create the database in terminal. I'm having a problem after I add my database to xcode and compile. It is not automatically in UTF-8. There are weird characters so there are lots of errors and it won't compile. Here's a screenshot:

SQLite is a binary format, and as such, you won't be able to view it or compile it in Xcode. Instead, you want to make sure it is treated as a resource like images. Make sure it's copied to your resources folder as well.
FMDB + SQLite does UTF-8 just fine- but the Xcode editor isn't the way to view it (you'll have to get at its contents pragmatically).

Related

How to sync localized storyboards' strings after modifying storyboard in Xcode 5

I'm just starting to look at IOS Apps' localization in XCode 5 and I've tried to add an Italian Localization:
Xcode 5 automatically generates the Main.strings file with a single entry, for the only label I've put within the Main.storyboard file:
/* Class = "IBUILabel"; text = "Label"; ObjectID = "PeT-4z-NSf"; */
"PeT-4z-NSf.text" = "Etichetta";
If I later modify the Main.storyboard file adding a new button to the view, then how should I tell Xcode 5, if possible, to add missing localization strings to the Main.strings file? Should I add a new entry by hand by looking at the Object ID field in Interface Builder (it works, but I don't know if this is how it is meant to update storyboards' localization)? Can I run something like genstrings on the Main.storyboard file to extract all the labels' text and add the new ones to the localized Main.strings files?
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.
Alternatively, if you prefer an open-source CLI tool without a GUI, you can also use BartyCrouch.
Install BartyCrouch via Homebrew:
brew install bartycrouch
Alternatively, install it via Mint:
mint install Flinesoft/BartyCrouch
Incrementally update your Storyboards/XIBs Strings files:
$ bartycrouch update
This will do exactly what you were looking for.
In order to keep your Storyboards/XIBs Strings files updated over time I highly recommend adding a build script (instructions on how to add a build script here):
if which bartycrouch > /dev/null; then
bartycrouch update -x
bartycrouch lint -x
else
echo "warning: BartyCrouch not installed, download it from https://github.com/Flinesoft/BartyCrouch"
fi
In addition to incrementally updating your Storyboards/XIBs Strings files this will also make sure your Localizable.strings files stay updated with newly added keys in code using NSLocalizedString and show warnings for duplicate keys or empty values.
Make sure to checkout BartyCrouch on GitHub for additional information.
The file that Xcode does not update automatically (at least 5.x version didn't) is the app's Localizable Strings. You can build a fresh file from Main.storyboard as follows:
In the project Navigator (the leftmost pane) click on the Main.storyboard file. In the Utilities pane (the rightmost pane) click on Show the File inspector icon. It is the leftmost icon in blue in the image below:
.
On the right pane that will appear, one of the sections will be Localization:
Uncheck the English (Localizable Strings) row and in the window that will pop-up check the Delete localized resource files from disk and click the Remove button (you do not have to check delete, in which case Xcode will ask for a permission to override it when you build it next).
Then check English (Localizable Strings) again to build it from scratch.
Using Xcode 6 the following worked for me:
I changed the localization for a language from "Localizable Strings" to "Interface Builder ..." like suggested at the SO question posted by h.orim. However the setting did not change, it still was set to "Localizable Strings". The next step now is to do that again, so Xcode will find the Storyboard it just created and show a prompt asking if it should be used or replaced. Now click on "Use file" instead of "Replace", otherwise the same will happen again.
Now you should have a localized Storyboard in the desired language. After you now switch back to "Localizable Strings" you will have a file containing all current strings used in the storyboard with your previous translations still in place.
Another way is to do it manually by selecting on the storyboard the field to translate. Go to the "Identity Inspector" and copy the Object ID (something like HP8-op-SmX).
After that, open the storyboard langage file (Main.strings, most cases) and past the Object ID. Depending your needs, you just have to add .text or .placeholder.
"HP8-op-SmX.placeholder" = "My translated placeholder text";
"HP9-op-VvD.text" = "My translated text";
Save, clean & build. It's a little bit painful but can save a lot of time if you only need to translate few things.
You can use a script called UpdatStoryboardStrings for this!Get it here: https://github.com/AppliedIS/iOSL10n
Intructions for use: http://blog.appliedis.com/2013/05/22/localization-of-an-xcode-ios-app-part-2/
With Xcode 6+, ideally developers should not have to manually manage strings files. Use XLIFF export to automatically gather development language strings to send to translators, and then use XLIFF import to update the strings files with translations.
https://developer.apple.com/library/ios/documentation/MacOSX/Conceptual/BPInternational/LocalizingYourApp/LocalizingYourApp.html#//apple_ref/doc/uid/10000171i-CH5-SW9
Another option is to use ibtool --export-strings-file directly.
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/ibtool.1.html
There are two options:
Option 1
Xcode can "reload" the file by converting the file to either an [Interface Builder Cocoa Touch Storyboard] file type or a [Localizable Strings] file type.
Select your base storyboard file from the Project Navigator
Find the Localization section in the File Inspector
If your file is currently a [Localizable Strings], change it to [Interface Builder Cocoa Touch Storyboard] or vice-versa.
Xcode should have converted your storyboard to the current version, while preserving your old localization efforts. Here you can change the file back to the original file type if you would like.
Option 2
Use ibtool to extract the strings in your storyboard.
Open the Terminal application
Locate your Base.lproj directory
Use this line to extract the strings:
ibtool MainStoryboard.storyboard --generate-strings-file file_name.strings
After ibtool extracts the strings to file_name.strings, you can copy and paste it to your original .strings file
Tested with Xcode 11, you can simply deselect the language.
Do not delete the file on disk.
And then choose to use the existing file.
The old translations will be kept and the new keys will be added.

Update Localizable.strings file Runtime in iPhone

I want to update or replace Localizable.strings Runtime. i have .strings files on server. so if any one can update .strings files on server. then also i need to update value or replace into bundle.
or
can i read .strings file form server directly? and make all static string localized.
Sure you can. You have to roll your own.
If you look at the NSLocalizableString macro, you can make your own like :
RMLocalizableString that instead of pointing to the resources, points to a file you have downloaded in your documentation folder. But of course you have to make sure the file is actually there.

how to get xcode code sense/autocomplete working with lex/yacc input files

Is there any way to get proper syntax highlighting, autocompletion, etc. for objective-C code in lex and yacc input files with XCode? Specifically, I'm even using .lm and .ym files, and XCode 4.2. XCode sort of recognizes them, since it builds them properly and formats them in a monospace font, but no help coding at all. Code sense is working properly in normal source files.
I've looked around and I did find the XCCodeSenseAllowAutoCompletionInPlainFiles user default, which helps a little, but it's still not anywhere close to real code sense.

Xcode Plist Error

I am generating some plist files for use in an app I am developing, however all of my generated plist files cause the following build error:
Command /Developer/Library/Xcode/Plug-ins/CoreBuildTasks.xcplugin/Contents/Resources/copyplist failed with exit code 1
However, if I open the plist with the plist property editor and then re-save the plist file, the error goes away. The plist property editor also displays everything correctly. Does the plist editor add some extra metadata to the file or something that xcode requires? Anyone have any ideas?
Might save yourself some time by checking on /usr/bin/plutil used in converting plists from one format to another also has a lint command.
copyplist failed with exit code 1 will occur if you've generated (or hand-crafted) an XML .plist file that doesn't satisfy the plist XML schema. Whitespace shouldn't affect this but misusing the supported tags will.
Using the plist property editor to open and save the file will force the XML into the right format, but long term you'll probably want to isolate the problem and fix your XML generator. (or write an XML-file "fixer" if you don't have control over the XML generated)
Checking you have spare disk space has also been suggested!

Are Objective-C function names stored in text?

I don't remember where I heard about it, (I think I was searching up on how selectors worked and it ended up not being exactly the same as a callback function) and I can't confirm it. But more importantly than that, is there a way I could get a list of the function names from another application?
See class-dump.
You can sometimes see a list of the method names in an application. Find the .ipa file for the app (possibly in the Music->iTunes->Mobile Applications directory on a Mac). Make a copy of one of the ipa files and change it from .ipa to .zip. Unzip the file and in the Payload folder, there's a file with the same name as the app. Right click on it and "Show Package Contents". In there, you'll find another file with the same name as the app (with no extension). This is the executable file for the app. If you open it in a text editor like BBEdit, you'll sometimes be able to see some method names, as well as a list of the frameworks the app is built against. You can find the path name where things were kept too, often with the developer's name.
For example, looking into the Japanese dicitonary Daijirin, I can see these methods:
-[HMWebSupport openMONOKAKIDOSupportWithSafariForView:style:]
-[HistoryViewController viewWillAppear:]
I can also see that one of the developers was called Norihito, and he was using SVN: /Users/norihito/Developer/SVN/Mobile/DAIJIRIN/Other
Other applications (like Weightbot) don't show as much information. I don't know the reason it shows up some times and doesn't other times.