using Listpicker to create categories?

I'm very new to creating apps, and all my searching has come up blank so I'm asking here.  Is it possible to use a list of numbers, in listpicker to create categories so that I don't have to predefine a set number of text boxes and then have some empty.  Let me explain - I am trying to create an inventory app and I'm using listpicker to ask how many categories the user will have.  Then after that number is chosen to have text boxes where the user can input their category names.  So, instead of creating 15 categories and having 11 empty if the user only needs 4, is this something that can be created dyamically?

So, I certainly don't mind doing the research and learning myself, but I don't even know what this would be called.  So if someone can just point me in the right direction, I'll go birddog it.

--

just use a textbox to enter a new category and a button to add that category into the category list, then in the listpicker display the list with all the categories

of couse you have to store the category list in TInyDB

first do the tutorials http://appinventor.mit.edu/explore/ai2/tutorials.html to learn the basics of App Inventor, then try something and follow the

 Top 5 Tips: How to learn App Inventor

--

Sorry, App Inventor can not create objects dynamically.

What users do in your situation is create  enough text boxes that will ever be needed, then within the list picker,   hide or show only the number of text boxes that are needed  using set Textbox1.Visible to true or false.     A neat feature of the TextBox that you can use a hint, rather than have a label next to each text box explaining what each text box is for  so use the built in hint feature of the Textbox.    If you clear all text in the TextBox, the hint appears.     You can write a routine clearing all your text boxes using the advanced component if you want to always start data entry with a clean slate.

--

Excellent!  Thanks so much.

--

Expecting TextBox component but got a YailList instead

I am using App Inventor 2/Windows 7/Chrome/32.0.1700.107 m

I created a profile screen with many textboxes and checkboxes and I store the settings in a TinyDB. (using standard elements I had this working for a few text/check boxes)

To make it easier to manage a large number of entries I want to use the Any TextBox and Any Checkbox components.

1. I created variables initialized as an empty list for AllTextBoxes and AllCheckBox

2. In the screen initialization I add each TextBox to the list AllTextBoxes (same for checkboxes)

3. When the user clicks Apply I run a procedure "updateDatabase" 

"updateDatabase" is supposed to cycle through each TextBox in AllTextBoxes and do the following:

⦁ First it determines if the textbox text is empty. It either stores the value "none" or the existing value to a variable called text

⦁ Then it sets the TextBox.Hint = text

⦁ Next it adds "text" to a new list called StoreValue

⦁ Last it sets the TextBox.Text to " "

Then it should go through the rest of the AllTextBoxes list before running a similar process for AllCheckboxes and the finally storing to the TinyDB.

When I try this I get the following error:

Problem with application 

Property getter was expecting a TextBox component but got a YailList instead.

Please SEARCH in this forum before posting your question.   There's a good chance your question has already been asked.

If you are asking for technical help, you must provide the following information:

- Are you using MIT App Inventor Classic, MIT App Inventor 2, or something else (what?)

- What OS are you using? (e.g, MacOS 1.8, Windows 8, ...)

- What browser are you using (e.g, Chrome version 30, Firefox 24, IE 8, ...)

Also provide as much information as you can, such as screenshots and instructions that will let others duplicate the issue.

--

Your problem is that in the "do" part of your "for each item in list" block, you are using "get globalAllTextBoxes" in four occurrences where you really want to use "get item".  The former refers to a list of components, while the later refers to one of the components in the list in each iteration of the loop. 

--

THANKS!!  That was it! I didn't realize I needed to hover over item to use it. It seems to be working great now and so much better than calling each text/checkbox individually.  I wish I had used this method in other apps.

--

search results for hint text or number

Re: Expecting TextBox component but got a YailList instead.

To make it easier to manage a large number of entries I want to use the Any TextBox and Any Checkbox components. ... Then it sets the TextBox.Hint = text; Next it adds "text" to a new list called StoreValue; Last it sets the TextBox.Text to " ". Then it should go through the rest of the AllTextBoxes list before ...

