 Most of that, this paper needs two people to present. So we have Ali, who is a first year PhD student, and we have Jerry, who is a master student. And they're going to tell us about how to handle uncertainty in compile time. Good afternoon. We are here today. You have to turn it on. Good afternoon. We are here today to convince you to embrace uncertainty in mobile app programming. You might be wondering why two people are presenting one paper. That's because our advisor was uncertain about who should present it, so he's like, OK, both were presented. So, Jerry, you are a mobile app developer, so what are you currently implementing? OK, what I'm planning to do right now is to create a game that is pretty graphically intensive and deploy it on the app store so that, you know, make some bugs around the way. So have you considered the energy consumption you would gain? I mean, you don't want people to run out of battery when they play the game within 20 minutes, right? Yeah, you're right. Yes, so I'm just planning to, you know, throw in a bunch of FL statements, and, yeah, should handle it fine. So let's speak about this statement. So are you going to have one threshold for all users? Currently thinking of setting the threshold to the 10% battery level, but I'm just not sure. So this is threshold. I mean, it could be very low for a set of people, right? Maybe, for example, for me, low battery means 30%, but for you, it would mean 10%. So how are you going to be sure of it? Yeah, I don't know how I handle it using my balance. So what about the branches? Do you even know if these branches work? Yeah, if the condition isn't right, then I wouldn't know. OK, let's assume that it works. How will it work? I'm lost. I just don't have an answer. My answer to vary is embrace uncertainty. So today, programming languages enforce programmers to be certain about each and every line of their code. So let's take an example. For example, if else a statement. The programmer has to be certain about the condition of a statement. And also for the branches, each branch will not be executed unless the condition will be true. So what we are proposing is maybe statement. So as you can see, maybe has no condition. And each branch is dealt with as an alternative that could be selected by the app whenever it sees that this is the best alternative available at the current time. Maybe statement can be represented in a various ways. For example, multiple blocks that have different alternatives. Each block has one alternative. And there is a label that helps the system to identify the statement and the code. It also can be used with variable assignments. For example, here we have string performance that could take one of these three values, low, medium, and high. And also maybe presents a new feature that is very inshore cut for integers. For example, I don't need to enumerate each and every number with an orange. I just write 1 to 16. So maybe statement can be used or used by programmers to express uncertainty. And maybe system uses testing and learning to convert that uncertainty to runtime certainty. So as a result, our major goal in this system is to know the best alternative at runtime. All right, so let's get to the magic behind the scenes here. So we have a piece of code here that is written in this way. So the presenter has Ali or the presenter could be Jerry. So the old people prefer Ali to present to them. Whereas the young people prefer Jerry, that's we need to present to them. So how does the app know about all of these things? Well, we'll come to that later. But this is a form of static adaptation in which one option is chosen and, yep, that remains steady for a long period of time. Similarly, from India, Ali is chosen to give a presentation from Kuwait, Jerry is chosen. And coming to dynamic adaptations, what if an app wants to behave differently during times in which it's not actually used much during the night. And it wants to behave differently during the day time. So all these are temporal adaptations, examples of temporal adaptations and network-based adaptations as well. For example, Ali prefers to use cellular data, whereas I prefer to use Wi-Fi. So how it works is like this. The maybe system has adaptation algorithms embedded into itself and this adaptation algorithm chooses which block to execute. So I'll talk about the adaptation algorithm later. But this, suppose if the app developer doesn't want to be, he doesn't want to give this form of control to the system itself, he or she could, you know, just over like this methodology. So our advisor, so he could control like, okay, Ali should give it the talk or Jerry should give it the talk. But as of now, he's confused and he's sitting in the back there. Okay, you guys handle it. So moving on to like maybe testing. So this is how the adaptive algorithm works. Initially, the system needs to be tested and then the system needs to be adapted for the use cases. So let's talk about testing phase first. We have a bunch of users and we execute a block, maybe the maybe block or the odd block on the set of users and we calculate the scores. And these, okay. And also another block is executed on the same set of users and the scores are calculated. Now, this is where in which the testing is done and the scores are actually evaluated. And what happens is given a bunch of users again, we apply randomly which block of code should be executed on them and we compute these two scores again. So all of these scores are kept in track at the backend server. So the backend server, yeah. So the backend server applies some form of machine learning algorithm so that it could classify like for this particular set of users, this is the best alternative that could be executed. All right, so this course, talking about this course, what exactly is this course we are talking about? This course is completed based upon the performance and the energy consumption of the app. This is the standard way of actually how we go about measuring the scores but the app developer has total control over how to measure the scores as well. So he can write a service like a JSON string or something that does a total different computation of this course. These scores given to the backend, some form of analysis is done and then push back to the app again. All right, so I'll even take over. So maybe the system has a lot of use cases. For example, based on our experience in our phone lab, which is by the way large-scale smartphone platform testbed, we had implemented a phone lab data collection tool that collects blood data from participant devices. And while implementing that tool, we had a lot of questions that we needed to be certain about at development time. For example, when and how often to upload data? How often to rotate logs on the device? How much data to cache on the smartphone? We needed to be to have an answer and be sure about our answer at development time. We also had to specify an end-to-end performance metrics. So we ended up by writing hundreds of boring code. One, if we used maybe segment, we had end-to-end just like by maybe tens of, or by line or two, of course, by specifying the available alternatives without worrying about being sure which one we should really specify at development time and leave that for the runtime. So another app that we have on the participants of phone lab is called Pocket Parker. So what this app basically does is to recommend a user a very exactly a parking spot is available and one of the parking lots at the University of Buffalo. So in order to have this set of computations, right, we had to actually get the app, the geographical location information of the user, like whether the user is riding a vehicle or whether the user is, like, you know, just walking from her car back to the building or something of that sort. So, okay, this app specific information we wrote a bunch of code. And also Google produced its set of code, like library APIs, after we actually implemented this code. So what actually ended up happening is we had two alternatives, whether to use our code or whether to use the Google APIs. So how do we actually know which one is better for our needs? So we ended up putting this into the maybe or log and what we are currently, you know, testing this course, like which are written from these alternatives. And on the long run, we'll get to know, like, which alternatives are better for our needs. So, fine. So these were some of our use cases at the phone lab, but when we look into the Android framework and the kernel, there are many places in which uncertainty could be mined upon. For example, the timer rates, the timeouts as well, when should the network search be timed or when should the Wi-Fi search be timed out? Like, you know, if the app is deployed in US, like, should it be set for five minutes? And if the app is deployed in a nation country, should it search for a longer time or should it search for lesser time? Cash sizes. This is another important thing. Like, we are not so sure about cash sizes during compilation time, but during run time, it's pretty important. And other things like, you know, performance quality trade-offs and attempts at battery life adaptation as what kind of discussion we and Ali had at the very beginning of the talk. And we are also open to, like, any suggestions. Like, where do you think uncertainty needs to be measured in the content or the Android screenbooks? So we want more feedback from the audience regarding that, maybe at the end of the talk. So as of our current status with, maybe, system implementation, we are currently implementing a rewrite-based implementation for Android Java. And the maybe system consists of four core components. The first one is a preprocessor that rewrites maybe statements or converts the maybe statements into current existing conditional statements. And we also have Android service to cache values and implement adaptation algorithms. There is also a backend server to drive testing, collect data, analyze data, and broadcast data. Broadcast the selected alternate. And we also have, this is a feature, I believe we also have a web interface to allow programmers to control the process. So the programmer has the choice to select one of the alternatives at any time. So, for example, maybe at the development time, he has just, like, 10 alternatives that he wasn't sure which one to select. But at runtime, he found out that one of the alternatives, as of the current conditions, is the best alternative to work with. So he can set it manually using the web interface. So to summarize, you can say that for certainty is a problem, particularly for mobile systems. And maybe this statement and system allow programmers to express and embrace uncertainty and activate testing and machine learning techniques. So please embrace uncertainty. Thank you, and welcome any questions. Any questions? I'm not using this question. So, I'm just wondering. My name is Shiv Mishra from University of Colorado. Isn't that essentially a context-dependent programming? Essentially, at runtime, you're trying to detect the right context, and based on that, you're choosing whatever the right algorithm are. So, by context-dependent... For example, whether it's day or night, or whether you are in India or in the US, these are all contexts, right? Yep. So, the baby statement is another way to implement context-dependent? Yes, I mean, this specific logic needs to be always implemented in the app. But sometimes, what we are talking about is the conditions that could be uncertain. The conditions could vary from two to maybe 100 conditions. For example, in this particular country, at this particular location, when the network statistics is so much, then execute this algorithm. With a lot of context. Yeah, so, a bunch of if-else statements, like we have like four, five, six, like 10 if-else statements, we are eliminating the deployment logic which the app developer has to concentrate upon. We are deploying it for the server to handle it. So, yeah, it is context-dependent. Eric, you might have started to touch on what I was going to ask. Is this something that's natural, I think, for programmers to do? What happens if you have a bunch of these nested maybe statements? So, that's something that's easy to think about what will happen. Well, if the user is sure about the logic, then, okay. Sorry, if the app developer is sure about the logic, you know. So, how Chen from UC Davis, so, what is the difference between the maybe statement and either if or switch statement, but where instead of using a constant or an expression as the predicate, you call, say, get context as the predicate. So, what's the difference? So, the difference is, as we see in this slide here, hold on a second, yeah, just for that. Yep, here, the condition is given, right? If battery level is lesser than threshold. Right. But the condition that whether the battery level should be considered or some of the parameters also need to be considered for a set of alternatives to be executed. The app developer isn't too sure, like, what all conditions he or she needs to be sure during runtime, yeah, during runtime. So, essentially you have either a library or another process as the decision maker. And instead of hard coding, a logic in the predicate, you call into that component or process. It's not a library. What was that? It's not a library. Well, conceptually, there's something else is either a component or it's another process that makes the decision. So, you call into that and you get back some value and your program execution, which branch to take depends on the return from that model. So, as far as I understand, you're saying that this could be implemented as a library? No, I'm just trying to understand how to map this to the existing programming tools we have. He's asking who decides, ultimately, what the condition is. Maybe statement who decides. Okay, the server decides for us. So, the server sends a bunch of vectors back to the application, based upon the statistics that it has learned from the usage patterns of different users. Well, actually, I'm more thinking of if I really love your approach, can I just implement it using existing languages as a Java instead of using the maybe keyword? So, in Java, instead of writing this, I make a call to that decision maker. Yes, you can, but you'll have to write a bunch of anonymous classes to do that. And if you want better constructs like maybe RRR and leave all this deployment logic to the back end, I prefer you, our developers would like this interface more. Why write a switch statement, can I? You can, because you're not too sure about the condition, right? Okay. All right, thank you. All right, thanks. So, I have something related to that as well. So, this thing's very similar to what we used to do in Odyssey, et cetera, where we did adaptation based on various CPU, et cetera. And the problem with those systems is the utility function turned out to be impossible to write. As in the little piece of magic that actually determined that battery is higher than this, that was so user-specific and app-specific that it was impossible to generalize. Do you all have any magic here that allows you to generalize this so they can actually provide us the service? You said maybe statements, if it's done. No, that's not what I'm saying. To do the maybe on your server, you still need a utility function, something to optimize for. And this turned out to be the place where all these adaptation systems failed miserably. I think if you get Stefan and me in the room and we talk about Maui and Chroma, you'll see this is where all of them fail miserably. When it comes to the per user, per app, utilization and utility function. So, do y'all have any thoughts on how you can handle that? I mean, this is great, but when you get user-specific requirements, it will fail miserably. That's what we found out anyway. Yeah. Well, as far as how we have thought of our prototype is to gain the statistics of users who, like, you know, a group of users who behave in a similar pattern, in a similar set of ways. So, like, very specific user implementation details, I think we'll get to know more about it only if the full system is still not. Okay.