3

I am using an open source component in my iOS project (sharekit), and they defined static variables in the header file. For example, in SHKConfig.h they define the App Name as:

#define SHKMyAppName            @"My App Name"

What I would like to do is make this dynamic; I don't want to hard-code those variables in that specific file. Since there is obviously no viewDidLoad method in a header file (as far as I know), how could I possibly dynamically assign this variable?

Is this even possible?

Thank you very much in advance!!!

AngeloS
  • 5,536
  • 7
  • 40
  • 58
  • 1
    How are you compiling your source code? You could probably add a `-D SHKMyAppName="Whatever You Want"` to the compiler options. Honestly not sure if this works in LVVM, but does in GCC. – pickypg May 22 '11 at 23:29

3 Answers3

4

#define is always evaluated during code compilation. You should modify the library to get this functionality.

Another solution is the following. Create some class Provider with a

+ (NSString *)getYourConstant;

method and use the following macro

#import "Provider.h"

#define kTheConstantYouNeed [Provider getYourConstant]
Anton
  • 2,342
  • 15
  • 17
  • will this be evaluated at runtime? Or will that method only be called during compilation? (your code example) – AngeloS May 23 '11 at 14:54
  • During code compilation all the occurrences of SHKMyAppName will be replaced (as a string) with the right hand side. So during runtime instead of having @"My App Name", you will get an actual method call. – Anton May 23 '11 at 15:21
  • perfect! thank you!! one last question, in the files where that method is being injected, do I have to import the utilities class (Provider.h in your example) or because it is imported in the macro header file I don't have to? – AngeloS May 23 '11 at 15:30
  • Nope, you should not. If a file has access to this constant, it will also have all the imports from the file where it is defined. – Anton May 23 '11 at 15:47
1

You could use ifdef macro preprocessor to redefine the variable at compile time. There is no way you could "change that variable" since it's not even a variable to begin with. It's a MACRO that replaces all occurrences of SHKMyAppName with @"My App Name.

Here's is what you could do. Define a compiler variable (you can do that in XCode project configurations) with the project name you are building. Then, replace #define with:

#if defined(PROJECT_APP_01_BUILD)
#define SHKMyAppName @"My App 01"
#elif defined(PROJECT_APP_02_BUILD)
#define SHKMyAppName @"My App 02"
#elif defined(PROJECT_APP_03_BUILD)
#define SHKMyAppName @"My App 03"
#endif

That way, when you are compiling App 01, macro SHKMyAppName will be replaced by @"My App 01"'. When you are compiling **App 02**, macroSHKMyAppNamewill be replaced by@"My App 02"'. And so on, so forth.

Pablo Santa Cruz
  • 176,835
  • 32
  • 241
  • 292
1

You could move these defines to a single appinfo.h file and include it within other headers.

This might also be a good place for version info.

E.g.

In SHKConfig.h:

#include "MyAppInfo.h"
#define SHKMyAppName    MyAppName // define MyAppName elsewhere

And in MapAppInfo.h:

#define MyAppName "Bla bla"


Or...

In SHKConfig.h:

#define SHKMyAppName    MyAppName // define MyAppName elsewhere

And in app's compiler settings add:

-DMyAppName=\"Bla bla\"
Danny Varod
  • 17,324
  • 5
  • 69
  • 111
  • This is true, but has nothing to do with the original problem: to get some kind of runtime evaluation of a #define statement in a third party library. – Anton May 23 '11 at 15:27
  • Read again - the word "runtime" was not mentioned once in the question. The problem stated was "I don't want to hard-code those variables in **that** specific file." Besides, as you know, #define is processed at compile-time, not run-time. – Danny Varod May 23 '11 at 15:56
  • The fact that some words are not present in the question do not change its sense for me. I really think that stackoverflow should be a place where people tend to help each other and not just automatically answer questions without even trying to get into the problem. – Anton May 23 '11 at 16:07
  • @Anton, I agree with @Danny. I never mentioned run-time in my question and he did answer my original question correctly, even though you provided a solution that worked better for me; so I don't know if it was worth a down vote. I'm going to give @Anton the accepted solution because it provided an answer that I originally didn't think of, but turned out to be better suited for my problem. If this is not consistent with SO guidelines please let me know and I will rectify. Thanks!!!! – AngeloS May 23 '11 at 16:10
  • Sorry, I really did think Angelo was meaning what I understood. – Anton May 23 '11 at 16:25