Creating a Chat Application in App Inventor 2

As we move on in our journey of creating mobile applications using Google’s App Inventor2, let’s try out a chat app. Our expert guides the reader in creating a demo chat application that can be refined and modified later.

Chat is the trendy feature on smartphones nowadays. It is more interactive compared to the traditional SMS. Chatting on a smartphone allows you to create a group comprising friends or relatives and then talk to everyone in that group, simultaneously. We see this in most popular chat applications like Whatsapp, Facebook Messenger, Hike, etc.

Since there’s been a lot of interest and enthusiasm among our readers to learn Android app development with App Inventor, we thought of exploring a new advanced topic. In the previous tutorial, we created a Web database using the open source cloud enabled Firebase database. In this tutorial, we will use our previous knowledge to deliver a fully working chat application.

For those who have missed the last tutorial, I would like to go over a few things quickly.

In our application, we are going to use the Firebase cloud database provided by Google, which is open source and freely available.

Features of Firebase

1. Firebase uses a GUI based data centre so that you can visually see and manage all the entries.

2. Being on the cloud, it is accessible on the go to any device.

3. Smart authentication provides secure access.

4. Being a real-time database, it reflects changes as soon as the data is updated.

5. Users can add collaborators, so that multiple people can manage the database.

6. There is no coding for fetching and storing data.

Figure 1: Firebase dashboard

Figure 2: Creating a new project

Figure 3: Demo project in the Firebase dashboard

Creating a project in the Firebase database

1. To use Firebase, you need a working Google account, which is also needed to run App Inventor.

2. Type https://console.firebase.google.com/ in the address bar of the browser you are using and hit Enter.

3. If login credentials are asked for, give your Google account credentials and proceed.

4. Follow the on-screen instructions, which generally ask you to accept the terms of usage.

5. Once everything is done, you will see the screen depicted in Figure 1.

6. Click on the ‘Create New Project’ button as shown in Figure 1.

7. Give the name of the project and country/region, as shown in Figure 2.

8. Once your project has been created, you will see the dashboard of your application, which will be similar to Figure 3.

9. Now select ‘Database’ from the left hand palette and then ‘Rules’ from the next page. It will display something like what’s shown in Figure 4.

10. At this point, we want to give all users access to the database; hence, we need to change the rules. You can manually change the rules by typing values, as shown in Figure 5. Once done, click on the Publish button.

You have now successfully created an empty space for your project in the Firebase database, and have given read and write permissions to all the users who have the URL.

If you are new to this Android journey, you are requested to go through a few of the articles for beginners to familiarise yourself with App Inventor. Let’s proceed to the idea behind our application, which we will be implementing in this session.

Figure 4: Reading and writing rules with authentication

Figure 5: Rules with read and write permission

Figure 6: Designer screen

The theme of the application

Most people use smartphones and, on a typical day, use it to browse the Internet, play games, listen to music, watch videos and chat with various people. Have you observed that all your chat records are well maintained, so that you can browse them afterwards as well and can export them via email or to the SD card if you wish? You are already aware of all the components that I will be using for this application — buttons, labels, horizontal arrangement, text box, Firebase DB, etc.

Figure 7: Components view

Figure 8: URL of the project

GUI requirements

For every application we have a Graphical User Interface (GUI), which helps the user to interact with the on-screen components. How each component responds to user actions is defined in the block editor section.

The GUI requirements for Screen1 are:

1. Labels: Labels are the static text components used to display some headings or markings on the screen.

2. Button: A button will let you trigger the event and is a very essential component.

3. Horizontal arrangement: These are special components, which keep all child components aligned horizontally within them.

4. Notifier: A notifier is used to display some instructions or give you control over your existing components. You will see its functionality in more detail as we implement it in our app.

5. Firebase DB: This, as you already know, is the cloud based database from Google. We will use it to store the user’s data on the cloud.

Table 1 shows the components that are required for this application. We will drag them on to the designer from the left-hand side palette.

1. Drag and drop the components mentioned in Table 1 to the viewer.

2. Visible components will be visible to you, while the non-visible components will be located beneath the viewer, tagged as ‘Non-visible’.

3. Labels along with their respective text boxes need to be put within the horizontal arrangement so as to keep them aligned horizontally.

4. If you have dragged and placed everything, the layout will look something like what’s shown in Figure 6.

5. Make the necessary property changes like we did when changing the text property for the label and button components.

6. Renaming the components helps to identify them in the block editor.

7. Your graphical user interface is now ready. Figure 6 shows how the application will look after the installation.

8. The hierarchy of the components that we have dragged to the designer is shown in Figure 7.

If you are confused seeing the designer and the components viewer, let me explain further. Here is the hierarchy that we have placed for our application.

1. We have just placed four text boxes to get the details from the user.

2. For easy reading, we have inserted a label before the text box.

3. We need to configure the Firebase component to connect to the demo project we have created using the steps mentioned above. For that, just assign the URL of your project to the Firebase URL property of the Firebase component in the designer.

