David's Blog

projects from my internship at Progress Software

Month: August, 2014

Provisioning an iOS App for Ad-Hoc Testing

So you’ve written a hot new iOS app and tested it on your personal device, and everything seems to be going smoothly so far. But now, before you take the plunge and submit it to the App Store, you want to share it around with a few friends to get their feedback. After googling around for a few minutes, no painfully easy method for doing this jumps out at you. Unfortunately, Apple’s provisioning process is pretty complicated, but I’ll explain how I did it for my project to hopefully make the process smoother for you.

First, you’ll need to talk to all those friends and ask them for their device’s UDID. The easiest way to do this is to plug your device into a computer and open up iTunes. Navigate to the ‘summary’ page for your device. Directly to the right of the phone image should be a line that begins with ‘Serial Number’. Click on Serial Number and the info will toggle to the UDID. It should look something like this:

Screen Shot 2014-08-20 at 1.39.28 PM

You’re not gonna get my UDID that easily!

Once you have the UDID, you’ll need to register it under your approved devices list on your developer account. Go to your account here, then click on ‘Devices’. Click the plus button to add the new device, using the UDID you collected from earlier.

Now you’re ready to create an ad-hoc distributing profile, which is basically an authorization that allows you to run an app on an approved device. Go back to your apple developer account, then navigate to Provisioning Profiles. Click the + button to add a new profile, select ‘ad hoc’, then navigate through the other menus to create your profile. Make sure all the devices you just registered are checked when you get to the device authorization page. Once the provision is created, download & double-click to install it. Then, open Xcode, navigate Xcode → Preferences → Accounts, click on your account and hit View Details, then click the little refresh button in the lower left corner. The provisioning profile you just created should show up.

Now you need to generate a build of your app that your users can run on their devices. Still in Xcode, scroll through the list of available run targets in the upper left corner until you select either “iOS device” or your plugged in device (basically, the option that isn’t a simulator). Navigate to Product → Archive. A window showing your archives should pop up.

Screen Shot 2014-08-21 at 4.23.19 PM

Select the archive you just made, then click Export → Save for Ad-Hoc Development. Navigate through the menus, which will result in your creating a .ipa file. This is an iOS Package file, used to distribute your app.

Your friends can install this package on their device by plugging their device into a computer running iTunes, then double-clicking on the .ipa file. In iTunes, click on the Apps button that shows up next to the device details. Your app should be somewhere in the list of apps on the left side of the screen. Click on your app, hit install, then hit sync. The app should now be available to run on the device!

If you get stuck anywhere in this tutorial, Apple has published their own App Distribution Guide. I found it pretty difficult to follow, but it’s more thorough than my quick tutorial here so it could well cover some case I glossed over.

Displaying OpenEdge Data in an AngularJS Web App

For my next project I was tasked with displaying data from a backend OpenEdge service on a modern web app built on AngularJS. As is often the case, Node.js is the perfect middleman to bridge the gap between backend and frontend. OpenEdge data can be accessed from Node using a Javascript Data Object (JSDO). I initialize the JSDO within a server-side instance of Node and then populate it with data from an OpenEdge temp-table using the JSDO.fill() method. In just a few lines of code the JSDO can be converted into an array of javascript objects, each object containing several key:value pairs representing various properties of each entry in the database (in this case I had a list of companies, with data fields like street address, city, state, and zip code for each company).

 

Once the data is in this array form we are back into a more typical use case of Node and Angular within the MEAN stack. I make the data accessible from Node through a RESTful API using Express. Angular accesses the data by sending a GET request to Node, which responds with a string form of the array. Angular receives this response and formats the data in an HTML table using the ng-repeat directive to iterate through the array. Note that by default, client-side Javascript can only send requests to endpoints on the same server as a security measure, so I had to enable Cross Origin Resource Sharing (CORS) on both the client and server side of the project in order for Angular to make an HTTP request to the remote Node server. With this in place, our stack is complete:

Screen Shot 2014-08-19 at 4.35.55 PM

Project Architecture.

One of the goals of this project was to host everything on Modulus, so I had to find some way to serve static web content using Node. Luckily, there’s a Node package exactly for this purpose (it seems there always is). Called Serverfy, you can simply run this package in your directory of static web content and it automatically re-formats everything into the Node application format. In a nutshell, it utilizes the node-static module to format the server correctly, then responds to each GET request for page data by serving the entire HTML file as a response. My (very simple) data table is pictured below, but once you have the data it’s easy to dress it up with a nice UI and display it in a visually appealing format to the end user.

Screen Shot 2014-08-19 at 3.52.09 PM

Data Table in Angular

 

 

Full Hue Control Outside Of The Local Network

As I mentioned in my last post, the Philips Hue system has the design limitation that it can only be controlled while connected to the same network as the bridge. Personally I turn off my phone’s wifi while on-the-go to save battery, and I don’t want to have to turn wifi on each time I come home just to control my lights. Or maybe I’ve just left the house and forgotten to turn the lights out, but am not quite in wifi range anymore to control them from my phone. Whatever the reason, there’s no point in saddling the Hue service with this network limitation when the technology exists for an easy fix.

My last project already demonstrates that it is possible to control the Hue from outside the local network. However, it was only performing two very specific actions with the bulbs: changing color to red/green and blinking the lights a few times. For this project I set out for full control of the lights: changing their color, brightness, and saturation, as well as being able to blink the lights or switch them to ‘gradient mode’, where the light slowly cycles through its color spectrum. This is pretty much the extent of the Hue API, and I wanted to control it all from one simple app.  

The architecture for this project is pretty much identical to the last project. The iOS app sends instructions to the Modulus Node server, which updates its Mongo database. Every few seconds, the local Node server, hosted on the same network as the bridge, pings the Modulus server, which queries the database and returns its contents. If the database has been updated since the local Node server last checked, it will parse those updated contents and send the appropriate update instructions to the Hue bridge. The Hue bridge then updates the lightbulbs. Here’s the architecture diagram:

The architecture diagram for the project.

The architecture diagram for the project.

As there wasn’t too much architectural innovation to figure out for this project, I decided to polish it a bit and streamline a few elements of the system. I stopped hosting the local Node server on my laptop, since I would have to restart the server each morning when i brought my laptop in. Instead, the server is now hosted on a BeagleBone Black, a pocket-sized microcomputer running the Angstrom Linux distribution. The BeagleBone is nice since it supports Node out of the box, but you could switch it out for a Raspberry Pi or Arduino and achieve the same result with a bit more legwork (node.js on Arduino likely requires a bit of hacking). To the BeagleBone I added a system daemon startup service that runs the service upon booting, which means the server can now run 24/7 with no human involvement.

IMG_0011

The BeagleBone in action

In addition, I’ve added a security layer to the project so some random person reading over my code couldn’t just bombard my server with http requests and cause the lights to freak out. Now, each request is authenticated with the server before being processed. Right now I’m just using a simple app key to authenticate requests since the system is built for use on one single Hue bridge, but if I were to expand the server to support multiple users and multiple bridges I would likely use passport.js to authenticate multiple users.

One other thing of note is that I’m running both the Roll Call and Hue Controller apps in one single Node.js server hosted on Modulus. Because Node is non-blocking, the two programs can coexist side-by-side and the server can handle simultaneous calls to both processes without any problems. Of course, when multiple requests are being sent rapidly to the Hue bulbs they might appear to be acting strangely to the user, but if I were using separate bulbs for each project you would never know the two were sharing a server. 

To finish, here’s a screenshot of the app in action:

IMG_0010