I learned a significant amount about JavaScript/JQuery Mobile, especially concerning being able to get/modify/set attributes, text values, etc. of lots of different elements.  This was helpful in passing needed values instead of needing to create arrays or variables to pass values.

I also learned about some of the nuances of the Android OS, issues with the emulator, and reported bugs/issues with Cordova.

– Android seems to scan for files rather rarely, so when files are added or deleted in the app it could take minutes to days before the updates are reflected in the content resolver.  To remedy this, I added code in the plugin to insert or delete into/from the content resolver.  Alternatively, I think the media scanner could be called but the coding seemed messier to use, especially within a plugin.

– The emulator broke down once for about an hour before I made a new one, saying it was unable to create a media player.

– A progress bar tracks the duration of the playing track.  I wanted to allow for seeking, but after reading some posts from users and Cordova devs and doing some debugging I found Cordova’s call to get the track duration doesn’t return the value immediately, making the value -1.  After pausing/stopping the track and playing again, the duration generally loads.

With more time to add features and to look into JavaScript and JQuery Mobile as well as better ways to store variables/information, I would like to add things like album artwork, album names, etc.  These things would be easier to test on a real device as well, versus using an emulator with Windows sample music.

For every second your Sphero isn’t driven at full speed, you’re causing it to die a little inside.  Yet your Sphero is fragile and it’s a dangerous world out there; objects are the bane of Sphero existence and colliding with anything at all eats away at your robot buddy’s lifespan.  With health bars on the line, you are faced with only one choice…

Drive or Die.

The idea behind this app will be driving your Sphero.  Sounds easy, right?  Wrong.  Your Sphero has a health bar, and for every second the joystick isn’t cranked all the way in some direction your Sphero will have a diminishing health bar.  Yet walls, chairs, and other objects loathe the Sphero for its ability of mobility, and conspire to drain your robot’s health upon collision.

Your Sphero’s intelligence, however, is rather lax.  Periodically it may become confused causing the joystick controls to suddenly be inverted.  It may also suffer bouts of extreme slowdown, lulling its master into feigned safety, before accelerating back up to full speed without warning.

The Sphero’s health is tracked both by health bar and by the Sphero’s color.  Green represents great health.  Yellow means your Sphero’s health is moderate, while red indicates critical condition.  A timer is used to show how long your Sphero has survived, and will ultimately be used to generate your final score.

The currently imagined screens involve:

A home screen, likely tracking the high score and hopefully providing the user with a selection of several difficulties.

A control screen, likely a joystick, health bar, and timer.  Messages may periodically appear warning the user of a power-down, such as inverted controls.

A defeat/score screen, notifying the user that his Sphero has met an untimely end and displaying his final score, possibly along with statistics.

Risks/Hurdles

The main risks/hurdles will likely be implementing graphic aspects for the interface and bringing all of the aspects (joystick, calibration, collision detection, color changing) together.  Individually, each task is simple to implement; bringing them all together and having them work well so as not to hinder gameplay could prove more of a challenge.

When the actual gameplay is in place, implementing extra features such as random moments of inverted control could prove tricky.

Division of Labor

Getting a base framework with movement controls, color changing, and collision working separately will come first.  Once that framework is complete, tasks will likely be split into integrating movement and collision, integrating collision and color/”health” changes, implementing the actual game, creating interface/graphics for the screens, and then hopefully implementing some extra features (such as inverted controls, other difficulties, etc.)

Pages relevant to the character have a header at the top of the activity, showing the character’s name, server, level, and class, along with the stored avatar of that character (XML includes!).  The progression option shows each boss under their respective raid instances (green for raid instance, white for boss) and the character’s kills of each boss in Normal and Heroic modes.  The items option shows the items and their rarity (color-coded) in each of the equip slots for the character.  Since the API is rather fragmented, it would’ve been a large ordeal to retrieve useful information about the items (“large” as in creating a separate connection for every single item).  Instead, the list has a listener which will send the user to the WoW Armory page to view the item, so useful item information is at least linked up to the item instead of only being able to see the name and slot.

