Local Hop: A year in review
Our original vision
Our group set out to construct a mobile app for event planning and real-time coordination to help users gather socially with friends and family. We aimed to address planning problems typically associated with group text messages and Facebook events. We planned features such as event group chat, event participant GPS tracking, and one-touch event creation.
What we have
What we ended up with is our first foray into Android programming. Although we do not have a polished final product, this was an excellent learning experience. What we do have is a basic shell. Users can create and view events as well as see their location on Google Maps. Additionally, Local Hop has a well-designed database and a completed node.js server.
What went well
The most successful part of our project was our initial design and planning. “} The behaviour of the application was discussed in great detail. UI design was a huge focus because we wanted to create an application that was intuitive and useful.


What didn’t go well
Despite our ambitious plans, we encountered several roadblocks when trying to implement many of our proposed features.
To a great extent, one of our greatest obstacles was overcoming idiosyncrasies in the Android UI model. One particular example emerged when we attempted to implement an automatic friend invitation system in Local Hop. The event creation tab lists both groups and and individual friends, with the ability to check a group or a friend:

An issue occurs when you try to check a group though: what happens to the checkboxes if the individual people that constitute the group? Ideally, when you check a group, everyone in that group would be selected. We set out intrepidly to implement this…
…and ran headfirst into a brick wall. Trying to make another checkbox change its state in response to a different checkbox being checked proved to be a frustrating, near-impossible task. We never fully resolved the issue, but after reading countless Stack Overflow posts, we concluded that the issue arises when checkboxes are used within a ListView widget.
A ListView recycles its UI elements for efficiency purposes. Suppose you have an unchecked box. If you were to change that box’s state to “checked” within a ListView, it wouldn’t immediately appear checked to the user—it would appear as if nothing happened. If you scrolled through the ListView such that that particular box went out of view, and then scrolled back, the checkbox would now appear checked! Apparently, this is because the ListView schedules for its UI elements to be redrawn only when not in focus, and we could not figure out how to force a redraw, even with tantalizingly named ListView methods such as .refreshDrawableState() or .invalidate().
This was far from our only UI-related impediment. Throughout development, we kept falling into subtle UI traps like this when trying to implement seemingly simple things, which cost us a significant amount of developer hours. Mastering Android’s quirks could be its own semester-long project, if not longer.
What didn’t/Future Plans
Due to our over-ambitious goals and the issues we encountered while developing core features, we were unable to develop features including friend/group management, group chat, one-touch event creation, and settings management.



