Megazine

That's for sure something that we will add on a future update :)

And yet again we realized that we were going cold turkey for hackathons. We simply couldn't wait to get to the next one. This time the WhyMCA team had the very nice idea of collaborating with Codemotion in order to give the hackers a suggestive location for them to create new awesomeness. What better place of H-Farm?

The Codemotion started at 10AM on 17th November and it was pretty interesting all in all, especially some talks regarding Android security matters and NoSQL databases. But the real fun began at 8PM of that very same evening. The hackathon started. The developers had 22 hours (more or less) to build somethig, anything, that could help in case of natural disasters or emergencies. The topics were:

coordination of rescue teams

gathering of donations (both material and economical)

helping for people in danger

Our team resembled the one that we showed at the previous hackathon in Bologna: Sebastiano, Dario, Stefano, Nicola (live from Berlin, thank you Skype, even if you're now being messed up by Microsoft). But this time we foresaw that we needed someone with high designing skills and some kind of "taste" when it comes to aesthetics. So we asked Roberta to join us.

We decided to build Nostradamus, a 360 degrees emergency suite which covered three kind of situations, where each one is a different moment of a disaster:

before the disaster

during the disaster

after the disaster

First of all, let's see what happens before a disaster. Since everything is going well, people is still working and doing their business, for instance, in a building. It may happen that the building has a surveillance system which Nostradamus can use to detect if, at the time of the beginning of the disaster, there are human beings inside the building. It does so by performing some computer vision operations in order to do what's called "face detection", thanks to the ReKognition APIs. Moreover, since it can detect whether there is someone in trouble in a particular building, it takes advantage of a bayesian network which dynamically calculates how to distribute the rescue teams (it makes no sense at all to send the ambulance to an empty building, doesn't it?).

Let's assume that in a specific geographical area disasters are pretty frequent. Let's also assume that citizens are willing to install an application on their Android smartphones which could really help them in dangerous situations, for the sake of prevention. When a disaster happens, the civil defense may automatically warn those citizens whose smartphone is equipped with the application, and here's what happens. The smartphone goes to a so called "emergency" mode, which triggers the activation of Bluetooth through which it broadcasts its position to eventual nearby devices. An opportunistic network is hence being created: devices who don't know each other may communicate and share their respective location.. Until a rescuer walks nearby with its "rescue" version of the application: the latter can detect nearby Bluetooth "emergency" devices and their location, so that rescue can be performed; those locations are also transmitted to the civil defense's servers.

What about coordination of rescue teams? The whole thing is done by calling each other via cellphones or using CBs (CityBand frequencies). So we built a prototype of a passive device which is meant to be placed in front of disaster-affected buildings or locations and which contains a small NFC tag. Each rescue team can write their operations on the tag and read what other teams did from the same tag. The tag is encapsulated in a water resistant shell, which also features notification LEDs powered by a small battery; the battery is recharged by a small set of solar panels.

The slides of our presentation can be found on Github, as well as the whole source code of a webserver, an AppEngine server, two Android applications and a bayesian network creator.

So: a Ruby frontend, an AppEngine backend, two Android applications and various AI and ComputerVision stuff, all together: did it worked?

Sure it did. It all worked well at the presentation.

Did we won? Nope, unlike last time in Bologna we managed to achieve an honest 2nd place, even if we were hoping for the 1st place. Why second place then? Because, according to the WhyMCA team, we (willingly) refused to use any of the sponsored APIs. Well, we wanted to do all on our own, as we proudly did.

Currently we doesn't have a Google TV so we can't test on it, but it should be available on Play Store.

Nowadays, a mobile OS that lacks for a proper social networks integration usually causes the developers some nasty headaches and a background sense of disappointment. Or at least, that's how we felt when we had to face this deficiency on Android.

The problem was not easy: we needed an easy interaction with all of the most famous socials, as abstract as possible (so that adding a new social network wouldn't mean that we had to do harakiri):

- Facebook

- Twitter

- Foursquare

- Flickr

- Tumblr

Due to the heterogeneity of their nature (there is no such "post to timeline" concept on Foursquare, and after all, it makes sense), the abstaction that we were able to perform was quite modest. We spent some weeks in learning how the socials' APIs worked and if there already were some social-specific Android library projects and we found some useful projects: unfortunately it took us some time to make them stable and fully working.

The second step consisted in wrapping those libraries in a bigger wrapper project and to integrate the missing socials/functionalities, always trying to maintain that little nip of abstraction between classes.

We called the result SocialWrapper. It's an Android library project that gives the developers a fast and easy way to integrate a basic social network support on their application. It should take less than 3 minutes to be successfully configured and integrated.

The project is not over yet - we don't like being tied to projects coming from third parties. We are considering the possibility of a full library rewrite in order to remove all of the external projects: this would give the library a totally higher level of abstraction, more control and more maintainability.

So, where can it be found? Right here (right now, lol): https://github.com/MegaDevs/SocialWrapper

We also uploaded a ridiculously ugly test project that will help you in testing various connections and functions, the SocialWrapperTester; you can find it here: https://github.com/MegaDevs/SocialWrapperTester

If you have any question, please, feel free to ask.

Recently we attended an Italian hacking competition named WhyMCA - Hack Reality. This kind of event (also known as "hackaton") requires the participants to develop a working system within a given time span (8 hours in this case) and following a predefined topic. The "Hack Reality" was about the interaction between mobile technologies and the real world.

A collection of tasty tools were offered to let our creativity explode, such as Wikitude ARchitect, LEGO MINDSTORMS, Arduino/ADK, Microsoft Kinect, and so on.

There were four of us: me (Sebastiano), Dario, Stefano and Nicola, who was in Germany and therefore remotely joined the competition via Skype.

We called our project "Anti Theft Social System" (ATSS). As the name suggests, it's a an anti-theft system with a social component. Here's how it works.

We connected a motion sensor to a Nexus S device through the Arduino platform and we developed a simple Android application which controlled the aforementioned sensor. The application (i.e. the entire system) could either be activated/deactivated via 4-digit PIN code or via NFC tag. A movement within the sensor's range triggers the application which activates the phone's camera: while the movement persists, the camera keeps taking pictures of the scene. When either the movement stops or a timeout occurs, the application sends the captured pictures to our server, where they are assembled in a GIF animation. The server also triggers two more services: an alert text message ("Theft warning!") is sent to a set of predefined mobile numbers and a call with a pre-recorded audio message is performed to other predefined numbers (e.g. neighbours). The SMSs and phone calls were performed by means of the Tropo API.

The GIF image of the thief is shared on the owner's Twitter account. A PUSH notification is essentially sent to the victim's iOS device, where a simple application will then display the image sequence of the robber.

- - - - - 

Our opponent's ideas were mostly valid and some of them were really brilliant..

But in the end we won the first prize! So here's a picture of us at the end of the day, very tired and very satisfied :D