Now let’s head towards the blocks editor to define the various behaviours. Let’s discuss the actual functionality that we are expecting from our application.

1. The user should be able to write a name in the top text box.

2. The user should be able to send the chat text by clicking on the Send button.

3. All connected users should see the chat history.

4. Upon clicking the button, chat history should be cleared.

So let’s move on and add these features using the block editor. I hope you remember how to switch from designer to block editor. There is a button available right above the Properties pane to switch between these.

Table 1

Figure 9: Set the URL to the Firebase component

Figure 10: Block editor Image 1

Block editor blocks

I have already prepared the blocks for you. All you need to do is drag the relevant blocks from the left side palette and drop them on the viewer. Arrange the blocks the same way you see them in the image. I will explain what each does and how it is called.

⦁ On the first line, we have initialised two variables to get the user name and chat history.

⦁ On clicking the Clear history button, all text from the History text box will be erased.

⦁ Upon clicking the Send chat button, we will first validate whether anything is entered in the chat box.

⦁ First, the procedure will check if there is anything entered in the chat box.

⦁ On the next line, it will call the next procedure to check for the name of the user.

⦁ If everything seems fine, it will store the chat message appended with the user name in the Firebase database. You are already aware of the tag and value terms of this database.

⦁ The greatest feature of the Firebase database is its concurrency and real-time updates.

⦁ Now you are done with the block editor too. Next, let’s move to download and install the app on your phone to check how it works.

Packaging and testing

To test the app, you need to get it on your phone. First, download the application to your computer and then move it to your phone via Bluetooth or USB cable. I’ll tell you how to download it.

1. On the top row, click on the ‘Build’ button. It will show you the option to download the apk to your computer.

2. You will be able to see the progress of the downloading process and after that’s successfully done, the application will be placed in the Download folder or the preferred location you have set for it.

3. Now you need to get this apk file to your mobile phone either via Bluetooth or via USB cable. Once you have placed the apk file on your SD card, you need to install it. Follow the on-screen instructions to install it. You might get some notification or warning saying that the install is from an untrusted source. Allow this from the settings and after successful installation, you will see the icon of your application in the menu of your mobile. Here, you will see the default icon, which can be changed and we will tell you how to do this as we move ahead in this course.

I hope your application is working exactly as per the requirements you have set. Now, you can customise various things like the image, sound and behaviour also.

Figure 11: Block editor Image 2

Figure 12: Block editor image 3

Figure 13: Block editor image 4

Debugging the application

We have just created the prototype of the application with very basic functionality and what the user may be interested in. Now come the various use cases that require attention, so that our app does not annoy the user but is able to sustain itself. Consider the following scenarios:

1. What would happen if two users are clicking on the Send button at exactly the same time? Do you think the current implementation is feasible enough to handle the confusion?

2. Can we create multiple groups and store the chats into different project buckets?

3. Can we think of sharing media as well?

4. What if the device of the user is not connected to the Internet? Will it be able to sync all the previous chats upon connecting to the Internet?

These are some of the scenarios that might occur and the user will be pretty happy seeing them addressed. Think about how you can integrate these into the application. Do ask me if you fail to accomplish any of the above cases.

You have successfully built another useful Android app for yourself. Happy inventing!

Feedback on your interests and ideas on how to make Android applications will be much appreciated.

Brief introduction to cloud data and the FirebaseDB component

Brief introduction to cloud data and the FirebaseDB component

Jan. 24: The Firebase component and cloud data is an experimental feature of App Inventor. We are publishing some preliminary documentation so people  can experiment with this feature as we’re working on it. You are welcome and encouraged to build apps with this for experimental use, but please note that the behavior may change significantly and your apps will stop working.   Also, the emulator provided with App Inventor does not support the Firebase component.

One popular feature of mobile apps is that people using the same app on different devices can share information within the app. For example, a game app might keep track of the highest score among all users of the game so that every user can see it. That game app must keep track of the scores of each user from each separate device. It is not enough to just store data (locally) on each device independently.

To store the global high score across all users of the app, across any connected device, the app’s inventor should store it online. It should be stored so that every copy of the game app can read and write the data about the high score.

Data stored online, on the Web, is called cloud data. One piece of cloud data is a cloud value.

App Inventor’s FirebaseDB component provides a way to use cloud data in apps you invent. The data is stored and maintained using the Firebase database service http://www.firebase.com, which is part of Google. In general, using the Firebase service requires having access to a Firebase account, and this costs money. But any MIT App Inventor user can use the FirebaseDB component cost-free through a special default account provided by MIT.   

This MIT account is intended only for personal work and testing. You’ll need to get your own Firebase account in order to make apps for heavy use and for distribution to large numbers of users.

This current release of the FirebaseDB component is experimental, and its properties may change in response to user comments. In particular, this experimental release does not include the ability to use it with your own Firebase account, but only with MIT’s default account. MIT plans to provide a way for people to obtain their own Firebase accounts after we gain more experience using the component.   

