Also, before deciding on the artifact above, I drew this nokia brick commander leading his snake warriors into battle.

While building this application, I feel like I became much more comfortable with javascript than ever before, and probably learned some important modern web practices as well.  I also learned that phonegap provides an awesome array of plugins that, at first glance, I am not quite sure what to do with other than to abstract away hours of development (which is OK), but I think this feeling might just stem from the thought that it seems difficult to mesh html and these functionalities into a cohesive app.  This makes me think it sometimes may be useful to use Phonegap to more easily pull data from the device than it would be natively, but then send that information back into a Java-driven app.  However, moving to web languages for layouts and design overall made me more comfortable and I really enjoyed the functional and asthetic potential that this freedom and jquery-mobile’s built-in feaures offer.

Below is the ‘add user’ page showing some form validation, the ‘view posts’ page that links to all posts and groups by day, and the ‘view post’ page which allows users to view a submitted post.

Most of the widgets used for this app are found in the menus as the main interface is the drawing canvas.  The app includes the following widgets:

• TextView (several places)
• Button (undo)
• ListView (server connect list)
• ImageView (connection status pane at bottom of canvas)
• ScrollBar (brush change menu)

During development of this app, I learned about the perils of connecting via Bluetooth.  More specifically, Android’s app restart policy for configuration changes means that maintaining a Bluetooth Connection requires extra thought, or cheating like I feel I did by having my app ignore these changes.  I also feel like with Bluetooth it is difficult to remove the user from the connection process as the user still needed to make their device connectable (as a server) or request to be a client for another device.  I think my app could use some help making connecting seem more intuitive.  As far as widgets go, my app idea made me learn how to set and retrieve values from the scrollbar for the first time.

The other half of Thesaurize retrieves and parses JSON from twodee.org and presents the retrieved data as clickable links in a ListView.

During the development of this application, I learned how to retrieve and parse JSON and use AsyncTask.  It also gave me a refresher on implicit intents to request the web browser to show links and gave me further experience creating user interfaces.  The stacked button-ListViews for each language construct took some time to get right, but after installing it on a phone, it definitely seemed worth it.  I also learned that web APIs often require your program to include some type of credit or link to their site for use.

I decided to make Super Munchkin by implementing some excellent functionalities of Munchkin Counter, but saving user data every time the player turn ends.  If the app for any reason exits, users are also able to resume their interrupted game.  Another drawback of the Munchkin Counter app was also that any time a game started, the user had to re-enter the player names, even if playing with the same people.  In SuperMunchkin, players can be added in the ChoosePlayersActvitity that starts when beginnning a new game and will still be present as long as the user does not remove (disable) the player.  Lastly, SuperMunchkin includes a statistics activity that allows a user to look back on the number of games played, games won, levels earned, and other stats.

The first image below shows adding a player during the ChoosePlayerActivity when starting a new game.

The second image is the following activity when starting a game where the user can order the players.

The third screenshot is of the GameTrackerActivity, which is the score-keeping activity used during gameplay.

The fourth image is of the StatisticsActivity, where all non-disabled users’ statistics are summarized for the purposes of bragging rights.

I learned a lot while making this app.  I became comfortable with passing Parcelable objects, restoring an Activity state, and enforcing intuitive app flow via intent redirection.  After an experiment, I also learned that having images in customized ListViewItems can be catastrophic.  As for the SQLite database, I found that I often could utilize built-in methods to populate my queries without having to resort to raw queries.  When it came to app design, I realized that screen size and finger dexterity make many decisions for you.  While I felt somewhat uncomfortable forcing a landscape layout for a particular activity, I found that the activity’s purpose could not be met without adequate screen resources.

Phone / Data Network Signal Mapper
This app would take in GPS and connectivity data and map the observed hot spots and dead zones through which the user travels.

Mileage and Speed Tracker
This would mostly be an application for exercise that could track a walking, running, or biking route and give summary data on distance, time, and speed.  If feasible, including elevation stats would be a neat addition for this app.

Teaching App using Voice Recognition
An initial idea for this app would present a user with a series of objects, letters, numbers, and colors that would need to be identified vocally (or skipped if purple looks too much like violet!).

Map-maker Geography Quizzer
This app would ask the user to construct a continent by placing countries into the correct locations within that continent by rotating and dragging.

Rolling Game using Tilt for Motion
In this game, the user would tilt the phone to move through a scrolling maze.  The maze would consist of a web of platforms with drop-offs on either side which would fall, disappear, or be consumed by some mystery being ( oooo! ) after a certain amount of time has passed.  The user would have to outrun this to victory and set new fast times.