And specifically, we're going to see how we could build the deployment engine for the Android app that Uber uses. Now technically this could also be very similar to the iOS application. The main components that I want to really talk about and the main nodes that I want to model deal with mobile versus a desktop system the Uber architectures so massive we probably couldn't even build it if we dedicated an entire course to it because it is made up of thousands of different applications that all have their own specific rolls and behavior. So what I wanted to do was pick out a type of architecture that is very common to have to build out which as if you're in the development industry you're most likely going to have to learn how to build out and model systems that work with mobile apps and so that's what this is going to focus on. So starting off on the right hand side. So we're going to get everything here on the left in a while. But right now I want to talk about the Android app as it relates to its data layer. Now with out an API connection there is no Android app. Uber cannot have an Android app that lives by itself. So one of the biggest components is needed in order for this to function properly is the API. This is where when you search for a user or you search for a location or any kind of outside data comes into the system its hitting this API and its returning a response.

So in the middle we have this node called the device which is going to be the smartphone. This is where the entire application is going to live. And then we have a connection and this association between the execution environment which is Android. Now if we were building this for iOS applications then we would have an iOS execution environment and part of the reason why this is important is because these types of systems are very different. So if we were to simply create one deployment diagram for both mobile apps then you're going to run into a number of problems and they mainly revolve around the fact that Android uses the Java programming language which has a completely different set up than iOS uses. IOS uses swift and objective c.

In order to have your applications run they are very different. The environment that you use to set them up is very different. The deployment processes are incredibly different in regards to deploying either updates or deploying to the App Store for the first time. I've performed both kinds of deployments and they are completely night and day. Google is very easy to deploy to if I perform an update in an Android app that I have then within a few minutes it'll be live on the App Store. If I do the same type of change to an iOS app it may be days before the update goes live. So all of that goes in the decision making process on modeling these systems out.

So we have our device we have our API. We know that the execution environment here is going to be Android and then we have a connection to that deployment engine.

So here we have our node which is the Android app itself which is an Uber app and we have a number of classes resources and these are going to be both compiled and uncompiled. If you're wondering what the difference is and why I wanted to separate those it's because Java is a compiled language. And so what that means is that your code itself is going to be compiled. However it does deal with data that does not compile so data that comes in from the API usually comes in in the jason format that's not compiled it's simply dynamic data that runs through the system. So it's important to understand that you have two different kinds of processes in regards to the code that is there in the app and then from that point we have our deployment specification. What this typically means is that we place in the system the different updates and we list out the changes that have been made to the application. We change version numbers we do a number of tasks. Kind of like a checklist. That's the reason why it's here.

Now, I want to point out that this is a very generic system. We don't know the code base that the uber team uses. So all we can do is estimate based off of what we can see from the outside. And so this is incredibly high level. My guess is that the system that you built out is probably completely different looking than mine and that's perfectly fine.

The main components that I wanted you to be able to model in this type of system is having some type of mobile application and recognizing that it does rely on an API because this app would not be able to live by itself. It needs to be able to have its own execution environment it needs to be able to dictate what type of phone this can go on and then from there the data can be pumped through. So this is one option on how you can model a deployment engine for the uber Android app.