UCOSP brings together students from coast to coast to work together on joint capstone projects. Students learn first-hand what distributed development is like. Each team has students from two or three schools, and uses a mix of agile and open source processes under the supervision of a faculty or industry lead. Find out more about UCOSP.

Latest news

Developing for Blackberry Cordova on Linux

James Wood from Waterloo is working on Blackberry Cordova plugins on Linux and provides this reference for future developers who are trying to do the same.

History

As of this writing, Linux is not supported by Blackberry for development, which means if you are reading this, that you have chosen to walk the difficult path. The good news is that you won’t be alone, and hopefully this guide will help get you started. The bad news is that a similar guide was written about four months before this one that was already so far out of date by the time I began working the BB10 Cordova, that it was of no use whatsoever. As a consequence, I fear that portions of this guide may also be obsolete by the time you need it. If so, let’s hope that this is because Blackberry has decided to fully support Linux, and a guide like this is no longer needed at all.

Let’s get down to business then.

Preflight Checklist

Before we begin, this guide makes some assumptions about you, the reader:

  • You have some idea of what an extension is and does, and moreover, why you want to write one.
  • You have a github account, and you have already forked the WebWorks-Community-APIs repository.
  • I am using Ubuntu 12.10, and you are (obviously) using some version of linux. Where things might differ between us, you can handle yourself.
  • You are working on a machine for which you have administrative rights.
  • You have a BB10 device with which to work. I am using the Dev Alpha C model myself.
  • Your device has the latest OS installed.
  • You have a Blackberry ID set up already. If you don’t, you can do so from your device directly, although you’ll need an internet connection.

The Guide

Step 1: Momentics Installation

  1. Download and install Momentics SDK from
    https://developer.blackberry.com/native/downloads/
  2. Go to the directory where you saved the binary, chmod it to be executable, and run it (as yourself, not as root)
  3. I recommend you use all the default settings, unless you have a good reason not to.
  4. Allow Momentics to run after the installation is complete. If you don’t, you can always start it from the terminal: ~/bbndk/qde (assuming defaults)
  5. On startup, it will attempt to find your device. Let if fail, and see Step 2. If you don’t have one, you can ignore this and always deal with it later.

Step 2: Device Setup

  1. Turn on your device, and go to Settings->Storage and Access
  2. Set the USB connection to “Connect to Mac” (see image below)
  3. Go back to Settings->Security and Privacy
  4. Scroll all the way to the bottom and select Development Mode
  5. Turn on development mode (see image below)
    • This requires the device password, which I suggest setting to something very simple while you work
    • Note that development mode automatically turns off when the device restarts, or after 2-3 days
  6. Connect the device via USB cable, and on Momentics click “Try Again”
  7. Enter the device password when prompted
  8. Install the recommended API level, and go get a coffee (this takes a while)
  9. If prompted about installing debug stuff, do so, but then do not click restart until it completes (see image below)
  10. Click restart, but don’t expect it to actually open again on it’s own.

Step 3: More Momentics Setup

  1. Open Momentics: ~/bbndk/qde
  2. Go to the menu: Window->Preferences
  3. Choose Blackberry->Signing from the panel on the left
  4. Enter your Blackberry ID password and click “Get Token” which will make you actually sign in with your Blackberry ID
  5. Once successful, click “Create Certificate”. You should no longer see a warning at the top of the page.
  6. Exit Momentics.

Step 4: Install Node.js

  1. If you aleady have this, then go to step 5, otherwise enter the following commands from the terminal:
  2. sudo apt-get install python-software-properties python g++ make
  3. sudo add-apt-repository ppa:chris-lea/node.js
  4. sudo apt-get update
  5. sudo apt-get install nodejs

Step 5: Install Cordova

  1. sudo npm install -g cordova
  2. You may need to add /usr/local/share/npm to your $PATH, but I had no issues without doing this.

Step 6: Clone the WebWorks-Community-APIs repo locally

  1. Make a directory where you want to put it. I made ~/UCOSP since I was doing this for the UCOSP.
  2. cd ~/UCSOP
  3. git clone git@github.com:your-git-username/WebWorks-Community-APIs.git

Step 7: Environment Variables

  1. cd ~/bbndk
  2. ls
  3. Notice the file “bbndk*.sh” (see image below). I found that actually running the script did not do as intended, but simply sourcing it was sufficient:
  4. source bbndk*.sh
  5. You must do this every time you open a terminal to work, so you might as well add line 4 to you .bash_profile or similar file.