Re: using Listpicker to create categories?

What users do in your situation is create enough text boxes that will ever be needed, then within the list picker, hide or show only the number of text boxes ... A neat feature of the TextBox that you can use a hint, rather than have a label next to each text box explaining what each text box is for so use the ...

Re: Changing hint box values using variables.

The top set of blocks just puts the actual number as the hint. The bottom set I had to use the text box to get it input what i wanted into the text hint field. Not sure how to call the variable so when I select fruit, grapes or whatever shows ...

Re: Multiple actions variable by text box?

Restrict numbers.?.. use a if else block with conditionals where if number < 2 or number > 20 provide an error message else proceed. ... Yes, it not exactly what you want but it should provide you a hint about what you should do.

Re: Doubt beginner - button triggers another button.

In case you can also send it as text "FRGF" than you can use the JOIN block to join the letters together into a label and then send the label.text to Arduino, I dont explain it in detail since I am sure ... I would use a clock to tell the app to send after half a second the content of the second index number etc.

Re: [MIT App Inventor] Re: How does AI handle strings?

I think you can also do Ceasar cipher using just Text and string operators -- ie, no need to convert to lists. Basically ... Add 4 tindex, and find the element of Alphabet at that incremented index. You'll ned to deal with the case where the incremented index is greater than 26. (HInt: Use modulo). The basic ...

Re: Calling specific variables from specific columns in an CSV file and displaying .

Some spreadsheets have the ability to export these values to a csv text file. Export the file ... Hint: you need the list from csv table or list from csv row block . You will ... You have several two digit numbers in your csv .. think about this a bit because you might need an image of each number shown. That is ...

Re: Trying to create flipbook.

one way is to number the database tags sequentially and call the images by number? If you need to sort the images ... and not in the form Page 1 , Page2 etc. Even in that instance, they could be sorted by using a Text block to remove the word Page. Is this the hint you need to continue with your project?

how to change the hint text of the filterbar on the ListPicker ?

as the title

--

Not in the base component.

Maybe one of the other variants of AI2 has it.

See the list in my FAQ:

FAQ for lists

-- 

The simple Virtual life

TUESDAY, FEBRUARY 19, 2013

A Single Thread of Execution in App Inventor Screens

The development documentation provides a very good example of why certain things in the User Interface (UI) of an app happen in the way they do. In App Inventor we use Screens to lay out components to create the UI of the app.

The main idea is that all actions that affect the UI happen sequentially. Some examples of these kind of actions could be changing the text of a label, or handling users interacting with the app via a button or a text box. 

Sequential execution in App Inventor means that different blocks can never interrupt each other. 

Different blocks and handlers will always be executed in sequence. Once a block starts executing, it will execute till the end, no matter if there are other blocks reacting to the one in progress, or users pressing buttons in the app. On more technical terms, we say that everything in the UI is executed in one Thread, the UI Thread, which is responsible for all updates and interaction that happen in each Screen of your app. For this to happen, we need some kind of mechanism to keep track of what needs to be done next, and when something should be done. A very simple model would be a Queue, just like the one you join at the supermarket to pay for your shopping. Tasks can be added to a Queue in the same way that people join in the queue from the end of it.

With all this in mind, let's see the example in the documentation. (From How to add a component )

“This gives a simple execution model for users: An App Inventor procedure will never be interrupted by an event handler, or vice versa; nor will one event handler be interrupted by another. This is illustrated in Figure 1:” (Ellen Spertus)

Figure 1: Sample program demonstrating serial semantics.

The example uses two Ball components, one CollidedWith handler that should fire as soon as Ball1 collides with anything, and an extra procedure called wait, which we don't really see what it does, but we are going to suppose that it takes 20 seconds to execute (imagine that it is loading content from the internet and it takes that long). All the code, except for the collision handler, is contained within a Click handler.

