Taking pics easily with #WeddingSnap

On 17th September I have taken part into WeddingSnap project as Android consultant and developer. At first, I was so confused and astonished by the idea that a guest takes pictures with his phone at a wedding. But after a few days I have noticed that this is a great idea! Far from Italian traditions, catching pics socially is a great thing because it increases and amplifies the sense of friendship and closeness between people. In fact, if you consider that we are talking about unforgettable and precious moments you’ll certain understand that the bride and groom want all best things in their precious day.

15 years ago we were used to take pictures through simple cameras but now, in an era governed by most famous social networks and technologies, we are using smartphones more and more. WeddingSnap tries to collect these special moments merging wedding’s pictures into shared album, avoiding  useless tricks to share pics between guests. Through this idea all people involved in a wedding can take and share a lot of photo shoots without caring of number limits and distribuition of them.

In just one month the Android app is grown quickly, giving to this project a great contribuition. In particular, if you decide to take a look on GooglePlay, you’ll find these new features:

• Off-line mode: you can collect pictures without connection and upload them in another moment
• Share: you were so marvellous at your friend wedding! Why not share that shoot on Facebook or Twitter?
• Get it! now you can download on your phone pictures shared by other guests!
• Fastness and responsiveness: old version of WS were too slow… and now it looks very fast!
• Delete it! Don’t worry if you have upload the worst picture of the Wedding!
• Several improvements on errors! have you noticed that now app is more stable?

If you aren’t ready for your first, second,….. wedding, give a look at ForeverSnap! You aren’t forced to use a wedding app if you only want to collect other events pics 😉

[TUTORIAL] Working in the background

In this tutorial we’ll talk some aspects that involves a mobile developer in many situations. In particular we’ll deepen concepts like threads (in particular AsyncTasks) and JSON parsing through Google GSON.

This slideshow requires JavaScript.

Before you start, take a look at:

• GET Twitter JSON Timeline
• JSONLint: it’s a web validator that allows you to view in a formatted way a JSON document
• Source Code

Now you are ready to perform this simple steps:

1. Take TWITTER_URL that you find in the project in AsyncTaskActivity
2. Past it into JSONLint board and press Validate

In this way you’ll view if your JSON is valid and how it’s structured.

After that you need to create (there’s mine 😛 ) an android project in which you add into AndroidManifest.xml the internet permission and an Activity that’ll be your ListActivity implementation. It’s important to that because our application uses an Internet connection to contact Twitter servers. After that you need to prepare your xml layouts and resources: you’ll find them into res folder.

Now there is the core of your application that it’s related to code implementation and in particular to the AsyncTaskActivity and HTTPUtil that you can read in the attached project.

• HTTPUtil: it’s a very simple utility class that performs a get request and returns the result as String
• AsyncTaskActivity: it’s the ListActivity implementation that I have provided to allow you to download some tweets from Twitter and show them on screen

Into your ListActivity implementation to avoid to stop your main UI Thread we’ll implement the data fetching into a background Thread. That’s not a good practise but a must that grants to user a good experience and  to avoid “Your application has unexpectedly…. bla bla”. Hence, I have provide an implementation of AsyncTask that allows you to perform into the background the following operations:

• contact Twitter servers
• retrieve JSON response
• parse response into a List of Tweets

In fact all these operations are performed into doInBackground(….) method. All those updates those involves UI, in our case list refresh, are done in the UI thread and for that are done in onPostExecute(…). Pay attention that if you perform these actions out of your main Thread you get a fatal error and your app crashes relentlessly. If you try this tutorial on your mobile phone or into emulator you’ll obtain the screens that you can see in the SlideShow.

The solution that I have provided is very simple and there are other mechanism that connected to data persistance grants to user a better UE (user-experience).

I hope that this tutorial will be very helpful,

Simone

REST: the re-birth of HTTP

Hi guys,
this time I don’t want to talk about code or patterns but just only about an useful and interesting way of think.
Sometimes you have to interface your application with data across World Wide Web and in particular you need a way, possible a simple way, to do this.
In the last 10 years, many companies and many people have thought about a solution to furnish this data to users, building usually complex protocols and architectures (etc. SOAP).

“Envelopes, body, …….” and many many other incomprehensible constructs.

You can consider for example this “simple” and short SOAP message that allows you to POST a card to our hypothetical web service.

POST /NewCard HTTP/1.1
Host: http://www.card.com
Content-Type: application/soap+xml; charset=utf-8
SOAPAction: “http://www.card.com/soap/soap-envelope”

<?xml version=”1.0″?>
<soap:Envelope xmlns:soap=”http://www.card.com/soap/soap-envelope”&gt;
  <soap:Header>
    <– another header?!?!? –>
  </soap:Header>
  <soap:Body>
    <m:CardContent xmlns:m=”http://www.card.com/soap”&gt;
      <m:CardReceipient>Jane@card.com</m:CardReceipient>
      <m:CardBody>Hi Jane, you were so beautiful last night!</m:CardBody>
    </m:CardContent>
  </soap:Body>
</soap:Envelope>

At first, it could seem an ordered and well organized way of communication,
but in my opinion this is a structure that we can associate only with this single web-service.
Another web-service will certainly use another type of format that doesn’t grant you to think to SOAP like something standard.
If we look in more detail we can see that I have put a terrified “<– another header?!?!? –>”.
That’s because if you consider the HTTP protocol and structure you are able to think about a way to reuse and maximize HTTP header and body use.

On the crest of this intuition it’s born a new idea that fully uses HTTP combining user and machine point of view.
It’s name is REST, that states for Representional State Transfer and that’s not a new protocol but a new software style architecture. In particular we are motivated to use HTTP status, responses,… as them are, without building complex response and formats.

If you consider our first example we can rewrite, rebuild and rethink that morbid and gloomy interface with a new one that respects REST principles:

POST http://www.card.com/cards
Content-Type: application/json

{
 “receipient”:”jane@card.com”,
 “message”:”Hi Jane, you were so beautiful last night!”
}

Do you really need any other explanation? 🙂
Wait wait and wait… this is good, understandable, reusable (not code but concepts that are based on HTTP) and any other adjective that you can imagine but it an hidden aspect that doesn’t allow to be portable at 100%.
Please be conscious that not all browsers support every HTTP request; if you consider a basic browser, it allows user to GET pages and POST(with buttons) messages but it doesn’t allows to DELETE an old message.
That’s not a really great problem because we can bypass it with a workaround (POST http://www.card.com/cards?id=5&action=DELETE) but that don’t respect HTTP protocol and that falls in a REST-RPC mechanism.
You could say “Oh what are you saying? This not the end of world…” and I’ll respond “Yeah! But it’s not our solution based on HTTP… It’s a Spaghetti Style!”

See you next time with some other little
hints to approach to common problems 🙂

Simone