Tag Archives: Android

Do You Know Where Your Nearest AED Is? There is an App for That!

Automatic External Defibrillators (AEDs) are everywhere around us, in airports, schools, gyms, and workplaces.  It has been proven time and time again that these devices can save lives as they deliver electric shocks to victims of cardiac arrests.  Such shocks are most effective in the first minutes after someone collapses.  Yet, there is no comprehensive map of such devices available to the public.  As a result, AEDs are often not used when they are most needed either because witnesses of a cardiac arrest incident do not know there might be an AED close by or that they should be looking for one.

A team of doctors and researchers at the University of Pennsylvania School of Medicine set out to address this issue and create awareness for AEDs by creating a comprehensive national database of AEDs that could be searched geographically on a map based on someone’s location at any given time.  They initiated MyHeartMap Challenge, a pilot project that will hopefully be taken nation-wide.

screenshot of MyHeartMap app

MyHeartMap Challenge is a crowd-sourcing contest to locate, photograph, and map out as many AEDs in the Philadelphia region as possible.  It is modeled after the DARPA Network Challenge, a crowd-sourcing experiment in which social media users raced to be the first to submit the locations of 10 moored, 8-foot, red, weather balloons at 10 fixed locations throughout the United States.  The MyHeartMap Challenge team is inviting the public to gather as much information as possible about AEDs around them.  The individual or team that finds the most AEDs will win $10,000 while other participants will win $50 if they are the first to identify one of the designated ‘golden devices’.

To this end, Azavea built three applications: two mobile apps — one for the iPhone, the other for the Android — and a web application.  With a free registration, contest participants can geocode their photos and register information about the AEDs such as manufacturer and condition of the device.  The data can be sent to the MyHeartMap Challenge team via the mobile apps themselves or the challenge’s website: http://philly.myheartmap.org/  The data collected will be used to create an updated database of locations of all public AEDs in the Philadelphia region with a person’s GPS coordinates to help them locate the nearest AED during an emergency.

Bennet Huber, one of the software developers who worked on this project, explains the development process:

In order to avoid having to create essentially the same app on three different platforms (web, Android, iOS), we decided to use PhoneGap so we could build our mobile apps in HTML, CSS, and JavaScript.  This meant we would essentially be creating two separate, yet intimately related, web apps: one for the web site and one as the core of the mobile apps.  We recognized early on that we would probably want to be able to share JavaScript code between the two, so we elected to use a JavaScript module loader.  The one we settled on was RequireJS , which implements the AMD API.  We chose it because it solved many of the problems we foresaw arising:

  • The AMD API it implements provides a good way for modularizing JavaScript and defining file dependencies, something that is notoriously difficult to do without mixing up dependencies in HTML <script> tags
  • jQuery Mobile – the UX framework we used for our mobile apps – does some rather weird things for the sake of performance, one of which is never actually changing pages after the app starts but instead modifying the DOM and dynamically inserting page contents on the fly.  Since page loading is so different, it is difficult to specify page specific JavaScript dependencies in the HTML files themselves.  The normal method of working around this when using JQM is to simply place all one’s JavaScript in a single file and load it when the app starts, but due to the complexity of this project we wanted to avoid this if at all possible, and a lazy loader for JavaScript files, which RequireJS provides, was a good solution.
  • RequireJS supports virtual names for files through its package system.  This made it easy for us to create a common JS library between the mobile and web apps that could be easily referenced without worrying about physical file paths, and therefore made file management much easier (no symlinks or git submodules required!).  It also makes refactoring much easier, should one decide to rename or relocate files.
  • It supports loading HTML files as JS strings, making templates a breeze.
  • It has an integrated build system, which allowed us to create minified, optimized builds of our files for the entire app when we were done with minimal additional effort.

It took us a few tries before we came up with a good way of using RequireJS effectively since we had never used the AMD API and the RequireJS API actually changed during our project’s development.  It was worth the effort, though, because our resulting paradigm is simple, powerful, generic, and should be a useful base for future projects.  It consists of a class inheritance structure that allowed us to easily create page specific JavaScript modules dependent upon numerous other modules in different places, which are either loaded separately and lazily during development or minified together at release time.  All this is accomplished entirely within our JavaScript files and with minimal extra configuration.

Unfortunately, the details are too complicated to go into here (perhaps in a future Labs blog post!), but suffice it to say we’re very happy with the way our JavaScript architecture turned out with RequireJS and will likely continue using it in the future.

The MyHeartMap Challenge project is funded by the Robert Wood Johnson Foundation; Physio Control; the Medtronic Foundation; the HeartRescue Project; Zoll; Cardiac Science; Philips and intramural Penn funding.  Follow the project on Twitter at @myheartmap

And now, we hope you go out into the wild streets of Philadelphia and start mapping some AEDs. Who knows, you might even win $10,000 in the process.

An NEH Digital Humanities Start-Up Grant to Enable PhillyHistory.org to Experiment with Augmented Reality

We’ve been announcing loud and clear that we are adding augmented reality capabilities to PhillyHistory.org, a web application we built for the Philadelphia Department of Records that enables the geographic search and management of tens of thousands of historic photos and maps.

Currently, PhillyHistory users are able to search the website from their smart phones and compare the historic images from PhillyHistory.org with the location where they are standing.  If they are not standing in the street, they can also access  contemporary 360-degree street level views on PhillyHistory.org,  thanks to the system’s integration with Google Street View and Google Earth, to see what a location looks like today.  However, augmented reality technology is different in the sense that it enables users to access additional information about the world around them in relation to their location as they point their smart phone directly at a building or street.

Why are we involved in this?

Research.  While we hear and have read about unbelievably exciting projects using augmented reality, like the app released a few months ago by the Museum of London, augmented reality technology is still in its infancy and not much has been written about what is and is not possible.  The Philadelphia Department of Records was awarded an NEH Digital Humanities Start-Up Grant to research both the creation of historic photographs as overlays and how augmented reality scales with a very large database of assets. Remember, PhillyHistory.org currently holds over 93,000 assets (and is still growing)!

The Department of Records will initially provide point-and-view access to a subset of approximately 500 historic photographs of selected sites around the city (thanks to Deb Boyer and our great PhillyHistory interns*) for a prototype application we are building as part of our research. Users will be able to automatically access and view the historic photographs by simply pointing a smart phone at the contemporary site and selecting an available image.  The prototype application will focus on images from several neighborhoods in the downtown area although images from other neighborhoods will also be used in order to evaluate issues such as tree cover, building height and other sources for multi-path error that may affect the accuracy of the augmented reality display.  In addition to the 500 photographs, the project team will work with an advisory committee, three of whom are the co-editors of the planned Encyclopedia of Greater Philadelphia, to provide additional interpretive information for up to 20 of the 500 sites.

Josh Marcus who is working with Erik Osheim on the prototype application is already recording his progress in a Developer Journal on our Labs blog, but we are also planning to publish a white paper through NEH later this year to summarize our findings, which we will make available for free.  The white paper will outline our research into various methods for creating an augmented reality application as well as the implementation process in both iPhone and Android platforms.  We hope our conclusions on the successes and challenges will prove useful to other organizations considering implementation of augmented reality applications.

* Read captivating blogs written by Hillary Kativa, Timothy Horning, Leslie O’Neill, and Deb on PhillyHistory.org’s blog.  Great thanks go to our guest PhillyHistory bloggers as well: Steve Ujifusa, Ron Hoess, Shawn Evans, Christopher Dougherty, Harry Boonin, Ron Avery, and others.