When Button1 is clicked, the two balls are positioned in exactly the same place, first Ball1, and then Ball2. Positioning the second ball in the same place as Ball1 should trigger the collision handler for Ball1. Some users would expect this to happen straight away, but if you were to execute this code, you would see that the collide handler will not execute until the click block finishes, and this would take at least 20 seconds because of the call to wait.

Following the same idea as above, you can think about the UI thread as if it was a Queue to get into the cinema; on arrival, ticket buyers will position themselves at the end of the queue.

When Button1 is clicked, we add the following things to the Queue:

⦁ position Ball1

⦁ position Ball2

⦁ wait

⦁ set Label1 text to : '...End of Button1.click...'

When Ball2 is positioned, the CollideWith handler is added to the Queue, but it cannot be executed straight away because the UI thread still has some tasks to do. So, after a couple of seconds we will see a queue such as:

⦁ position Ball1 (DONE)

⦁ position Ball2 (DONE)

⦁ wait (IN PROGRESS)

⦁ set Label1 to: '… End of Button1.click ...' (TO DO)

⦁ CollidedWith (added to the queue when the collision happens)

⦁ ⦁ set Label1 text to: '… Ball1.CollidedWith ...' (TO DO)

So Ball2 makes the handle trigger, but that does not mean that it will be executed straight away, instead it means that it will be added to the queue in the UI thread.

In the end, Label1 will always be assigned the value '...End of Button1.click...' first, and the value '...Ball1.CollidedWith...' later.
When both blocks finish, it will always read: “...End of Button1.Click......Ball1.CollidedWith...”.

Please note that having a procedure like wait blocking the UI is a really bad idea in an app, because as we saw in the explanation above, the app will be unresponsive for those 20 seconds, and this is not a pleasant experience for the users. If your app needs to do some expensive processing, it is quite possible that this interaction will block the app for as long as it takes.

From a design and development point of view, it is also important to note that certain blocks in App Inventor were designed with the UI thread in mind, and broken down into two different stages. For instance, the Web component Get call could be considered part 1 of a call to a web resource. This call will not block the UI because it is not performed in the UI Thread. When the response from the Get call is received, then part 2 will execute, which would be the eventGotText (or GotFile, depending on how Get was configured). If you are planning on developing a new component for App Inventor, you need to take this into account.

Also related to this idea of sequential execution, a lot of users ask why their timers do not fire on time, for instance exactly every 2 seconds. Actually the timers fire at the time they are supposed to, but this only means that their handlers get added to the scheduling queue for UI updates. If at that particular moment something else is executing in the Screen, then the actions fired by the timer will have to wait for those other actions to finish, before they can be triggered. But once they get next to be executed in the Queue, they will fire one after the other, not waiting for any intervals. The waiting was already done before joining the Queue. 

This is actually something very usual in UI libraries, from Java (Swing) to Android, and even JavaScript. The browser, in which JavaScript executes, also has a single thread of execution, generally called the event loop, and it will behave in the same way as App Inventor does. Same happens if you run JavaScript on the server through something like node.js.

This is all a simplification of what really happens, and Android can create other Threads of execution that do not conflict with the UI thread to carry on with other operations. For a deeper dig in the matter, follow the link in the Android documentation to the Painless Threading article.

Controlling Bluetooth Low Energy devices with MIT App Inventor

Controlling Bluetooth Low Energy Devices with MIT App Inventor

Tiffany Le (tiffanyl@mit.edu)

Hal Abelson (hal@mit.edu)

Andrew McKinney (mckinney@mit.edu)

May 2016

ABSTRACT

This paper describes the initial design and testing of an App Inventor component for working with Bluetooth Low Energy (BLE) devices.

