Search
Recent Tweets

Entries in mobile (10)

Wednesday
May162012

CodeStock 2012 Windows Phone App

The CodeStock conference is coming up soon on June 15th in downtown Knoxville. As such I have upgraded the CodeStock 2011 Windows Phone app for this year's conference and am pleased to announce it has been published to the marketplace.

Changes Over Last Year's Version

I have not had much time this year to enhance the application but below are highlights of what changed for the 2012 version. For more details see the commit history.
  • Mango upgrade - OS target upgrade from 7.0 to 7.1 and many fixes to address breaking changes
  • Map view - new map view with various points of interest and directions. Points of interest are externally configured so if you have suggestions, let me know.
  • Branding - logo, title, date, image and theme related changes
  • Source control and hosting - switch from HG and bitbucket to git and github
  • New app, not an upgrade - Due to various factors this year's version was submitted as a new app and last year's was hidden. If by chance you have last year's version installed, uninstall it first.

Potential Future Changes

There is a chance I might make additional updates before the conference and might consider pull requests if you are so inclined. Feel free to add an issue for any bugs or feature requests.

Some changes I'd like to see in the future:
  • Live tile - maybe showing next session via schedule and/or favorite
  • Better twitter integration - i.e. more of a native twitter client instead of mobile twitter links.
  • More graceful public WiFi handling - better error message when an HTML response (from a WiFi logon page) was received instead of expected JSON. (change pending Marketplace approval in v2.2)
On another Windows Phone project I started refactoring the Phone.Common assembly out into multiple NuGet packages that are a bit more generic. I have not had the time to finish that or incorporate it into the CodeStock app yet.

Overview Video

The below video gives an overview of most of the features minus a few miscellaneous ones.


This page can also be accessed via http://www.geoffhudik.com/codestock-wp7.
Sunday
Feb192012

Windows Phone Login Navigation

A common desire for a mobile application is showing a welcome / login type screen initially when an account is required and the user first runs the app. My past two Windows Phone apps have not needed this but my current one does. I thought it would be very simple and straightforward; just check some user settings in App.xaml.cs and conditionally navigate to a different page depending on whether validated credentials are present.

Some Problems

It turns out it was not quite that straightforward. First of all the process of navigating to MainPage.xaml (or whatever startup page you use) is already underway in App.xaml.cs. Navigating to another page required either cancelling that navigation or using UriMapper to setup the initial page. This post by Peter Torr provided a great starting point. I chose the UriMapper approach and it worked in terms of conditionally changing the initial page.

However, after initially navigating to the welcome / logon page when credentials were missing, I tried redirecting back to MainPage.xaml after credentials were validated but nothing happened. The welcome page remained on screen and it was not obvious why the navigation to MainPage.xaml was not working.

Solutions

In turning to a programmer's best friend (Stack Overflow), I found this WP7 sign-in redirect post. That post suggested that the only real option was making the main page conditionally show a login control or pop-up. I was not fond of that approach; for one it did not seem like a good separation of responsibilities. For another it meant dynamically hiding/showing or covering/uncovering content and it felt like the experience would be worse for both the end user and myself.

Late last night I decided to experiment a bit more with the separate welcome screen approach and did manage to get it working, though there may be a better approach.

The main class looks like this:
public class StartupNavigator : IStartupNavigator
{
	private readonly UserSettings _userSettings;
	private PhoneApplicationFrame _rootFrame;

	private const string MainPage = "/MainPage.xaml";

	public StartupNavigator(UserSettings userSettings)
	{
		_userSettings = userSettings;
	}

	public void Initialize()
	{
		_rootFrame = ((App) Application.Current).RootFrame;
		SetupUriMapper();
	}

	private void SetupUriMapper()
	{
		var map = new UriMapper();
		map.UriMappings.Add(new UriMapping {Uri = new Uri(MainPage, UriKind.Relative)});
		_rootFrame.UriMapper = map;

		var navPath = _userSettings.HasValidatedCredentials ? MainPage 
			: "/Pages/WelcomePage.xaml";
		map.UriMappings[0].MappedUri = new Uri(navPath, UriKind.Relative);
	}

