Motivation
I decided to try out Google App Inventor, being invited to the Beta. I wanted a simple enough project to get a feel for the process without becoming bogged down in complex logic or user interface (UI) design. It occurred to me that a random Oracle generator for the In A Wicked Age role-playing game by Vincent Baker would be interesting enough and maybe even useful to others.
The Application
Here is a link to the APK file for the application:
The Logic
App Inventor uses OpenBlocks as a visual programming environment. Very cool for beginners, but also very mouse-intensive when one has repetitious tasks (like pasting in 208 lines of text!)—I’d have liked to be able to edit a TXT or XML file to populate the Oracles lists.
Here is an image of the basic logic for the Blood And Sex Oracles button:
Nothing too fancy going on here:
- Copy the set-specific list to the OraclesCurrent temporary list.
- Call the generic procedure that populates the Oracle labels:
- Populate the first Oracle label element’s Text with a random Oracle from the list.
- Set the second label’s text to the same value as the first.
- While the second is the same as the first, populate the second with a random Oracle from the list.
- Repeat Steps 2 and 3 for the remaining two label elements, checking them against all preceding labels.
Put another way, an Oracle label element can not contain the same Oracle text that is currently in any preceding label element.
The rest of the app is a simple UI of buttons for choosing an Oracle set (the BloodAndSex.Click event in the logic shown) and, of course, four global list variables (one-dimensional arrays) to hold the Oracle-set-specific text (the OraclesBloodAndSex in the logic shown).
Credits
In A Wicked Age is ©2007, Vincent Baker, all rights reserved.
IAWA Oracles For Android app is ©2011, David Carle Artman, CC-BY NC 3.0.
Folks who know me know I’m irritated by Facebook closing the native interfaces to Google apps (specifically Calendar on Android). Turns out, there’s Another Way:
- Go to any Event that you are Attending.
- Scroll all the way down to the bottom of the page.
- Click Export.
A pop-up will offer you two options for that single Event: Download or email.
It also shows a link under “Export all of your upcoming events.” - Highlight that link and copy it (or right-click it and choose Copy link location).
- Open Google Calendar in your web browser.
- Under “Other calendars,” click Add > Add by URL.
- Paste the Facebook URL into the pop-up’s URL field.
Note: You probably do not want to check the checkbox to make it public. - Click Add Calendar and then wait a moment. A “Firstname Lastname ‘s Facebook” calendar should appear on your “Other calendars” list.
- Sync with your Android device or other Google Calendars client and enjoy!
FREEDOM!!!
Challenge
Municipal food banks depend upon food donations to serve the hungry. Coordinating donors with bank locations becomes a logistical challenge:
- Picking up donations in a timely manner, without disrupting donor business
- Distributing donations to banks that need them most
- Accounting for the storage space of banks
- Transferring food between banks, if actual numbers do not align with projected needs
Use Cases
A donor registers what they have to donate on a Google map, and chooses a range of pickup time (e.g. a restaurant will usually want it to be between 2pm and 4pm; a grocery store might prefer 10pm to 2am). Options to schedule recurring pickup days, dates, and times.
A recipient registers current stock (one-time, upon setup), storage maximums by volume or weight or other? (one-time, upon setup; and if storage increased), pickup minimums by volume or weight (below which it’s not worth the bank’s costs to pick-up; adjustable as needs change), and projected need (daily, weekly; based on history, once sufficient data is accumulated).
A bank’s delivery drivers are given a “traveling salesman” shortest route to pickup donations equivalent to the bank’s projected need. When they commit to the route, those donations are not made available to other banks unless released later by the receiving bank (to be re-distributed where most needed).
Architecture
Initial setup form, as donor only or recipient/donor.
Site (donor or bank) location definition, via manual text entry, push-pin on Google map, or GPS.
Secure verification of valid bank via server check against state or municipal registries.
User deletion of “bad” donor locations -OR- “bad” donor location reporting and server-side banning.
Multiple location support, for owners of several donor businesses or managers of multiple food banks.
Route navigation interface, once a bank’s delivery drivers commit to best-route pick-ups.
Option to use less efficient routing, if necessary to deliver more balanced meals at a given bank or system-wide.
Historical data storage, server-side or locally, for need projection for a given distribution period (day, week, month?).
Optional automatic application of need projections based on historical data, with ability to adjust before submitting to server for distribution.
Costs
Application development and maintenance – Open source community? Grants?
Validation of food banks against municipal or state charters – Possibly manual labor; possibly automatic with connection to government systems.
Server-side data accumulation and re-distribution to apps – Possibly a function of a public Google map; more likely hosted via grant or by government servers.
License
This work is distributed by David Carle Artman under the Creative Commons Attribution-Noncommercial-Share Alike 3.0 License.


