Descent Condition Checker For Android

 Application, Design  Comments Off on Descent Condition Checker For Android
Feb 212011
 

Motivation

Descent Condition Checker ScreenPlaying Descent: Journeys In The Dark can be an exercise in confusion, especially when one has several conditions in play, is a Necromancer, and is wandering through a trapped dungeon. My second app for Android, built using App Inventor, is designed to make such checks fast and error-free.

The Application

Here is a link to the APK file for the application:

Descent Condition Checker For Android

Descent Condition Checker QR Code

The Logic

The app is simple enough: click the condition button and it checks against one of three subroutines, as appropriate to the particular condition: rollBlank, rollSurge, or rollPowerEnh. Based on whether TRUE or FALSE is returned by the subroutine, a specific message is displayed in the results area at the top of the screen.

Problems

The following code is supposed to delay a bit and show some text after a button press, to confirm the press for the user:

Descent Code Block Problem

The RESULTS text change, however, does not work properly, no matter where I call for it (even if I make the text change its own procedure). I have to assume that this is a bug with App Inventor, because the exact same calls are used to make the results area change its text based on check results, as well as its background color (green for good-for-the-user results, red for bad-for-the-user results).

Credits

Descent: Journeys In The Dark is ™ and ©2011, Fantasy Flight Games, all rights reserved.

Descent Condition Checker For Android app is ©2011, David Carle Artman, CC-BY NC 3.0.

IAWA Oracles For Android

 Application, Design  Comments Off on IAWA Oracles For Android
Jan 312011
 

Motivation

IAWA Oracles ScreenI 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:

IAWA Oracles For Android

IAWA Oracles QR Code

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:

IAWA Oracles Logic Blocks

Nothing too fancy going on here:

  1. Copy the set-specific list to the OraclesCurrent temporary list.
  2. Call the generic procedure that populates the Oracle labels:
    1. Populate the first Oracle label element’s Text with a random Oracle from the list.
    2. Set the second label’s text to the same value as the first.
    3. While the second is the same as the first, populate the second with a random Oracle from the list.
    4. 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.

Food Bank Coordination

 Application, Design  Comments Off on Food Bank Coordination
Jan 072011
 

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

Creative Commons 3.0 BY-NC-SAThis work is distributed by David Carle Artman under the Creative Commons Attribution-Noncommercial-Share Alike 3.0 License.