Fetching the latest programs, projects, and workspace data.
Find open source projects actively accepting contributors. Search repositories, filter by program milestones, difficulty tags, or tech stack.
Use our Orbit AI Matcher to find out! Get instant matching scores based on your developer skills, preferred frameworks, and contribution experience.
Convert your selected open-source project into a winning GSoC, LFX, or Outreachy application using Proposal Studio.
<p>As a part of my GSoC proposal, I plan to integrate a Menu component in the existing MIT App Inventor. Menus are a common user interface component used to provide the user with a set of actions in an activity. Currently, this can be implemented using a number of buttons and setting their visibility appropriately. Developing a menu this way could be very tedious and complex for the user. Hence having a dedicated component in app inventor would be more convenient.</p>
<p>Internet of Things (IoT) is a fast growing field of where sensors are monitoring appliances, actuators, and machines, as well as controlling them remotely, over the Internet. It has helped to create pervasive smart things that integrate computation into everyday environments and link them through Web and Cloud applications. This evolution is impacting our lifestyle and thus quickly and easily creating applications to leverage full potential is of paramount importance. This project is an effort to realize that goal, by integrating the Android Things SDK on the MIT App Inventor platform.</p>
<p>Currently, extensions are limited to just non-visible components. Due to this, extensions can't be dragged into the screen designer. To work around this, extension developers have to get a reference to a visible component as parent under which they create UI views. This, however, defeats the idea of App Inventor, which allows the users to create their UI of their apps using the concept of WYSIWYG. My proposal to solve this problem is to have a generic <code>MockVisibleComponentExtension</code> which can be dragged into the designer. The extension will be just a visible component as opposed to non-visible component. This allows the extension to be placed under a <code>ComponentContainer</code> under which the extension can create its views. This allows the users to view a clear hierarchy of their app's UI when using "visible" extension. Then, there will also be a need for <code>MockComponentContainerExtension</code> into which any visible component/extension can be placed.</p>
The main point is to create an abstract class in both Swift and Java, shared among all AI components, which will contain all the necessary functions for such components. This abstract class will then be inherited by the ImageClassifier and AudioClassifier classes, allowing them to perform correct classification, especially thanks to asynchronous operations, utilizing AsyncTask in Java and GCD in Swift, respectively.
This project is to enable the selection of multiple blocks at the same time and allow moving and doing actions on multiple blocks on Blockly. This behaviour is pretty much the same as when you try to manage your files on your Operating System, and you can drag a rectangle to select multiple files, then moving them around, copying, deleting. The design is that the Blocks multi-select feature will be only functional when you hold the Shift key, so that users can still drag the workspace when not. Users can simply click on the blocks to select or unselect them, or drag a rectangle to select a set of them at the same time. A button would also be added to enable multi-selection feature in case users are unable to access the keyboard. It sounds like a little bit easy, but actually, I would say that it's not. Multiple selections can become a crazy-complex feature when you start thinking about the details. When dragging two blocks, you have to think about how the connections will work. When you right-click on multiple selections, you also have to make sure that those options apply to all blocks. And the touch screen problem would also need to be addressed. The feature request (https://github.com/google/blockly-samples/issues/267) has remained open on the GitHub Issues for 6 years, but it's still in the discussion phase and far from the beginning of Implementation there. So I hope we can implement that during GSoC 2022 if possible.
The primary objective of this project is to enhance the user experience of MIT App Inventor by providing users with information about the availability of components on iOS or Android platforms. To achieve this, proposed changes will be made to the Designer editor code to enable users to determine whether a component is accessible on a particular platform or both. The coverage.json file will be utilized to extract information about the availability of components, which will be represented by iOS or Android icons displayed on the palette items and a text displaying if the component is exclusive to any of the platforms(Android or iOS) on palette Help Popup dialog box. Furthermore, a dialog box will inform users about unsupported components when they connect their devices through the AI companion. The proposed modifications will empower users to make informed decisions when creating their applications, resulting in higher-quality apps that cater to user needs and expectations.
<p>This project aims to improvise ListView in App Inventor. It was one of the most demanded improvements from users. Idea - Adding custom layouts to ListView. Expected Outcome - 1) Users will be able to select one of the pre-defined ListView layouts and use it in their applications. 2) Users will be able to create any custom row of ListView if it is not present in the pre-defined set of layouts.</p>
<p>Currently, App Inventor does not have an element in the user interface similar to RadioGroup in android. As part of my GSoC proposal, I plan on adding a CheckBox Group component to the user interface which would automate the task of unchecking the rest of CheckBox’s in a group once one of CheckBox is checked.</p> <p>However, it can be implemented using existing CheckBox and blocky editor but it is quite tedious and it’s not scalable. It would be better if this feature is natively implemented as a user interface and it could use the platform-specific implementation of this technique.</p> <p>Update: After discussing with my mentor, we would instead be adding a RadioButton and RadioGroup Component. They would function the same way as they do on android.</p>
The project aims to set up a code coverage metric with additional unit tests to test the GWT client code. We will be using Jacoco a as code coverage metric and writing the Junit tests to unit test the GWT client code.
This project aims to introduce a scalable and maintainable internationalization (i18n) system for applications built using MIT App Inventor. Currently, App Inventor does not provide a structured approach for handling multi-language support, making it difficult for developers to create globally accessible apps. The proposed solution introduces a key-based translation system that decouples user-visible text from UI components. The system integrates across multiple layers of App Inventor, including the Designer, Blockly, runtime, and build system, enabling automatic translation handling in generated applications. Key features include: - Automatic detection of user-visible text from component properties and Blockly blocks - A centralized translation editor for managing multi-language content - Context-based key generation to ensure stability and avoid ambiguity - Runtime translation using JSON for flexibility during development (Companion) - Build-time generation of native Android/iOS resources for efficient production builds The system is designed to be fully backward compatible and supports progressive adoption, allowing existing projects to continue working while enabling developers to gradually migrate to the new translation model. Deliverables include: - A working runtime translation system for App Inventor apps - Integration with Blockly for key-based text handling - Designer-level synchronization and key management - Build-time resource generation for native localization - End-to-end tested implementation with documentation
<p>Each operating system has its own "packages" that allow installing different applications to extend the features in the device. Android is not an exception, and their package type is the .apk file type (Android Application Package). This file has been present in Android since the very beginnings, allowing the development of several applications.<br> And App Inventor has the ability to build the app projects into those .apk files, as it is an Android app creator.</p> <p>Google, as the owner of Android, always tries to optimize its environment by protecting the users and enhancing the development ecosystem, among other things. So, they wanted to make a change. In Google I/O 2018, Google introduced the .aab file format (Android App Bundle).<br> This new format is being used by Google Play Store, and Google is encouraging everyone to use it when distributing apps.</p> <p>This project proposal intends to bring the option of exporting app projects in MIT App Inventor as .aab files, which make their distribution more straightforward in Google Play Store.<br> Moreover, if App Inventor had support for .aab files, it would be possible to make use of the App Signing by Google Play.</p>
An approach to enhance the functionality of App Inventor by adding the support of augmented reality using Google's expertise AR-Core and OpenGL ES. This will bring Google's augmented reality experience in App Inventor.
<p>This is the new feature added in MIT APP INVENTOR which allows users not to permanently delete the project once they click the Delete button intentionally or unintentionally. Rather it moves the deleted projects to Trash tab and once user makes up his mind he can go to trash tab and delete the project permanently.</p>
<p>This project is related to Designer which will introduce new theme styles preview option in App Inventor when the Device Default option is clicked. Through this option we can preview how our app will look like on different Android Platforms as well as iOS. The preview options is divided into three categories: Android Holo which is (Android 3.0-4.4.2), Android Material which is (Android 5+) and finally iOS version. Implementing the look and feel of these categories would provide users an idea of how their app would look and work on different platforms.</p>
This proposal aims to enhance MIT App Inventor by developing artificial intelligence (AI) components for iOS platforms. By re-implementing existing AI features, the project seeks to democratize AI development and empower users to seamlessly integrate AI functionalities into their mobile applications. The deliverables include designing and implementing these components, integrating them into the MIT App Inventor platform, providing comprehensive documentation and tutorials, and conducting thorough testing for reliability and performance. Ultimately, this endeavor strives to foster innovation and creativity in mobile app development while making AI accessible to a broader audience.
App Inventor is becoming increasingly popular among users accessing the platform through mobile phones and handheld devices. In response to this trend, this project aims to implement an enhanced user interface tailored for smaller screens. By leveraging GWT's UiBinder framework, we will introduce flexible interface layouts that adapt to both device type and user preferences, ensuring a seamless and practical experience for mobile users. Deliverables will include optimized interface designs and usability improvements for small-screen devices, aligning with the growing accessibility of handheld technology globally.
The current color editor in MIT App Inventor is outdated and lacks important features that could make color selection easier. This project aims to replace it with a modern and user-friendly color picker. The new color picker will allow users to select colors from a color ramp and quickly access frequently used colors from their projects. Frequently used colors will also be importable and exportable, as they will be stored in project properties.
While developing apps using MIT App Inventor, students often need help. For this MIT App Inventor has a community where students can reach out for help. While the community is very helpful and makes development easier, it would be even more convenient and time-saving to have a user interface on the app inventor website itself from which users can directly ask questions in the community and project files can be automatically uploaded on community website along with that .
This GSOC project aims to integrate the Blockly work-space search plug into App Inventor and add App Inventor specific functions to it. Adding dropdown to select what filter to use and implementing these filters in JavaScript.
<p>A Recycler View component would be created which can display media along with text</p>
<p>App Inventor is a web application for building Android apps, which includes a block-based coding editor. The editor includes many blocks which accept enums as inputs. Currently these inputs are filled by assigning a constant number, which is not very readable nor localizable.</p> <p>This project seeks to replace those constants with enumeration dropdowns. These dropdown-blocks will be defined via <a href="https://en.m.wikipedia.org/wiki/Java_annotation" target="_blank">Java annotations</a>, so that they can also be added by <a href="http://ai2.appinventor.mit.edu/reference/other/extensions.html" target="_blank">App Inventor extensions</a>. They will then be added as <a href="https://developers.google.com/blockly/guides/configure/web/toolbox#shadow_blocks" target="_blank">shadow blocks</a> to the blocks in the <a href="https://developers.google.com/blockly/guides/configure/web/toolbox" target="_blank">toolbox</a>. In addition, other means of accessing the non-shadow versions of these blocks may be added.</p>
<p>Modernising and modularising the App Inventor Projects View by introducing shortcuts for project actions and integrating markup UI declarations with standardised design systems</p>
Currently, the properties for the screen1 form contains a number of project project-wide properties such as App Name, Theme and many more. We want these properties separated from the component and maintained on a separate dialog on the designer view.
The project "iOS versions of Android components" aims to develop iOS counterparts of popular Android components that are widely used in mobile app development. The objective is to provide iOS developers with an easier transition between the two platforms, by providing iOS versions of Android components that they are already familiar with. The project will involve identifying and analyzing popular Android components, understanding their functionality and behavior, and then developing their iOS counterparts using Apple's development tools and technologies such as Xcode and Swift. The iOS versions of Android components will be designed to be compatible with the latest versions of iOS, including iOS 14 and higher. The components will be thoroughly tested to ensure compatibility and reliability across different devices and operating system versions. This project will be beneficial to developers who are familiar with Android development and are looking to transition to iOS development. It will also be useful for iOS developers who want to incorporate popular Android components into their iOS apps. Overall, the project aims to improve the ease of transition between Android and iOS development, and ultimately enhance the user experience of mobile apps across both platforms.