Skip to content
Apr 3 / Brett Brainerd

API Integration

I decided that writing a completely separate ProjectPier API for our android app had to be the wrong decision considering the maturity of ProjectPier.  Besides, I really didn’t feel like spending the afternoon writing a bunch of, likely redundant, wrapper methods for raw SQL queries.  So, after spending a couple of hours digging through ProjectPier’s guts looking for a reasonable integration point I discovered the beginnings of an API controller.

The controller itself was abstract and did next to nothing but it prompted me to investigate it’s inheritance.  It appears the unfinished ApiController class represents a split from the main dependency of ProjectPier controllers.  Namely, controllers that will gather object data and drop it into a template to be human-viewable from a browser.  The ApiController path will instead take object data and then output a condensed and strictly structured response for later manipulation by the requester.  For our android client use we’ll be requesting the output in JSON formatting.

For starters I came up with a simple controller of my own to retrieve the list of projects.  Here’s a simplified UML diagram of the controller hierarchy and where my API implementation now exists.

UML Integration Point Diagram

Mar 27 / Brett Brainerd

Android App as a Client to Web App

There is little argument that the most popular use of Android apps is to interact with previously existing web resources and this makes sense.  They provide immediate value and benefit if the end-user is already a frequent visitor of the browser-based service.  Following this model seemed to be a great way to enter into the Android development world and as such, I believe it be a reasonable choice for a class room project.


Ruth Waite and I decided to work on a client app for the open source project collaboration and management suite, ProjectPier.  ProjectPier is a web-based application released under the AGPL and is written in PHP.   It doesn’t contain a API for accessing data objects and structures specifically so we’ll be creating one as we go along.  But, for the scope of this project the focus will be on Android programming practices and the web API will only need to be strictly functional.


For a high-level overview of the project take a look at this document:  ProjectPier Client Overview PDF

Nov 21 / Brett Brainerd


The main goal for the Embedded System Project is to create a cataloging and warehouse application in which an end-user is able to simultaneously interact with a digital record and it’s associated physical object.  The object can be a tagged standalone item or a tagged container containing tagged and/or untagged items.  The objects will be tagged using radio-frequency identification and read using a USB connected RFID reader that will be manipulated by the user’s hand.  To simplify operation, the user will wear a custom suit that contains the hardware and provides appropriate mobility for the desired functionality.

To accomplish the overall functionality, the project is being split into seven components with varying priorities:

  • Custom OS Image – Required
  • RFID Reader – Required
  • User Interface – Required
  • Custom Hardware Suit – Ideal
  • Camera and HUD Display – Ideal
  • Remote Database Access – If Time Permits
  • Local Data Editing – If Time Permits
Nov 18 / Brett Brainerd


Over the next month I will be completing a project for CSC 4992 Embedded Systems.  Although I’m already a good ways into development of this I would like to take a step back and give an overview of the project’s platform environment.  A description of the project’s goals and end functionality will be given in a following post.

For the scope of this project my embedded system will be summarized as a light-weight computer running a real-time operating system.  I am using an eBox-3310 as the hardware platform and Windows Embedded CE 6.0 R3 for the operating system image.  The OS image is being custom built and tailored specifically for the eBox and my project functionality.  Visual Studio provides an OS platform builder template that I’m using as the basis for my OS.  During debugging the image is sent via Ethernet to the eBox, loaded into memory and then booted.  Debug information is sent back along the Ethernet connection to the development workstation.  However, for the final project build the image will be stored onto a microSD card and replace the system’s default boot image.

Load OS image via ethernet.