 Awesome. Topic is going to be design patterns for building network agnostic apps. The initial intention was to do it for a very generic design pattern talk which is covering iOS and Android. Later I remembered that I haven't done anything in iOS. In the fear of getting caught I just updated the topic to just say design patterns for network agnostic Android apps. Whether I know about Android we will know it. So this is the first talk for this conference. Fragments is a new initiative. Before going to the talk I thought of rambling around. How many of you are iPhone users? I am not talking about iOS development I am talking about iPhone users. How many of you are keen to find out what is getting launched tonight? So should I do the original talk or just do all the leaks and then finish up next 15 minutes? There is a reason for bringing up this slide in an Android talk. 10 years ago, actually slightly more than 10 years ago, it was almost like 10 and half years ago, when he launched this phone, I don't think the world realized that many of our salaries are going to be based on that particular event. The whole mobile world changed from then and in fact I would say iOS gave that tough competition to Android. It damns out 2-3 years of lagging in features and that whole evolution and the whole new mobile world which is rolling the entire community right now and employing so many developers like us was probably started that particular event. Speaking about a motivating person, how many of you know this person? She mentioned this in many of her ads saying India has the fastest and widest network which works perfectly from Shimla to Tamil Nadu. She conveyed that in many annoying ways was many of her ads but unfortunately we still see this when the network is bad which is a regular scenario we see that infinite loading progress bar in our apps and when the network is completely gone which is like a slightly less regular scenario we see that check your network connection. So these two are the blames that we keep on our users and our users cry when they see this. The intention of this talk is not to remove that completely. The intention of this talk is to ensure that we can do around this and then still provide great experience irrespective of the network ending. We will go through a few standard design patterns. We will also go through some of the best practices which some of the product companies came up with. When implied the expectation is we are going to provide that experience which is not very different based on the network ending whether it is like available, not available, screwed up, nearly screwed up. So obviously this is not the right thing to do and it is not to provide this experience to the users all the time and what we actually intend to provide is something like this. It should load at least in a matter of a second or so but keeping that healthy result on the website. We see the 2G behavior and we can actually go through a movie review completely before it comes up. So in the interest of time and go ahead and continue because this video is going to take another 30 seconds before the results show up completely. So once again obviously this is not expected. This is not what we want to provide to our users. We cannot just improve their network speeds. Somebody tried. We all know how much they are successful of. I think we just forgot to understand a simple mathematical logic that if you have a huge pipe coming in and if you are putting in that 100 pipes it makes sense but if you are that information which is coming in that huge pipe if you are distributing in 1 million pipes we all get 2G in the name of 4G and how many of you are getting very good 4G connection in India all the time. There are two extremely satisfied customers. I think we should all listen to them and take the class in terms of how to live happily in life. So most of the time I do not attempt a video call in our mobile data and whenever I attempted it showed why I shouldn't and why if I is always there in office for free at first it was not a major problem but considering the scenarios where that is not the case let's try to define quickly what is a network agnostic app finally coming to the topic a network agnostic app is supposed to behave similarly different network you assume that these two mobiles were in different network conditions but they are providing simple experience and that is the big mark that we want to achieve right now is this first time is this never happened before not really these two famous apps which are now used by our parents most of the time have done that well except for the first blue guy killing our battery so what's up and Facebook actually have applied a lot of this practices around network agnostic implementation of their app we have we have stolen some of the same patterns here we will go through them before just going there how many of you are regular users of whatsapp awesome how many of you have paid that 50 rupees subscription in your life two people I think I will find some way to give some credits to them old users that was not expected this is expected okay so the first design pattern is pretty simple wanted to start with something which we all do implicitly a cashable content with time to live so this is so Android developers if you are using ok HTTP and if you are using ok HTTP cache in your app then you are already doing this internally so this pattern is nothing but whenever you make a network call listen to the server server provides you some TTL keep that response till that TTL is expired till that time do not disturb server again and again just use that response for any of your so what is the advantage and how is it going to impact in terms of network agnostic implementation the difference is when you are having probably an image which is having a detail of three months and then if you are going to use that image in every launch then probably for the next three months once you fetch one don't have to fetch it again and it's always going to be available few primary things the server needs to add TTL for this and all the responses and the client is supposed to cash that data if that is valid that TTL is valid and when the TTL is expired it should clear it up the last important one you can extend this design pattern to ignore any network response essentially if you have cache use it otherwise do not use it there is of course cache option available in ok HTTP this is specific to ok HTTP but you can apply this design pattern in here this is just taken from our friend Jake Wattons website or Squares website more precisely this is their architecture in terms of how things are actually managed in ok HTTP so they have one request side or input side and they have two data sources cache and network so for cache to be available you need to explicitly set it that is an important point but otherwise with this approach you have that flexibility to get the data from cache if server is setting your TTL and things like that also your application is not disturbing the network or laying a lot of honestly if you do this properly in your app most of the network calls are probably just to give a while ballpark number 60 to 70 percent of the network calls will be avoided because doing this properly well all the time which is compared to when you are not doing like if you have not set TTL at all if you are not taking the header from back end and if you are using ok HTTP cache we probably end up making another 70 percent of the app that is the average so this is a flow diagram first of time I will keep it because this is probably very boring just lights are going to be available you can always have an update quickly move on to the next one the design pattern around content versioning and 304 response HTTP 304 is a code which comes into picture when you are requesting a particular resource you already have a version of a resource and there is no update in the server so essentially server just replace back saying ok I have the latest or whatever is supposed to be you are having just continue how is it going to impact your network industry story that when you have a cache maintained with whatever recent version of information that is available and if you are going to do this whenever app is launched or when you are navigating to a particular flow then this API call can happen just in the background irrespective of the network condition if the network is not available just don't make the network call you will continue to use the version which is available and whenever the version is new version is available whenever you make this API call in the background you get that information it is available for your next plan so for the user he is just consuming the previous data there is no change and there is no loss in terms of experience or it is not like an infinite progress by coming and waiting for the response to find out whether that is the latest data or not important part of it is it fetches only if the content is changed which also means you are going to save in terms of network data so if you are having a content app which is like a news app become a feed based app where you have multiple categories then this actually comes into picture a lot and in fact the example that we had seen before the movie TV experience you see the left one and the right one the left one is without the categories version and stored the right one is with the categories version and stored since when the app comes up at least it will not show that complete blank screen to the user making him think things are completely broken we view that feeling that it is partially broken so whether partially broken is good of course not we are going to see another design pattern later which will solve the problem this is the flow diagram for this once again the key player is content manager and the cache is the one that helps storing that skipping this slide in terms of flow so the other important design pattern which actually came into picture long back today is by Google very greatly in the recent times the name of service worker and background sink is prefetching information so essentially user behavior in emerging markets is always like we move around a lot and we get good network connectivity when we don't need it and we get very pathetic network connectivity when we need it and just to utilize that amazing behavior we do prefetch when it is available we keep all the resources and everything ready and we use it when the user needs it prefetching and updating the background for now if you take the progressive perhaps in the consideration it works well in browsers like Chrome but the design pattern is pretty generic in terms of you maintain a manifest which is returns you the current set of resources that you want to download and you download them whenever network is available and probably user is connected to wifi when the user connects again you are actually preserving them from your local cache so essentially it doesn't matter at all whether the user is connected to a good connectivity or not you will still be able to provide that good experience to the user progressive web apps they follow this approach you can use download them in wifi and avoid the data consumption so there is another call out to be done here because you are going to use wifi for those majority of download if you have written that logic that way then you may also end up reducing in terms of data cost to the user because the good chunk of your download has already happened in wifi which is non-metered and the remaining things happen in the meter network I used to have this misconception that because geo is available nobody is I mean facing any data issue anymore I learned from my friends recently that they are still running into data balance being I guess there are many things to download in the internet these days geo is not actually solving that problem completely we are still running into that data limits so please be cautious around that part and do not penalize the user this is the design pattern which is for the service worker I just kept this block diagram for the context essentially service worker fetches the data when you are having the background sync enabled and when the app is progressive web app is opened by the user it can decide whether the content will be served by the service worker or from network a generic flow diagram will keep the same behavior without worrying about service workers and progressive web apps and this can be done for any platform as such I understand IOS will not I mean IOS does not support that background service directly but still you can maintain this manifest and then downloading resources logic and then you can trigger them whenever app is open so they will be downloading the background in IOS as well and then they will be ready when you launch the app again later next is another design pattern which is actually done very very well by whatsapp how many of you have probably used whatsapp when network is very flaky or almost not there have you tried sending chat messages to your connections when network is not there have you ever seen it crying saying network not available won't ask your geo provider all those things the best thing that they had done in whatsapp is probably avoiding that retry tap to retry button in their messages I think in most of the other messengers we will see that irritating thing that we are not able to deliver it right now we will please tap to retry and LinkedIn is the father of that I mean we want to send that message send it when you are when you can and why are you even asking me to tap to retry again as if I will change my mind after 5 minutes maybe for those people whatsapp is not the best tool anyways so how they do that is pretty simple they know that you just want to send that message it's an asynchronous operation it doesn't matter whether it takes few milliseconds or some more time to send up providing you that option of sending that message when you tap on that send button just for train something I sent a message the first one if you see I am not very sure if people at the end are able to see the status there so if you are sending a message without network it will just give you that history icon or whatever training out icon and later after few moments whenever network is available it will send that message and then it will update the status how is it different from tap to retry we all know just that we have to be there and then retry and this is like a helper who is doing it for you and this provides that seamless experience where the user who is actually receiving the message even if he is not online I remember even if you guys have seen like few years back the messengers used to tell us that the other guy has gone offline you cannot send the message anymore whatsapp has removed all those barriers and screwed our life flow diagram for it actually this is pretty simple so we actually kind of maintain a class name lazy ABA manager where whenever you want to make a network call for which you are not really worried about the response immediately but you want that to be successful you just post it to the guy this guy maintains in a persistent cat he makes the network call in a batch to manager or some other way later then he gets the data back and you get everything ready you get everything done at a later point of time without even knowing when it is done if you hear that story again this is what happens with analytics is the case so you actually post all your events when you are offline online whichever line and it stores everything in a DB and it batches those requests those thousand year 11 events that you are firing all of them are batched together and they are sent to the server which we never look at it how many of us are how many of us are consuming all the events that we are hitting to the server and make sense out of it how many of us are using 50% of the data that we are hitting as part of analytics how many of us are using 10% of the data there are 8 layers in the room that brings us to another friend how many of you are having facebook app installed in your device how many of you are still using facebook I think you guys have made a good decision but let's still go through the design pattern that they have done which might be useful later in your so the facebook feed which is getting centered as per one of their blog post is not anymore cooked by server and this is a pretty good design pattern and I would really encourage everyone who is doing a content based app to evaluate this in your setup may not be applicable directly for you but at least you will be able to apply few of the learnings from whatever they have done or whatever they claim they have done and it will be very useful so the first thing obviously we want to see the list of cards to be shown up on our mobile client that is our focus generally it comes directly from server because server is intelligent enough only intelligent enough to order the cards in the way that user should see most of the product managers have I hope there are no product managers here and in the mobile client instead of going to the server it essentially goes to another local manager which is like a pool of stories you can assume for them they have considered this as a passive component but you can assume that this pool of stories is an active component which is actually deciding which card to be shown and it is not based on what is the most recent card which is available they are deciding based on these various factors the ranking score which is coming from server is one of the parameters but they try to see whether this particular story type is going to work out for the user at this point of time whether the story is completely good for example a card which is someone's birthday wish having some gif and some few other resources probably comes as a metadata with only text and few URLs yet card is completely good when every resource which is required to show that card completely on screen are available so this pool of stories are the guy who is actually managing all these cards internally verifies whether all the metadata and all the resources required to show that cards are available and then take a call on adding that to the feed so if you have seen in the recent times facebook does not show those empty images or random cards are used again but we do not see a lot of missing images we do not see a lot of mismatching content in the card just because they always ensure that a cooked card is shown and also there is another criteria related to the network condition so for example if you are on a slower network even if server gave you lot of video cards the client will actually filter them out for that session and it will show you image cards and textual cards which are ready at that point of time and if you have an extremely good connection they have a connection class written by them they have an open source library so they will provide that information they will decide based on the information available from the card to show or not based on the current network condition so essentially this app is not network agnostic in the implementation it does not show everything irrespective of the network but it provides that experience to the user that there is no mismatch or empty card to the user it is always a card which is like working condition and if it is a video card and if you are in a slower network it ensures that it does not even show it up and this ensures that experience which is clear obviously whenever it needs some more stories to be fetched it talks to the newsfeed backend it fetches them and it starts processing them in the background that is why Facebook is still one of the best battery killers and I used to always have this conspiracy theory that Facebook has made a deal with all the OEMs to ensure that they take care of the battery and you always have to update your phone every year the last part and probably the important part which gives you that flexibility in terms of when you are completely off network how does this information come out that is provided by this persistent cache and this persistent cache is just keeping all the cards which are ready are partially ready which was served from backend before hooked by the bull of stories for future use so essentially if you have seen in some scenarios you might see in Facebook app or you will see some cards which are very old a few weeks old at time that might be because those are stored in the persistent memory and they came up are probably some unknowing friend of yours just like that photo and it bumped up the trade ranking moving on to another design pattern or this is more like a technology pattern options that we can provide in our app by providing network interactions that might need mobile data the slides which are going to be from here are as useful as till now so you can take a call so the sms and ussd based transactions are pretty simple if you have seen 99 hash in your mobile you will be able to dial that and then kind of make up transactions to any other account or buy stuffs and actually this flow explains railway ticket booking and the next one actually explains transaction in terms of money transfer and other things the flow is pretty simple we can try it out this and just move on to the next design pattern which is final one thankfully for all of you and this design pattern is prefetch and pull notifications pretty simple our gcm is not reliable our network is not reliable our users are not reliable everything is reliable so we want to provide a reliable mechanism to send notification to the users and pull notifications are going to provide that flexibility for you so essentially you fetch notifications once in a while and with those notifications you also get the short time and expiry time so that you can actually schedule future notifications and then they will be available to the user even if they are not connected to network so if you have a sports app and if you want to notify user about some game being started you can send this notification even much earlier and say you can schedule this notification for a particular time and this will be available so this information need not even come through push it can be just fetched by the app and then stored and then shown when the right time comes that is about it next one is target reading notification which is nothing but immediately after receiving the notification you also fetch all the resources required to load the landing page and in that sense you achieve that flexibility that when the user is opening that notification it may not need network connection or it may not need faster network to show the content you will have everything ready and that is about it this particular design pattern once again we have the flow diagram I work for Uber and we are having a booth here so once again we can always have a catch up and understand what we are doing and we would like to discuss with you guys how we want to improve the networking experience in India and all other emerging markets yes for work would say I have reached to the end of the slide if we have any questions I am not very sure if we have time for questions right now we have so if you have any questions please go ahead I think we are not using that client side feed generation we are mostly in different markets we are not using ussd yet otherwise I didn't take those examples from our codebase because I wanted to keep them generic and call out some of the open source and other popular platforms which are available but we are most using most of them if you open the Uber app most of the time you will get that experience atleast show caps in the previous position and then it will load the new position yes we are using most of the patterns yeah please go ahead so in the background these pictures are coming up soon and already live so some of them are not available so if I understand correctly all the background restrictions that are being brought in are mainly around those hard scheduled background services or services which are running for longer time essentially they do not want to block the experience of the user who is actually using another app in the foreground and you are in the background in fact in most of these design patterns you should just stick to something like a firebase job dispatcher and if you do that you will essentially get that flexibility in terms of because google play services is running that show it will know when to trigger your service and it will have options like on start and on stop you can say I want to run this service for some more time once your service is done you can say job finished and things like that so it is not at all a problem and it is in fact recommended you can use job dispatcher to do lot of your work just you have to be careful in terms of fetching too much of data or things like sometimes the interest of keeping the experience amazing we end up prefetching everything in your server that should be avoided but otherwise actually these background restrictions are mainly for those services which affect the performance of foreground apps that's it awesome so even if you have some queries later we would love to meet you guys please do visit us please ensure we are not feeling alone thank you