With the Event App, we wanted to introduce you to the process of collecting and retrieving data. Now that you are approaching apps from more of a developer’s perspective, you will probably be aware that every time you enter your email address or other information into an app, that data is getting stored into a database. But, as we mentioned at the beginning of this chapter, Fusion Tables as a database has its limitations. If you were to share the Event App as it is with multiple event organizers, who start using it on different devices, there will be a problem because the app uses a single Fusion Table as the back end. If many people use the app for their different events, all of the data from all the different devices will be aggregated in to one single Fusion Table. Of course this will create mass confusion for the event organizers (and guests) as all of the data for different parties will be all mixed up!

Before we outline a possible fix to this problem, lets discuss what we did in this app. Since our app accesses and modifies the Fusion Table, we had to create Google service level authentication. This step ensures that our app is authorized by Google to access Fusion Tables. Then, we inserted the Fusion Table Id into our app to let the app know which Fusion Table to access. Additionally, we created a service email address for our app and shared the Fusion Table with this service email address. These steps ensure that the Fusion Table allows our app to read/write data. So we basically had three different entities interacting with each other - Google service level authentication, our app, and the Fusion Table.

One way to address the problem of the single Fusion Table associated with the Event App is for the developer to create different copies of the app that uses different copies of a Fusion Table. This means that each copy of the app will have to be updated with the Id of the new copy of the Fusion Table. Additionally, this also means the Fusion Table will have to be re-shared with the app's service level email (using the original service email address).

It is easier than it sounds. First, open the Fusion Table that you used previously, go to the File menu and select, Make a copy. This will create a new copy of the original Fusion Table with all of the changes we made to the columns and settings. If your previous Fusion Table had any data in it, you will need to clear the data. Next, repeat the Fusion Table Id identification step outlined in the last few paragraphs of Creating a Google Fusion Table section. (Since you are creating a new Fusion Table, you will have to use the Id of this new table.) You will also have to repeat the Sharing the Fusion Table with the service account email section for this new Fusion Table (using the original service email address).

Lastly, in Blocks editor, paste the new Fusion Table Id into the Text box (attached to the TableID slot of the call FusiontablesControl1.InsertRow block) to ensure that the app uses the new Fusion Table.