Monday 1 June 2020

A Novel Mobile Telemedicine System for Ambulance Transport. Design and Evaluation

Tuesday 10 March 2020

Applying Agile Methods in Designing an Earthquake using Android

Applying Agile Methods in Designing an Earthquake using Android
Early warning system aims to avoid and reduce the risk of damage and casualties caused by natural disasters. Landslides and earthquakes are natural disasters that often occur in Indonesia. The objective of the research is to develop landslide and earthquake early warning system applications for smartphone devices with Android operating system. Current smartphone contain slow cost sensors able to detect movement. Despite of less accuracy than scientific instruments, but the ubiquity of smartphone can cover larger area. Crowdsourcing the data collection also reducesthe false positive rate caused by the sensor. We embed our prediction model in Android application to distinguish between earthquake and common human activity. Further, the data is sent to cloud server if predicted as earthquake. When the number of user reported the same event at the same time in certain area met the threshold, push notification then delivered to smartphone user which may have impact by the event. We use data from Sistem Informasi KebencanaanLongsorby Research Center for Geo technology to develop landslide early warning system. When smartphone user entering area with highly landslide potential, thewould receive notification about the areapotential. This research uses Agile method to develop early warning system on Android device. Research activities are conducted in 6 (six) phases: requirement, plan, design, develop, release, track & monitor. In this paper,we described the process of design phase system that will be a guide in the next process in making the next program.
Dissemination of disaster information quickly and precisely requires a variety of efforts, including through the use of technology that has popularized. Indonesia territory is very wide with natural conditions often occur natural disasters. Sometimes the delivery of disaster events information to the community encounters obstacles. One of the factors is the information and early detection of disaster occurrence in a region or area is not known widely.The Indonesian smartphone user base experienced an average growth of 33% (Compound Annual Growth Rate from 2013 to 2017) based on Smartphone User Persona Report (SUPR) released by Vserv based on a study conducted by Nielsen Informate Mobile insights. Meanwhile, a survey conducted by APJII (Indonesia Internet Service Provider Association) in 2016 describedfrom the total population of Indonesia 256.2 million people, as many as 132.7 million have been using the internet and spread from the island of Sumatra to Papua. The survey results show 50.7% or approximately 67.2 million users use smartphones to access the internet with the type of content that is most widely accessed is social media 97.4% (129.2 million).Currently social media applications (such as twitter, facebook, whatsapp and others) have become part of the activities of Indonesian society. Various events often become trending topics in Indonesia even worldwide including various disaster events in Indonesia. By analyzing the data conveyed in the timeline, the landslide disaster information can be immediately communicated to the public.In addition, studies conducted by several universities and research institutes in Indonesia have placed sensors to detect potential landslides. The parameters measured as landslide potential arerainfall, land use, land slope, soil type and elevation. The occurrence of earthquakes is often addressed as well as a warning sign of the occurrence of landslides in a region.The Crowdsourced concept is one way to get certain services, ideas and content by asking for help from others in bulk, especially through online communities. This method began to be used for disaster mitigation applications, both for landslide information (potential events and landslide events) as well as earthquake detection. One of the earthquake detection research projects with crowdsourced was conducted by the University of Berkeley Seismology Laboratory through the MyShake project[3]. The MyShake application will record motion data through the accelerometer sensor on the smartphone and send it to the server for analysis. Data from the sensor will be validated to ensure earthquake or non-earthquake vibration data (false earthquake). In this app, smartphone devices only function as seismometers based on mobile devices.CodeShoppy
https://codeshoppy.in/
The development of earthquake detection applications with crowdsourced is done by the University of Berkeley Seismology Laboratory through the MyShake project [3]. The MyShake app will record motion data through the accelerometer sensor on the smartphone and send it to the server for analysis. The data from the sensor will be validated to ensure earthquake or non-earthquake vibration data (false earthquake). In this app, smartphone device only functioned as seismometer based on mobile device only. In addition, the smartphone device is not equipped with a self-warning system.In other projects iShake[4] utilizing accelerometer sensor on iPhone and iPad devices. Seismic activity is connected to the server through the network infrastructure. The most important part of this research project is the comparison between high-fidelity accelerometer as a reference with the existing accelerometer on the iPhone device. The results show the similarity of velocity and displacement results in the simulation of the earthquake. This study concludes that earthquake events can be detected if the pattern has been identified.The accelerometer on the smartphone is used to detect earthquakes. This study conducted an earthquake pattern recognition by applying N-gram modeling, and obtained 93.15% accuracy that accelerometer sensor on smartphone can detect earthquake occurrence.
 
 

