Cluster Grid

Font Size



Menu Style

  • Error loading feed data

WWH Android Application

Application's Description

WWH(Who, Where, How) Application's aim is to help the user or a group of users in choosing a place to go out to. It will show suggestions of places and events based on the users' list of preferences and tags saved beforehand. For the moment, the application will only be available for the city of Bucharest, Romania.

The features that should be completed for the first version

  • The list of preferences consists of favorite places that are added by the user in time. There will be two such lists, one stored on the phone, using the SQLite DB, and the other one will be stored on the server, using MySQL. The second list will be used as backup and to support other features for the application.
  • The user must create an account on the server in order to save his preferences in the remote DB. This is achieved when he opens the application for the first time. Afterwards, each time he opens it, he will be signed in automatically, having the user name and password previously saved, both in the local storage and in the remote DB.
  • The application can work both online and offline. While online, it will take advantage of the Google API and it will dynamically show the suggested places/events on the map. The offline version will be further developed(next version. It will use the last list of suggestions made by the server and will show it on a cached map(this will be documented in the future).
  • The user has the option to choose from a set of generally defined places (e.g. theaters, pubs, cinemas) and events (e.g. parties, concerts, expos. He will also have the option to choose the region of the city he is interested in and receive a list of suggestions for that region only.

The main modules and submodules of the application from the developer's point of view

The application on Android

  • creating the graphic interface
  • creating and using the SQLite DB
  • integrating GoogleMaps API
  • developing the client interface for server communication

The server

  • collecting data from sites in HTML format and parsing it
  • creating and using the MySQL DB
  • calculating the lists of suggestions
  • developing the client interface for client communication

The process of completing the modules mentioned and the main problems encountered so far

The main problem comes from being unacquainted with the technology, basically we had to "get intimate" with the new platform. So, the following can be seen as observations, hopefully coming into the rescue of the newbie.

Exploring the Graphical Interface (and Android in general)

Creating the Graphical Interface makes one interact with all the system's concepts. What got me started were the video tutorials found on where there is a basic introduction in using the Android's graphical interface and features. Upon completing this first stage, I immediatly started coding and got stuck because I didn't even think about things like:

  • Android uses a different way of reading/writing from/to a file, for I wanted to store the user account information. As it is pointed out here, there are two main functions that retrieve “references” to internally stored files:

- openFileOutput(), which returns a FileOutputStream object

- openFileInput(), which returns a FileInputStream object

One must be aware, though, of where these methods are reading from, which is only from the local application's folder: “/data/data/”, as I discovered it to be by testing on the simulator.

After all this trouble with the file reading and writing, I've found out that this isn't efficient at all for what I was needing. So, the better alternative is using a class especially made for this: SharedPreferences. It retains a pairs of keys and values which can be retrieved by using the getSharedPreferences() method and edited with an SharedPreferences.Editor object.

  • Another thing to be mentioned is that while the GUI is running on one thread, no other thread can call or access the GUI's components. So this must be done by finding a means of communication between threads and this is Handler object.

Corina Radulescu

Exploring the Google API

One the biggest challenges when it came to integrating Google API into an application was the different approach. When I started reading about it I thought it was an easy job of just importing some classes and using the methods, but the approach is a bit different.

The best way to start understanding a new concept is “Hello, World”, and in this case Hello, Google Maps, and a great link to help you do this is:

Google API uses a specialized Activity called MapActivity, an extension of the original Android class, but built specific for the needs of displaying a map. This class uses the same onCreate method as a normal Android class but you have to be careful to include the isRouteDisplayed() method, that should just return false if you are just begining.

To start a MapActivity you can use the same sequence of steps you would use to open an Activity, but the similarities end when you need to construct the .xml file corresponding to it. First of all you need a Google Maps API Key. You can find a great tutorial at

It is very important to gather information and understand the basic concepts and the way a developer interacts with the API, but once you understand the basic concepts you quickly realise that it is a very powerfull tool and one that is not hard to use. Adding a zoom to the map require no more than a few lines of code.

One of the most important features, at least the one that would serve most developers well, is the one that enables you to add an overlay over the map using whatever elements you need to make you’re map unique (the Overlay class).

Since it is a free service, and quite a powerfull one, there are a few strings attached , and the most important one is the fact that if you develop an application using this API you are bound by the License Agreament ( you need to agree to get the Key ) to make the application free.

Sinziana Gafiteanu

Features that should be completed for the second version

The second stage of developing the software, if ever released, would add the following features to the first version:

  • A group feature - which is basically an option for the friends in a group that facilitates the process of choosing a location that satisfies the preferences of the most/every friends in the group.

Implementing this feature requires for one host/friend/phone to act as master, that first collects the id's of the friends in that particular group, making a list, then sends the list to the server. Upon receiving the list of id's, the server will calculate the place that fits most preferences, based on the list of preferences of every 'friend' (recognized by the id in the list received), stored on the server's database. The computed location is then sent to the master, which broadcasts it into the group of friends.

  • A suggestion feature - the purpose of this feature is to provide a list of places and events in the nearby locations of a host. This would be achieved by first locating the host's location, using the GPS, these GPS coordinates will be then sent to the server that will select and provide the host with all the events taking place within, let us say, 500m of the host's position.