teaching machines

Assignment 1 Post Mortem

September 29, 2011 by . Filed under cs491 mobile, fall 2011, postmortems.

So for this assignment I took the dichotomous key idea Dr Johnson suggested in the write-up, and thought I’d make a flowchart. Actually I thought I’d make a very specific flowchart, that being the Tech Support Cheat Sheet from xkcd.com by Randall Munroe.

For the layout of the flowchart I needed a text view and either one or two buttons. At first I made two separate layout, but as I looked through the reference I found that I could set the visibility of one of the buttons to GONE, and it would be like only one button existed.

The two button version

 

The implementation of the actual flowchart was pretty straightforward. I wanted to implement it in a way that would allow for autoporting, which made the implementation much less general than I would have liked, but oh well.

One of the things I wanted to try out was adding links, which was actually quite easy. Android, of course, provides some api for this, Linkify.addLinks(), that takes the view you want to add links to, and what type of thing you want linked (urls, phone numbers, etc).

 

The last thing I really wanted to do was to able to play around with the title screen through settings. I thought it might be fun to pass the app off as a tech guide for specific programs, so I made the title editable. Also the illusion would be blow if there was a link to a webcomic on the bottom when you were playing a joke on someone, so I needed to be able to turn it off. But what fun are preferences if you can’t reset them do their defaults?

 

To do this I wrote a custom preference. First we need a view. It turns text view will do just fine.

Next the preference needs to be adding to the xml file containing the preference screen you’re using:

<edu.uwec.cs491.techsupport.ResetButtonPreference
android:key=”@string/reset_pref”
android:title=”@string/reset_pref_title”
android:summary=”@string/reset_pref_summary”>
</edu.uwec.cs491.techsupport.ResetButtonPreference>

The final piece is the implementation of the preference itself. The preference class has three constructors, and I don’t know which the system calls so i implemented all of them, which was basically trivial. We have two things to do in our constructors. First we need to set the view, which is slightly different than in an activity,  using :

setWidgetLayoutResource( )

which takes an id (R.layout.reset_button_preference_view) that I’m sure we’re all very familiar with.

The other thing we need to do is to set an OnPreferenceClickListener to our button when it’s made. Instead of having an anonymous inner class I just had my custom preference class implement the interface, whos only method is onPreferenceClick(); which looks like this.

*context is a class variable set by the constructor of class Context

public boolean onPreferenceClick(Preference preference) {

SharedPreferences prefs= PreferenceManager.getDefaultSharedPreferences(context);

// clear the values stored in the shared preferences
prefs.edit().clear().commit();

// reset them to their defaults
PreferenceManager.setDefaultValues(context, R.xml.settings, true);

// visually confirm the button was clicked by closing
// the activity that is it’s context
((Activity)context).finish();

// let the system know that we handled the click
return true;

}

This is largely the same as how Dr Johnson implemented the reset button in ketchup.

The one unusual bit is ” ((Activity)context).finish();”

Here we’re taking the Contex that was provided to us on construction (the preference activity that our preference belongs to) casting it back to an activity and telling it to finish. In our case this will cause the preference menu to close back to the screen where the menu and settings were called from.