 Don't I'll just give you a brief introduction. We are an e-commerce company. Basically, we are into ticketing. You can buy tickets for movies, Facebook, anything that you need in India. Okay, so today what I'll be talking about is how we rebuild the entire app which you already have right now. We have rebuilt it from scratch. We will talk about what went in, why did we decide to do all of those things, and give you a brief idea as to what is happening. So this is the short agenda as to give you an idea of what we'll be talking about. I will get, anyways, we'll go through them each one by one. So when I say a rewrite, I want to talk to you about what kind of a rewrite it was, whether it was just a small UI, what did we exactly change? So to begin with, it was a ground up rewrite. So nothing from the old app was used. None of the source code was used on the new app or anything. It was not only just the code which was not being reused. We changed the entire UI and the UX of the way the app behaves. So the app has been having the same set of UI and the UX from like five years now. This is the first time we have gone ahead and changed it to revamp it totally end to end. So just to give you an idea, even before I delve into the recalls, the new rewrite took us approximately about three lakh lines of code to get done on the existing, just to replicate the existing app out there today. The new app has three lakh lines of code. Took us eight Android developers, around 10,000 cups of coffee and like six months of time to get this done. So that should give you an idea as to what kind of a rewrite it was. So today before, by the end of the talk, what the aim is to give you an idea as to should you rewrite your app? Like what does it do? If you are in that boat, whether you are considering, should I rewrite my app or should I just patch it up and let it work as it is working. So that is the objective of the talk today. I will try to help you take that decision as to what is happening, what kind of effort is involved so that you can make that decision whether do you need it, do you need a rewrite. So we'll begin with looking at book my shows motivations of rewriting first. Like why did we choose to rewrite? So what happened was a year ago, I was given that option to improve the performance of the existing app or do I want to rewrite it? So I of course took the rewrite option because I always like to be latest. So a few bigger motivations we'll look at as to what why did we choose to rewrite it is not just because I wanted latest. So I'll break them down as problems and challenges. These are problems and challenges that the old app had previously, which we wanted to overcome with the new rewrite. So the first thing which would I would classify as a problem was spaghetti code. So if you don't know what that means, it does basically a bad paradigm in like a word which is used to indicate bad code in general. So there is nothing called as bad, bad code. It is just that it lacks something like a naming convention. So if you see the examples at the right hand side, you can see there is no standard being followed. The variable naming is all over the place. There is underscore being used. There is a lower case of a case. There is everything in lower case. So not having a naming standard will hurt you in the longer run, wherein a new developer comes to you. It is very hard to read this code. Like if you give me the code, I would say I will not be able to understand what is happening here. Lack of reusability and modularity is again a big challenge that we had. So we have a as an example, I'll give you a rating screen in the app which the app has. So you can rate a movie. There are multiple screens where you can rate the movie from. You can rate a movie via push notification. You can go to the synopsis page of the particular movie and then rate it. You could even go to the ticket history and then rate it. So like this is just an example. So this is like three places where you had it. The old app had the rate functionality being returned at all the three places. Each activity had the logic being there. So why it should have been just in one single place so that you know, okay, like rate as a functionality is one to the entire project. It should not make a difference where you are calling it from or where it is being used. The other thing which was a big major hurdle was tight coupling between the business logic and the UI. So if you can see this example, everything here is very use case specific. And if you see at the very top, like you see you you see GA so Google analytics code. So right from your analytics code to your view to your business logic of modifying checking whether it is credit card debit card, all of that was happening in one single screen. So tomorrow when you modify the screen it is you just two things. One is breaking existing functionality and it is very hard to understand why where what is happening. So debugging also becomes a problem. The other biggest challenge which book my show had was scalability. We over the past years, few years have been growing at a scale, which we did not anticipate. Our users have downloads have grown up and users users drastically, but the app has not been able to keep up with the same. So and adding a new feature was very hard. So in general, I'll talk a little about what scalability issues we had as well. A lot of it was redundant duplicate code. Again, I'll come to a simple example. This is how the world have used to make a HTTP call. So every API call which you make would go ahead, create a new HTTP post, HTTP URL, add those patterns, do the basic text and then make the call. So what would happen is for every API call, the same things would half of the things would keep repeating, but they were just written everywhere. So a lot of duplicate code was being there. This kind of code is very hard to refactor. So as an example, let's look at that. You say I give you look at one, two, three, fourth line that it has a parameter called as a timeout and it takes in a 30 seconds, 30,000 millisecond kind of. So let's assume you wanted to increase or decrease this timeout for all the API calls with this kind of structure what would happen is every single class you would have to go and modify that 30,000 value, which is very bad if you like, you know, have to touch 20 different files to make one small thing. Ideally, this value should have been at one place and that updating that value should just be changing it everywhere. So it would be kind of started becoming hard to refactor. This call started causing delay in our app really cycles as well, wherein our app updates started becoming slower. And of course, when you have code like that, you end up with a lot of regression bugs. Like when developer tries to touch something on a particular screen ends up breaking somebody else's feature on that screen altogether. So it becomes very cumbersome. And again, this also affects your development cycle in terms of everything that you touch on that screen has to go through a thorough QA process. And that takes time. Like you have to get through QA if there is something broken fixed, that cycle keeps on happening until you get there. So again, a lot of delays being introduced before for a very small functionality also, like imagine adding just one line of code and you end up saying, okay, I will take four days to test it an hour to develop, but four days to test, which did not make sense at all. Like it was becoming the bottleneck for the company. AB test. So what the company has a challenge wanted to do was try a few things based on AB test. So basically wanted people to look half of the users go to a particular, see a particular view and rather see a particular view so that we could take our conversion ratios and all of those things as well. So that was very hard with the new old app to be done because of the way it was structured. It became very hard to run a AB test and that was something was the company wanted from a long, long time. So let's look at what we did. These are some of the major challenges and problems and the motivations behind why book my show was really good. Let's look at what did we change? Why, how did we do it? The first thing that was changed was the architecture. So for over the past two years, you have kept clearing MVP, MVP and so many of these have come up. Like everybody keeps saying MVP, MVP is great, MVP is great. It helps you do that. It helps you do this. So one thing I had always complained from the past two years was there was no example out there in the production in the wild saying, yes, I have used this in a production on a 10 million plus user base and it works the way it is saying. Everybody says it is nice. Everybody gives the most talks about it, but nobody did it in a real world. So we took it up as a challenge on ourselves. We wanted to run a very leading edge kind of tech stack for the new app. So we changed the architecture to MVP, doesn't have to be MVP. Like I keep getting this question a lot of time with architecture is the best according to you. I would say there is no silver bullet. It is based on what you are trying to do is that is more important. MVP suited book my show does not necessarily mean it is the best or it should suit you. It depends on your use case. So you don't know what MVP is, just a quick glance on the right side. You break up your code into use presenters and models. Presenters are basically responsible for the use of basically responsible for the UI. Presenters and models being your business logic and presenters being the interactor between both of those things. So we changed after the architecture the big change was the user experience in general of the entire app as I mentioned. I will show you a few things. So now we have smart filters in the new app. So a lot of people if you have been using the website you have you already have used this feature on our website wherein you could filter show times by time and price as well. You could tell okay show me all the shows all evening shows within the price range of 100 to 200 and we would filter that. So that comes up with the new app. We have those filters now. Seat layout something which was a most used screen in the entire app which we have today. So what we noticed was a lot of people would go to the seat layout screen then figure key they did not find the best seats which way they were trying to look for. So what they would have to do is go back change the show time change the category and then come back again. That was a little frustrating like you know how many times would you go back and what all could you take. So now the new app gives you a quick switch at the top itself. If you see you can change the show time right away from here itself. This is a 8 5 p.m show. You could just click on it and get the show time. You also can change the quantity as well. So previously it was very hard to change the quantity you would have to go back choose the show time again and choose the quantity again. So now you do not need to do this everything happens in this single screen itself. The synopsis page went through a bit redesign as well. We now show you very rich information about everything related to the movie right from the runtime to the lead cast and a lot of things on the synopsis page. The other big thing that happened was unit testing. So as I said that cycle of update kept going higher and higher. One hour of code would four days of testing did not work out. So we started off with that approach where we wanted everything to be unit tested within the code itself and not rely on the manual QA thus reducing the times. So this is just a sample test which we have which basically test presenter as of this is the presenter test I believe. So that is one thing. So this is why we did it. This is what we did. We chose to do a few things different from what you would have seen in the regular Android voice. We will quickly have a look at what they are packaging. So the general packaging has always been of the factor you club all your activities together you club all your adapters together. So what ends up happening is you have if you are having you have an application like book my show at that scale you your activities package has like 300 lines of active 300 classes activity you have 200 adapters so it becomes used and like you know it is very hard with not no standard naming convention it becomes very hard which adapter is being which use where which makes debugging harder. So what we went ahead and did was package strength by features. So as a screenshot if you see everything related to summary page would be on the summary inside the summary package everything related to the settings and the seat layout would lie in the respective packages. So tomorrow when you have a bug that is how you get a bug right somebody reports a bug to you he says on your seat layout this does not work. So I exactly know what the set of files to look at to it becomes very easy to debug because seat layout I know there is a package named a seat layout anybody can debug it not only the developer who has written it just to give you an idea what the package internal packages look like. So let's look at coupons as a feature internally we have coupons as a functionality has three sub features you can add coupons you have to get the coupons from the server and you can remove the coupons which you have previously added so they are sub package as well based on that standalone module. So Arun also spoke about just in his graded morning in today morning wherein break up your project into different things and add them as a dependency that is exactly what we have ended up doing. So on the right hand side if you see our network our analytics error models all of these are separate projects and repositories by themselves. So what happens is your motivations are two one is it is easily refactored today we use retrofit as our networking library tomorrow if you want to use volley for some reason move away from retrofit it is very simple that does not need to change some some team can independently work on the network module fix make those changes give me a pre-compiled jar or a new versioned ar file and I just include it so that becomes dead simple in terms of integration and your timelines become parallel. So previously what would happen is if you are trying to do volley you would either create a separate branch and then merge it and you would have conflicts or you would wait until he finishes and then start on with the changes he has done today you don't need to do that because both of them can work parallely without since they are both two different projects all together. So this is just an example of how we have broken up all our things into separate repositories just to give you a fair idea as to how we maintain how does I how do I know with with moving from retrofit to volley nothing breaks so we follow try to follow the standard Java API kind of structure wherein if a method is public and has been exposed in any version or a jar file which has gone out the structure and the parameters the return type nothing ever changes so if you see my app always talks to network manager does not does never talk to retrofit directly network manager talks to retrofit and gives me that thing so I have created this abstract layer if you see this there's something called as get trending API if you see there is no mention of retrofit within it and the response return type is of observable so the app who is calling this will only call get trending API does not need to know whether I'm using retrofit or volley for that matter so you could easily switch tomorrow and nobody will even have a problem with it same thing with the analytics thing just to give you you a fair idea we have a rapper class on the analytics manager as well self sufficient view so this was a pretty interesting idea I'll take the rating as an example again as I said it was being used in three different places in the entire app you could write your code logic in one place but you the UI would still need to be included in three different places we were still not happy with that we decided why can't both the UI and the logic stay at one place and everybody reuses it so this is what we went ahead and did so there is something called as a view provider a abstracted layer which we have written on top of a manager kind of thing the activity whoever wants the view right asks the view provider to give me that view what the view provider does is it builds that view returns the view and you can just show it in your activity does not have to be declared in your XML pre predefined so you could essentially put it in activity ABC as of today and tomorrow if you want it indeed it would just be one line of code just to give you an example as well this is what the code looks like so we used view stub here in this case you could return a regular view also it would not make a difference so if you see he just inflates the view so does the find you by ID has the logic for everything inside it sets the click listener as well so this is a self-sufficient view it not only returns you the view but the click listener on those views also are handled by that itself so you say give me a ratings view the ratings view comes up the ratings view has edit text now it has a submit button wherein it has to make an API call so you as a developer do not need to know somebody has already worked on the ratings view so you say give me the ratings view and when you click submit you do not need to know what is happening with API to head what to do all you need to know is whatever the value is the view will take care of it so you do not need to bother at all so these views are self-sufficient in that way wherein the logic and the UI is both on them itself so I in particular was not happy with the way android developers write API request calls params the way you too much of lowercase uppercase mismatch of cases happening too many problems occurring so what we decided was there has to be a better way of doing this we wanted to be very user friendly developer friendly more like so that any new developer that comes in the company it does not have to go through like 10 20 different documentation just to understand what param is the key and what is the value type it is expecting so we created something called as a param builder these are nothing but simple plain old Java objects so if you see this is just an example this is a plain Java class which has a ton of strings and defined in it so these are key and values defined here so what that lets me do is looks like something like this so I say new API builder and I do a dot on it now since this is a separate project and as I did as a dependency I get autocomplete on it so I the moment you do new API builder dot you see all the available API which you can make a request to and once I choose the same API which we just saw and it do a dot again you all see the set parameters available so you do not need to know what the key are what the URL is what the type is you don't you as a developer do not need to bother okay like is this a post request is this a get request what are the keys that I'm supposed to send to this what are the session time modes that I'm supposed to send so none of that is on the overhead all you do is focus on the values which you need to be sent so they are written in a way wherein they are human readable as well so if you see set app version who is version so that you just understand just by reading at it okay this is what I have to send and the dot build API parameters will set up everything and give you a custom object of the thought so two things here as I mentioned improved readability autocomplete just by looking at this piece of code I can tell you what parameters it is expecting and what is not I do not need to look at the documentation dimension naming so we were again unhappy with the way android developers name dimension file it is always a fight between these two you either take a very generic approach as at the bottom you define font dot font underscore large font underscore small or you take the very specific approach give it the activity name underscore image underscore all of those things so both have their own set of problems so the below one has this problem wherein if somebody is using font dot small and tomorrow somebody changes that font dot small from 12 dp to 14 dp everybody who uses it breaks away who whereas you might just want 12 dp there and 14 dp somewhere else if you use a specific one you well that's all the problem you end up with tons of duplicates 16 dp 16 dp has been declared like many times in your things because all of them are specific what we did was embrace both of them so if you can see at the top we define something called as demand underscore 3 dp 4 dp 5 dp 6 dp at the bottom there was specific naming so in this example particular you can see c-clayout activity underscore text coupons available size and that would then reference the dimension declared at the top so now it avoids those duplicate every dimension is declared exactly one and you still have that specific city so that you can debug quickly okay this is the dimension which is being used so you do not need to know what is happening so I would want to talk to you about what were some of the learnings or the outcomes which we read like six months we have been working on this so I mentioned using MVP as the architecture which we use for the new app one thing which we realized over time is I would not call MVP an architecture I would call it more of a design pattern it is not really a full-fledged architecture architecture it is more of a design pattern use it if you know what you're trying to do if you want clean code this is one way of doing it but it is not a full-fledged architecture kind of thing wherein how MVVM would work so that has been one big learning so you always can't skip anything about talking about without talking about multi-dex so if you are using the latest stack something like a retrofit dagger and anything on those lines rx java you will hit this limit very fairly soon like there is a blog post as well which says if you use google play services along with these four libraries you will hit the 52k limit without even having one of your own methods so out of those 64 65k 52k methods are gone away so that becomes a problem so of course your easiest solution is multi-dex go to your application class multi-dex.install this end of story multi-dex should work our experience has been different so what happened was we started facing a lot of crashes on devices which are not up to the mark with google standards so xiaomi phones redmi phones what would happen is the app would just crash away like it did now so one thing is that take care of it one quick solution if you are running into that same problem wherein it is crashing on such devices is extend your application instead of extending your application class by just extend multi-dex application that solved a lot of crashes for us I have no clue why though the other thing which you need to look at when you enable multi-dex is the startup time so one thing that has happened is the startup time has gone up on a device below api level 21 where multi-dex is not supported natively the startup time on a cold start might increase by a few seconds so that is something you should seriously consider whether you want to do it or not maintenance so after all of this the whole reason of doing this was maintenance one thing I would say is it has been able it has now become very easy to maintain a particular the app in general so we do not any longer feel a problem when it change comes since the views the presenters and everything has a single responsibility I know what to change before and it does not break anything since you have unit test the unit test automatically tell you before even before you give it to the qa that it that it is breaking you need to fix it so maintenance has become very simple very easier to do maintaining the app is now very easy in general the other thing is adding new features so adding a new feature also has become fairly simple as an example our previous average time a new feature basic feature would go live on by a developer single developer would be around seven to ten days worth of work today after the new architecture we are seeing the same feature when we rebuild the same feature on the world app and the new app as well so on the new app we are able to do it in like two days so that is one big gain like your development time will drastically efficiency wise will improve so that is something which you might be interested in if you are looking to build a product on the longer run wherein you have a lot of features planned and scalability and maintenance is your concern then I would definitely suggest you to rewrite it in a particular fashion does not have to be MVP as I said you could use any MV VM any of those whatever suits you better I like to call it MVW M model view whatever so you can use whatever you want to do it with it will just work the same to be honest so that has been pretty much what we have done I'll just talk to you about what we plan to do in the coming months as well dynamic view rendering so this has been on a list for a while now so as you saw I spoke about self-sufficient views what we want to do is send some data some sorts of JSON from the server and render those views on the fly without an app update so imagine doing this wherein I have a recycler view with I have a ratings view so tomorrow on any screen the server sends you a particular key all I need to do is just inflate that view there so it does not make a difference any longer to us so eventually what we would want to do is control view rendering all together you would want to be able to position items one below after all from the server without an app update one thing which I also forgot to mention is when you use architecture like this for that mvp mvvm your code base increases in size what used to happen in one single java class with one activity is now spread across five to six different classes you have interfaces you have use case controllers you have their presenters for each just one single screen you have six different things so that takes time like development time goes up there writing six different screens in their respective packages all of that takes time so what we were able to do we have a basic demo of this working wherein we used annotation processors to generate all of this so what did happen is you could go to a terminal right now it is a command line tool you could just go to a terminal and tell him what you are trying to do give him he this is the name of the screen and I need this kind of a particular view what did you do is two things it would give you a view let's say you say give me a recycler view with this name so what it would do is it would set up a activity for you it would set up a adapter for you it would give you a recycler view in the xml and would take care of writing the presenters and the domains all together you just have to go there and put your business logic all the boilerplate for you is generated all of this happens at compile time using annotation processors so that is something which we are very excited about in the future we would want to generate a lot of code like this wherein I could just go to the terminal in this project I want a recycler view with so these these these features and it generates the basic setup for me I just have to implement the business logic out of it so we would eventually want to move to an event-driven architecture we used event buses in our current in the new app as well specifically we used auto our experience has been a mixed bag kind of thing wherein it is very nice in decoupling everything you don't have that hard binding okay I need to implement this interface on this activity it takes care of it by on subscribe and push but one big there are a lot of problems which we face with event buses in general so as a quick example what I could do is let's look at the show times so you have a show times response model which is created of same plain old Java class we just created now let's say the user went to the screen he's shown a loader the network is call is still going on he went back and came back quickly so what would happen is if the response would come since the model object is the same for both the api calls that happened so I would there would be no way for me to differentiate whether it was the first one or the second one that came through so that becomes a little problematic in such edge cases everywhere we have to have a flag kind of thing where did this user call something so that has been a little big learning wherein event buses have been a little backfiring to us to be honest that should be it I should be open to taking questions I have 12 minutes hi thank you for the talk so is this new app was like parallelly getting build like meanwhile the old app is there or like how was the development process so we in book question specifically what we did was we had a four member team android specifically i'll talk android specifically four member team existing who was maintaining the old app we did not touch those resources we hired a built a parallel team of eight members and they built it within the six months so both of them were working parallelly for the past six months currently this new app is in a strange rollout phase wherein it has been rolled out to 20 percent of a user base by the end of this month every it should be on 100 and everybody should have it but then how did you handle like the code duplication like a feature being developed on the other one and then you probably have to afford the code on the new one because you need a right like everything from 100 correct so what a good question like you know what happened was there were a few features which the old app could not wait for like we could not push those features away so what we ended up doing was of course we had to write the old app team wrote the feature on the old app and while the new app team did it on the new app because the architectures were way too different to reuse anything to be honest hey yeah so we had similar issues while dealing with auto building an event-driven architecture and using like a view page or something and ridiculous number of flags and publishers and subscribers to just figure out where the event is going when you go out of the app and come back in so how did how did you fix your event-driven architecture because one day we woke up and they have put up on the GitHub page saying we have deprecated it please use rx hour so you're like you know what we just deleted from our app we are not going to use it anymore so how did you deal with this so there were multiple solutions which we came up with one was you could modify the if you are talking about the same screen thing right on the same screen if you are getting he goes back and comes back again and the call comes called gets two times and you get two responses of the same type what we one simple solution was having a flag enabled whether I have called this API already in the past or not that would tell me whether okay have we already called this and there is the response coming supposed to be something else so what we ended up doing like that was a quick hack to do it what we actually ended up doing was we use rx Java and observables to for our networking tied with retrofit whenever you the user went away and we did not need that information I would cancel that API call all together or unsubscribe so you could either cancel that API call the first one or you could just unsubscribe the current subscriber yeah so we are doing the same then yeah whatever was a very bad decision to be honest like in the coming future I would get rid of auto and use fall back to interfaces yeah thank you yeah so you're showing your code so at one place you had the dt problem and you assigned variables to all the dp sizes correct so I mean we followed I was sometime back I was working in Monster and we followed the same practice for colors and I mean I was doing that and I was wondering why am I doing that I mean that's a that even though I implemented you know our manager and everyone told us to do that but I found it to be a very bad practice because in the end all color like a color 93 you know the whole hash code a hex code and map to the color itself and they were about like 100 200 colors same thing you did for the dp thing correct so but I mean I think there is no point behind it what would be the use case of I mean what could be a possible reasoning for you to do that so it is debugging becomes easier so what happens is when you have a huge layout and let's say you have like 14 different colors in that thing and you have no clue which color is binding from where okay now when you want to debug what would happen is you would have to click click click go to that then realize okay this is not the color I am looking for go back this is not the text you color which I am trying to change so what would now if you look at my slide what so what this would do is with such specific naming conventions like seat layout activity image coupon tag height I exactly know what you I am talking about on the UI so we try to map it how it looks on the screen in our XML as well correct correct so so you are saying like I could have just written 6 dp here correct so we did that we did that we started off there the problem was 10 different developers 10 different screens everybody wanted a 8 dp everybody would define 8 dp 8 dp 8 dp we had 10 8 dp so duplicate so that is one way of handling it where when we wanted to be unique hi hi on what bit on what basis did you choose 20% of users to enable new application so that was a stage rollout we started off with 5% at as of now it is at 20% so it has a place so place or stage rollout we do not choose the users how do you see the difference between old app and pardon how do you see the difference between old app and new app very drastic differences one thing is development is easier today we are able to do things which we had never imagined we would be able to on the old app one example is deep linking what we ended up creating was one single class with deep links everywhere so today you could give me any book my show html link and I would be able to deep link it to a particular section in the app and it is very smart enough to figure out fallback so let's say it will be smart enough to figure out okay you tried to open this page but you did not have a particular value which was needed to render that page what did you do is it would make an epi call get that value and then render that if that is a possible use case how did you find out the area that you needed improvement so most of it is user feedback since the website went live a lot of people have been asking us for price and this filter on the app for a long long time so majority of our us changes have been driven by users feedback so I have two questions one is that are you going to make a few things that you think can be open sourced like these auto generated code and dynamic view rendering or things like those so we have spoken about it we might not open source the entire thing but we might just put up a demo sample which gives you how we did it so as to just to answer your question that auto generated code right look up something called as annotation processors just try to figure out to match your use case it has nothing look just so if you have used butternife in the past if you have used dagger any sort of annotation like if you have used android you know annotations at the rate overwrite that is what tells android okay you are trying to do something so we use the same concept where and we have at the rate generate at the rate generate make presenter what that would do is you will need to just compile it once and when you run it it would automatically generate a set of classes in the folder so but yeah hopefully I will at least put up a sample project which you can look at and mother question is like how do you deal with db schema updates so do you use a no-sequel kind of thing or you will use SQLite or how do you work so the old app uses SQLite the new app uses rel so there is nothing much of a difference apart from the speed and the performance to be honest it still has the same problems from migrating from the older to the newer version so you write like multiple schema changes codes again and again like if we have to so one thing which we have learned is writing for scale involves a few thinking changes as well the way you think about it was more important so today whenever I ask request the server side things to send me a key a response a value kind of thing I usually ask them to give it to me in a json array instead of a json object so let's say tomorrow if today let's say ads we are doing native ads within the content so within the movie list you see a third card being as an ad so that ad would come through but what would happen is okay today you wanted to do one ad tomorrow you said to add now your json structure changes you can't break the older api but you want to have the new one so what we end up doing is we created json arrays so json arrays with one element as of now so tomorrow if you want to scale you can keep just adding whatever you want to that is one thing on the client side of things is we try to make it as I said I try to maintain a very public kind of facing interface from all those other projects so what we do is we usually take in our hash map as a parameter okay so what hash map let's me do is add multiple params over time without breaking the constructor so if your constructor is not changing you do not have to bother and of course we use dagger for dependency injection as well so everything is injected rather than being created so testing becomes easier so hash map has been a great thing but hash map again comes at a cost memory is on the higher end for the hash map compared to a comma separated string comma constructor so we try as much as possible to keep the hash map structure followed because it works for us because our requirements keep changing that much let's say we are using certain library for now okay so we have a non-standard phone and that library doesn't work so how do you are going to handle it so never actually came across something we do not support non-google pay services nothing in china everything has been in india for so honestly that does not we have not really thought about something like that can you give me an example if something has happened to maybe i can then relate like why would a library work on x and not on y because at the end of the day just java right so you use rx java rx java is still java at the end of the day it's not something else just a simple thought that if you are using an image library yeah so sometimes it might work and really it didn't come out across that such cases okay not really to be honest we have never faced something like that yes we do hi you said you are using you developed a view provider for reusing some components like and not only views the functionalities attached to those views also yeah so why didn't you go for fragments for developing fragments instead of creating new view provider and so fragments provide can provide the same functionality i guess correct but so fragments we have two problems life cycles being attached which i do not want to be responsible for i let's say just want to show a dialogue on a screen i would not want to use a fragment and if you are using a fragment you need to know the position of the fragment beforehand in your XML that can be handled you can you can to be honest but we chose views were simpler so if you see the synopsis page had a small strip of lead cast right so that has been written as a separate view and functionality together so tomorrow if you could give me a event a movie code i could randomly show that view in any screen of the activity without anything okay but again the fragment should work as yeah hi uh just want to ask like uh there are two questions from my side one like why do you choose mv mvv m over mvp like what specific problem you are not able to solve by m using mvp so mvp also what we chose right has been heavily customized so mvp clearly says your context android and all of those things need to be there we have customized mvp also to match our requirements and one thing we have learned over time is there are always exceptions so if you look at the seat layout screen which we have there is too much of interaction happening typical mvp implementation would mean your activity and the presenter would need to communicate via the click would need would go to the presenter the presenter would then call something on the view so that was too much of happening so seat layout is the only exception in the entire app wherein we have everything in a single activity again so mvp we chose for mvv m because uh mvv m we did not want to be uh doing view models and we had no interest in data binding anytime sooner so mvp seems like a more possible solution because we wanted to unit test our presenters independently as well so all our presenters ideally in an android mvp project the presenter can contain context application android related things but we have made it a point our presenters also do not have anything android related so the only thing that is android related is uh rx android schedulers dot main thread which obviously can be switched with a test subscriber okay so like you are saying like you are prefering mvp at the end of the day we are because it's a pitta use case better okay and like but you said like uh like you are using some of the properties of mvv m as well so we not only use some properties from mvv m we have looked at wiper which is an equivalent of mvp in ios okay so we really like the router vip er r is the router part of it so we modeled our navigation and everything on the router side of things so i have a class called as router or java which is one single place anybody who wants to navigate anywhere in the app has to go through that screen so that happens wherein like you know you get a push notification that screen comes he processes everything and he knows which screen to redirect you to or if that screen is not available at a particular point of time maybe like a new feature was added in a newer version of the app versus older version to one ita so what it would do is it would gracefully fall back if it is a web either open a web view or give a error to the user i think we can do that simply in mvp as well by using rx like by using subscribe or unsubscribe i think we can do that you can you can i'm not saying you can't i'm just giving an example as to what we have been trying to do it's not just looking at mvp or mvvm or something else it is trying to pick up things which are good and across even across places as well thank you yeah if you had to estimate the time it would have taken you to refactor the app what do you think it would have been pardon if you had to refactor the app how long would have uh the new app the old one so i give you a timeline oh you started from scratch right it took you six months starting from scratch if you had to refactor the old app into the new one um difficult to be honest uh i would give it into the new one as in what terms like do you want just a number of days you think it could have taken you like when you're deciding to refactor or rewrite the estimates it would have taken me approximately the same time to run based on the tight coupling right every screen i had to do that so that makes it also i didn't quite understand the dimensions thing you've done here because you still have the dimensions on the score 28 repeated as many times as you would have if you just yeah but that is just a reference to it right and it is declared at once so it is not i'm not defining 2dp like two different times it is just referencing to the exact same thing but they still have a one-to-one mapping right like with dimensionals go 28 wherever you would have had 28 so that's a one-to-one mapping correct so isn't it just boil of it it is but much more readable it depends on your use case again as i said like we prefer because scale scalability and maintenance was a bigger concern to be honest thanks a lot thank you