Wednesday 4 March 2020

A Study on Open-Source Android Applications

A Study on Open-Source Android Applications
Android applications do not seem to be tested as thor-oughly as desktop ones. In particular, graphical user interface(GUI) testing appears generally limited. Like web-based appli-cations, mobile apps suffer from GUI test fragility, i.e., GUI testclasses failing or needing updates due to even minor modifica-tions in the GUI or in the application under test. The objective ofour study is to estimate the adoption of GUI testing frameworksamong Android open-source applications, the quantity of modifi-cations needed to keep test classes up to date, and their amount dueto GUI test fragility. We introduce a set of 21 metrics to measurethe adoption of testing tools and the evolution of test classes andtest methods, and to estimate the fragility of test suites. We com-puted our metrics for six GUI testing frameworks, none of whichachieved a significant adoption among Android projects hosted onGitHub. When present, GUI test methods associated with the con-sidered tools are modified often, and a relevant portion (70% onaverage) of those modifications is induced by GUI-related fragili-ties. On average, for the projects considered, more than 7% of thetotal modified lines of code between consecutive releases belong totest classes developed with the analyzed testing frameworks. Themeasured percentage was higher on average than the one requiredby other generic test code, based on the JUnit testing framework.Fragility of GUI tests constitutes a relevant concern, probably anobstacle for developers to adopt test automation. This first evalua-tion of the fragility of Android scripted GUI testing can constitutea benchmark for developers and testers leveraging the analyzedtest tools and the basis for the definition of a taxonomy of fragilitycauses and guidelines to mitigate the issue.CodeShoppy
A Study on Open-Source Android Applications



present in older releases but are removed in the masterbranch, the project will not be extracted.2) Only files smaller than 384 kB are searchable.3) Only repositories with fewer than 500 000 files are search-able.The second and third issues may be not very relevant inour context, since the size of projects and files considered istypically not so big (with the exception of projects containingwhole firmwares or clones of the Android operating system).3) Count of Lines of Code:We used the open-source cloc16tool to count the total lines of code inside a repository (or, ingeneral, a set of files).To compute the number of modifications performed to files ofa GitHub project, thegit diffcommand is used to obtain all themodified, added, and removed lines of code between the two re-leases considered. By default, the diff command shows the mod-ifications performed to the whole repository; as an alternative, itis possible to specify the full paths of a file for both the releasesto obtain the modifications that were performed only on it.The -M parameter allows us to identify files that have beenrenamed or moved in the transition between the releases, withoutconsidering such operation as the combination of a deletion andan addition of a file. The git diff command takes into accountalso blank lines and rows of comments inside files.
https://codeshoppy.com/php-projects-titles-topics.html
 

Mobile GUI Testing Fragility

