Authors: (1) LI LI, Beihang University, China; (2) XIANG GAO, Beihang University, China; (3) HAILONG SUN, Beihang University, China; (4) CHUNMING HU, Beihang University, China; (5) XIAOYU SUN, The Australian National University, Australia; (6) HAOYU WANG, Huazhong University of Science and Technology, China; (7) HAIPENG CAI, Washington State University, Pullman, USA; (8) TING SU, East China Normal University, China; (9) XIAPU LUO, The Hong Kong Polytechnic University, China; (10) TEGAWENDÉ F. BISSYANDÉ, University of Luxembourg, Luxembourg; (11) JACQUES KLEIN, University of Luxembourg, Luxembourg; (12) JOHN GRUNDY, Monash University, Australia; (13) TAO XIE, Peking University, China; (14) HAIBO CHEN, Shanghai Jiao Tong University, China; (15) HUAIMIN WANG, National University of Defense Technology, China. Table of Links Introduction Background of OpenHarmony The State Of OpenHarmony Ecosystem Overview Of Mobile Software Engineering The Research Roadmap Discussion Related Work Conclusion & References 6 DISCUSSION OpenHarmony, as an emerging mobile platform, is still in its early stage, and so is OpenHarmonyfocused software engineering research. As summarized previously, although there are plenty of opportunities for our fellow researchers to explore in this field, there are still various challenges that need to be addressed. In this section, we highlight some of the representative ones. 6.1 Challenges in App/Library Development. In this work, we have highlighted the gaps that require to be filled in order to catch up with the popular mobile platforms (i.e., Android and iOS). Towards filling the gaps we argue that there are still a number of challenges that need to be addressed. The rise of large language models has been demonstrated to be promising for automated code generation, automated test case generation, library API recommendation, etc. However, it is not yet possible to directly achieve that for OpenHarmony as there is generally no data available for training (or fine-tuning). Even with a set of OpenHarmonyrelated software data (e.g., ArkTS code and its comments), there is also a requirement to further distill high-quality ones in order to achieve a highly precise large language model, as the performance of large language models is known to be highly correlated with the quality of the training dataset. Lacking Data for (AI-based ) Learning. At the moment, there are only a limited number of libraries (in ArkTS) available for supporting the implementation of OpenHarmony apps. The lack of third-party libraries makes it difficult for developers to implement OpenHarmony apps as many of the functions need to be developed from scratch. To fill this gap, the OpenHarmony community is currently encouraging practitioners and researchers to translate popular libraries in other languages to ArkTS. However, this simple translation campaign will introduce another challenge, which is to keep updating the library following the updates of the original version. To that end, we argue that dedicated efforts are required to ensure the maintainability of these libraries. Lacking Third-party Libraries. 6.2 Challenges in App/Library Analysis After app (or library) development, there is a strong need to ensure that the app/library satisfies the requirements and is of high quality. The relevant challenges include the newly designed system architecture of OpenHarmony, the comprehensive GUI interactions, the newly introduced app programming language, etc. We now summarize the representative ones. The Android system has introduced various challenges to the software engineering community in order to develop automated approaches to analyze Android apps. First, Android takes components to construct apps, for which the components by themselves are independently developed. The components will not be directly connected at the code side and the actual invocation (via the so-called Inter-Component Communication (ICC) mechanism) will be done over the system. This ICC mechanism could also be leveraged to implement inter-app communications, making it a challenge to perform inter-app analyses. Second, the components in Android are designed to be run over a set of pre-defined methods (known as lifecycle methods) that will be triggered by the system following a certain order. These lifecycle methods are not connected at the code site as well, making it also a challenge for static app analysis (from the analyzer’s point of view, there is no relationship between two lifecycle methods, despite they may be continuously called by the system). Third, similar to that of lifecycle methods, there are callback methods that are not directly connected to the app code as well. These callback methods are directly invoked by the system when certain events (either system events such as receiving an SMS or UI events such as clicking a button) are triggered. OpenHarmony generally shares the same challenges as that of Android. System-related Challenges. The GUI part has been known to be a challenge for precisely analyzing Android apps. First of all, a given GUI page often contains a comprehensive view tree that includes various widgets with different types positioned via different layout strategies. The widgets in the GUI page are further associated with interactive actions (e.g., a button is associated with a click event). Furthermore, a given GUI page may contain different groups of widgets that will only be rendered if a certain condition is satisfied. In OpenHarmony, the analysis of GUI pages is even more challenging as its design principle encourages to use a single component (i.e., Ability) to implement multiple visual pages, which would be implemented via multiple components (i.e., Activities, one page per Activity) in Android. GUI-related Challenges. The language used to implement mobile apps per se may introduce challenges to the software engineering community. For example, in the Android world, the reflection mechanism (inherited from Java) has been known to be a challenge for static analysis. OpenHarmony takes a new language called ArkTS for developers to implement OpenHarmony apps and the ArkTS language per se may introduce various challenges to the software engineering community as well. Indeed, ArkTS allows defining functions with optional parameters and default parameters, which may cause inconsistency between the function signature and its usage in practice. Language-induced Challenges. This paper is under CC 4.0 license. available on arxiv

Software Engineering for OpenHarmony—A Research Roadmap: Conclusion & References

Software Engineering for OpenHarmony: The Research Roadmap

EScholar Technologies

Too Long; Didn't Read

Make resilience your competitive advantage

Addressing OpenHarmony Development Challenges: Insights and Solutions

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Smart Cards, IPv6 Packets, and the Future of Post-Quantum Security

10 Steps To Create Your First Mobile App

10 Promising Mobile Apps by Startups to Watch Out for in 2022

4 Tips for Building the Ultimate Finance App

5 Best Mobile App Design Tools in 2022

Smart Cards, IPv6 Packets, and the Future of Post-Quantum Security

10 Steps To Create Your First Mobile App

10 Promising Mobile Apps by Startups to Watch Out for in 2022

4 Tips for Building the Ultimate Finance App

5 Best Mobile App Design Tools in 2022

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps