Find research datasets worth reusing
Search datasets from major research repositories and use ShareScore to quickly assess how well each record supports discovery, access, and reuse.
1,532
datasets available to search
ShareScore release 0.9.0
Dataset results
1,532 results for “App”
PopSweeper: Automatically Detecting and Resolving App-Blocking Pop-Ups to Assist Automated Mobile GUI Testing
<p>Collected data for paper: PopSweeper: Automatically Detecting and Resolving App-Blocking Pop-Ups to Assist Automated Mobile GUI Testing</p>
AURORA Energy Tracker App
<p>The Excel document contains the algorithm of the AURORA Energy Tracker app. <span>Each of the sheets of the document corresponds to each of the 27 EU member states. This document serves as a calculator of CO2 emissions and energy consumption by entering the data in the corresponding cells. </span>The last version corresponds to April 2024.</p>
Provenance of luca App development.
<p>Provenance documents in <a href="https://www.w3.org/Submission/prov-json/">PROV-JSON</a> format of the <a href="https://gitlab.com/lucaapp">luca App GitLab repositories</a>.</p> <p>Retrieved on June 22<sup>nd</sup>, 2021 using <a href="https://github.com/DLR-SC/gitlab2prov">GitLab2PROV</a> Version 0.5.</p> <p>Commands:</p> <pre><code class="language-bash">gitlab2prov -t <GitLab API-Key> -f json -r 1000 -p https://gitlab.com/lucaapp/web > lucaapp-web.json gitlab2prov -t <GitLab API-Key> -f json -r 1000 -p https://gitlab.com/lucaapp/ios > lucaapp-ios.json gitlab2prov -t <GitLab API-Key> -f json -r 1000 -p https://gitlab.com/lucaapp/web-crypto > lucaapp-web-crypto.json gitlab2prov -t <GitLab API-Key> -f json -r 1000 -p https://gitlab.com/lucaapp/android > lucaapp-android.json gitlab2prov -t <GitLab API-Key> -f json -r 1000 -p https://gitlab.com/lucaapp/security-overview > lucaapp-security-overview.json gitlab2prov -t <GitLab API-Key> -f json -r 1000 -p https://gitlab.com/lucaapp/badge-generator > lucaapp-badge-generator.json gitlab2prov -t <GitLab API-Key> -f json -r 1000 -p https://gitlab.com/lucaapp/cwa-event > lucaapp-cwa-event.json gitlab2prov -t <GitLab API-Key> -f json -r 1000 -p https://gitlab.com/lucaapp/fdroid-repository > lucaapp-fdroid-repository.json </code></pre>
Dataset used for "A Recommender System of Buggy App Checkers for App Store Moderators"
<p>This is the dataset used for paper: "A Recommender System of Buggy App Checkers for App Store Moderators", published on the <em>International Conference on Mobile Software Engineering and Systems (MOBILESoft)</em> in 2015.<br> <br> <strong>Dataset Collection</strong><br> We built a dataset that consists of a random sample of <em><strong>Android app metadata</strong></em> and <em><strong>user reviews</strong></em> available on the <em>Google Play Store</em> on January and March 2014.<br> Since the Google Play Store is continuously evolving (adding, removing and/or updating apps), we updated the dataset twice.<br> The dataset D1 contains available apps in the Google Play Store in January 2014.<br> Then, we created a new snapshot (D2) of the Google Play Store in March 2014.<br> <br> The apps belong to the 27 different categories defined by Google (at the time of writing the paper), and the 4 predefined subcategories (free, paid, new_free, and new_paid). For each category-subcategory pair (e.g. tools-free, tools-paid, sports-new_free, etc.), we collected a maximum of 500 samples, resulting in a median number of 1.978 apps per category.</p> <p>For each app, we retrieved the following metadata: <em>name, package, creator, version code, version name, number of downloads, size, upload date, star rating, star counting</em>, and the set of <em>permission requests</em>.<br> <br> In addition, for each app, we collected up to a maximum of the latest 500 reviews posted by users in the Google Play Store. For each review, we retrieved its metadata:<em> title, description, device,</em> and <em>version</em> of the app. None of these fields were mandatory, thus<br> several reviews lack some of these details.<br> From all the reviews attached to an app, we only considered the reviews associated with the latest version of the app —i.e., we discarded unversioned and old-versioned reviews. Thus, resulting in a corpus of 1,402,717 reviews (2014 Jan.).</p> <p> </p> <p><strong>Dataset Stats</strong><br> Some stats about the datasets:</p> <p>- <strong>D1</strong> (<em>Jan. 2014</em>) contains 38,781 apps requesting 7,826 different permissions, and 1,402,717 user reviews.</p> <p>- <strong>D2</strong> (<em>Mar. 2014</em>) contains 46,644 apps and 9,319 different permission requests, and 1,361,319 user reviews.</p> <p>Additional stats about the datasets are available <a href="https://sites.google.com/site/androidbuggyappcheckers">here</a>.<br> <br> <br> <strong>Dataset Description</strong><br> To store the dataset, we created a graph database with <a href="https://neo4j.com/">Neo4j</a>. This dataset therefore consists of a graph describing the apps as nodes and edges. We chose a graph database because the graph visualization helps to identify connections among data (e.g.,<br> clusters of apps sharing similar sets of permission requests).<br> <br> In particular, our dataset graph contains six <em>types of nodes</em>:<br> - <em>APP</em> nodes containing metadata of each app,<br> - <em>PERMISSION</em> nodes describing permission types,<br> - <em>CATEGORY</em> nodes describing app categories,<br> - <em>SUBCATEGORY</em> nodes describing app subcategories,<br> - <em>USER_REVIEW</em> nodes storing user reviews.<br> - <em>TOPIC</em> topics mined from user reviews (using LDA).<br> <br> Furthermore, there are five <em>types of relationships</em> between APP nodes and each of the remaining nodes:</p> <p>- <em>USES_PERMISSION</em> relationships between APP and PERMISSION nodes<br> - <em>HAS_REVIEW</em> between APP and USER_REVIEW nodes<br> - <em>HAS_TOPIC</em> between USER_REVIEW and TOPIC nodes<br> - <em>BELONGS_TO_CATEGORY</em> between APP and CATEGORY nodes<br> - <em>BELONGS_TO_SUBCATEGORY</em> between APP and SUBCATEGORY nodes</p> <p><br> <strong>Dataset Files Info</strong></p> <ul> <li><strong>Neo4j 2.0 Databases</strong> <ul> <li><em><strong>googlePlayDB1-Jan2014_neo4j_2_0.rar</strong></em></li> <li><em><strong>googlePlayDB2-Mar2014_neo4j_2_0.rar</strong></em><br> We provide two Neo4j databases containing the 2 snapshots of the Google Play Store (January and March 2014). These are the original databases created for the paper. The databases were created with <strong>Neo4j 2.0. </strong>In particular with the tool version <em>'Neo4j 2.0.0-M06 Community Edition' (latest version available at the time of implementing the paper in 2014).</em><br> </li> </ul> </li> <li><strong>Neo4j 3.5 Databases</strong> <ul> <li><strong>googlePlayDB1-Jan2014_neo4j_3_5_28.rar</strong></li> <li><strong>googlePlayDB2-Mar2014_neo4j_3_5_28.rar</strong><br> Currently, the version Neo4j 2.0 is deprecated and it is not available for download in the official <em>Neo4j Download Center</em>. We have migrated the original databases (Neo4j 2.0) to Neo4j 3.5.28.<br> The databases can be opened with the tool version: <em>'Neo4j Community Edition 3.5.28'.<br> The tool can be downloaded from the official </em><a href="https://neo4j.com/download-center/#community">Neo4j Donwload</a> page.<br> <br> In order to open the databases with more recent versions of Neo4j, the databases must be first migrated to the corresponding version. Instructions about the migration process can be found in the <a href="https://neo4j.com/docs/upgrade-migration-guide/current/understanding-upgrades-migration/">Neo4j Migration Guide</a>.<br> <br> First time the Neo4j database is connected, it could request credentials. The username and pasword are: neo4j/neo4j <br> <br> </li> </ul> </li> </ul> <p> </p>
Replication package for "How does Migrating to Kotlin Impact the Run-time Efficiency of Android Apps?"
<p><strong>Replication Package</strong></p> <p>This section briefly describes the contents of the replication package, which makes it possible to replicate this study.</p> <p><strong>Dataset construction:</strong> The recreation of the GitLab AndroidTimeMachine instance is done using the snapshot related code found in the Kotlin program. This program uses a running instance of the AndroidTimeMachine’s Neo4j database and uses its data to make API calls to a running GitLab instance which imports the GitHub projects found. This step can be skipped, and a GitLab instance can be instantiated directly using our created Docker volumes. The is also capable of performing the Kotlin filtering steps. For this, it uses the results of the previous steps as input and clones each repository for performing the filtering procedure.</p> <p><strong>SLOC counting:</strong> SLOC counting related scripts are found in and implement our methods by cloning the project and running CLOC. It also plots the line graphs that we manually categorized into evolution trends. The raw SLOC data is found in , and all of the plotted evolution trends are found in.</p> <p><strong>Kotlin migration mining:</strong> The implementation for mining is located in , and implements our methods by cloning a repository from the running GitLab instance and executing described methods. All commits we found are located in.</p> <p><strong>Run-time efficiency:</strong> As mentioned in the thesis, we used AndroidRunner. A fork of AndroidRunner we used for conducting our experiments is located in . In the folder , each configuration combined with raw results is found per test subject. The final data we used after removing corrupt frame times is located in the folder, which also contains . This python script implements our statistical analysis methods.</p>
Apps para dispositivos Android que generan Deepfakes
<p><em>Apps</em> para Android que generan <em>Deepfakes</em></p>
Energy Consumption Estimation of API-usage in Smartphone Apps via Static Analysis
<p>OPEN CALL FOR COLLECTING ENERGY PROFILES @ <a href="https://github.com/AbdulAli/replication-kit-msr-2023">https://github.com/AbdulAli/replication-kit-msr-2023</a></p> <p>Cite this work as:</p> <p>@inproceedings{bangash2023msr,<br> title={Energy Consumption Estimation of API-usage in Mobile Apps via Static Analysis},<br> author={Bangash, Abdul Ali and Jamal, Qasim and Eng, Kalvin and Ali, Karim and Hindle, Abram},<br> booktitle={2023 20th International Conference on Mining Software Repositories (MSR)},<br> pages={5721--5730},<br> year={2023},<br> organization={IEEE}<br> }</p> <p>This is the replication-kit of the paper published at MSR 2023.</p> <p>It includes:</p> <ul> <li>SQLite operations' benchmarks</li> <li>SQLite benchmarks' energy profiles</li> <li>The E-Factor Calculation program</li> </ul>
FPCA - From mobile app-based crowdsourcing to crowd-trusted food price estimates in Nigeria: pre-processing and post-sampling strategy for optimal statistical inference
<p>Timely and reliable monitoring of commodity food prices is an essential requirement for the assessment of market and food security risks and the establishment of early warning systems, especially in developing economies. However, data from regional or national systems for tracking changes of food prices in sub-Saharan Africa lacks the temporal or spatial richness and is often insufficient to inform targeted interventions. In addition to limited opportunity for [near-]real-time assessment of food prices, various stages in the commodity supply chain are mostly unrepresented, thereby limiting insights on stage-related price evolution. Yet, governments and market stakeholders rely on commodity price data to make decisions on appropriate interventions or commodity-focused investments. Recent rapid technological development indicates that digital devices and connectivity services are becoming affordable for many, including in remote areas of developing economies. This offers a great opportunity both for the harvesting of price data (via new data collection methodologies, such as crowdsourcing/crowdsensing — i.e. citizen-generated data — using mobile apps/devices), and for disseminating it (via web dashboards or other means) to provide real-time data that can support decisions at various levels and related policy-making processes. However, market information that aims at improving the functioning of markets and supply chains requires a continuous data flow as well as quality, accessibility and trust. More data does not necessarily translate into better information. Citizen-based data-generation systems are often confronted by challenges related to data quality and citizen participation, which may be further complicated by the volume of data generated compared to traditional approaches. Following the food price hikes during the first noughties of the 21st century, the European Commission's Joint Research Centre (JRC) started working on innovative methodologies for real-time food price data collection and analysis in developing countries. The work carried out so far includes a pilot initiative to crowdsource data from selected markets across several African countries, two workshops (with relevant stakeholders and experts), and the development of a spatial statistical quality methodology to facilitate the best possible exploitation of geo-located data. Based on the latter, the JRC designed the Food Price Crowdsourcing Africa (FPCA) project and implemented it within two states in Northern Nigeria. The FPCA is a credible methodology, based on the voluntary provision of data by a crowd (people living in urban, suburban, and rural areas) using a mobile app, leveraging monetary and non-monetary incentives to enhance contribution, which makes it possible to collect, analyse and validate, and disseminate staple food price data in real time across market segments. The granularity and high frequency of the crowdsourcing data open the door to real-time space-time analysis, which can be essential for policy and decision making and rapid response on specific geographic regions. <a href="https://datam.jrc.ec.europa.eu/datam/perm/news/870?rdr=1666109837893">Link to the project</a></p>
Data for "Boosting propagule transport models with individual-specific data from mobile apps"
<ol> <li>Management of invasive species and pathogens requires information about the traffic of potential vectors. Such information is often taken from vector traffic models fitted to survey data. Here, user-specific data collected via mobile apps offer new opportunities to obtain more accurate estimates and to analyze how vectors' individual preferences affect propagule flows. However, data voluntarily reported via apps may lack some trip records, adding a significant layer of uncertainty. We show how the benefits of app-based data can be exploited despite this drawback.</li> <li>Based on data collected via an angler app, we built a stochastic model for angler traffic in the Canadian province of Alberta. There, anglers facilitate the spread of whirling disease, a parasite-induced fish disease. The model is temporally and spatially explicit and accounts for individual preferences and repeating behaviour of anglers, helping to address the problem of missing trip records.</li> <li>We obtained estimates of angler traffic between all subbasins in Alberta. The model's accuracy exceeds that of direct empirical estimates even when fewer data were used to fit the model. The results indicate that anglers' local preferences and their tendency to revisit previous destinations reduce the number of long inter-waterbody trips potentially dispersing whirling disease. According to our model, anglers revisit their previous destination in 64% of their trips, making these trips irrelevant for the spread of whirling disease. Furthermore, 54% of fishing trips end in individual-specific spatially contained areas with mean radius of 54.7 km. Finally, although the fraction of trips that anglers report was unknown, we were able to estimate the total yearly number of fishing trips in Alberta, matching an independent empirical estimate.</li> <li>We make two major contributions: (1) we provide a model that uses mobile app data to boost the mechanistic accuracy of classic propagule transport models, and (2) we demonstrate the importance of individual-specific behaviour of vectors for propagule transport. Ignoring vectors' local preferences and their tendency to revisit previous destinations can lead to significant overestimates of vector traffic and biased estimates of propagule flows. This has clear implications for the management of invasive species and animal diseases.</li> </ol>
Data from: Wallace 2: A shiny app for modeling species niches and distributions redesigned to facilitate expansion via module contributions
<p>These are the occurrence locality datasets used in the example provided in "<em>wallace</em> 2: a <em>shiny</em> app for modeling species niches and distributions redesigned to facilitate expansion via module contributions" published in Ecography (DOI: 10.1111/ecog.06547). The analysis workflow is displayed in the Supporting information of the paper (Fig. S1), and these data are also used in the <em>wallace</em> 2 vignette (<a href="https://wallaceecomod.github.io/wallace/articles/tutorial-v2.html">https://wallaceecomod.github.io/wallace/articles/tutorial-v2.html</a>).</p>
FLOC App Prototype - Version 2 - Data Analysis
<p>This database gathers the feedback from 20 users regarding the second version of FLOC (Floating Companies App) - a prototype of an AR application for tablet and Oculus Quest 2. The data was collected anonymously using the 'thinking aloud' method.</p> <p>Floating Companies (FLOC) visualizes the design companies registered in Portugal in 2019, under the form of a set of floating spheres. This project was framed by the Project Design OBS. - For a Design Observatory in Portugal: Models, Instruments, Representation and Strategies, which collects and interprets data on the Portuguese design ecosystem.</p>
Strategies, Benefits and Challenges App Store-inspired Requirements Elicitation - Supplementary Material
<p>This is the supplementary material for the paper "Strategies, Benefits and Challenges App Store-inspired Requirements Elicitation" (also included in this repository). </p> <p>Abstract: App store-inspired elicitation is the practice of exploring competitors’ apps, to get inspiration for requirements. This activity is common among developers, but little insight is available on its practical use, advantages, and possible issues. This paper aims to study strategies, benefits, and challenges of app store-inspired elicitation, and compare this technique with more traditional requirements elicitation interviews. We conduct an experimental simulation with 58 analysts and collect qualitative data. Our results show that specific guidelines and procedures are required to better conduct app store-inspired elicitation. Furthermore, current search features made available by app stores are not suitable for this practice, and more tool support is required to help analysts in the retrieval and<br> evaluation of competing products. While interviews focus on the why dimension of requirements engineering (i.e., goals), app store-inspired elicitation focuses on how (i.e., solutions), offering indications for implementation and improved usability. Our study provides a framework for researchers to address existing challenges and suggests possible benefits to foster app store-inspired elicitation among practitioners.</p> <p>The package contains the following files:</p> <p>1.Protocol.pdf - it describes in details the steps of the protocol and the intermediate results obtained during the execution.</p> <p>2. Codebooks:<br> 2.a. Codebook Strategies: codebook of the strategies to select apps<br> 2.b Codebook Benefits: codebook of the benefits of use IBE (sheet 1) and ASE (sheet 2)<br> 2.c Codebook Challenges: codebook of the challenged of use IBE (sheet 1) and ASE (sheet 2)<br> 2.d Differences IBE-ASE: table of the identified (categorized) differences between IBE and ASE</p> <p>3. Labelled Data <br> 3.a Strategies - labeled data: the file contains the name of the selected apps, the motivation behind the selection, and the themes assigned to them (refer to 2.a for the explanation of the themes).<br> 3.b Benefits IBE - labeled data: the file contains the extract of the raw data about IBE benefits and the themes assigned (refer to 2.b for the explanation of the themes).<br> 3.c Challenges IBE - labeled data: the file contains the extract of the raw data about IBE challenges and the themes assigned (refer to 2.c for the explanation of the themes).<br> 3.d Benefits ASE - labeled data: the file contains the extract of the raw data about ASE benefits and the themes assigned (refer to 2.b for the explanation of the themes).<br> 3.e Challenges ASE - labeled data: the file contains the extract of the raw data about IBE benefits and the themes assigned (refer to 2.c for the explanation of the themes).</p> <p>4. Raw data.xls: it contains the raw data used in the work (two sheets, one for strategies and one for reflections).</p> <p>5. SLR data: data related to the lightweight systematic literature review <br> 5.a Codebook Scopus.xlsx: codebook for the themes elicited from the SLR. The themes are also present in the files in the folder Codebooks.<br> 5.b SLR-scopus-results-and-selected.xlsx: results of the search string, and, in green, the selected papers. </p> <p>6. Readme.txt: summary file. </p> <p>Note that some of the rows in Raw data.xls (and in the corresponding "Labelled Data" files) are substituted with N/A. This corresponds to those participants who asked to not publicly share their responses.</p>
source IPA files of IOS app with on-device models
<p>To meet the requirements of the double-blind review, we choose to anoymously share here our collected dataset of ios apps with on-device models. For some reason unknown to us, we are also unable to upload individual files that are over 5 g. After many attempts, we can only share some of the files here, hope it is understood. We will release all ios app files and models after the anonymity period is over.</p>
An Exploratory Study on the Occurrence of Self-Admitted Technical Debt in Android Apps
<p>This is the code and dataset that accompanies the study: "<strong>An Exploratory Study on the Occurrence of Self-Admitted Technical Debt in Android Apps</strong>." This study has been accepted for publication at the 2023 International Conference on Technical Debt.</p> <p><strong><em>Following is the abstract of the study:</em></strong></p> <p>Technical debt describes situations where developers write less-than-optimal code to meet project milestones. However, this debt accumulation often results in future developer effort to live with or fix these quality issues. To better manage this debt, developers may document their sub-optimal code as comments in the code (i.e., self-admitted technical debt or SATD). While prior research has investigated the occurrence and characteristics of SATD, this research has primarily focused on non-mobile systems. With millions of mobile applications (apps) in multiple genres available for end-users, there is a lack of research on sub-optimal code developers intentionally implement in mobile apps. </p> <p>In this study, we examine the occurrence and characteristics of SATD in 15,614 open-source Android apps. Our findings show that even though such apps contain occurrences of SATD, the volume per app (a median of 4) is lower than in non-mobile systems, with most debt categorized as Code Debt. Additionally, we identify typical elements in an app that are prone to intentional sub-optimal implementations. We envision our findings supporting researchers and tool vendors with building tools and techniques to support app developers with app maintenance. </p>
App Store data
<p>Data sets from 2 apps stores Google Play and Apple’s app stores. These data sets contain data of 30 apps belonging to 6 different categories. The data was collected from Dec 2018 to Dec 2019.</p>
Wireframe CS Mobile App
<p>Wireframe CS Mobile App proposal</p>
Supplementary Materials for The Privacy-Value-App Relationship and the Value-Centered Privacy Assistant
<p>Supplementary Figures and Tables for preprint: The Privacy-Value-App Relationship and the Value-Centered Privacy Assistant</p>
BrainAgeReversal app data
<p>Data to run the ShinyApp deposited in the AgingVsLSD github repository <a href="https://github.com/AuroraSavino90/AgingVsLSD">AuroraSavino90/AgingVsLSD (github.com)</a></p>
UControlPain App (This is the Official IRB Title)
ClinicalTrials.gov study NCT03833648. IPD Sharing: NO. Countries: 1. Publications: 17.
Pilot Trial of a Game Embedded in a Smartphone App for Smoking Cessation
ClinicalTrials.gov study NCT05227027. IPD Sharing: NO. Countries: 1. Publications: 2.
ScienceDex guides
Understand access before you commit
These curated guides explain access requirements, typical timelines, costs, and reuse considerations for widely used research datasets.
Allen Brain Atlas
Allen Brain Atlas is an Allen Institute collection of brain map atlases, datasets, APIs, and analysis tools covering mouse, human, and non-human primate brain resources.
Annotated Behaviour and Observability Dataset (ABODe)
ABODe is a University of Edinburgh DataShare dataset for behavior classification in group-housed mice using home-cage video, identities, bounding boxes, ground-plate positions, and annotator labels.
DANDI Archive for NWB datasets
DANDI is a BRAIN Initiative archive for publishing and sharing neurophysiology data, including electrophysiology, optophysiology, and behavioral data packaged as NWB and related standards.
International Brain Laboratory public data
The International Brain Laboratory public data releases expose standardized mouse decision-making experiments, including Neuropixels recordings, widefield calcium imaging, behavior, and session metadata accessed through the ONE API.
OpenNeuro
OpenNeuro is a free, open platform for sharing neuroimaging datasets, with public search, dataset pages, and download paths for web, S3, DataLad, and the OpenNeuro CLI.