As part of the UCOSP program, Dom from the University of Calgary spent part of the past term setting up a test application and figuring out how to make this work, in addition to some other work. Here is his account of the term:
In late August 2014 I was frantically looking for a course to complete the requirements for my undergraduate degree at the University of Calgary. Classes had filled up and I was in need of a fourth year course in order to avoid having to take an extra semester to wrap up my degree. Fortunately, as I was just about to give up on my search I was presented with an opportunity to take part in something called the UCOSP. As spots were filling up quickly (only 3 students would be able to go from the U of C), I jumped on the opportunity to take part in something that would not only give me the credit I needed to complete my degree but also something that would teach me some valuable lessons in software development to take with me into the workforce.
Armed with only the advice that previous students who took part in the UCOSP wrote on the website, I headed to the code sprint a little nervous as I had no idea of what I would be getting into. I had signed up to be part of the BlackBerry team but I was not aware of exactly what I would be working on for the term. As I was introduced to the team however, I immediately knew that I was going to be in good company and at the very least I’ll have some great teammates to work with throughout the term. After a positive experience at the code sprint, I walked away with an understanding of the purpose that the WebWorks framework served as well as the general structure of a plugin so that I could start working on my first project: adding in support for some of Facebook’s native dialogs for the Facebook Connect plugin.
After putting the finishing touches on my little corner of the Facebook Connect plugin, I was now ready to take on my next project, a sample app to serve as a proof of concept for running PouchDB on a BB10 device and connecting to a Couchbase Server via a Couchbase Sync Gateway. In typical fashion I wrote code and deployed it to the device for testing, making sure I was positive that any new code I wrote was functioning properly before I moved on to the next. As time went on, the bugs and errors began to really pile up. Conflict errors were happening on almost every get/put operation to the database, and I wondered how this could be, given things had gone so smoothly before. More specifically, how does an empty database return conflict errors if there is nothing to be in conflict with? As I later found out, the database was in fact not empty at all. Before this I had wrongfully assumed that restarting the app and creating a new instance of the local database would give me a fresh clean database. Instead, what was really going on was PouchDB was pulling the same database instance every time I called the create method. Why? Well the whole point is persistent data storage should be persistent; after all, this is the entire point of persistent storage! It would be counter intuitive for PouchDB to create a new instance every time the app was updated as users would essentially lose their settings after every restart… Another valuable lesson learned: persistent storage is persistent. Okay, maybe that one isn’t as applicable as the last, so let’s try: even though your code passes your test cases, it doesn’t mean your assumptions are correct for future implementations.
Dom’s sample project has been contributed to our sample repository, where you can take a more detailed look and try it out. This is the first post detailing the work done this past winter term with UCOSP, and we’ll be following this post with more on what the students accomplished. If you are interested in following along with the student project, watch #bbucosp on twitter. All of the code will be going into the public BlackBerry repositories on GitHub. If you want to get involved yourself, contact me to get started: @timothywindsor on twitter, https://github.com/timwindsor on GitHub.