 on Wally and OKHATP, with which you can build an Android application. Let me send the, set the agenda of it. My agenda is, after this talk, you should be able to go back and integrate Wally as well as OKHATP in your Android application, or you should be able to develop it. So we'll be starting, first of all, with Speedy and Google SpaceSpeed, which are the two Google-developed server-side programming or modules for Apache servers, EngineX, and other servers, which will speed up your websites at the server end. And the Speedy is a different kind of protocol which Google has come up with, which requires special implementation of the client-side as well. So for that, we'll be talking about OKHATP library, which is an HTTP client which supports Speedy and is developed by Square. Then we will be reviewing how you interact with your network in an Android applications using default Android HTTP libraries. We'll be just over-viewing them. Then we'll be going back into how high-level libraries have been built and what is the boiler code has been built upon it. Then we'll deep-dive into Wally, which is just presented in Google Iow in May 2013, which is a high-level networking API which includes best practices caching and all. We'll also go through a code walkthrough of how you can implement it directly, straight from downloading it from GitHub and integrating in your application. Then we'll compare some issues which you might face when you are trying to communicate with Wally in HTTPS. And how do you overcome that? Then we'll also compare it with one very similar library called Ion, which has been developed by Kaushik Dutta. And we'll compare the two, what's the difference between them. And finally, we'll be summarizing it and concluding them. So let's get back to Speedy. As I said, Speedy has been developed by Google as a protocol to be interacted and to make your web faster. HTTP was when the blob was not meant to do all those crowdsourcing and activities which people are interacting with, like, the user itself is generating content on the internet. So, and your browser has a limited number of connections. It cannot open more than six parallel connections to your same website. So when you are communicating to your server in multiple instances, there is a limit and there is a serialization which is happening. What Speedy tells us that I will sit between your application layer and presentation layer. I'll be sitting beneath your HTTP layer and will be protocol-ing them and sniffing them, like, analyzing it, what to do, what to do, and make it faster. How does it make faster? It, first of all, automatically provides free compression. Like, it's a transparent, easy compression support. All your requests and responses will be compressed. Secondly, to solve that multiple parallel connection problems, it automatically gives you an architecture of multiplexing. So using a single thread, you can handle multiple requests. And it also allows you to prioritize those things. So this is one of the greatest benefits with which you can remove your CDNs. So you don't have to maintain different CDNs to host your images, JSS, CSS. And you are maintaining five different CDNs and trying to distribute your page load time around those different hosts. With Speedy, you can just call them up and Speedy will take care of it within the same number of connections. And because it is sitting beneath that, your HTTP layer, when you are giving your response back, it actually analyzes the response which is getting back to the browser or to the requester. And it can read what are the future requests going to be made. And instead of browser asking for the request, it has the power to automatically push content to the server. So if your Speedy is installing the server and you are doing a get request of a website, the Speedy can intelligently say that, okay, after this get call of a website, I have a JSS and CSS to be pushed. I can do that intelligently without browser being asked for it. So because it is a different protocol and it allows streaming and all, and to be frank enough, it actually powers up your STTPS. As an Android user or a mobile user, we are very, very performance oriented and we do not want to use STTPS because it has an extra layer. But with Speedy, you will be able to do it faster. And there are a whole lot of browsers which support Speedy. In fact, there is a plugin or add-on on Firefox if you search on the internet which can tell you that which site is using Speedy and which site is not. So which is Speedy compliant because the browsers are already accepting Speedy. So these are the few more tech companies which accept Speedy, which are already built on it and it has been proven technology. The next thing was what comes to mind when you're developing a website for mobile specific is how do you optimize your test site or whatever request you want to make. So here Google SpaceSpeed also comes up. It says that, okay, Speedy gives us all of these features but what about, I still want to combine my GSS and CSS and images, I want to make them sprites. What does it say that the optimization of your website keep that concern separate from your development and it provides out-of-the-box implementation just the way like Speedy does. Google SpaceSpeed can sit on your module on Apache and through the network it can request all the... It can analyze all the requests and combine your images. Not only combine and do the minification of the code at runtime but it can also control your image sizes and resizing of them. So if I'm on a tablet, I can call for a 3MBA of an image but if I'm on a smartphone which has a lower resolution I can call the same image with a different parameter so say they degrade the quality to 30% and I can get a probably 500KB or 200KB of that image. The same 3MBA image. So I can control the real-time images which otherwise I have to create a copy of them keep it in my server, give it a different logic to it. And lastly, it has not only image control quality it has 40 plus configurable optimization filters which will help you optimize your website. So how do you implement them? They sound complicated, they can achieve a lot of good things but Google's page speed is much more easier to implement. It comes in three flavors. One is module which you can install it on your servers. It's an open source code, both. So you can install all those filters which will be sitting on your Apache or you can use it as a service. Let's say you don't have your domain name and you don't have the control and access to your server directly then you can use them as a service. They will be using your website routing it through a proxy server and it will be out of the implementation. Or you can use your SDK to be used to their API as a web service code. So in a nutshell, let's summarize that here is your server which is running either Apache or Nginx or Jetty or NodeSpeedy. All you have to do is either compile it yourself and deploy or you can use ModSpeedy. They are the pre-compiled modules which you just install them. Go to these websites which are beneath ModSpeedy.com or comium.org. You will be able to get all the tutorials and steps how to install them and it's very simple. Now let's talk about OK HTTP. What does OK HTTP does? Before OK HTTP I'd like to tell you that in Android if you want to communicate with the network there are two ways you can communicate. One is Android SDK comes with Apache HTTP client which supports on Flora Plus. Another one is HTTP URL connections which is Java.NET Android HTTP URL connections which is supported after Gingerbread Plus. What OK HTTP says is I'm similar to those Apache HTTP client. I'm built in Java so you can also use on any of the Java applications and it's robust and efficient than Apache HTTP client or HTTP URL connection. How it is efficient? So it definitely supports PD protocols so that you can make your network calls faster, easier, multiplex them. If speedy is not installed on your server still OK HTTP is faster because it uses connection pooling. Connection pooling actually reduces your latency and optimizes your Android bandwidth or the threading concepts. It supports transparent Zzip compressions. It also has a response caching like an Apache HTTP client or HTTP URL connections has. And one thing I like is on a mobile network it's very hard to develop a network for error prone sites. So you might be in a faulty network you might be having a fail HTTP connections or proxy servers. So it automatically recovers from them. And if it is an IPv4 and IPv6 failover so it cannot attempt an alternate address. So let's say how it is implemented. So once you download the OK HTTP code you build a jar out of it and it supports Apache HTTP, OK HTTP, Apache clients compliance where you can port your Apache HTTP client or it has own OK HTTP client for HTTP URL connections. So how do you implement it? Just create a client out of it, OK HTTP and just do client.openurl and HTTP URL connection instance will be returned. And then you are good to go to port your applications because that's why you are already using it and it follows the same standard protocols. So let's now look at that how does Android applications use to communicate with the network. The main thing is on your UI thread you are not able to communicate with the network directly. It has to be in an async manner as you all know. So one thing when it strikes like OK I have to make an async HTTP call because the UI thread is not allowing me to block it so I'll show a loader and in the background I'll create a thread. So hence the first implementation it started with threads then handlers came into picture and then async task was introduced by Android but the problem with async task when your screen is rotated let's say from portrait to landscape mode your application re-starts the activity is recreated, sorry if your activity is recreated your async task if spawning from on start or on create will be called again there is no way you can cancel your old async task which you've already spawned so your old async task is already running you are for the same request you will be spawning a new async task and your old async task will be updating the old UI and not the present UI which has been shown to counter this problem loaders have been introduced so there are cursor loaders and async task loaders which takes care of rotation mode then after this there is a lot of boiler code to be written you need to handle request let's say that I have spawned two, three some industry request now if the second request comes before the first request how do I handle it all those async request and responses has to be written so what is the problem problems are all the network request which I am spawning in my applications happen serially if I have not designed it properly and there will be rotating screen as I just described will actually reload everything and all the async task will be recreated there will be no default cancellation of the thread so if the user has switched and cancel the activity or hit a back button I will not be able to properly manage my threads and response which I have created pausing an activity doesn't pause the async task so it's a similar thing because it's an async task which is running into your background and it's different from your activity life cycle so you will not be able to do it and there is no mercy on image loading because image loading is the one where you just cannot put source equals to image URL you will have to download the image create a bitmap out of it and render it into image view and caching of the image loading is another problem in android applications so there is no out of the box caching implementation for all the network request which you will have to design it for yourself so to overcome all these things people have tried to identify all these high level requirements which you have to rewrite again and again for every android application so here I will be describing the ones which is developed by square one is OKHGTP it's a speedy client one is Picasso it's a very good library for image processing not image processing, it's for image downloading and using the image cache but to resize and do image operations they have introduced another third library called polexer which is a Thumborg client for image processing and there is a retrofit which is a REST client for it but think of it except for image processing at most of the tasks android does when it communicates over the network it communicates through JSON it communicates through images it downloads images you will never see an app which only does image gallery you will have to have a retrofit and Picasso together if you want to use these applications or boilerplate codes so in Google IO this year, Fikker Skid Patrick he is an engineering lead android team in Google has developed volley which is a same high level framework which you can say is a group of all these things like anything which is communicating over the network he has developed best design practices and frame plugin and customizable framework which you can implement and it is being used by Play Store other applications which are out there there are many boilerplate codes like iron which will be just touching over will not be discussing universal image loader which is one of the good libraries for managing your galleries and lots of images and thumbnails RoboSpice is another image processing or image downloading library which uses background service as a concept which I will not recommend because the purpose of background service is very different the activity, spawning a background service doesn't make sense at least so let's come back to volley as we have just described volley is a boilerplate code for best design practices to be used while communicating your android application over the network it uses its own best design practices casting solutions common code for performing all the network requests it doesn't say that this is for images this is for JSON this is for XML or what not so it has simplified all your requests in context management it has done out of... it supports all these formats or anything and it has a boilerplate code for even the authentication and odd tokens you would be needing for most of the account integrations things and yes, volley is being used by Play Store app which is the biggest app being used with every phone so it's proven that it's not a concept or a project it is stable library code so what are the advantages of volley let's first look at it what volley does is it keeps your network request in a request queue and she dos them automatically in a round robin fashion so you don't end up spanning n number of threads together it does provide you implementation or a framework where you can extend and provide disk and memory-based implementation of caching in May when volley was released when I took a check out there was a bit... in-memory bitmap casting implementation which we have just removed which in the present check out and only the interface has been... has been remain just to showcase that there is a customization capability and you should customize your in-memory image caching if you want to do it there's a cancellation request API where you... when you have spawned a request for a network you can always cancel it you can do a cancel all or you can do a cancel filter and there is a powerful customization capabilities like we'll be just replacing the HTTP stack from HTTP or URL connection or Apache client support which volley provides by default with OK HTTP then yes it does support a lot of good debugging and tracing tools and it can be handled highly... high-resolution images and it can catch your out-of-memory exceptions which even Picasso fails to create thumbnails if given a high-resolution image so I read a blog where they were doing a comparison between a volley image processing and Picasso image processing and they were saying like when high-resolution images are provided Picasso just goes out of the memory and fails to load the thumbnails but volley does it very beautifully so let's see how it is implemented so it's a structure that you create a request queue and you keep adding your network request into the queue and it will check for the cache first it will do this image if it's a cache mess then it will go into a network request dispatcher where it will schedule the network request and it will come back and it will give back the way you implement it is create a request queue object here as in the first line it's created and then you create a new request queue calling volley.newRequestQueue here is the below example for JSON request so you can there is a request interface which provides cache code and other HTTP methods so for JSON request you can create a JSON request object where you will be passing the method method name parameters URL connections and the callback functions so like in a do in background you have an onPostExecute function you have a response listener and as well as error listener which you will implement and when the response is get back those listeners will be called how do you handle image views so you will not be able to in your layout instead of image view layout or tag you will be creating a volley network image view tag and you will be spawning an image loader which wherein you will be passing the request queue as well as the custom caching implementation which of your image cache objects or interface which can be at the disk base or bitmap base or whatever caching strategy LRU caching strategy based implementation so once the image loader is created you can create it in your application start to create it in your each activity so image loader can be a static thing which you can create and keep it aside for all your image and whenever you have to set a URL or load an image from a URL you just call that image view or set image URL give the URL and the image loader path image loader will in turn check it in your image loader cache and if it is a mesh then it will go to your request queue and fetch the image and download the request queue so below is the GitHub link by Tray Robinson which is a very good head start or a boiler pit for using Wally starting with image processing or image caching so as I said all the responses Wally guarantees that all your responses will be delivered on the main thread and if you rotate your skin and if the activities break and there is a new activity is being spawned then Wally will say that I have a tool which identifies those threads and will be delivering those responses to those listeners and if you cancel a thread Wally guarantees that the response will not be delivered so how do you cancel a request so if your request queue is not null you can for an activity what I generally do is for each of the activity I create a separate request queue so that on stop I'll just call them that cancel all all you can do it if you you can create a request queue for all of your activities in an application context or application constant and manage them but when you will do that you will not be able to do a cancel all when an activity stop so Wally does provide some implementations where you can either do a new request out of the request you have spawned or you can cancel particular request which you have created individually so let's see some code walkthrough these are the snapshots which I just took yesterday night which says, which just means that the GitHub is active and people who have developed it are very active in this community and they keep updating and fixing the stuffs so what you do is first of all you have to check out the code make a clone out of these two GitHub libraries OK HTTP and the Wally so once you do a check out your code will look like this so since it is a palm dot XML that means it runs on May 1 so you will be compiling a May 1 and creating a jar out of it similarly with Wally and paste so when you compile Wally you will be getting a Wally.jar in bin when you do that just copy paste it in your Android Libs directory so this is here where you will copy your OK HTTP and Wally jars that's it now your code is ready and your app is ready to integrate all of these things but before going to Wally let's say that all of this Wally and OK HTTP let's look at the source code of Wally what it does so you will be seeing two package folders one is Wally and Toolbox I will highly recommend that spend at least one or two hours before them starting into Wally and understand what each of these class means because there is a less documentation out there and trying to interpret what it does so when I started I just looked into it and I just looked into couple of tutorials how they have looked but then I started exploring what this Wally source code looks like so if you see like let's say I want to implement let's first go through some classes so let's say that there is an HTTP stack interface it says that it performs an HTTP request based on all the GET posts and other parameters and it is being implemented by two of the things one is HTTP client stack which is an extension of Apache HTTP client and implementation of it so you will be seeing GET perform request and all those things here similarly there will be a Hull text which say that this is an implementation based on HTTP URL connection so you will be using this code for HTTP URL connections then there is a request queue object and there is a request object which is again an abstract class which you can enter they have already implemented few of it like JSON request or image request kind of things where JSON request has been further extended to JSON object request or JSON array request and if you want your own XML and other request to be respond you can do that as well and then there are couple of image image loader and image request which you can look into it let's say that how it is implemented so once you have integrated the jars into it in your activity create a request queue object in the request queue called Wally.NewRequest this but here we are trying to use OK HTTP so we want to modify the HTTP stack what we can do is we can create our own HTTP stack which extend Hull stack or if you want you can implement your HTTP stack extending Hull stack because OK HTTP though it comes on both ways I am more comfortable with HTTP URL connections so what I have just done is create an OK HTTP client and in the constructor I have just created an OK HTTP client and once the client is initialized I will I am just spawning a method called create connection and instead of HTTP URL connection create URL I will just say client or open URL and done this is the one line of class or code which you need to implement OK HTTP and integrate with Wally so once it is done you just say that OK this is my Wally with OK HTTP stack hence I will this request queue will be using OK HTTP beneath the request which I have spawned now another problem which I faced while I was integrating JSON request object was we had an API which supports authentication so we have an which needs to be passed on header as an authorization layer but in this you will you will find that you cannot pass on headers so we created another JSON object request or we created our own JSON request by extending the request and if you just browse through the code it does because it is ultimately an HTTP call so it has to spawn some headers so it does spawn some headers by yeah so it does that by creating a map inside it which is there in the request object but not in the JSON request which Wally has provided so what we have done is we have created our own implementation of JSON request we have created a header and we are passing it in the constructor to create the headers and the maps so in your JSON object request when you say that here is my listener, method and URL connection along with it I will be passing the headers itself so once done that it's so it's which which on a click off a button it creates a get service with the URL and if it's a it constructs a JSON get URL and does say that this is my new JSON request and here is my response listener here is my error listener if you go to my response listener you can get the JSON response and you can then convert it and talk to your UI threads and similarly for the error listener now let's see how image loading is done so if I have not used Wally I would have used image view but let's and I would but with Wally you would have to just put it in your layout that you are using Wally.network.imageView and this is a list item so I have a list activity an adapter in it in adapter this code but before this code I'll just show you that in main application I have defined my disk cache so in your main application which creates you can create an image cache manager and you can create an image loader itself here by specifying your stuff an image cache manager it's been copied from Ray Robinson which on the example of image GitHub library which I have just shown and it handles it beautifully by extending the image loader and doing the disk base caching of the image otherwise with in your Wally GitHub you will just see that image cache interface is there you will not be able to see those implementations those implementations are left to the users so you do you image manager and your image loader is created by calling your my image loader my image loader is sorry so when you are done this you just say that here is my image view which I always find and I will just say that this is my image which I want to fact this is the URL of the image and image cache manager.getInstance.getImageLoader and I will pass on the request which will be a separate thread handling for it that's pretty much it and you will be able to integrate it but when it comes to communicating through an SUDPS Wally has a trust trust source involved we will just come to it yes so the SUDPS if it's from a third party or a trusted manager in a certification authority you will be able to gracefully use it but if it's a localhost configuration you are hosting an SUDPS in localhost machine and it's not signed from a trusted party you will have yourself signed certificates will be rejected the solution is to modify that SUDPS client again and provide your own trust manager on how to modify your SUDPS client to implement your own trust manager and then you will be able to use it now let's go back and look into how your what happens when you do a request q.addRequest it's as it is shown in the diagram it first caches and add it to the cached priority and your request is dequeued and checked for the cached dispatcher if it is a hit if the response is sent back if it is a miss you will be sent to a request dequeued network dispatcher which will manage your maximum number of threads and in a round robin fashion execute and process that order in terms of priority as well you can set the priority of your request of request and once the SUDPS transactions you have got a response it will take it, cache it as per the strategy which you have told you can go back so these are the logs get printed when you call an image or any network request so as you can see it's add to queue then there is a cache queue cache queue hit expire queue network queue take and network HTTP complete pass complete cache return post response and done so now let's compare it with a very similar library called ion it's developed by it's inspired on the scale or an api logic and the patterns are inspired by Picasso so if you are already using Picasso for image loading and you want to migrate to something common so that you don't use two different or three different libraries third party libraries you can use it and the background it uses android async which is again developed by him in an NIO based structure trying to multiplex your request and not creating threads for many requests and it supports both cancelling operations, caching and images but as compared to the volley it's volley is more customizable I will say it's beautifully written for on a request queue object and as you have just seen we have changed the HTTP client we have changed the image cache frameworks it's a network an interface driven library which volley is being written and you can implement and extend and change it to whatever level you want and the cancellation management of this volley is definitely better than any of the existing libraries which I have seen so far so let's conclude speedy is good because it multiplexes, compresses and automatically fails if it recovers your responses even if you don't use speedy is does your connection pooling as well as transfers is it networking request and android slips are basic and you need to write a lot of boilerplate code for that there have been libraries which does that but volley does it very beautifully in a simple manner and volley with okhqpp can be a very good strategy for bootstrapping your android and as a boilerplate for all of your android applications which interact with the network and you can actually look for other interaction applications or you can actually I like android async so there is one more try which you can run and do probably a benchmarking and try implementing android async of an IO HTTP client with volley, thank you this includes yes for which library or otherwise google okhqpp plus or google volley of android you will get these links for image processing also just type tray robinson and volley you will get a link for image caching do you have the numbers comparing okhqpp with volley and HTTP client with volley how much improvement we can see I have not compared but on the okhqpp on the speedy website there is a video which shows that the network or the page request for loading a page which used to take 3-4 seconds is taking 1 second now without speedy yes yes yes yes yes yes actually actually it not depends on payload it depends on number of threads you are spawning so if there is a large number of request and you can do a load testing on it then volley and okhqpp will be better but I have not done the benchmarking yet no question volley supports speedy volley supports speedy volley by default has only 32 implementation HTTP UL connection and apache client so to support speedy you need to integrate okhqpp no it still does make a sense because if speedy is not available it will do automatically your connection pooling so if you have more than 10 threads then volley also does the same part but okhqpp takes care of it in a different manner after the volley part so there are other aspects which you can look for failed handshakes or proxy servers it can automatically recover out of it you can do a it supports zzip and compressions volley is a set of high level it tells you okhqpp use sttp or use apache sttp client but this is how you should use it so yes all the request which volley spans is independent of the life cycle of an activity so if your activity is gone your responses will still be running like an async task but it guarantees you that if you want to get the response on the main thread it will deliver it and if you cancel it will definitely your response will not be delivered you mentioned the talk in which the developer at google presented volley so I also saw the same talk he mentioned something that the sttp url connections classes are little buggy below 2.2 and yeah remember exactly he specifically mentioned that volley takes care of the bug of both sttp client and url connection itself in volley but you are suggesting okhqpp so those considerations may not be there in sttp it might be there I am not very sure I just wanted to clarify yesterday I just read a blog on okhqtp which mentioned the same thing older version of the sttp url connections like which supported gingerbread and furrow they had some buggy but in that your responses were not the stream was not getting close properly and okhqtp solves it so I thought so if volley has already solving this problem okhqtp has also taken care of this thank you one more thing see I am a fan of so I have been using volley for quite a long time I have also used ignition framework so is it better is volley network image networking is better than drive queue have you heard of drive queue I have not heard of drive queue I have compared it to universal image router, robo spice and Picasso and I have found volley to be outperform all of these three thank you