I've been developing an app which is localized in two languages. Everything has been going good so far until today.
What happens is that if i deploy the application on device, it alternates between being localized and not being localized (in which case it just shows the localized keys and not strings). It is getting really really annoying and I haven't been able to find a solution for this. I think it has to do with my Xcode setup perhaps?
This happened earlier in another project as well, but I could never see what was the matter.
Well, right after posting this question, it struck me that the only common thing I added in both projects was the ShareKit. share kit introduces its own localizable strings and for some odd reason, the iOS alternates between ShareKit's localizable files and my own. Moving share kit localizations into my own fixed the issue.
How should such a situation be handled?
I updated the question.
How should such a situation be handled?
The library (in this case, ShareKit) is at fault. Libraries that are meant to be included in other code should not use the default file name Localizable.string. They should give their .strings file a unique name and use NSLocalizedStringFromTable() in their code.
Related
I've been asked to write scope the effort for rebranding a significant iPhone/iPad application for multiple customers, locale, languages, etc. Each incarnation of the rebrand might include different look and feel, possibly different behavior, or subsets of functionality.
My initial impression is it should be possible to use a single xCode project, and just include multiple .plist files targeted to specific project configurations. I'm unsure exactly how to accomplish this in xCode, thus I'm not sure how to accurately estimate the effort required.
I'm looking for pointers and developer references to find the most reasonable method to rebrand an existing app multiple times without forking new xCode project each time.
The feature I've been looking for is called "Targets" in xCode.
I'm going to use these as described here to deploy my single project into multiple binaries.
I'm not sure that's possible but with MVC, Cocoa makes it easy to localize apps.
I've used a client-server approach, where everything specific to one customer is downloaded or configured from a remote server. You still need customers with overlapping requirements, but you can switch on/off modules based on the needs of a particular customer.
Low-tech approach: grab the data, configuration files, and images from a different location in the file system. Or the same location, but drop the new customer data into the directory and archive the old. A plist, a text file, a series of #defines, etc, can switch a behavior on or off. Write your code so that it doesn't know how many images, which modules, what color the buttons are, etc, until it checks the configuration and gets the data and images it needs from your directory.
I've been writing iOS apps for some time now and for this particular project, I decided that I needed a static library for code sharing purposes.
I've followed some tutorials in creating static libraries and everything works perfectly.
Now I wonder, is there any way of versioning the static library?
I couldn't find any files regarding version number in the static library project, nor any good search results (both Google and here) regarding this particular issue.
I think I could create some kind of "fake" Info.plist and store the version info there.
Is that the way of doing it? Any other approaches to the problem?
Edit:
I think I may have not been clear on my purpose:
I have a workspace that has both my library project and related projects using the library, which is imported using the .xcodeproj file, then configured the dependencies so it builds whenever needed.
I just need some way of versioning the library, so that I can include that in some sort of about box, just in case.
I think you should stay away from bundling binary builds of your own code. Unless you're building a really, really, really massive library, you're better off just importing the code in any of your projects, and rebuilding it each time. You can put it in a separate target though, so Xcode doesn't rebuild it all the time.
You might want to write a tool that takes version info in a .plist and writes it out as literal strings defined in a .h file, which you can then include in your own code.
To make it foolproof (avoid mismatch between the header and the library), define a class method like [YourLibraryClass versionString] that returns a NSString with the version number or signature.
Hi experts i have created a set of UItableviewcustom cell classes. Now can i group those classes to an static library so that i can include that library in whichever project i want and i can use it.
You can, but it really isn't worth the trouble... with the rate that they keep on releasing new SDKs, and considering that you'd have to make it a Universal binary supporting both the simulator and the iPhone device, it really isn't worth the effort... I'd just save the ".h" and ".m" files and drop them in a new project.
However, if you are absolutely determined to go that route... I do have some articles on creating iPhone frameworks: here. Note that they are somewhat outdated (circa iPhoneOS3.1), so I don't know how much has changed, and I've since converted to the Android camp... but you still might find the info there useful.
Anyone want to share an Xcode project that has MGTwitterEngine in it? Mine won't compile. Are there certain project settings to set? I just made a stock tab bar app for iPhone and added the MGTwitterEngine files. Tons of compiler errors. What am I missing?
I had same problem. To get it to compile I added "$SDKROOT/usr/include/libxml2" to the Header Search Paths list. I also checked Recursive checkbox.
Make sure that you're adding "$SDKROOT/usr/include/libxml2" to header search paths in your Target settings and not just the Project.
I managed to get the library path right eventually. However, in the end, I got rid of the whole MGTwitterEngine thing and went with the TwitterHelper stuff that I noticed the folks from the Stanford iPhone class using. It uses the synchronous calls and it's not as full-featured. But it's lighter and I understand it better. I just use threading to counter the synchronicity. (Hey, wasn't that a song?!) Anyway, a little JSON code and it's all under control. Most of you are probably going to think I'm a noob but it just feels cleaner and easier to handle. I know there are plenty of good reasons to use MGTwitterEngine.
Bottom line is, even though I got it to work by getting the library path right, I don't even need to worry about any paths by adding the very small TwitterHelper stuff to my project. Seems more Mac-like than to have to go into too much tinkering (I can already hear the experts saying that setting paths is not too much but I absolutely detest the Project Settings dialog.)
You also need to add
libxml to Header Search Path ( should be something like /usr/library/libxml2 )
I just wanted to add something that tripped me up. You have to make sure the Target header search path is also set because it may override the default project search path headers. If you are unable to find some header files that the path is definitely pointing to correctly in your project search path headers, then this is probably the reason.
You're probably missing the libxml library. You need to add that to your linked frameworks. Here's a question that has a little more information, but that's the gist of it.
Best approach for XML parsing on the iPhone
I'm in the process of creating an app. I'd like to have a pared down free version and a full paid version. Obviously, they will share a lot of code and some xib files. How to I share these without just duplicating them?
Create a second target (duplicate the main one) for the light version. You can then remove any files as necessary and define a preprocessor macro if necessary to distinguish between code for the lite vs paid version within a given code file.
How about making it one project with some sort of key or switch or something like that which will distinguish with version of the code to run.