From home appliances to wearable accessories, the rise of Internet of Things devices has led to a growing need for mobile applications that can control and connect these dissimilar devices together. Building these mobile apps, however, generally requires considerable investment of time and knowledge of text-based programming skills. Our work aims to alleviate these constraints by using MIT App Inventor as a common platform to simplify the creation of mobile apps in the Internet of Things development process, thereby making it more accessible to a wider audience. In particular, we develop a novel Bluetooth Low Energy Component (BLE) that integrates into the App Inventor framework. At its core, the BLE Component is designed to allow mobile phones to communicate with Internet of Things devices. Its added capabilities are dynamic detection and support for device-specific functionality, such as a temperature reading from a sensor. The BLE Component interacts in real-time with the sensors on the WICED Sense device and the Arduino 101 board. This overall design enables even those without any programming experience to create their own mobile applications that can communicate seamlessly with the ever-changing world of Internet of Things devices

I. INTRODUCTION

Internet of Things (IoT) devices, ranging from home appliances to wearable accessories, have been proliferating rapidly in recent years and this trend does not appear to be abating. By 2020, it is expected that approximately 24 billion of these interconnected smart devices will be in use [4].  With all of these IoT devices hanging in the balance, there is a need for mobile applications that are able to manage communications between currently existing devices as well as with new devices as they arise. However, despite this need, the development of mobile applications faces several obstacles. Most potential novice developers deterred by their lack of traditional, text-based programming knowledge, and also by the time it takes to complete the development process.

To mitigate these constraints, we develop a BluetoothLE Component for MIT App Inventor to provide a standardized, quick, and easy way to create mobile applications that can connect to IoT devices [1]. In building the BluetoothLE Component, we merge two main technologies: MIT App Inventor and Bluetooth Low Energy (BLE). This paper discusses the technical approach used and the results and implications of the implementation.

MIT App Inventor

MIT App Inventor is ideal for developing IoT applications with its visual, blocks-based programming interface. With App Inventor, users can simply select, drag and drop functional blocks onto the web-browser based platform to create their own Android mobile applications [2]. Supporting over 4.5 million users, this easy and simple programming interface affords everyone, even those without any programming experience, the ability to quickly create their own mobile applications. Unlike traditional Android application development, that typically requires programming in Java, App Inventor encapsulates the Android development model and hides the implementation details through graphical blocks, making the Java programming code is invisible to users.

As a result, building apps in App Inventor need only to combine components of their choice by plugging them together and manipulate the associated blocks that activate the components’ desired functionality. This is done using the two parts of the MIT App Inventor Interface, which are shown in Figure 1:

⦁ Designer - The designer allows users to select the components they will be using in the mobile app and adjust the layout of the app.

⦁ Blocks Editor - The blocks editor allows users to connect the blocks together to provide the app with functionality. Figure 2 shows an example of a set of connected blocks used to create an app that reads aloud a message.

Figure 1: Screenshot of App Inventor Platform with Views of the Designer (top) and Blocks Editor (bottom)

Figure 2: App Inventor Blocks Used to Create an App that Reads  User Input‘

Bluetooth Low Energy

Our work focuses on developing a BluetoothLE Component to provide IoT connectivity since BLE technology plays a significant role in the IoT ecosystem. Building off of traditional Bluetooth technology, also known as Bluetooth Classic, BLE is similarly a standardized, short distance wireless communication protocol that enables devices from across multiple vendors to send and receive data. However, BLE is more suitable for IoT devices because it supports low peak and sleep mode power consumption, allowing these devices to conserve battery power in between connections. In fact, it is this low power consumption when BLE is enabled that makes it ideal for sensors and smaller devices such as headsets and heart rate monitors [6]. Another reason why BLE is a natural fit for the IoT environment is due to the fact that it can directly connect devices to applications on smartphones, PCs or tablets.

There are two ways that an interaction between BLE devices can occur, depending on whether a connection has been made. The rules regarding these connections along with device discovery and advertisements are governed by the Bluetooth Generic Access Profile (GAP), a mandatory framework that all BLE devices must adhere to.  

⦁ Broadcaster vs. Observer - In this scenario, the sensors embedded in various IoT devices will send periodic advertising packets to the smartphone in listening range. Since the smartphone merely acts as an observer by scanning the frequencies of these devices to receive the advertising packets being broadcasted, there is no connection between the sensors and the smartphone.  

