Best Practices Moving from SQL Server to SQL Azure...

1. When you choose your objects, I recommend going one object at a time. Personally, I go in the following order: Tables, Views, Stored Procedures, User-Defined Functions… Basically, I go in the order that they are shown in the “Generate and Publish Scripts” dialog as shown here:

2. Use the “Advanced Scripting Options” dialog.

• Turn “Include If NOT EXISTS” to true.
• Turn “Script DROP and CREATE” to “Script DROP and CREATE”
• Turn “Script for the database engine type” to “SQL Azure Database”
• Turn “Script USE DATABASE” to false. This should be automatically disabled when you change the database engine type as previously described. But, if for some reason, it doesn’t get disabled, ensure that this value is “false”.

Saving and Retrieving Arrays in Local Storage...

With the HTML Local Storage feature, you have a more powerful approach to storing information instead of the traditional cookie. At first glance, this feature appears to only work with strings. But, you may have a need to store something more complex. Like a collection or an array of JSON objects. That was the situation I ran into when I got an education on this feature.

Storing an Array in Local Storage
To store a collection or array in local storage, you must first convert it to a string. To do that, you can use something like the following:

var myCollection = { "people":[
{'ID': 1, 'FirstName':'Chad', 'LastName':'Campbell'},
{'ID': 2, 'FirstName':'John', 'LastName':'Smith'}
};
localStorage.setItem('collectionKey', JSON.stringify(myCollection));

In the previous snippet, we took a JSON array and we made it into a string. This process of converting it to a string was handled by he ever-popular, ever-useful JSON.stringify function. This native function in modern browsers handles the process of serializing the data. The way to get this value back to an array is shown in the next section.

Retrieving Arrays from Local Storage
If a JSON array is stored in local storage properly, it will be stored as a string. To get it back into a usable form, you can use the complementary function JSON.parse. A sample is shown here:

var savedString = localStorage.getItem('collectionKey');
var savedCollection = JSON.parse(savedString);


Its important to recognize that “getItem” will return null if the key isn’t in storage. Because of that you may want to add an additional check. Regardless, the process of using local storage involves serializing / deserializing. This process is leveraged via the JSON.stringify and JSON.parse methods.

Windows Phone 7 – Speed Up Development with ...

Often times there is a routine, repetitive task that you perform during development to help you meet an end goal. For instance, a lot of applications have a login screen. Just a basic screen that requires you to enter your username / password, then click “Login”. Well, if you’re writing an application, pretty soon this entering of your credentials gets old. In order to relieve this pain, I’d like to revisit an old friend, the preprocessor directive.

A preprocessor directive can be used for conditional compilation. In other platforms, this conditional uses a separate preprocessor. However, C# the directives are processed as if there were only one. Altogether, C# has 14 preprocessor directives. To show how you can use a preprocessor directive to speed up your development, lets consider the login screen again.

If you have a basic page, you may be tempted to enter the credentials in your constructor like the following:

public Login()
{
  InitializeComponent();

  if (Microsoft.Devices.Environment.DeviceType == Microsoft.Devices.DeviceType.Emulator)
  {
  usernameTextBox.Text = "testUserName";
  passwordBox.Password = "testPassword";
  }
}

The problem here is the .xap file. If you publish this application, your test credentials will actually be stored in the code. Because of this, someone could use a tool like RedGate’s .NET Reflector and see your credentials. If you’re a solo developer, you may actually be using your real credentials which could open a personal pandora’s box for you.  To help you avoid this unfortunate situation, you could improve the previous code by doing the following:


public Login()
{
  InitializeComponent();

  #if DEBUG
  usernameTextBox.Text = "testUserName";
  passwordBox.Password = "testPassword";
  #endif
}


This approach will remove your credential code when you compile your application in Release mode. Something you should do before you submit your application to the Windows Phone Marketplace. The reason your credentials are removed is because of the special DEBUG directive. This directive is defined by Visual Studio be default. Basically, it means anytime your application is compiled under “Debug” configuration, the code in-between the #if DEBUG -> #endif directives will be included.