Hey guys,
So I just looked into it and we've got an interesting issue to resolve. If you build the sample app in release mode (or your app) with the photo browser library, you will not face any issues. But if you build it in debug mode, you will get the error you reported.
The issue is because when I was developing the B4i wrapper for the MWPhotoBrowser library, I realized that there is a conflict with an internal library of B4i, called iDebug. iDebug relies on MBProgressHUD to present the progress dialog while we are debugging an app. This class is also used internally by the MWPhotoBrowser library to present progress dialogs. So when I was building my app in debug, I was getting the above reported conflict. In order to resolve the conflict at debug time, I compiled the MWPhotoBrowser library without the header file that containes MBProgressHUD related classes. This resolved the issue for debug.
The story didn't end there unfortunately. When I compiled for release, I got an error where the compiler complained that the linked library MWPhotoBrowser did not have the said interfaces declared. So to fix this I added the MBProgressHUD.h back to the MWPhotoBrowser library, and the release worked perfectly.
The short story is that it seems quite complex to resolve this issue. This is because when we compile for release, classes in iDebug.a do not end up in our apps(this is what I believe happens) so the linker cannot find the MBProgressHUD classes which in debug mode were provided by iDebug.a library. So what I have done myself now is to have two versions of the MWPhotoBrowser library(.a files): one that I use for debug and the other that I use for release.
I understand that this solution sucks as far as technical grace goes. Its ugly and will not work with hosted builders. I have a few solutions in mind and am open to discussing them and working on them with you guys, :
- Build a debug version of the library that you will use in your project while debugging but switch to the release version when you want to release the app. So you will have an HHPhotoBrowser-Debug and HHPhotoBrowser-Release available in your B4i IDE and you use the one depending on your deployment cycle. An ugly solution in my opinion but hey, we're dealing with a dog of a situation here
- Use a local mac builder and swap/replace the debug version of the libMWPhotoBrowser.a file depending on whether you are compiling for debug. So in your mac builder's lib folder, you will have two libMWPhotoBrowser.a files, with one named -debug.a and the other just named libMWPhotoBrowser.a. Again an ugly option.
- I will try to work on creating a wrapper for another photo browser library but this photo browser in my opinion is the best and the most widely used in my research.
- The final I can think of is for asking Erel to help us out with this Perhaps he can find a way to conditionally load the MBProgressHUD related classes from the iDebug.a if required? Not sure.
I am attaching a version of libMWPhotoBrowser.a Please rename it so you remove the -DEBUG from the name and use it in your local mac builder when you build for debug. Later, when you want to buld for release, you should copy the original libMWPhotoBrowser.a and save the debug version by renaming it again -DEBUG. Yuck....
Let me know how you guys get along and let's try to find a solution.
Link to library that you can use in debug:
https://drive.google.com/file/d/0ByDFbtVDbyXZamRta3hXd2thcW8/view?usp=sharing
Best,
Harris.