⦁ Central vs. Peripheral - In developing the BluetoothLE Component, we primarily focus on providing the blocks to interface with BLE devices via this communication method. When the smartphone finds a device it wants to connect to, it will then initiate a connection. The smartphone now assumes the central or master role by managing the timing and sending or receiving data from the sensor, which only plays a peripheral or slave role during this connection. Being the master, the smartphone can connect to several slaves/peripherals at the same time. On the contrary, the peripheral devices cannot communicate with each other while one of their peers is connected to the master. Peripherals are required to have low power consumption since they have to be inactive for long intervals [10].

Once the connection has been established, the smartphone and the peripheral device will start exchanging data according to the Generic Attribute Profile (GATT). This is a specification for sending and receiving short pieces of data to help developers develop their own specific applications. It also has various use cases that developers can incorporate into their apps. For example, a developer can use the GATT heart-rate measurement data for his heart-rate tracker application.

Depending on the data needed, a master smartphone can be the GATT client and the slave sensor can be the GATT Server, or vice versa.
In our work, the smartphone containing the app with the BluetoothLE Component is the GATT client. It requests data from the GATT server, which, in the present implementation, could be a sensor on either the Broadcom WICED Sense devices or the Intel Arduino 101 board. These sensors have a database that stores services, characteristics and other data that the GATT Client needs. A characteristic is analogous to a data type that contains a single value. A service is a grouping of similar characteristics, where each service differentiates itself from the other by a universally unique identifier (UUID). Similarly to services, a characteristic also distinguishes itself with its own unique, numeric UUID [7]. Figure 3 shows the hierarchical nature of services and characteristics, with a characteristic at the lowest level in a GATT transaction.  A client relies on a characteristic to give it a data value so that it can read and write when exchanging data with a server.

Figure 3: BLE GATT Communication Protocol. Taken from [8].

II. PREVIOUS WORK

Prior to our work, the only way to develop a mobile application with BLE functionality was through traditional Android development, as the set of connectivity components in MIT App Inventor to enable mobile apps to interface with various communication protocols did not include BLE. The closest communication protocol to BLE that App Inventor supports is Bluetooth Classic, which is available through a two-component, client-server model, with one component acting as a client and the other as a server. However, despite some similarities between Bluetooth Classic and BLE, BLE is built with entirely different core specifications and design goals. BLE uses a star topology which theoretically would allow connections of billions of devices at a given time. By contrast, Bluetooth Classic only allows up to seven devices at a time with its piconet topology. Furthermore, while Bluetooth Classic is often used for high bandwidth, continuous streaming applications which drain battery power rather quickly because of its intensive data transfer rate, BLE is optimized for small bursts of data exchange typically found in sensors running on coin-sized batteries for months [3]. In light of this difference in power efficiency, App Inventor users cannot use Bluetooth Classic to connect their apps with IoT devices. Hence, our BluetoothLE Component is developed to address the IoT connectivity issue.                  

III. TECHNICAL APPROACH

The BluetoothLE Component is a novel addition to MIT App Inventor. As shown in Figure 4, the BLE Component can be implemented as part of a mobile app when created on the MIT App Inventor platform. This mobile app can then be used to interface with any number of IoT devices via BLE. Like all of the other components currently in MIT App Inventor, the component models the Java-based approach to Android development. In particular, the BluetoothLE Component breaks down the BLE communication process into Java methods to form the blocks on the App Inventor interface.

To implement these Java methods, the BluetoothLE Component uses and builds off of the BLE API provided for Android development. The API allows applications to wirelessly connect with other BLE devices via scanning, querying, connecting through service discovery, transferring data and managing multiple connections [5]. Most importantly, the API enables the creation of blocks that offer these generic, basic communication functionality so that BLE devices are able to establish a connection with the mobile phone.

Figure 4: System Schematic - The Mobile App with the BluetoothLE Component created on App Inventor interacts wirelessly with an IoT Device. Arduino Board taken from [9].

