Tagged: phonegap

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…

Connected Wellness: Threads, Cordova Lib, and Java to iOS

So it’s been another eventful week for the Connected Wellness iOS team at CDOT. We’ve made a lot of progress towards having the project completed, but there are still some major outstanding issues that we need to tackle. The PacketParser has yet to be completed (one of the most complex portions of the plugin), we’ve still yet to hear back from A&D about low energy BT devices, which we need in order to use the CoreBluetooth framework provided by Apple, and we’re still running into some problems regarding the amount of control that the CoreBT framework gives us. The CoreBT framework does not expose a way to start, stop, or enable Bluetooth in the device. These are all things that the Android plugin is able to do. Although it is not completely necessary to implement these (the user can start it manually) it would be nice to provide it to the user as a convenience.

Threads

To continue my discussion from last week in regards to the Invoker and dispatching Commands asynchronously on threads – it has been ridiculously easy to implement this. Instead of going through and creating our own WorkQueue and thread management classes I’ve implemented NSOperationQueue and NSInvocationOperation inside of the Invoker class. NSOperationQueue is provided by Apple and has all the functions to properly manage thread execution on a work queue and NSInvocationOperation allows us to specify the target and selector that the threads started from the work queue will invoke. Check out how easy it was to do here.

Cordova Lib

During this last week we ran into a big problem of everyone checking code into the repo that wasn’t compiling or causing problems. Yesterday I went through and fixed all the compilation problems. We’re planning to have a more strict review process in the future. One of the major problems that I encountered was the Cordova Lib not being properly compiled and linked to the project. This was caused because for some reason Cordova 2.0 doesn’t support armv6, so I had to remove that from the Cordova project as well as the iOS port project. The other big issue is that currently the Cordova library is not included in the repository. This means that when a fresh copy is cloned you have to go through the process of manually downloading PhoneGap and incorporating it into the project. So in the next day or so I’m going to set up the repo to include the compiled archive and point the project to it by default.

Java to iOS

The other major problem that I ran into this week was specific to the port from Java to iOS. In the Java version the concrete commands reside as inner classes in the DevicePlugin class. Due to this they all have access to the BluetoothServer stored within the DevicePlugin class. Moving over to iOS we cannot use inner classes and so the commands need to be provided with access to the server in some other way. To compensate this I’ve introduced a new command, BluetoothCommand, which sits between the concrete commands and the ReturnableCommand. BluetoothCommand exposes the base plugin in the ReturnableCommand as a MedicalDevicePlugin as well as exposing a property on it to access the BluetoothServer on the MedicalDevicePlugin. You can check out that here. Now that I’m thinking about it a BluetoothCommand doesn’t necessarily need to work with a MedicalDevicePlugin… what we’d need to do then in order to abstract it more is to create a base class like BluetoothPlugin that will expose a BluetoothServer property. I don’t really know if we should do this though as I’ve read a lot recently about the dangers of over designing code. I’ll post back next week about what comes from this.

Next Week

By the end of next week I’m hoping that we have most of the pieces in place to start testing. The PacketParser will be done and the few other commands that are left to be implemented will be done. Personally I will be working on some of the outstanding commands such as the listen and isSupported() commands.