3 ms·
This situation is most commonly encountered on iOS, with ad networks and SBJson. As the developer behind one of the ad network SDKs included in countless iOS a
by SeoxyS 14y ago
This situation is most commonly encountered on iOS, with ad networks and SBJson.
As the developer behind one of the ad network SDKs included in countless iOS apps, I struggled finding a good solution to this problem. Spoiler: there isn't one.
The good news is, while there were often collisions on SBJson; pretty much all versions of the version are compatible. For a while, we would compile our static library without the SBJson objects, and ship the library and SBJson separately.
Recently we decided to create our own fork of SBJson, and switch to using our own prefix, which allowed us to embed it in our library, and not worry about what other libraries were doing.
Note: another tricky gotcha with static libraries for iOS: There is a bug in the linker, in that it will not import Objective-C categories from `.o` files unless there is another another symbol that is recognized, such as a class of C function. This has caused crashers and much headache.
- krevis 14y agoAbout that category issue: you know about the -all_load and -force_load linker flags, right? c.f. the "Important" box in http://developer.apple.com/library/mac/#qa/qa1490/_index.html http://developer.apple.com/library/mac/#qa/qa1490/_index.htm...
- SeoxyS 14y agoYes, but that's a flag that our library's users would have to figure out how to add to their project. And if they forget to, it would create crashes at runtime. That's not a can of worm we were willing to open.
- thought_alarm 14y agoNamespaces don't really solve that problem, do they?. Your options are to either fork SBJson and give it its own namespace/prefix, or require SBJson as an external dependency and lets your users provide their own version of the framework.
- objclxt 14y agoParse do this with their SDK, which requires Facebook Connect: all Facebook classes are prefixed "PF_".
- wsc981 14y agoI prefer if SBJSON is an external dependency, since there's less chance that I need to modify external projects my own projects make use of. The downside of course is that not all external projects might use the same version of SBJSON, so method names could have changed, could be missing, etc... So it falls to the developer to provide patches to external libraries if they use an outdated version of a library like SBJSON. Still, this is for me the preferred approach.