Note:  The FirebaseDB component requires Android API Level 10 (GINGERBREAD_MR1) or greater, both for live-testing apps as you develop them and for running apps (.apk’s) that use the component.

This document introduces the FirebaseDB component and provides a simple example. The full documentation (still being written) for the FirebaseDB component is here.   

The FirebaseDB component is based on an MIT undergraduate project by Kristin Asmus, subsequently modified by William Byrne and Jeffrey Schiller. Kristin’s report on her work can be found here.

Using cloud data

Adding the FirebaseDB component to a project provides access to several blocks. To make an app store data in the cloud, use the StoreValue block. StoreValue takes a tag (which must be a text string) and a value (which can be text, a number, a list, or a boolean), and stores that value in the Firebase Web service under the tag. To retrieve the value stored under a tag, use the GetValue block. GetValue takes the tag and requests the stored value from the Firebase service. All users who have installed that same app (apk file) will get the same stored value.

Note: When we say “the same app” we mean an app with the same name, created by the same developer. For example, if you build an app with FirebaseDB and later modify that app and rebuild it, the new app will still share values with the old app. On the other hand, if you change the name of your project, the old values will become inaccessible.   Also, if another developer uses your app source code (AIA file), the resulting app will not share variables with your app, even if the two apps have the same name.

You can also specify a valueIfTagNotThere that GetValue should return if there is nothing stored under the given tag.  If you omit valueIfTagNotThere the default will be the empty string.

When the value is received from the service, the GotValue event is signaled with the tag requested and the value stored for that tag:

The Firebase service also tracks any changes to an app’s cloud data. When a value associated with any tag is changed, the DataChanged event happens, and sends the original tag and the new value to all running copies of the app.

There’s a final event called FirebaseError that lets the Web service report an error, which is usually the result of a communication problem:

ShareValue: A simple app with cloud data

ShareValue is a simple app that uses the FirebaseDB component. It lets anyone who has the app installed set a shared cloud value and see when the value changes.

The app has a button, a textbox called ValueToSet, and a label called ReceivedValue. You enter a value in the text box and press the button. Everyone else using the same app will see their ReceivedValue label change to the new value that you entered in the ValueToSet textbox.

Component type	Name	Purpose
Textbox	ValueToSet	enter the value to be stored
Button	Button1	Click to store the value
Label	ReceivedValue	show the current cloud data
FirebaseDB	FirebaseDB1	store the cloud data and signal when it changes

Here are the blocks for ShareValue:  

All that’s required is to store the value when the button is pressed, and set the ReceivedValue when the data is changed.  Before changing ReceivedValue, the DataChanged handler checks that the tag is equal to mySharedData, which is the tag for the cloud data that was stored. The check here is actually not necessary because mySharedValue is the only cloud data for this app. If there were several cloud values, then the tag would let us distinguish among them.

This is the entire app: it doesn’t even have to use GetValue, because the FirebaseDB component automatically pushes the changed value to all the users.

Even this simple app is already interesting. If you build it and distribute it to your friends, you have a simple chat program that all users of the app can use to send a single message (the value of mySharedData) to all other users.  

A more elaborate chat program could keep a historical list of the messages, and use that list as the shared variable. Pressing the button could add a message to the list and store the extended list in Firebase.  All users would then see the complete history list when a new message is added.  

In contrast, other apps cannot access those variables. A different app that uses the FirebaseDB component will have its own separate store of cloud variables, and will not interfere, even if it uses the same tags. Each app has its own data store.

A collaborative drawing app

Here’s another example by Hossein Amerkashi that shows how to use Firebase to combine chat with a drawing program for collaborative sketching: Firebase Chat with Interactive Drawing.

FirebaseDB versus TinyWebDB

If you are familiar with App Inventor’s TinyWebDB component, you’ll see that the StoreValue, GetValue, and GotValue methods for FirebaseDB work almost the same as the corresponding methods for TinyWebDB.  The difference between the two components, other than FireBaseDB’s DataChanged event, is whether the variables from different apps can interfere. With TinyWebDB, MIT App Inventor provides a single demonstration data storage that is used by all App Inventor apps. If you use that storage, then any App Inventor app can change your values, provided it uses the same tag. If you want more isolation than that, you’ll need to deploy a custom TinyWebDB service, as explained in the MIT App Inventor Documentation. With FirebaseDB, each app has its individual data store so that variables from other apps cannot interfere. The isolation is provided by the Firebase Web service.

More general sharing

The example above shows how the FirebaseDB sharing can be simple and useful, but it’s limited. There’s no way for two different apps to share variables, whether from the same developer or different developers.  There’s also no way to use your own Firebase account instead of MIT’s shared account. These things can all be done: they are controlled by the FirebaseDB component’s properties. If you leave the properties set to their default values, you’ll get only the simple sharing described here. MIT is still updating the component and will provide documentation.  Meantime, you are on your own to experiment.