Mobile Web Week #4 Homework

Phil and I made some big progress on our mobile app, StreetEyes, made with PhoneGap and jQuery Mobile.  Our screenshots are below the jump:

Our homework:

  • Add the following to your app:
    • console.log calls at the beginning of each function in your app to log the name of the function, e.g. console.log(“init()”); — hint, this is a very useful technique to identify where your javascript is running into problems.
      • Upload a screenshot of this working in the Eclipse LogCat or Firebug console (or other).
    • a “deviceready” listener that calls an onDeviceReady() function if you don’t have one already.
    • Inside of the onDeviceReady() function, log all the device information in the PhoneGap Device API using console.log
      • Upload a screenshot of this output
    • Where appropriate, add a PhoneGap Notification to your app. Replace any alert() or confirm() calls with the corresponding PhoneGap navigator.notification calls.
    • Continue work on your app. Try to layout the remaining pages in HTML and CSS.
      • Upload a screenshot of each “page”
      • Upload a zip of your app
  • Extra credit
    • 5 points: Make a fun app that uses the accelerometer, GPS, compass, connection or a PhoneGap Event, to trigger capture and/or playback of a picture, audio, or video.
      • Describe the functionality on your blog
      • Upload a video of your app working
      • Upload a zip of the app
    • 5 points: Make a simple app using the tabs example
      • Add console.log calls to init() and showtab() functions to help you identify how the tabs are being shown/hidden.
        • Take a screenshot of the console showing the logs
      • Add new functioning tabs with corresponding content divs
      • Use CSS to make the “tabs” look like “navigation buttons” and the content divs look like “pages” of an app.
        • Upload a screenshot of the app to your blog
        • Upload a zip of the app to your blog

 

We added console.log() commands for each function, and for onDeviceReady():

function init() {
  console.log("init() called.");
  document.addEventListener("deviceready", onDeviceReady, false);
  ...
}

We init’d the phone’s camera and outputted the device’s stats:

var onDeviceReady = function() {
  console.log("onDeviceReady() called.");
  pictureSource=navigator.camera.PictureSourceType;
  destinationType=navigator.camera.DestinationType;
  var elementDeviceProperties =
    'Device Name: '     + device.name     + ', ' +
    'Device PhoneGap: ' + device.phonegap + ', ' +
    'Device Platform: ' + device.platform + ', ' +
    'Device UUID: '     + device.uuid     + ', ' +
    'Device Version: '  + device.version  + ', ';
    console.log(elementDeviceProperties);
};

A PhoneGap notification upon mouseClick:

Your GPS position is located:

And you can take a photo and have it show up in the preview form input:

So our app is coming along.  I even coded in native Android a menu bar that pops up when you press Android’s menu button.  There are no intents for the bar’s buttons yet, though.

Code is at Github.

Phil and I have come across a few technical problems:

  • The interface is really jerky.  I am not sure if this is because Ice Cream Sandwich (what I have on my phone) is janky, as jQuery Mobile says it hasn’t tested it thoroughly yet, or if there is built-in lagginess with our choosing to put all the app into one html document instead of separate ones.
  • We tried to make an IFRAME to put one of our Google maps into, but for some reason, upon starting up the app, it shows the IFRAME’d Google map and NOT the whole app.  Not sure why it’s doing that, but I had to go back to putting the map into the index.html page with everything else.
  • I think this may cause another problem, which is that the Google map data is not fully loading.  Only a few grid squares of the map are displayed, and the rest never loads.  I’m not sure if having two separate Google maps in the same document is what’s causing loading problems.  I tried init’ing the maps separately, with different function names, but that had no beneficial effect.

Despite these noticeable flaws, Phil and I should be able to spend a lot of time trying to make the app more useable and adding in broadcasters to the maps, and then streamlining the process of a viewer clicking on the map and selecting a broadcaster to talk to.

We still need to make a web version of the app, and to figure out ways to bring in live video streaming as well as a chat/real-time blog sort of feature.