Mobile GUI Testing Fragility

 market analyses underline, Android hasgained a very significant market share with respect toother mobile operating systems, reaching the 86.2% in the sec-ond quarter of 2016.1Mobile devices, nowadays, offer theirusers a very wide range of different applications, which havereached a complexity that just a few years ago was exclusive ofhigh-end desktop computersOne of the points of strength of the Android operating systemis the availability of several marketplaces, which allow devel-opers to easily sell the applications or release them for free.Because of the huge amount of apps available on such plat-forms, and the resulting competition, it is crucial for developersto make sure that their software works as promised to the users.In fact, applications that crash unexpectedly during their normalexecution, or that are hampered by bugs, are likely to be quicklyabandoned by their users for competitors [1] and to gather verynegative feedback [2]. Mobile applications must also complywith a series of strict nonfunctional requirements, which arespecific to a mobile and context-aware environment [3].In such a scenario, testing mobile apps becomes a very crucialpractice. In particular, it is fundamental to test the graphical userinterfaces (GUIs) of the apps, since most of the interaction withthe final user is performed through them.There is evidence that relevant players of the industry performstructured testing procedures of their mobile applications, alsoleveraging the aid of automated tools (for instance, Al ́egroth andFeldt documented the long-term adoption of visual GUI testingpractices at Spotify [4]). By contrast, it has been proved byseveral studies that open-source mobile developers rarely adoptautomated testing techniques in their projects. Kochharet al.[5] found that, on the set of open-source projects (mined fromF-Droid)2they examined, just 14% of the set featured any kindof scripted automated test classes; Linares-V ́asquezet al.[6]found that the majority of an interviewed set of contributors toopen-source projects relied just on the execution of manual testcases, even though a variety of automated testing tools (opensource or not) are available.Performing proper testing of Android apps presents a set ofdomain-specific challenges, principally due to the very fast paceof evolution of the operating system and to the vast number ofpossibleconfigurations andfeatures theapps must becompatiblewith. In addition to that, the development process for Androidapps is typically very quick, and the need for making the ap-plications available to the public as soon as possible may be adeterrent for developers to perform complex forms of testing.Mucciniet al.[7] stress the differences between traditional soft-ware and Android applications when it comes to testing them:the huge quantity of context events, to which apps have to re-act properly; the diversity of devices, to which the apps must becompaSimilar to what happens for web applications testing, auto-mated GUI testing of Android apps is also hampered by thefragility issue. For our purposes, we define a GUI test case asfragile if it requires interventions when the application evolves(i.e., between subsequent releases) due to modifications appliedto the application under test (AUT). Being system level tests,GUI test cases are affected by variations in the functionalities ofthe application (as it happens for lower level component tests),as well as from even small interventions in the appearance,definition, and arrangement of the GUI presented to the user.Fragility is a significant issue for Android application testing,since a failing test may require in-depth investigations to findout what are the causes of the failures, and entire test suitesmay need modifications due to even minor changes in the GUIsand in their definition. If that happens, developers may decideto not exercise any kind of structured scripted testing. In ourprevious work [8], we developed a small test suite (made of 11test classes) for K9-Mail3—a popular large-sized open-sourceAndroid mail client—and tracked the modifications that wereneeded by test classes to be executable on different releases.We found out that up to 75% of tests that we developed hadto be modified because of modifications performed on the GUIof the app. If scripted test cases were obtained through the useof Capture&Replay techniques, for some transitions betweenreleases, the entirety of the test suite had to be rewritten of gui. CodeShoppy
Mobile GUI Testing Fragility
 In this work, we aimed at gathering information about ex-isting test suites featured by open-source Android applications.We extended the context of previous similar work (like the oneby Kochharet al.[5], who analyzed a set of about 600 open-source Android apps collected from F-Droid), considering allthe projects hosted on GitHub that contained proper Androidapplications and that featured a history of releases, for a to-tal of 18 930 projects. We identified six open-source AndroidGUI testing tools cited in available literature and producing testclasses in Java, and we searched for the presence of code writtenwith those tools in the mined Android projects. This way, wesubdivided the projects in six subsets, according to the testingtool they featured. Then, change metrics about the evolution oftesting code produced with a given testing tool were computedfor each project and averaged over the respective sets. In addi-tion to its evolution, we measured the relevance of testing codewith respect to the total production code for each project in termsof quantitative comparisons of the respective amount of lines ofcode. To estimate the fragility issue, we defined a set of metricsthat can be obtained for each project by automated inspectionof the source code. Thus, we can give a characterization and aquantification of the average fragility occurrence for each of thetesting tools considered.The results of this paper provide a quantitative analysis ofautomated test suites developed with a selected set of GUIautomation frameworks for open-source Android applications.Since many GUI automation frameworks have been providedin recent literature for mobile applications, this paper does notprovide a comprehensive evaluation of all available alternativesfor Android developers to test their application. These metricscan be used as a benchmark by Android developers adoptingthose tools or similar ones to evaluate the maintenance effortneeded by their scripted test suites and to decide whether it isconvenient to keep leveraging automated testing. Based on thisfragility evaluation, it can be possible in the future to define ataxonomy of fragility causes for scripted Android GUI testing,and to give more in-depth actionable guidelines for developersto circumvent some of them. Finally, automated tools can bedeveloped to adapt test methods the modifications that areperformed in the GUI source code and appearance
https://codeshoppy.com/android-app-ideas-for-students-college-project.html
 
 

Tuesday 25 February 2020

Two-Level Rejuvenation for AndroidSmartphones and Its Optimization

Two-Level Rejuvenation for AndroidSmartphones and Its Optimization

