Object-oriented fun

Kristine and I designed and are building a Friend class in our application framework that hopefully will make it much easier for other members of our group to contribute to the coding. We were concerned that the different learning curve shapes meant some members were getting left behind and not learning a lot. This class abstracts out the facebook backend plus our mysql backend, so all you need to do is create a

$person = new Friend(userId)

and then all of the things that are relevant about that person are available within php programmatically.

$person->getStatusMessage() will pull their current status message from facebook, while
$person->latitude() and person->longitude() will pull their locations from our mySQL database.

I suspect this will reduce performance - when we trying to display information for 10 friends at once, we will be hitting the facebook database/our database 10 times sequentially, rather than using their preferred array calls which get info for many users all at once (I did make it so all of the values get pulled from facebook at once, to at least somewhat limit the quantity of hits: if the desired member value is not yet set, it will call a member function to set all facebook values at once, and then if it is set, it will just display that value without talking to facebook again). However, performance is not what we're optimizing right now, right now we're just trying to make it a little easier to work inside our application framework.

Once again I'm learning practical uses of things I only had an academic appreciation for before... I've always "known" object-oriented programming, in that I created an object once in MAE 9, and knew that objects were containers for functions and variables. However, I've never really used it for a purpose, and now I'm excited at how useful objects are, how easy they make things.

Accessing GMaps javascript inside PHP

The integration hurdle I'm currently working on is accessing Google Maps javascript functions inside PHP. The reason Phoogle and the other wrappers I was able to find didn't cut it is they basically output javascript/html to the browser, they don't actually let php call the functions. They are very nice in accelerating the development of simple applications, but they don't truly re-create the GMaps API in PHP. What we'd like to be able to do is use getLatLng for the location the user enters and store that in the database, or let them choose a location if getLatLng isn't able to find anything for what they've entered.

The solution that I've come up with is to use AJAX - the page we're making the call from sends the user-entered location to another PHP page, which generates the appropriate javascript to make the call and output the collected information as XML, which then can be read by the calling page.

For now, I'm not really sure if I can implement that. Given the unpredicted constraints in learning curves and availability I've had to largely take over development of the GMaps portion of our application, and it may simply be easier to send the raw strings entered by the users over to GMaps, and if it can find a latitude and longitude for them, great, if not, oh well. Data validation is great, but we work with what we can.

Using MapLink / draggable markers

I was able to talk today with Beth Surrell from Tritonlink, who is putting me in contact with the programmer who created MapLink. Interestingly, MapLink was built by a student who just recently got hired on to work full time for Tritonlink. I'm still waiting for the communications to filter through, but hopefully we can begin working on that part of it soon.

In class on tuesday the Google Maps presentation gave me a lot of new ideas about the ways we can use Google Maps in our interface. The draggable marker could easily be used for a person to set their location graphically, making data validation much easier. We can be relatively confident that the latitude and longitude of a GMarker is valid; with text input we need to run the geocoding function and check to see if we get lat/long values back. Potentially this could also be used for community geocoding: users type in something textually, and if we/google don't recognize the location, we can say "okay, find it on a map for us". Then they will drag the marker to the correct place on the map, and we can store that data in a separate table for the next time that user, or indeed any user wants to use that location.

Using FBML

I have been working alongside Kristine today, and she has been figuring out much of the FBML which makes it very easy to display information like profile pictures and names. All you need is the user id as an attribute on many of these fbml tags, and it will be able to generate (for example) the profile picture and name for a user, linked back to their profile. To implement this programmatically, we would need to call the users_getinfo function with username and fields as arguments, then fish the results out of the returned two-dimensional array. We do need to get some of this information programmatically to update the database, but luckily we can avoid much of this in designing the UI. On the google map for example, we hope to be able to put information such as the profile picture and status into an infobox for each point on the map. If we change our minds about how exactly we want it to look, we can manipulate the fbml much more rapidly.

The near future

Integrating with the google half of the application will be another hump, but luckily I have already specified what the interface would be: one string for the current user's location to center the map, and a 2-d array with [friend index][friend name, friend location, last update time] to plot friends. I have a little feeling that we should already start specifying interfaces for the more advanced functionality we have speculated on, but it is very difficult because we have to have a fairly specific idea of how it's going to work before we can specify the back-end interfaces. It is great to be future proof, but it is better to have a usable product TODAY.

Depending on whether or not our scheduling works out this week, we should be able to easily complete Round 1 of our development this week or this weekend. So, to make sure we have somewhere to go after that, I am going to be meeting with my friend Beth from Tritonlink tomorrow to see if we can make use of MapLink for the campus-level geography.

In the super-long-term, it is interesting to think about how this could be extended to other campuses, with community input of campus geographies (sort of how facebook started, with community input of available courses at each university and the like). That is far beyond the scope of this application however... if we are lucky we will get to use facebook's SMS functionality but that would be the farthest I see us getting this quarter.

Humps - education and integration

After an initial "where on earth do we start?" period we are proceeding very rapidly. Although it's important to keep up with what everybody in the group is doing, deciding to specialize has really helped us move forward by reducing the education burden. I'm handling the location-setting part of the facebook application and the back-end, so I have been able to focus pretty much entirely on learning php and mysql. I'm actually really excited about that, because I've been "learning" php for about a year and a half now, as in I have had a nice thick book on my bookshelf for a year and a half and have gone through the first 2 chapters about 5 different times. But now after just a couple of long nights trying things and misplacing semicolongs, I'm confident enough to hack around with the framework that I have up there already, and spend more time looking at the text editor than at google or the php book. Mysql had no hump to speak of - it's incredibly simple to write the queries, and since it comes with a very nice GUI it's a snap to update or change the structure when we decide we need to.

Now that the education hump is over we still have the integration hump to deal with. Kristine and I have been working separately on the two halves of the facebook/server side of the application in separate files just running on our own server; bringing our work together and putting it on facebook has been a tricky process and it seems like maybe we should have started that a little bit earlier. There are an assortment of niggly little things to deal with; for example, on my own server the action of the form transfers variables to another php page very easily, but on facebook it doesn't like leaving the callback URL so I need to figure out how to get multiple pages up or have the form be self-referential. However, the collaborative aspect of programming is very interesting - working side by side on computers and being able to instantly glance over and give tips and see what kind of code is happening is very effective. It's not quite "extreme programming" but it works pretty well.