	public void GoHome()
	{
		_rootFrame.Dispatcher.BeginInvoke(() =>
		{
			// recalculate URI mapping - should have a different answer now 
			// on validated credentials. this is needed
			SetupUriMapper();
			// we need to vary the query string, otherwise OS doesn't think we 
			// are navigating to different page and won't do anything. Despite 
			// changing the initial Uri mapping from Main Page to login/welcome, 
			// _rootFrame.CurrentSource remained as /MainPage.xaml the whole time.
			_rootFrame.Navigate(new Uri(MainPage + "?fromLogin=true", UriKind.Relative));
		});
	}
}

Keys to the Solution

The SetupUriMapper method takes care of setting the correct initial page to be navigated to according to whether validated credentials exist in settings. The less obvious part is the GoHome method which will later get invoked from the welcome / login page's ViewModel once the user's credentials have been validated. As the comments indicate, the root frame's UriMapper needed to be set again now that MainPage.xaml is now the starting point instead of WelcomePage.xaml.

Next, when navigating to MainPage.xaml, I had to add a query string parameter just so the Uri changed a bit. Despite changing the initial Uri mapping before, RootFrame.CurrrentSource remained as /MainPage.xaml during the process (set in WMAppManifest.xml). Windows Phone appeared to be ignoring the request to navigate to MainPage because it detected the Uri was not changing.

Perhaps my understanding of this is flawed and there may be a better approach; in either event, I would love to hear about it. This was the main gotcha I ran into. For subsequent page navigation I went with the standard navigation approach I have used in the past - see this bitbucket code for an example.

Hitting the back button after a successful login will take the user back to the welcome page and hitting it again will exit the app. This provides the expected behavior for certification purposes, though you might be able to get away with calling NavigationService.RemoveBackEntry() later in MainPage.xaml if the previous page was WelcomePage.xaml and you did not want to navigate back to the welcome page. Subsequent runs of the app with valid credentials results in a direct navigation to MainPage.xaml where pressing the back button will exit the app.

The Rest of the Story

Hopefully what follows is more typical / obvious...

The user settings class that StartupNavigator uses is straightforward:
public class UserSettings
{
	private readonly ISettingsHelper _settingsHelper;

	public UserSettings(ISettingsHelper settingsHelper)
	{
		_settingsHelper = settingsHelper;
	}

	public string Username
	{
		get { return _settingsHelper.GetString("Username"); }
		set
		{
			_settingsHelper.SetSetting("Username", value);
		}
	}

	public string Password
	{
		get { return _settingsHelper.GetPrivateString("Password"); }
		set
		{
			_settingsHelper.SetPrivateString("Password", value);
		}
	}

	public bool? CredentialsValidated
	{
		get { return _settingsHelper.GetBool("CredentialsValidated"); }
		set
		{
			_settingsHelper.SetSetting("CredentialsValidated", value);
		}
	}

	public bool HasValidatedCredentials
	{
		get
		{
			return !string.IsNullOrEmpty(this.Username) 
				&& !string.IsNullOrEmpty(this.Password)
				&& true == this.CredentialsValidated;
		}
	}

	public void Save()
	{
		_settingsHelper.TrySave();
	}
}
In App.xaml.cs at the end of the constructor the startup navigator is initialized which sets up the UriMapper:
public App()
{
	// ... default App ctor initialization here	
	InitializeIoC();
    IoC.Get<IStartupNavigator>().Initialize();
}

private static void InitializeIoC()
{
	IoC.LoadModules(new MainModule());
}
When validated credentials were not found in settings, WelcomePage.xaml is navigated to which kicks off the WelcomeViewModel:
public class WelcomeViewModel : AppViewModelBase
{
	private readonly UserSettings _userSettings;
	private readonly IUserValidator _userValidator;
	private readonly IStartupNavigator _startupNavigator;

	public WelcomeViewModel(UserSettings userSettings, IUserValidator userValidator, 
		IStartupNavigator startupNavigator)
	{
		_userSettings = userSettings;
		_userValidator = userValidator;
		_startupNavigator = startupNavigator;
	}

	private string _username;
	public string Username
	{
		get { return _username; }
		set
		{
			if (_username != value)
			{
				_username = value;
				RaisePropertyChanged(()=> Username);
			}
		}
	}

	private string _password;
	public string Password
	{
		get { return _password; }
		set
		{
			if (_password != value)
			{
				_password = value;
				RaisePropertyChanged(()=> Password);
			}
		}
	}

	private void GetStarted()
	{
		// go ahead and save settings now. if incorrect and user comes back in 
		// another session, we want those values to stick
		_userSettings.Username = this.Username;
		_userSettings.Password = this.Password;
		_userSettings.Save();

		_userValidator.Validate(this.Username, this.Password, OnLoginSuccess);
	}

	public void Load()
	{
		this.Username = _userSettings.Username;
		this.Password = _userSettings.Password;
	}

	private void OnLoginSuccess(User user)
	{
		_userSettings.CredentialsValidated = true;
		_userSettings.Save();

		// TODO: do something with user result; persist somewhere so we don't have 
		// to fetch data again. Then on MainPage, elsewhere we can access later.
		Debug.WriteLine("Welcome " + user.Fullname);
		
		_startupNavigator.GoHome();
	}

	public ICommand GetStartedCommand
	{
		get {return new RelayCommand(GetStarted); }
	}
}
The user validation class simply creates a service client class that invokes a service method to validate the user credentials entered.
public class UserValidator : IUserValidator
{
	private readonly AppSettings _appSettings;
	private readonly IMessageBoxService _messageBoxService;

	public UserValidator(AppSettings appSettings, IMessageBoxService messageBoxService)
	{
		_appSettings = appSettings;
		_messageBoxService = messageBoxService;
	}

	public void Validate(string username, string password, Action<User> onSuccess)
	{
		if (string.IsNullOrEmpty(username) || string.IsNullOrEmpty(password))
		{
			_messageBoxService.ShowOKDispatch("Username and Password are required.", 
				"Required data");
			return;
		}

		var client = new DataClient(_appSettings.ApiKey, username, password);
		client.UserInfoComplete += (sender, args) =>
		{
			if (string.IsNullOrEmpty(args.Result.ErrorMessage))
				onSuccess(args.Result.Result);
			else
				_messageBoxService.ShowOKDispatch(args.Result.ErrorMessage, 
					"Login Failed");
		};

		client.FetchUserInfo();
	}
}

Sample Project

Download WinPhoneLoginRedirect.zip for a working sample project.

Wednesday
Jan252012

Windows Phone: App Config Settings - Thinking Outside the Box

File this post under the OCD, late night, crazy category. I just started a new Windows Phone application and have been working on a client for a service my app depends on. I wanted to test out the service interactions but with unit tests of my WP7 class library, not via building out a user interface.

Quickly there were a couple minor snags that I allowed myself to get bogged down in:
  • State of testing support - The last time I attempted unit testing with WP7 I was not real happy with the testing support. Is it better now? Is there another better approach? More on this in an upcoming post; I changed my mind and decided to follow the single responsibility principle for this post :).
  • Where to put service credentials, other test settings - The service API being tested requires a private API key, username and password. I thought the client and tests might go public later and I did not have a separate test account, only my own credentials. Where and how should these values be stored and passed to the tests so they are somewhat protected and configurable?

Config Settings Goals

In this context I am referring to settings as the rough equivalent of standard <appSettings>, not runtime settings for the app and user. My context is also currently one of a unit testing app project but some of this could be applicable to other projects as well.

There are a few options but I wanted one that addressed the below, some of which conflict. Goals:
  1. Private settings - Namely keeping the credentials out of source control and any public distribution. I need to keep this data out of the tip as well as all revision history. If I have to remember to remove personal settings prior to a commit or publish, it is only a matter of time before I forget.
  2. Configurable - Ideally these settings could be edited in a file w/o being manually typed into app code
  3. Isolation - Some way to keep the more private settings separated from everything else, maybe outside the solution / IDE
  4. Default settings - Exclusions and isolation implies the container for these settings might not exist (new source control pull etc.). However everything still needs to build and there should be a way to create empty/default settings when not found. It also needs to be obvious where/how people supply their own values for these settings.
  5. Runtime performance - Preferably there would not be any real runtime I/O for these settings so test performance does not take a hit. These "app settings" are not changing during the course of an app / test execution run but they may change between runs.

Hard-coding settings

Manually hard-coding the credentials to test with is the easiest option and what I started with but it does not address any of goals above with the exception of #5 Runtime performance.

App.config

There is not really a concept of app.config for windows phone projects. Someone created a modified WP7 version of the mobile configuration block that could be used but it felt a bit forced to me and has some overhead.

Isolated storage

Isolated storage is more suited for runtime user settings / options / preferences to me. IsolatedStorageSettings.ApplicationSettings is an option but I cannot easily create, view and edit app config type settings without doing something programmatically or using some kind of isolated storage browser. The data will not be there to start with and the initial values have to come from somewhere. Additionally changes to the settings will be lost anytime the emulator app is restarted. Even all that aside, isolated storage doesn't quite meet the runtime performance goal and there are various caveats and serialization issues I have run into in the past. If you are interested in runtime user settings however, the code in my Codestock post has an example (just search for settings).

App.xaml

A custom settings class can be created and instantiated in App.xaml resources. First a simple TestSettings class:
public class TestSettings
    {
        public string ApiKey { get; set; }
        public string Username { get; set; }
        public string Password { get; set; }

        private static TestSettings _default;

        public static TestSettings Default
        {
            get { return _default; }
            set
            {
                if (null == _default)
                    _default = value;
            }
        }
    }
Next TestSettings.xaml to instantiate and configure the class.
<ResourceDictionary 
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="clr-namespace:DataBoundApp1"
    >
    <local:TestSettings x:Key="Settings" 
        ApiKey=""
        Username=""
        Password=""
    />      
</ResourceDictionary>
Then in App.xaml the resource is merged in:
<Application 
    x:Class="DataBoundApp1.App"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"       
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:shell="clr-namespace:Microsoft.Phone.Shell;assembly=Microsoft.Phone">

    <Application.Resources>
        <ResourceDictionary Source="TestSettings.xaml" />
    </Application.Resources>

	<!-- ... -->
</Application>
Now we can set default settings in App.xaml.cs, or refer to the App class elsewhere:
private void Application_Launching(object sender, LaunchingEventArgs e)
{
	TestSettings.Default = this.Settings;
}

public TestSettings Settings
{
	get { return (TestSettings)this.Resources["Settings"]; }
} 

/* or elsewhere:
//    var settings = ((App)Application.Current).Settings
*/
All of that is fine and good except it does not meet the goal on private settings. If I plug my private settings in TestSettings.xaml, I have to remember to later empty those out. I cannot just exclude the file from source control as it is required to compile the app.

One solution is to use pre and post build events to temporarily swap settings in and out automatically. We can create 2 new copies of TestSettings.xaml outside of Visual Studio to facilitate this. TestSettingsPrivate.xaml will contain the personal / private settings values that we do not want in the project or source control. TestSettingsDefault.xaml will contain the empty (or default) settings that we want to include in the project and source control for others as a starting point. TestSettings.xaml will be our "Main staging area" that will be replaced before and after; sort of like Towers of Hanoi or a shell game, except not. :)

In the pre-build event of the test project (all on one line):
if exist "$(ProjectDir)TestSettingsPrivate.xaml" xcopy /y "$(ProjectDir)TestSettingsPrivate.xaml" "$(ProjectDir)TestSettings.xaml"

and then in the post-build event (all on one line):
if exist "$(ProjectDir)TestSettingsDefault.xaml" xcopy /y "$(ProjectDir)TestSettingsDefault.xaml" "$(ProjectDir)TestSettings.xaml"

If the default and private settings do not exist, as in the case of a new source control pull, then the default/empty contents of TestSettings.xaml get used. In that case you might wonder why bother with TestSettingsDefault.xaml when TestSettings.xaml could be "backed up" and restored automatically. The main reason has to do with the way Visual Studio locks files during a build; trying to make a copy either did not work or generated an "exited with code 2" failure.