The Android operating system (OS) is a sophisticatedman-made system and is the dominant OS in the current smart-phone market. Due to the accumulation of errors in the systeminternal state and the incremental consumption of resources, suchas the Dalvik heap memory of software applications and the physi-cal memory, software aging is observed frequently and recognizedas a chronic problem of Android smartphones. To mitigate thisproblem, we propose a two-level software rejuvenation, with thetwo levels referring to software applications and the OS, in this pa-per. Based on this strategy, a Markov regenerative process model isconstructed to evaluate the steady-state availability and to optimizethe time required to trigger rejuvenation for Android smartphones.The parameters of the model, such as the degradation rate and fail-ure rate of software applications and the Android OS, are obtainedvia our testing platform. Experiments on two real Android applica-tions show that the availability of an Android smartphone increasesby 10.81% and 10.18% for the two subjects in our experiments,respectively. An empirical study comparing our two-level strategywith one-level strategies (single application-level and system-levelrejuvenation) further verifies the effectiveness of our approach.
The Android operating system (OS) is a sophisticatedman-made system and is the dominant OS in the current smart-phone market. Due to the accumulation of errors in the systeminternal state and the incremental consumption of resources, suchas the Dalvik heap memory of software applications and the physi-cal memory, software aging is observed frequently and recognizedas a chronic problem of Android smartphones. To mitigate thisproblem, we propose a two-level software rejuvenation, with thetwo levels referring to software applications and the OS, in this pa-per. Based on this strategy, a Markov regenerative process model isconstructed to evaluate the steady-state availability and to optimizethe time required to trigger rejuvenation for Android smartphones.The parameters of the model, such as the degradation rate and fail-ure rate of software applications and the Android OS, are obtainedvia our testing platform. Experiments on two real Android applica-tions show that the availability of an Android smartphone increasesby 10.81% and 10.18% for the two subjects in our experiments,respectively. An empirical study comparing our two-level strategywith one-level strategies (single application-level and system-levelrejuvenation) further verifies the effectiveness of our approach.Index Terms—Android, Markov regenerative process (MRGP),multilevel software aging, software rejuvenatioN Code Shoppy
 
Two-Level Rejuvenation for AndroidSmartphones and Its Optimization


ATREMENDOUS increase in the number of smartphonesover the last fifteen years has been observed. Smartphonesassist people both in their personal and business activities, sim-plifying their lives in various ways, e.g., enabling people to sende-mails, browse the Internet, and play games. Thus, as the func-tionality and complexity of smartphones rapidly increase, usersexpect a highly reliable and responsive platform. According tothe International Data Corporation (IDC), Android commanded86.8% of the world’s smartphone market in 2016 [1]. Android applications are written in Java and run in their own separateaddress spaces, and the Android operating system (OS) keepstrack of the applications and supports, e.g., their memory man-agement, process management, and device management.This paper focuses on the mitigation of the software agingproblem for Android smartphones. Software aging refers to theprogressive performance degradation of long-time running soft-ware, which may lead to system slow down, system crashes,or undesirable hangs [2]. Typical causes of software aging arememory leaks [3], nonterminated threads, storage fragmenta-tion, unreleased locks, and shared-memory pool latching [4].Software aging is known to occur for Android smartphones andmay greatly affect a user’s experience, especially after a longperiod of usage. Typical examples reported by Google’s An-droid project [5] include the camera application crashing afterrunning for a long time [6], a smartphone responding poorlybecause of a memory leak in thesurfaceflingerprocess [7], andan out-of-memory error occurring after many iterations of theprocess of language switching [8]. Therefore, the study of soft-ware aging mitigation techniques for Android smartphones isnecessary to help prevent/postpone or eliminate performancedegradation, solve the issues related to memory consumptionand avoid unexpected failures for Android software applica-tions and the Android OS [9]–[11].To counteract software aging, a software recovery techniqueknown as software rejuvenation was introduced [4]. Softwarerejuvenation is a proactive fault management technique aimed atpreventing/postponing performance degradation and crash fail-ures. It involves occasionally terminating an application, clean-ing up the system internal state, and restarting the system toprevent/postpone the occurrence of future failures [12], [13].Android offers a technique called low memory killer (LMK),which can partially refresh the system state to realize the goalof software rejuvenation. That is, once the amount of free sys-tem memory is below a threshold, the LMK chooses a targetapplication and terminates its host process. Thus, the mem-ory associated with the process is reclaimed and can be reallo-cated [14]. Simultaneously, Android intelligently manages thephysical memory for caching applications. After a user exits anapplication that is running in the foreground, Android stores theapplications process in memory. Consequently, the next timethe user requires the old application, the Android OS does notneed to repeat the initialization work
https://codeshoppy.com/php-projects-titles-topics.html