Basic Communication Functionality

The process of enabling a mobile app to communicate with a BLE device is broken down into several main stages, which are reflected in the development of the BluetoothLE Component. First, a GATT client is established on the phone to act as the main communication backbone interfacing a mobile app with BLE devices. Once that step is complete, the app will start to conduct a scan to find possible BLE devices to interface with by requesting information on each device in the vicinity. Only the BLE-enabled devices nearby will be able to respond to this request. Based on the information provided by the BLE devices, the app on the phone will choose a specific device and start to initiate the connection to the GATT server hosted on the discovered BLE device. From here, data transfer can take place once the connection is established between the phone and a BLE device. The data exchange between the GATT client on the smartphone and GATT server on the connected BLE device can occur in four different ways:  

⦁ Read  - This operation is requested by the GATT client on a specific characteristic held by the GATT server such as integers. The server complies by providing the requested value.  
⦁ Write  - This operation is initiated by the GATT client on a specific characteristic held by the GATT server, providing the server with the new value. The server stores this new value and may or may not send an acknowledgement to the client.  
⦁ Notify - This operation is initiated by the GATT server when a new value is written to one of its characteristics, provided that the GATT client has subscribed to notifications on that characteristic. The server returns the new value so that it can be read by the client.     
⦁ Indicate - The only difference between this operation and notify is that it is acknowledged.

To manage the data transfer and ensure that the transfer is successful, the BluetoothLE Component contains callbacks to indicate connection status such as when the data has been read, written, or changed. During this callback, the client may retrieve a read or notify value from the server.

Device-Specific Functionality

Beyond the basic communication functionality, however, more support is needed as each BLE device also has its own unique capabilities that vary from device to device. While these diverse capabilities are what makes BLE devices so popular, they also pose a challenge for developers, as consumers do not merely want basic communication between the BLE devices. Consumers expect to be able to capture data to meet their ever changing needs. Thus, the BluetoothLE Component is designed to handle device-specific functionality by including blocks to dynamically detect all of the GATT services and characteristics supported by a particular connected device. The blocks scan for services and characteristics provided by the device and return these services and characteristics in a list.   

Furthermore, in order to provide flexibility and broaden the support of more devices, the BluetoothLE Component was developed with blocks that allow users to choose particular services or characteristic from the entire list of detected services and characteristics. For some of the more commonly used services and characteristics, we used a dictionary that contains a mapping of the UUID of the services and characteristics to a human-readable name. As a result, users can simply select a particular service and characteristic without having to know the exact UUID or details regarding how the services and characteristics work. The selected service and characteristic enables the characteristic data value to be read or written. For example, with a Battery Level Service and Characteristic, the battery level of a connected device can be monitored. This approach allows for compatibility with a large number of BLE devices due to the universal nature of GATT services and characteristics.

Testing

With the BluetoothLE Component development complete, the next step involves testing of the component. This includes developing several sample apps to communicate with the BLE devices. The testing process consists of having testers replicate several sample apps as well as creating their own original apps. These sample apps can range from turning on and off an LED to monitoring the heart rate of a user.

IV. RESULTS

A final set of twenty-eight new blocks was created to form the BluetoothLE Component after a round of testing. These blocks range in capabilities from connecting to a particular device to determining when a value from a characteristic changes. They are grouped into several categories, generally corresponding to the different phases of the mobile app and BLE interaction:

