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.
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:
- Take TWITTER_URL that you find in the project in AsyncTaskActivity
- 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,
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.
<– another header?!?!? –>
<m:CardBody>Hi Jane, you were so beautiful last night!</m:CardBody>
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:
“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 🙂