Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conflict with SBJson #1

Closed
thom-ek opened this issue Aug 28, 2015 · 7 comments
Closed

Conflict with SBJson #1

thom-ek opened this issue Aug 28, 2015 · 7 comments

Comments

@thom-ek
Copy link

thom-ek commented Aug 28, 2015

SumupSDK.framework uses SBJson internally. It conflicts when developer also uses SBJson in his project. SBJson framework usage should be prefixed to internal namespace like SMPJson to avoid conflicts. For example, DropboxSDK also uses SBJson as DBJson.

@mollidor
Copy link
Contributor

Hi Tomasz.

Thanks for your feedback. We will look into this in an upcoming release.

Regards,
Lukas

mollidor added a commit that referenced this issue Sep 2, 2015
Rename SBJson to avoid conflicts.
Fix #1
@mollidor
Copy link
Contributor

mollidor commented Sep 2, 2015

Hi Tomek.

Can you check if 1.2.1b1 fixes this issue?

Thanks,
Lukas

@thom-ek
Copy link
Author

thom-ek commented Sep 10, 2015

SBJson conflict is ok now, but now I've found another conflict on base64_encode with another lib which I use (fortunately I have source code for it and I change that function name). SDK is working now.

@thom-ek thom-ek closed this as completed Sep 10, 2015
@mollidor
Copy link
Contributor

Hi Tomasz.

Glad to hear. Which base64 method is in conflict? Should be easy to fix on our side and will probably be in conflict for other devs, too.

@thom-ek
Copy link
Author

thom-ek commented Sep 11, 2015

It's base64_encode() :)

@mollidor
Copy link
Contributor

We are using a copy of this category: https://github.com/l4u/NSData-Base64/blob/abeb10cfdbe5c2c3f16ed45f2a7f2b5094f097dd/NSData%2BBase64.m

Is this causing the conflict for you?

@thom-ek
Copy link
Author

thom-ek commented Sep 11, 2015

Yes, I used exactly same category, but this was very easy to fix at my side. Other conflict was with zbar and I had to recompile zbar.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants