Cyberherbalist's Blog

I would have been done with Fraction Calculator sooner if not for the need to cram Trial Mode into it first.  Microsoft recommends it, since more users will download an app if they can try it out first, and apparently most people who go for the trial will upgrade to the full edition within just a few hours.  I hope so, because my download rate is, for want of a better and more cheery term, abysmal.  I don’t know what I was thinking with this app, but it would be nice to be able to earn at least minimum wage making apps for Windows Phone! 

Actually, I am fairly certain that most Windows Phone users WON’T have an urgent need for a fraction calculator, but hope springs eternal that maybe a few hundred might.  So, enter Trial Mode.

My first foray into Trial was quite a trial, in fact, since I didn’t understand things very well (see my earlier post regarding this).  But after acquiring some understanding, it took some good trial and error to incorporate the feature effectively.

First decision I had to make was what exactly I was going to do to give the user a good idea of the app’s usability without giving away the entire farm — I don’t like crippleware, but that’s pretty much all one can do in trial mode.  Users can download the app multiple times, and if I were to set a certain number of uses as the limit, then they could reset it at need.  I finally hit on the notion of limiting the user to one mathematical operation while in trial.  And since Addition and Subtraction of fractions are the two hardest operations to do manually, it seemed a good idea to permit the user to only multiply fractions, since this is the easiest operation to do manually.  It would give users a good idea of how the app worked, while not enabling them to use it forever for the hardest operations.  So, allow only multiplication.  Good.

I created a Buy button (a nice dollar sign) for the AppBar, and made its appearance contingent upon trial mode.  I also coded the operation button so it would display a “nag” screen if the user tried to switch to anything other than multiplication.  And to check for trial mode I created the following:

public MarketplaceDetailTask detailTask = new MarketplaceDetailTask();

/// 
/// Checks the marketplace to see if app is in Trial mode.  
/// If the debugger is attached, provides option to select 
/// which mode is active for debugging purposes.  
/// 
/// 
public static bool AppIsInTrial()
{
    bool inTrial = false;

    if (System.Diagnostics.Debugger.IsAttached)
    {
        MessageBoxResult result = MessageBox.Show("CLICK OK TO SIMULATE FULL LICENSE", "BUY NOW!", MessageBoxButton.OKCancel);

        if (result == MessageBoxResult.OK)
        {
            return false;
        }
        else
        {
            return true;
        }
    }
    else
    {
        inTrial = licenseInfo.IsTrial();
        return inTrial;
    }
}
 

There is code in the fragment above which checks to see if one is in the debugger, and if so, then there’s no license info to actually check. And so in that case it gives you the opportunity to arbitrarily decide whether you’re in trial or not, and then it acts accordingly. Anyway, the statement “inTrial = licenseInfo.IsTrial();” is the way to check to see if the app has been purchased by the user.

I won’t go into all the mess-around I had to do in order to get this to work properly, but it wasn’t quite as bad as all that once I finally got it done. But there was a LOT of trial and error, let me aver.

Oh, and since I didn’t want the app to fail due to the inability to get to the Marketplace to verify the license, after the app verifies that the user is indeed licensed, then it saves information to this effect in Isolated storage so if the app can’t phone home, it will nevertheless not suddenly drop the user back into Trial Mode.

Yesterday’s blog entry about dynamically adding and removing AppBar buttons generated a question from Alex Sorokoletov. He asked: “Do buttons jump when added/removed?” The answer is, no, the operation is quite smooth.

It is a common proverb that a picture is worth a thousand words, and so perhaps, a video is worth a million.  Therefore, have a look at this demo, taken from an app I am currently developing: an Amateur Radio practice exam generator.

.

I am now back to working on an app that will be brand-new for the Marketplace, namely a Ham Radio practice exam app that I have mentioned on my product page, though not here, apparently.   I temporarily abandoned it to address problems in my Fraction Calculator, as well as adding support for Trial Mode and tightening up its execution speed.  But having submitted the improved F/C to the marketplace today (and I hope to be able to publish it in a few days), it time to get back to the Ham Practice Exam app.

