Tagged: xcode

Connected Wellness: Build problems..

For the last week I’ve been trying to fix some Xcode build problems that we’ve been having. After I upgraded the project to 2.3 Carl tried to run it on the simulator and it didn’t work. After doing a lot of digging I figured out that I only provided an armv7 static library of Cordova. What this meant was that we couldn’t run it on the simulator because it runs on the Mac which uses an x86 processor. What I ended up having to do was add two versions of the library to the project, one compiled for x86, and one compiled for armv7, and then make the project conditionally link them in based on if we were building for x86 or armv7. This was kind of tricky because I didn’t know at first how Xcode manages this stuff. I finally discovered that you can add a build condition underneath other linker flags in the target’s properties that will allow you to do this.

After this was all done I had to take care of adding in the 2.3 version of the AppDelegate and ViewController because these weren’t in the project when I switched over to 2.3. They had been taken out, by me I believe, I forget why. Once that was done I began to get some problems with the linker not being able to resolve some of the symbols in the Cordova library that had to do with extending classes. Fixing this required me to add “-force_load” to the linker flags. This specified to Xcode to load the entire library, whereas if you don’t put that, its default mode is to not load extensions… strange.

There’s still one last problem with the build that Carl has informed me of. The problem isn’t currently surfacing on my own machine so we’re going to have to do some more digging.

Final, thing that I did was attempt to simplify the Command hierarchy by making ReturnableCommand just a Returnable and then having BluetoothCommand implement the Command protocol. This simplifies it a little because ReturnableCommand no longer has to be an abstract class. It also makes sense because an object that is returnable to the Cordova library isn’t necessarily a command. This way in the future it will be possibly to have many different types of objects be able to return a plugin result back to Cordova.

Connected Wellness: Upgrading Cordova 2.0 to 2.3

We’ve gotten quite a lot of work done this week in the Connected Wellness project. However, we’re getting close to a point where we might not be able to do any work until we get Apple Developer licenses. Most of the preliminary development has been done and we now need to start testing cod; to do that we need those licenses! I heard from Carl that it’s being worked on and we should have them soon, so I’m hopeful.

Other than that we had a big review on Catilin’s packet parser implementation. I probably spent a few hours just reviewing that alone. I also went around cleaning up a few of the issues such as removing commands that we aren’t able to implement yet due to not being able to fully control Bluetooth on Apple Devices and implementing the last few commands.

The biggest thing that I’ve done this week is to include the Cordova library into the mercurial repo and get it set up so that it is incorporated into the Xcode project out of the box. This way we don’t have to set it up manually every time we clone a fresh repo (that was getting tiring). It took a little bit of figuring out how to do this, but what ended up working was to include the library file along with the header files of the library (Apple requires header files for statically linked libraries to be somewhere in the project). After I did this I needed to add the folder that holds the library and header files to the required frameworks list of the project, modify the header search paths to include the directory where the library’s headers are, and set the linker up to link with the library by giving it the path to the .a file. All these options can be found in the “build settings” tab of the build target in Xcode i.e. the project file.

After I got the library incorporated into the repo I went about moving our current code to support Cordova 2.3 (we were on 2.0 before). This proved to be very easy. The only things that changed were the include paths of the Cordova headers when #import-ing them, the function signature of the method that Cordova calls in the plugin, and the way that Plugin Results are passed back to Cordova. It was actually easier moving to 2.3 than it was to code 2.0 because they’ve made it a lot more easier and intuitive to work with.

You can check out that code in the pull request here.

After that pull request lands there’s only going to be one last thing to code – the stopListeningCommand. That will probably not be hard. I’m hoping that we will be able to get those Apple Developer licenses early next week so we can continue powering through this. It is due by the end of February…