1. Scanning for devices - As seen in Figure 5, the blocks in this category can initiate and end the scanning of BLE devices as well as return the devices found in the scanning process in the form of a callback. Since scanning is a battery-intensive operation, a StopScanning block is needed to prevent the battery from fast drainage.    
2. Establishing a connection with a device - The blocks in this category can connect and disconnect from a BLE device as shown in Figure 6. There are several different mechanisms to do so. The device can be connected by using its address or by an index. There are also blocks to indicate whether the connection is successful.
3. Getting connected device properties - The blocks in Figure 7 provide some basic information about the connected device, including the device name, address, and signal strength.
4. Reading Values: Figure 8 shows the blocks for four different data types - bytes, integers, decimal floats, and text strings - that were created to enable reading from a BLE device. These blocks encompass both reading a single value and reading on a notify when a value has changed. For each instance, the particular data value is returned.
5. Writing Values:  Blocks for two different data types - integers and text strings - were created to enable writing to a BLE device along with a block to ensure the particular value has been written successfully. These blocks can be seen in Figure 9.
6. Getting Services and Characteristics - The blocks from Figure 10 enable the detection of the more device-specific functionality. There are several different mechanisms to achieve this goal. The devices can be discovered by either their characteristics or services.  

Initial testing was done with a group of five users, who all tested this newly developed component with the Intel Arduino 101 or Broadcom WICED Sense devices. The Arduino 101 is an open-source, programmable circuit board that was chosen for the diverse sets of sensors that could interface with it. Users could easily control the circuitry to attach a wide range of sensors to support their own needs. Arduino 101 also has a real-time operating system and framework that supports BLE capabilities. Moreover, due to its battery-charging circuitry, it is a relatively low maintenance system. Finally, Arduino 101 kits are frequently used in classrooms, making them ideal targets for testing with App Inventor, as a majority of App Inventor users are students in the classroom learning programming for the first time.     

At the other end of the spectrum, the WICED Sense was chosen for its integrated set of sensors. The WICED Sense comprises of a BLE-enabled System on a Chip (SoC) and sensors that enable interactions with the environment: gyroscope, accelerometer, magnetometer, pressure sensor, humidity sensor, and temperature sensor. The SoC connects directly to the sensors without the need of an external microprocessor.      

Using the BluetoothLE Component, the testers were able to create a variety of apps that interacted with these two devices. Specifically, all of the testers were able to create apps to scan for nearby BLE devices and connect to them, as shown in Figure 11. Once a device was connected, the user was able to read to or write from the sensor with the services and characteristics supported by that sensor. An example of one app, presented in Figure 12, is the ability to read the battery level of the BLE device using the Battery Level Service and Characteristic. A subset of the blocks used to retrieve battery level is shown in Figure 13. Another sample app that a user created was to turn an LED Light on and off. As another example, users were able to implement an app that would detect whether or not a child was in a car seat and warn parents if they began to walk away from the child by utilizing the magnetometer on the WICED Sense and monitoring the changes in signal strength. Finally, users could also obtain readings from temperature and moisture sensors that would allow them to monitor the quality of their plants.

Figure 5: Blocks used to Scan for Devices

Figure 6:  Blocks Used When Connecting and Disconnecting with a Device

Figure 7:  Blocks Used to Get Connected Device Information

Figure 8: Blocks Used to Read Data Values

Figure 9: Blocks Used to Write Data Values

Figure 10: Blocks Used to Get Device Services and Characteristics

Figure 11: Sample App - BLE Device Scanning

Figure 12: Sample App - Battery service and characteristic to read battery level

Figure 13: Sample Blocks program to read battery level

V. DISCUSSION

From these results, the BluetoothLE Component is functional and can be used with a variety of BLE devices. The strength of this component is that it provides a balance between general and device-specific functionality. The device-specific functionality is critical because it provides flexibility that can be easily extended and added to in the future as the IoT population continues to grow. This scalability feature will add new capabilities to MIT App Inventor, allowing it to continue to stay relevant.

From the initial testing results, it is evident that there are still features that would greatly enhance the usability of the BluetoothLE Component. For example, adding the ability to send a decimal value to a connected device was desired in testing, but missing from the current version of the component. Testing also revealed that it would be beneficial to change some of the block names to make them more accessible for users unfamiliar with BLE. Additionally, testing indicated redundancies in blocks that were unnecessary and areas where several blocks could be made from a single block for a more well-defined functionality. Suggestions from users indicate that further testing with a broader range of devices and a larger number of users would more accurately determine the compatibility and capabilities of the BluetoothLE Component. This large-scale usability testing will also help guide how to refine or modify the blocks to better suit the needs of App Inventor users and determine if the issues from the first round of testing had been resolved.