Step 8: Running the Template Sample App

  1. cd ~/UCOSP/W*/BB10-*/T*
  2. cordova create sample2
  3. copy the www folder in /sample to /sample2, and overwrite anything there
  4. cd sample2
  5. cordova platform add blackberry10
    • This is most likely fail. If not, go buy a lotto ticket.
    • The easiest solution is to change ownership of ~/tmp to yourself instead of root, then try again.
    • If you find an alternative solution, please document it, and let us know.
  6. cordova plugin add ../plugin
  7. cordova run sample2
  8. Your device will eventually start and app called “Cordova3″
  9. Click “OK” on the Web Inspector popup
  10. Scroll down to see the test output from the app
  11. Congratulations, the hard part is over!

What’s Next?

The sample app uses the Template plugin to make several different types of Javascript calls to the native-level C++ underneath. To make your own extension, copy the Template directory, and use it as a basis for your work. Read Template/README.md for more information. Good Luck, and Happy Coding.

Initial UCOSP Report

Hi! My name is Brandon Noad, and I am a Computer Science student at the University of Waterloo. This term I was selected to participate in the UCOSP program where I get to work on an open source software project with other students from around the globe—for credit!

The project I was assigned to is called GeoTrellis. GeoTrellis is a Scala library and framework for creating useful, high performing web services that load and manipulate raster data (visit the GeoTrellis documentation and GitHub pages for more information). You can check out a cool example of GeoTrellis in action here.

In the past few months, I have completed Coursera’s “Functional Programming Principles in Scala” course, written a web application in Scala using the Play framework, and attended several local Scala Meetups here in Waterloo. I really enjoy programming in Scala, and GeoTrellis was at the top of my list of project choices because I wanted to continue to improve my Scala programming skills. Although I had very little experience working with geospatial data, I was able to get up to speed quickly with help from my project mentor Rob.

To prepare for the UCOSP Winter 2014 code sprint, I completed the following list of tasks:

  • Forked the GeoTrellis repository (my fork).
  • Built the project using sbt and ran the unit tests.
  • Submitted a pull request to fix a typo in the README.
  • Created a new test file containing a FunSpec test with ShouldMatchers that runs a single unit test. This test creates an Array of 100 random integers, sorts the array, and checks to make sure that for every i, j in {0 … 99}, if i < j, then array[i] < array[j], where array[x] represents the xth element in the sorted array.
  • Completed the GeoTrellis web service tutorial.
  • Worked on one of the project’s issues (#678).
  • Submitted a pull request to fix issue #678.
  • Read chapters 1-15 of “Programming in Scala”.

This term’s code sprint took place at Facebook HQ in Menlo Park, CA. It was my first time in California, and although California is supposedly in the midst of a drought, it rained for most of the weekend. That said, I was just happy to escape the polar vortex, so I wasn’t going to let a bit of rain ruin my trip. At the sprint, I had the opportunity to meet my project mentor, Rob, and the other students working on the project—Mitch (UBC), Jonathan (MIT), and Armstrong (BU). Overall, I had an amazing time. Besides coding alongside my teammates, I listened to a couple of engaging talks by Scott Chacon and Jay Borenstein about GitHub and startups respectively, visited Stanford’s beautiful campus, ate a lot of beef jerky (mmmmm), bowled my first turkey, and had a cup of tea in downtown San Francisco.

One of the challenges for the sprint was to identify an action plan for the rest of the term. My task is to implement a Scala wrapper for the JTS Topology Suite that facilitates vector to raster operations. By using Scala language features such as sealed classes, we can leverage the power of Scala’s type system to make working with vector data much more enjoyable for developers. Rob thinks that if we design and implement this wrapper well, it may become the “go-to” solution for working with vector data in Scala. Once the wrapper is complete, the next step is to create a Feature library on top of it to replace the existing suite of vector operations in the main GeoTrellis project. At the sprint, I began working on the wrapper and submitted a pull request after implementing intersection, union, and difference methods for the various geometry types. It’s exciting to be working on such a meaningful project.

The GeoTrellis team uses a fairly standard Git/GitHub workflow. We create topic branches off of master for the issues/features we are working on, and we commit to the topic branches locally as well as regularly push any work done to the same named branch in our forked GitHub repo. After hearing Scott Chacon speak at the sprint, Rob decided it would be a good idea to open pull requests as early as possible (e.g. after your first commit). These pull requests then act as a form of code review, allowing us to communicate and receive feedback about our work. Once our work has been reviewed and approved, it can be merged into master.

To keep in touch with Rob and the rest of the team, we have a weekly standup meeting via Google Hangouts. GeoTrellis also has an IRC channel (#geotrellis) on freenode and a mailing list.

If you have read this far and are still wondering if you should apply for UCOSP next term, the answer should definitely be yes! Meeting and interacting with the other students at the sprint was an amazing experience, and my confidence that I belong alongside other software developers has grown as a result. Having the opportunity to do version control, unit testing, and code reviews on a real-world software project has been an invaluable experience so far, and I am certain that my skills as a developer will continue to improve throughout the rest of the UCOSP program.

Review Board projects from the fall

Check out the demos that students working on ReviewBoard created in the fall term.  Great work!