It’s story where a little task causes an interesting trip through several open source libraries and programming languages. I’d like to mention that the text below is not the nagging about others’ or my code quality but just a yarn about how things are highly connected and how challenging and fun unraveling these links and finally solving a problem.
I’ve got an iOS app - Moulinella. It’s a cross-platform app written on Haxe using OpenFL and JiveUI frameworks and run on iOS, Android and in the web. I needed to support a document opening feature. So other apps could send specific files to my app.
First of all I’d found a great tutorial about document sharing on iOS. There was some changes to XCode project but using OpenFL’s templates I did in the past. It was OK. The main code changes were related to UIApplicationDelegate. This part was several layers deeper than my app’s code. I hoped that OpenFL team passed this feature closer to me. It was a bit hard to find but they did it. Singmajesty mentioned on the forum that there is lime.ui.Window.onDropFile event already, thanks to SDL library. This event provides an URL of a file that is passed to an app on iOS. Great! Here we can see two more layers:
Lime - a foundational Haxe framework for cross-platform development. It provides the wrapper code for different platforms so it’s written on Haxe, C++, Objective-C and Java. It’s a base for OpenFL.
SDL - Simple DirectMedia Layer is a cross-platform development library designed to provide low level access to audio, keyboard, mouse, joystick, and graphics hardware via OpenGL and Direct3D. It’s base for Lime and written mostly on C;
Try #1: Code was written, compiled, run but didn’t work well! Nothing happened.
Oh, I forgot that I’d replaced SDL’s UIApplicationDelegate by mine already. It was needed to implement third party authentication: Facebook and VK. So the code related to the onDropFile event just wasn’t run. OK, let’s call SDL’s code from mine. So I’d just added a small piece of Objective-C code.
Try #2: Code was written, compiled. I’d got an error from the linker - my code couldn’t find symbols for SDL’s code.
Maybe the Lime library compiled badly (I’ve got the latest dev version of Lime) and doesn’t have corresponding symbols. Let’s compile Lime. Hm! Lime can not be compiled! I definitely did something wrong. After investigation the wrong part was an updating hxcpp library to the latest version. It emerged that the Lime dependents on some part of Hxcpp that was deleted as unused. I had a hack and reverted that changes for me for now and informed the Lime team about an issue.
Try #3: Lime compiled. But I still got an error from the linker - my code couldn’t find symbols for SDL’s code.
Here I have to say that I’m not experienced C++ developer so didn’t find the cause earlier. After a quarter of an hour or more of googling why C++ linked could find symbols I learned that if the symbols were written on C it needs to link them differently (using extern "C" linkage-specification). So I’ve added the wrapper to my code.
Try #4: Code was written, compiled, run and worked great!
I was extremely happy that the problem was finished successfully!
Now I’m thinking how I should perceive described situation. Firstly, I was losing time not doing something valuable for my customers but just fixing my faults. Secondly, it was an opportunity to understand better how the app works on the different layers and increase the code quality. Finally, the software is a complex thing and it’s tough to deal with it.
When I spent several hours and went through several layers of the framework code I had a moment of satisfaction thinking how big and complex the modern software is but we (developers) can handle all this information structure. At that moment I realized how much I love and proud of my profession because it can give this kind of emotions.
I hope you feel the same.
Top comments (0)