Overall, while the BluetoothLE Component was successful in testing with the supported services and characteristics of the devices, there are still limitations in what the BluetoothLE Component can do. For instance, most services and characteristics are only able to be identified by UUID, with only a small number of them named. This is problematic only for custom services and characteristics rather than standardized ones.

In the future, implementation of additional functionality for compatibility with wider range of devices and applications can be achieved by adding or modifying new blocks. Additional prototypes can also be created to showcase a wider range of capabilities of the BluetoothLE Component. Finally, App Inventor users will be able to better familiarize themselves with the BluetoothLE Component and use it to create apps connecting to IoT if there are more examples of specific applications along with the tutorials on how to recreate them.

VI. CONCLUSION

In conclusion, developing the BluetoothLE Component contributes new capabilities to MIT App Inventor. This development is essential as the popularity of IoT devices grows, increasing the demand for mobile applications to control them. The BluetoothLE Component addresses this need by providing an easy-to-use tool for connecting a mobile phone and BLE devices. Beyond simply providing basic BLE communication capabilities however, the BluetoothLE Component also adds the ability to detect and manipulate device-specific functions as well. The flexibility in the dynamic design of this component allows for new devices and capabilities to be accommodated as they emerge in the future with minimal development efforts. This feature has enormous implications with the broad variety of IoT applications that are possible.

ACKNOWLEDGEMENTS

The authors would like to thank all of the members of the MIT App Inventor team for their help with the development process.

REFERENCES

[1] Bandyopadhyay,  D.,  &  Sen,  J.  (2011).  Internet  of  things: Applications and challenges in technology and standardization. Wireless Personal Communications, 58(1), 4969.

[2] Wolber,  D.,  Abelson,  H.,  Spertus,  E.,  &  Looney,  L.  (2011). App Inventor. ” O’Reilly Media, Inc.”.

[3] Mackensen,  E.,  Lai,  M.,  &  Wendt,  T.  M.  (2012,  October). Bluetooth low energy (ble) based wireless sensors. In Sensors, 2012 IEEE (pp. 14). IEEE.

[4] Gubbi, J., Buyya, R., Marusic, S., & Palaniswami, M. (2013). Internet of Things (IoT): A vision, architectural elements, and future directions. Future Generation Computer Systems, 29(7), 1645-1660.

[5] ”Bluetooth Low Energy - Android Developers”, 2016. [Online]. Available: http://developer.android.com/guide/topics/connectivity/bluetooth-le.html#setup.

[6] ”The Story Behind Bluetooth Technology - Bluetooth Technology Website”, 2016.

[Online]. Available:https://www.bluetooth.com/what-is-bluetooth-technology/bluetooth.

[7] ”Introduction to Bluetooth Low Energy - Adafruit Learning System”, 2016. [Online].

Available: https://learn.adafruit.com/introduction-to-bluetooth-low-energy/gatt.

[8] ”Getting to the bottom of the Android Bluetooth Low Energy API — Lemberg Solutions Blog - Mobile, Drupal, and All Tech”, 2016. [Online]. Available: http://blog.lemberg.co.uk/getting-bottom-android-bluetooth-low-energy-api.

[9] ”Arduino - Genuino 101 Curie BLE Heart Rate Monitor”, Arduino, 2016. [Online].

Available: https://www.arduino.cc/en/Tutorial/Genuino101CurieBLEHeartRateMonitor.

[10] Rowberg, J. ”[REFERENCE]: BLE master/slave, GATT client/server, and data RX/TX basics”, Bluegiga Technologies, 2016. [Online]. Available: https://bluegiga.zendesk.com/entries/25053373–REFERENCE-BLE-master-slave-GATT-client-server-and-data-RX-TX-basics.