הפוסט זמין גם בעברית כאן - http://iandroid.co.il/dr-iandroid/archives/14894
Hello again,
As i stated in an earlier post, after my Hebrew blog posts started to get published on the wonderful iAndroid website i decided to transform this blog into the English edition.
Slowly but surely i'll translate my earlier posts to English and i'll start with the first one (I think you find it quite logical).
For those of you who don't know, all of my posts until now (including this one) or derived from AndconLab; the developer code lab that +Ran Nachmany, +Amir Lazarovich and myself created last year for the great MultiScreenX convention we helped organize.
To get started, I want to make a point on the fact that when you approach a project you have a few choices to make which will dictate the server-client communication state for all times, here are a few of them:
To get started, I want to make a point on the fact that when you approach a project you have a few choices to make which will dictate the server-client communication state for all times, here are a few of them:
First choice - format.
There are usually two options; JSON and XML and the key differences between them are made very clear by a short example.
Here is some data about 2 events that i helped orgenize last year:
JSON:
{
"events": [
{
"name": "Herzeliya GDG April",
"lectures": [
{
title: "Google play services",
speaker: "Royi Benyossef"
},
{
title: "MVC in Android",
speaker: "Mr. Ruslan Novikov"
}
},
{
"name": "Google I/O 2013 reloaded",
"lectures": [
{
title: "Google play services #2",
speaker: "Royi Benyossef"
},
{
title: "The pro-tip trilogy",
speaker: "Ran Nachmany "
}
}
]
}
<events>
<event>
<name>Herzliya GDG April</name>
<lectures>
<lecture>
<title>Google play services</title>
<speaker>Royi Benyossef</speaker>
<title>MVC in Android</title>
<speaker>Mr. Ruslan Novikov</speaker>
</lecture>
</lectures>
</event>
<event>
<name>Google I/O 2013 reloaded</name>
<lectures>
<lecture>
<title>Google play services #2</title>
<speaker>Royi Benyossef</speaker>
<title>The pro-tip trilogy</title>
<speaker>Ran Nachmany</speaker>
</lecture>
</lectures>
</event>
</events>
I would imagine that most of you switched to reading the XML example to understand what's written there (i.e. human readability is in the pros column for the XML format), however, simply counting the amount of characters needed to represent the same amount of data in the two formats will give you the key advantage of the JSON format, but, you might be asking yourself why would i care how much characters are used?
First choice - format.
There are usually two options; JSON and XML and the key differences between them are made very clear by a short example.
Here is some data about 2 events that i helped orgenize last year:
JSON:
{
"events": [
{
"name": "Herzeliya GDG April",
"lectures": [
{
title: "Google play services",
speaker: "Royi Benyossef"
},
{
title: "MVC in Android",
speaker: "Mr. Ruslan Novikov"
}
},
{
"name": "Google I/O 2013 reloaded",
"lectures": [
{
title: "Google play services #2",
speaker: "Royi Benyossef"
},
{
title: "The pro-tip trilogy",
speaker: "Ran Nachmany "
}
}
]
}
XML:
<events>
<event>
<name>Herzliya GDG April</name>
<lectures>
<lecture>
<title>Google play services</title>
<speaker>Royi Benyossef</speaker>
<title>MVC in Android</title>
<speaker>Mr. Ruslan Novikov</speaker>
</lecture>
</lectures>
</event>
<event>
<name>Google I/O 2013 reloaded</name>
<lectures>
<lecture>
<title>Google play services #2</title>
<speaker>Royi Benyossef</speaker>
<title>The pro-tip trilogy</title>
<speaker>Ran Nachmany</speaker>
</lecture>
</lectures>
</event>
</events>
I would imagine that most of you switched to reading the XML example to understand what's written there (i.e. human readability is in the pros column for the XML format), however, simply counting the amount of characters needed to represent the same amount of data in the two formats will give you the key advantage of the JSON format, but, you might be asking yourself why would i care how much characters are used?
Well, normally you wouldn't really care but since this post is about mobile server-client communication in which some (if not most) of the time, connectivity is provided by 3G which might be priced by used transportation volume and thus each char might make your application more costly to the end user, i would say you should care, don't you agree?
Well, normally you wouldn't really care but since this post is about mobile server-client communication in which some (if not most) of the time, connectivity is provided by 3G which might be priced by used transportation volume and thus each char might make your application more costly to the end user, i would say you should care, don't you agree?
Right now you're probably wondering if this means that JSON is more efficient than XML, well if you were, the answer is NO.
Many benchmark tests have shown that in many cases XML is more efficient but fortunately in the case of most mobile application, these states are rare and the benefit from XML is negligible.
You can read about these tests in the following links:
- http://www.edwardawebb.com/tips/xml-json
- http://blog.mudynamics.com/2009/05/01/json-xml-performance/
Many benchmark tests have shown that in many cases XML is more efficient but fortunately in the case of most mobile application, these states are rare and the benefit from XML is negligible.
You can read about these tests in the following links:
- http://www.edwardawebb.com/tips/xml-json
- http://blog.mudynamics.com/2009/05/01/json-xml-performance/
Second choice - Service, Class או Singleton.
In most applications there is a class which manages the server-client communication and it is usually designed with a subset of these requirements in mind:
- Must be accessible from everywhere in the application.
- Must perform all of its actions in the background so they will not affect the UI thread.
- Must be lean and not use many resources (runtime memory).
- Must be able to commence and cease actions on demand as well as in other predetermined forms.
these aforementioned requirements figuratively spell out Service which is exactly the approach we took (finally, some code :))).
So first of all, since we are trying to approach a remote server, you must ask permissions from the user (even if the user is you right now).
<uses-permission android:name="android.permission.INTERNET"/>
And we need to let the device and application know that we have a service by defining it in the Manifest like so:
<service android:name="CommunicationService"/>
And here's the basic form of the service class itself:
public class CommunicationService extends Service{
public static final String RESULTS_ARE_IN = "RESULTS_ARE_IN";
private Thread mWorker;
private HttpClient mHttpClient;
private ResponseHandler<String> mResponseHandler;
@Override
public void onCreate() {
super.onCreate();
mHttpClient = new DefaultHttpClient();
HttpParams params = mHttpClient.getParams();
int serverConnectionTimeout = getResources().getInteger(R.integer.http_connection_timeout_in_seconds) * 1000;
HttpConnectionParams.setConnectionTimeout(params, serverConnectionTimeout);
HttpConnectionParams.setSoTimeout(params, serverConnectionTimeout);
mResponseHandler = new BasicResponseHandler();
initApiStrings();
}
@Override
public IBinder onBind(Intent intent) {
return null;
}
@Override
public int onStartCommand(Intent intent, int flags, int startId) {
if (null != mWorker && mWorker.isAlive()) {
//we are already running a transaction, nothing to do here
return Service.START_STICKY;
}
//start new job
mWorker = new Thread(new TransactionJob());
mWorker.start();
return Service.START_STICKY;
}
}
Please notice a few details:
- A function by the name of initApiStringsin which we used in order to sort out the API format is missing and because is post is long enough i decided against adding it but please feel free to fill in any gap by looking at the actual full version of the code here.
- The Service is of the START_STICKY form which pretty much states that Android will place it at the end of the queue of components to kill off in order to release resources when in need and it will restart it automatically once the crisis is everted and there are enough resources..
- The Service uses a thread because unlike IntentService it might interfere with the smooth operation of the main UI thread.
And now, here's the code for that Thread which holds all functionality that has to do with; sending the request, receiving the response, and parsing the response from the format we selected (JSON) to POJO (Plain Old Java Object):
private class TransactionJob implements Runnable {
private static final String TAG = "Service";
@Override
public void run() {
try {
HttpGet httpGet = new HttpGet(GET_EVENTS);
String responseBody = null;
try {
responseBody = mHttpClient.execute(httpGet, mResponseHandler);
} catch(Exception ex) {
ex.printStackTrace();
}
List<Event> events = null;
if(responseBody != null) {
events = JacksonUtils.sReadValue(responseBody, new TypeReference<List<Event>>() {}, false);
if (events != null) {
//fire an intent
Intent intent = new Intent();
intent.setAction(RESULTS_ARE_IN);
CommunicationService.this.sendBroadcast(intent);
}
}
} catch (Exception e) {
e.printStackTrace();
}
}
}
For the actual parsing we chose the open source library Jackson , although we could have gone with any number of other open source solutions such as; gson, json-simple and more.
All of these libraries are good and each has it's own strong point as you can see on any number benchmarks that were done online but as i said we went with Jackson and.... that's that.
The code for the parsing could be found here and will require you to download the appropriate .jar file.
And... that's about all for now, my next post to be translated will cover the likes of issues such as; connecting the server responses to the UI smoothly by using response caching in 2 tiers.
I would like to conclude this post by saying thanks again to +Ran Nachmany and +Amir Lazarovich which wrote most of the code which I used in this post and to link you to the full source code for AndConLab here: https://github.com/RanNachmany/AndconLab
In most applications there is a class which manages the server-client communication and it is usually designed with a subset of these requirements in mind:
- Must be accessible from everywhere in the application.
- Must perform all of its actions in the background so they will not affect the UI thread.
- Must be lean and not use many resources (runtime memory).
- Must be able to commence and cease actions on demand as well as in other predetermined forms.
these aforementioned requirements figuratively spell out Service which is exactly the approach we took (finally, some code :))).
So first of all, since we are trying to approach a remote server, you must ask permissions from the user (even if the user is you right now).
<uses-permission android:name="android.permission.INTERNET"/>
And we need to let the device and application know that we have a service by defining it in the Manifest like so:
<service android:name="CommunicationService"/>
And here's the basic form of the service class itself:
public class CommunicationService extends Service{
public static final String RESULTS_ARE_IN = "RESULTS_ARE_IN";
private Thread mWorker;
private HttpClient mHttpClient;
private ResponseHandler<String> mResponseHandler;
@Override
public void onCreate() {
super.onCreate();
mHttpClient = new DefaultHttpClient();
HttpParams params = mHttpClient.getParams();
int serverConnectionTimeout = getResources().getInteger(R.integer.http_connection_timeout_in_seconds) * 1000;
HttpConnectionParams.setConnectionTimeout(params, serverConnectionTimeout);
HttpConnectionParams.setSoTimeout(params, serverConnectionTimeout);
mResponseHandler = new BasicResponseHandler();
initApiStrings();
}
@Override
public IBinder onBind(Intent intent) {
return null;
}
@Override
public int onStartCommand(Intent intent, int flags, int startId) {
if (null != mWorker && mWorker.isAlive()) {
//we are already running a transaction, nothing to do here
return Service.START_STICKY;
}
//start new job
mWorker = new Thread(new TransactionJob());
mWorker.start();
return Service.START_STICKY;
}
}
Please notice a few details:
- A function by the name of initApiStringsin which we used in order to sort out the API format is missing and because is post is long enough i decided against adding it but please feel free to fill in any gap by looking at the actual full version of the code here.
- The Service is of the START_STICKY form which pretty much states that Android will place it at the end of the queue of components to kill off in order to release resources when in need and it will restart it automatically once the crisis is everted and there are enough resources..
- The Service uses a thread because unlike IntentService it might interfere with the smooth operation of the main UI thread.
And now, here's the code for that Thread which holds all functionality that has to do with; sending the request, receiving the response, and parsing the response from the format we selected (JSON) to POJO (Plain Old Java Object):
private class TransactionJob implements Runnable {
private static final String TAG = "Service";
@Override
public void run() {
try {
HttpGet httpGet = new HttpGet(GET_EVENTS);
String responseBody = null;
try {
responseBody = mHttpClient.execute(httpGet, mResponseHandler);
} catch(Exception ex) {
ex.printStackTrace();
}
List<Event> events = null;
if(responseBody != null) {
events = JacksonUtils.sReadValue(responseBody, new TypeReference<List<Event>>() {}, false);
if (events != null) {
//fire an intent
Intent intent = new Intent();
intent.setAction(RESULTS_ARE_IN);
CommunicationService.this.sendBroadcast(intent);
}
}
} catch (Exception e) {
e.printStackTrace();
}
}
}
For the actual parsing we chose the open source library Jackson , although we could have gone with any number of other open source solutions such as; gson, json-simple and more.
All of these libraries are good and each has it's own strong point as you can see on any number benchmarks that were done online but as i said we went with Jackson and.... that's that.
The code for the parsing could be found here and will require you to download the appropriate .jar file.
And... that's about all for now, my next post to be translated will cover the likes of issues such as; connecting the server responses to the UI smoothly by using response caching in 2 tiers.
I would like to conclude this post by saying thanks again to +Ran Nachmany and +Amir Lazarovich which wrote most of the code which I used in this post and to link you to the full source code for AndConLab here: https://github.com/RanNachmany/AndconLab
הפוסט זמין גם בעברית כאן - http://iandroid.co.il/dr-iandroid/archives/14894
Royi is a Google Developer Expert for Android in 2013, a mentor at Google's CampusTLV for Android and (last but not least) the set top box team leader at Vidmind, an OTT TV and Video Platform Provider. www.vidmind.com
