To avoid unresponsiveness, a core part of mobile development is asynchronous programming. Android providesseveral async constructs that developers can use. However, developers can still use the inappropriate async constructs, which result in memory leaks, lost results, and wasted energy. Fortunately, refactoring tools can eliminate these problems by transforming async code to use the appropriate constructs. In this paper we conducted a formative study on a corpusof 611 widely-used Android apps to map the asynchronouslandscape of Android apps, understand how developers retrofit asynchrony, and learn about barriers encountered by developers. Based on this study, we designed, implemented, and evaluated ASYNCDROID, a refactoring tool which enables Android developers to transform existing improperly-used async constructs into correct constructs. Our empirical evaluation shows that ASYNCDROID is applicable, accurate, and saves developers effort. We submitted 45 refactoring patches, and developers consider that the refactorings are useful.

Industry leaders provide concurrent libraries because asynchronous & parallel programming are increasingly in demand: responsiveness, scalability, and high-throughput are key elements of all modern applications. However, we know little about how developers use these concurrent libraries in practice and the developer's toolbox for concurrency is very limited. We present the first study that analyzes the usage of concurrent libraries in large codebases, such as 2258 open-source C# apps comprising 54M SLOC and 1378 open-source Windows Phone apps comprising 12M SLOC. Using this data, we find important problems about use and misuse of concurrency. Inspired by our findings, we designed, evaluated, and implemented several static analyses and refactoring tools.

Asynchronous programming is in demand today, because responsiveness is increasingly important on all modern devices. Yet, we know little about how developers use asynchronous programming in practice. Without such knowledge, developers, researchers, language and library designers, and tool providers can make wrong assumptions.

Parallel programming is hard. The industry leaders hope to convert the hard problem of using parallelism into the easier problem of using a parallel library. Yet, we know little about how programmers adopt these libraries in practice. Without such knowledge, other programmers cannot educate themselves about the state of the practice, library designers are unaware of API misusage, researchers make wrong assumptions, and tool vendors do not support common usage of library constructs.