Besides XML includes and learning how to deal with JSON when formatting in inconvenient ways across many different connections, I messed with Activity flags more.  In not allowing an activity to be kept in the history stack, it is immediately killed when navigating away so that it will always produce only the freshest, organic (live) data.   It also effectively seems to push the user back to the character options menu upon return, which worked out nicely.

Being subject to the API’s results, there was one strange case of a duplicate boss listed in an instance, and the average item levels seem like they may not necessarily match up in live time, though most of the other information seems to.  I also only included an English release because the app only works for US servers at the moment; adding multilingual support would’ve been a fairly arduous task to find how Blizzard translates all of the information, and supporting non-US servers would add another input and some research into how the API functions and what it returns for JSON.  However, with the framework nailed down and the way I set the options list up, I made sure it would be easy to go back in and add more features later.  The actual API has almost anything you could ever want to know about a character or realm, and I’d like to think I’ll return to this app someday to add more features, possibly support non-US servers and other languages, and overall polish it up a bit..

Users want feedback

in their daily processes

I show them my toast

Android SDK

your libraries increase stats

Plus five laziness

I am tipped over

Android phone does not compute

Tell me what to do

Touch screen devices

Speech-to-text, code completion

Goodbye, wpm

With my mobile phone

Productivity now fades

Gaming on the go

Web feeds for others

my network is not social

Hashtag resistance

Databases store

my anger and frustrations

Debugging is pain

Error detection

my spotless coding you mock

TargetAPI!?

Roommates will soon grieve

when their Phones become Lonely

Patience will be tried

Web Services, great!

Varying data formats?

Weep in the corner…

Your lines constrain me

May I use the internet,

Mister Manifest?

Greedy UI thread

no outside access, no blocks

Gives “main” new meaning

Google convention

version names are based on foods

What happens at X?

As far as the new concepts go, there were three I found notable:

To allow users to update or delete entries I decided to use an onLongClick format.  However, after some searching I found it was just as easy to register the ListView for a context menu (registerForContextMenu()).  With this, the context menu works very similar to the options menu.  When using this, there was a bit of a stumbling point in finding the “AdapterContextMenuInfo” object required to actually retrieve what entry you originally selected.

In passing foods around between activities, I considered using Shared Preferences, but had read about Parcelable during the first assignment.  This actually ended up being very simple; by having an object implement Parcelable and creating the methods in that object to write the variables out, you can then define a constructor that creates and object by reading in a parcel.  This allows you to use the Intent’s putExtra() to store these parcelable objects and send them across activities, and I’ve read that it’s (supposedly) quite fast compared to querying databases or other methods.  This also allowed me to have only two activities; the ListView activity and one activity that was able to handle inserts and updates by controlling whether or not the information was editable.

XML is extremely powerful.  I was struggling with fitting all of the information on the screen, then I found you can create a res/layout-land directory and create default landscape layouts.  This allowed me to have two layouts completely differing in structure between portrait/landscape.  It probably would’ve easily solved my issue with foreign languages having unreasonably long translations as well, if I have time to go back and research someday.  Along with this, in XML layouts you can specify input types for every edit text and “imeOptions” which relates to focus.  It can dictate how focus is passed to other widgets, and probably more importantly, in landscape an EditText has a bad habit of expanding to fill the entire screen.  ImeOptions can solve this with flagNoExtractUi.

Overall, this app took way longer than I expected when I started on it and resulted in having fewer features than I originally planned, but this was due to all of the roadblocks I encountered and all of the concepts I worked with in order to find fixes.

I wanted to write a paint app as a way to work with touch event tracking and management of variables between activities, while being able to use a fairly wide range of widgets.  The MainActivity is the canvas that allows the drawing of paths.  A second activity, the Brush Settings activity, contains a progress bar that allows you to adjust the brush width, a spinner which allows you to select a color, and a toggle button that lets you toggle the blurring mask for the brush (textfields separate these and provide information).  I used a RelativeLayout to set these, mostly to play around with this type of layout; the setup is probably the same as a LinearLayout would be, but I feel like I have more control with the RelativeLayout.  The four buttons on the bottom (Accept, Cancel, Save, Load) are within a LinearLayout nested in the RelativeLayout.

