Getting Started With Google App Inventor – A Twitter Search Client

I had a quick play with Google App inventor yesterday, and aside from a few issues related to reliably connecting my phone to my Mac, it all seemed to work pretty much as advertised.

As a quick example of what’s possible with no coding and not a lot of programming (ya hearing me, @jimgroom?!;-), here’s a simple Twitter search client:

The paired blocks at the top define a variable called uName containing the search term (in this case, psychemedia, my Twitter user ID).

The second grouping relates to a button I created within the application call search; when the button is clicked, a query is sent to twitter using the search term contained in the uName variable. (Note that I didn’t really need to use the variable – I could have used a text block to set the twitter query term directly.) The third grouping of bloxks tells the app what to do when the Twitter search is successfully completed and the results returned to the app. In this case, the results of the search are assigned to the variable searchResults; when the results have been successfully received by the app, a label I have named searchResultsDisplay is set to display the contents of the searchResults variable – that is, the results of the Twitter search.

When the app is run, a search is made on Twitter for “psychemedia” and the results displayed on the phone. It’s easy enough to imagine an app where we have several buttons that can run separate searches over different search terms – a 1-click Twitter search app.

Whilst there are certain circumstances where a predefined search app may be useful (for example, a conference hashtag search app), we often want to allow our users the freedom to choose their own search terms so that they can decide what they are searching for. So here’s an overview of an app that allows a user to enter a search term into a text box, and then click a button to run the search and then display the results in a label:

The app itself is contains four components: a text entry box (userName), a button (search), a label (searchResultsDisplay) and a predefined Twitter component (Twitter1). The programme is, if anything, simpler than the first example shown above. This time, rather than using a pre-defined variable to contain the search term, we take it from the text entry box. Here’s an annotated version of the above showing how the components relate to each other:

One problem with displaying the whole set of results in a label is that the output display is just one huge block of text. Although he Twitter search returns a list containing separate search results, when we use it for the label display, the separate list items are not separated from each other. In order to tidy up the display, we need to create a routine that will produce a block of output text where each separate result is placed on a separate line. To do this, we need to insert one or two new-line characters (\n) in between each list item. The following programme achieves that:

Here’s how it works. We create a variable (op) to contain the structured output text. When the search results are returned and successfully placed into the searchResults variable, we use a foreach block to run through each item in the results list in turn, one at a time, and do something to each one as we do so. To act as a temporary placeholder for each item, we use the item variable. The set global block builds up the output text message by appending the each item in turn to the current output string (which starts off empty), followed by two newline characters. That is, the string starts of empty; after the first result item it contains “(first result)\n\n”; after the second item it contains “(first result)\n\n(second result)\n\n”; and so on. Once each of the result list items has been added to the output string, we set the label to display that output; this time, each result appears on its own line.

Whilst the above application is very simple, it’s easy to see how we can quickly create a single function application. With a little more thought, and bit of knowledge about how to create advanced Twitter search strings, we could create a more refined application. For example, the “to:” search limit allows us to search for tweets sent to an individual. So we could imagine tweaking our app to include another search button that allows a user to search for tweets sent to a particular user, or sent from a particular user. For example, if we enter a username in the search box we can construct a limited search query by prepending the search term with the “to:” search limit before running the search. That is, doing something like this (untested!):

Note that I have made use of a second instance of the Twitter search object, so that I could in principle run – and handle the results from – two separate search queries initiated from a single button click.

With a little bit of branding added to the app, the “5 mins is all it takes” development cycle for an app like this means we could, if we wanted, create a disposable app around a set of canned search terms to support the reading of a backchannel during an event by meeting participants who don’t subscribe to Twitter.