Just before the build the test settings file will get replaced by the private settings file and that will get compiled into the assembly. A moment later after the build the test settings file will get reset back to the defaults just as if nothing happened. I thought Visual Studio might pop-up a "this file has been modified outside the environment" type dialog but that was not the case.

If we peek into the assembly contents we can see the private settings were sucked into the DLL while the empty/default TestSettings.xaml remains without the private settings post-build.



Granted when distributing the project I need to be sure not to include the compiled DLL and the private settings file. This is not a problem if I exclude them from source control, only if I zip up the directory. If using Mercurial for source control my .hgignore file might look like the below:
	syntax: glob

	*.csproj.user
	obj/
	bin/
	*.ncb
	*.suo
	_ReSharper.*
	*.resharper.user
	MyApp.Tests/TestSettingsPrivate.xaml
Download DataBoundApp1.zip for an example project of this approach.

T4 and JSON Settings

Another option is T4. First I added a new text file TestSettings.txt to the project. Then I renamed .txt to .t4 (.tt works too) and set the file's Custom Tool to TextTemplatingFileGenerator. In the T4 file I first setup the generation of what will become TestSettings.generated.cs:



Next the T4 file looks for a TestSettings.json file (not included in the project) and if it does not exist it creates it by instantiating a new instance of TestSettings and serializing that to JSON (JSON Helper method shown later). One thing to note is the use of file I/O methods like File.CreateText; these are marked [SecurityCritical] and we cannot call them at runtime in a windows phone app but at "design time" in the IDE it works fine. Another thing to note is that Host.ResolvePath throws an exception if the file does not exist; the reference to App.xaml is just to get a fixed handle on some valid file so we can resolve the directory.



Why JSON for the settings? Well if you have just string properties you can get away with simple string.split, name/value pairs etc. With other data types JSON makes more sense and it is pretty readable and hand-editable (maybe with the exception of dates). Why create a custom format or go through more overhead with XML when JSON works fine? The next block of code reads the json file and builds a C# code block that will instantiate TestSettings in the generated code class.



Finally the T4 has a JSON helper method to serialize the settings object. I tried using JSONSerializer initially but it was throwing "could not find file or assembly ..." exceptions.

TestSettings.json will get created initially when it does not exist with empty values. It can then be hand-edited outside the IDE.
{
  "ApiKey": "SecretKey",
  "Username": "SecretUsername",
  "Password": "SecretPass!",
  "IntProperty": 0,
  "BoolProperty": false,
  "DateProperty": "\/Date(-62135578800000-0500)\/"
}
This T4 will produce a TestSettings.generated.cs that looks like below. Note that for this example I took the existing TestSettings.cs and made it a partial class and added some properties of other data types just for testing.
namespace MyApp.Tests
{
    // see also TestSettings.json outside ide in this folder for default values
	public partial class TestSettings //.generated.cs
	{
		private static readonly TestSettings _defaultInstance;

		public static TestSettings Default
		{
			get {return _defaultInstance;}
		}	

		static TestSettings()
		{
			_defaultInstance = new TestSettings
			{
				ApiKey = "SecretKey",
				Username = "SecretUsername",
				Password = "SecretPass!",
				IntProperty = 0,
				BoolProperty = false,
				DateProperty = System.DateTime.MinValue       
			};
		}
	}
}
At this point you may be thinking, "so what? you've just hard-coded the settings again but in a more elaborate way." That is true to an extent but this generated code class as well as the settings json file are both discardable now. As long as the t4 file is there it will take care of the rest. These can be excluded from source control just like the private XAML settings file. This approach has the advantage of only needing a single settings file and it is the least hit to performance at runtime as the work is already done and compiled by then just as if I hard-coded the settings by hand.

By default with this approach if I update the settings file I have to manually re-run the T4 transformation. However I can use something like Chirpy to automatically run the T4 on every build if desired.

Download: TestSettings.t4

Conclusion

This certainly isn't an exhaustive list of possibilities and some of this may be a bit crazy but at any rate it is food for thought.