For Trial Mode with the Fraction Calculator I needed to be able to modify the AppBar buttons on the fly, adding and/or taking away a button as needed, and as it turned out I had a similar need in the Ham Practice Exam a couple of months ago, and figured out how work dynamically with the AppBar.  In the case of Fraction Calculator, I needed for a Buy button to show when the app was in Trial Mode, but not otherwise.  In the case of the Ham Practice Exam, I needed to be able to use the button bar to both navigate forward and backward to sequential questions, and if a question was associated with a diagram that needed to be displayed, then a diagram display button needed to be added and then taken away.

The AppBar is defined in the page Xaml.  Once it is there, it can be modified.  In the main page of the app, the Normal Mode has one AppBar button, a Help button which takes the user to the Help page.  In Trial Mode, it must be joined by a Buy button that will cause the user to be directed to the Marketplace to purchase the app.  Here’s the Normal AppBar Xaml.

<phone:PhoneApplicationPage.ApplicationBar>
    <shell:ApplicationBar IsVisible="True" IsMenuEnabled="True">
        <shell:ApplicationBarIconButton x:Name="AppBarHelpButton" 
             IconUri="/Images/QuestionMark.png" 
             Text="Help" Click="AppBarHelpButton_Click" />
    </shell:ApplicationBar>
</phone:PhoneApplicationPage.ApplicationBar>

Now, you might think that you could put a second ApplicationBarIconButton in there, with some kind of property set to true that would make it invisible.  But there isn’t, not at the ApplicationBarIconButton level.  You can make the entire AppBar visible or invisible on the fly by changing the IsVisible property, but not individual buttons.  

To start with, before you add the Buy button, you should make sure it isn’t already there.  Two of them might serve to emphasize to the Trial user that you’re really serious about getting paid for your app, but three might be overkill.  So, use this to see if you already have one:

private bool BuyMeButtonPresent()
{
    bool result = false;
    string bt = string.Empty;

    for (int x = 0; x < ApplicationBar.Buttons.Count; x++)
        {
            bt = (ApplicationBarIconButton)ApplicationBar.Buttons[x]).Text;
            if ((bt == "Buy")
           {
                result = true;
           }
    }
    return result;
}

As you can see, the method loops through each of the buttons, checking them to see if any of them has “Buy” in its Text property, and if so then it returns True.

Now, if you have an existing button that you need to get rid of, simply use the same strategy, and loop through the AppBar’s buttons, removing the one(s) you need to remove.

private void RemoveBuyMeButton()
{
    string bt = string.Empty;
    for (int x = 0; x < ApplicationBar.Buttons.Count; x++)
    {
        bt = (ApplicationBarIconButton)ApplicationBar.Buttons[x]).Text;
        if ((bt == "Buy")
        {
            ApplicationBar.Buttons.RemoveAt(x);
        }
    }
}

And once you’ve satisfied yourself that you don’t have any such button, and you want to add one, well, here’s how you do that:

private void AddBuyMeButton()
{
    ApplicationBarIconButton b = new ApplicationBarIconButton();
    b.IconUri = new Uri("/Images/BuyMe.png", UriKind.Relative);
    b.Text = "Buy";
    b.Click += BuyMe_Click;

    ApplicationBar.Buttons.Add(b);
}

Note that the BuyMe_Click event method included above already exists in the app’s code; you just need to add it to the new button’s Click event as shown above.

Note carefully, that I did not check to see if it is a good idea to remove the reference to the Click event if you are removing the button from the AppBar — in my case, this removal would happen exactly once during the app’s lifetime in any event, so if it were a loose end remaining, it wouldn’t be particularly loose. If you have a need to remove and re-add a button time after time while the same app instance is running, then perhaps you better make sure this isn’t going to be a problem. I can’t do everything for you, you know!