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…
We’ve gotten a lot done in the last week for the iOS port of the Bluetooth Plugin. You can check out my work here.
- I’ve finished the MedicalDevicePlugin class.
- Wrote the Command Protocol.
- Wrote a template for the ReturnableCommand class.
- I started on the WorkQueue class, but Carl told me to shift from that to the Invoker class because WorkQueue will be removed sometime in the near future.
- I also wrote the Invoker class but left out the bulk of the implementation as it uses the WorkQueue, so there is no point to code it for now as I don’t know what kind of design we will be using.
- I’ve also pushed a lot of bug fixes to the repo.
Objective-c vs. Java
There were a lot of changes going to iOS from Android. The biggest one was that a lot of the architecture and functions of the Cordova Library in iOS are different than in Android. They still follow the same idea, but are different in implementation. Most of the functions in Android have an iOS equivalent. One of the ones that do not is onActivityResult() in the DevicePlugin implementation. I’ve talked with Carl about this though and it seems that it won’t be that big of a deal since we are planning to remove that function in the future. It seems to me that the Cordova Library for Objective-c is a lot more immature then the Java one. You can see this in the fact that going from version 2.0 (the one that we are using) to 2.3, most of the Objective-c code changes, but almost nothing from the Java code does. This indicates that there is still a lot of work to be done on the Objective-c library. I’m not complaining, but the Java Cordova Library just looks so much nicer.
Another thing that is a lot different are language specific things. For example in Objective-c you cannot specify the visibility level (i.e. public, protected, private) on member functions, and you can’t specify static member variables in exactly the same way as Java. This isn’t a big deal, but it is one of the many things that must change from going to Java to iOS. Another, rather concerning, thing that is different is that Objective-c offers no way to synchronize entire functions. This is a problem because this design paradigm is used a lot in the Java plugin. We will have to find a way around it in Objective-c.
- Caitlin has currently been tackling the BluetoothServer class as well as doing the full implementation of the ReturnableCommand class.
- Vince has been working on the PacketParser implementation. I haven’t heard much from him this week, but I hope he has been making good progress.
After Caitlin gets the ReturnableCommand landed we will be able to start implementing the concrete Command objects that inherit from ReturnableCommand and begin to tie the commands into the Invoker as well as the MedicalDevicePlugin class. I’ve taken on writing the isSupported(), isEnabled(), and isDisabled() commands. Everything is looking good so far baring the problem we may have with the Bluetooth Protocols…
Recently heard from Carl that I should be implementing threads in Objective-c in the Invoker class. It’s up to me how we get that done. So I will be working on that before continuing the Command implementations.
So I’ve started a new job here at CDOT (Seneca’s Centre for Development of Open Technology) and the first project that I’ve been assigned to work on is a project called Connected Wellness that is being done in collaboration with NexJ and other colleges. I’m on a team of three who will be porting the current android Bluetooth plugin over to iOS. I will be blogging a lot about this in the next two months since the deadline for it to be done is the end of February.
What I’ve been doing so far is setting up my development environment and getting acquainted with Mercurial which I have never used before. I’ve started work on the MedicalDevicePlugin class which will be the entry point for Apache Cordova to the plugin. I’ve also ported over the basic outline for the Command interface and inheritance structure in order for me to be able to reference them in the MedicalDevicePlugin class. Everything for my part looks like smooth sailing so far. The only thing I’m worried about is getting the Cordova library to work properly in iOS.
My teammate, Caitlin, has recently blogged about troubles with the current libraries we are using for the Bluetooth protocol not supporting the specific devices we want to interface with. Hopefully, we will be able to work around this. My first thought is to use an open source Bluetooth library for iOS, that is if Apple even lets outside frameworks access the Bluetooth hardware directly in some way.