I lied.  There are a few extraneous paint tools such as blurring and saving/loading; creating the blur mask was simple to do, but finding how to save bitmaps to the gallery took many attempts before finding a way that worked – once finding a way, it was a bit easier learning to load images from the gallery as well.  Most of the lessons with this file I/O; the list is rather long and painful, but I’ll boil it down to some of the essentials:

• A black canvas is easier on the eyes than a white canvas when working late nights decrypting blocks of red console text.

• Attempting to use cache or memory arrays to store Bitmaps induces serious headaches; I don’t think they were set up with the mindset of being used.

• You can easily and conveniently store information in a file private to your application:

FileOutputStream fos = this.openFileOutput("screenSave.JPEG", 
Context.MODE_PRIVATE);
screenSave.compress(Bitmap.CompressFormat.JPEG, 100, fos);

• I ended up shipping Intents back and forth using startActivity before learning about the startActivityForResult; this constant use of startActivity may result in several instances of the MainActivity filling up the runtime stack.  Fortunately, Professor Johnson tracked down some flags that can be set on intents to dictate other behaviors of activities (such as checking to see if an activity is already running and closing all activities on the stack on the way to that activity instead of just tossing a new one on the stack) by a simple .addFlags() on the intent.

• More heartbreaking than coding the Intents a bit off is learning that everything I was passing with the intents could be stored in Android’s Stored Preferences.

• I don’t know how correct it is, but I found handling orientation change in the onDestroy() method to be the easiest way to do it, the supposed orientation change listener failed miserably at what its title claims.

Overall, I’m sure it’s still not the most efficient way to write a painting app, but a lot was learned in passing data and having data persist when working between activities and a fair amount was learned about saving and loading files.

Side note: Originally, I was rotating images 90 degrees when loading them in, but when loading in an image saved with the painting app it was then loading in incorrectly; I could be way off base, but I think the emulator camera may save images in landscape orientation.  Regardless, it’s not a huge issue and I’d need a device to truly debug everything that’s going on, so maybe if I come back to the project someday to build on it it’s something to be fixed.

By the end of the semester I am hoping to know how to write an assortment of apps, some of which could ultimately be combined to create more full feature apps such as a way to secure a list of reminders/appointments.

Device Security:  An application adding either alternate security, such as a spoken passphrase, or several layers, such as multiple codes or questions/answers.  It seems like the default phone security wouldn’t be terribly difficult to break if someone wanted in badly, so I’d like to begin with simple security options which make it possible to build on and allow for more layers with further development.

To-Do/Reminder: An app that allows you to create reminders, preferably with an alarm or notification.  When I know more, a more full feature version would allow the setting of recurring reminders (Every Monday @ 1:00 PM) that are not removed when a new year rolls around…which can result in the unfortunate forgetting of paying the bills on time.

Budget Planning:  Users can input their monthly budget and keep track of their purchases in such an application, which will allow them to see a running total of their expenses/remaining budget for the month.  Possible other features would include being able to classify purchases into categories, or being able to input how much you can spend for the year and having it calculate a monthly budget for you from that yearly input.

Calorie Counter:  Have some database, whether it be simple, local and editable or a more complex collection from the web, wherein a user can select a food and the quantity consumed and the application will provide caloric information.  Maybe find a way to include a…pie…chart, to give a visual representation of calories consumed vs. calories allowed, or a history option to track trends over some period of time.

Tilt Utilization: Any application (likely something along the lines of a maze) which has an object or objects that respond via the device’s tilt sensors; failing this, implementation of alternative controls to allow for touch-screen controls.  However, this would likely require commandeering an Android device from a roommate or friend for testing purposes — I’m mostly just interested in seeing the lengths of coding required for utilizing tilt sensors or other such smartphone features.