Azure App Service: Offline Sync – Do not use CreatedAt for Display

In the Azure App Service Mobile Client Offline Sync:

With offline sync, the CreatedAt field for a new record that has not been synced is null. If you set CreatedAt to DateTime.Now or another value, on sync, CreatedAt will be replaced with the DateTime of when the sync occurred (used for incremental syncs among other things). If you need to have a created time that corresponds to the actual time the user created the record, created your own property, say DateUTC, and set it yourself to DateUTC.Now;. This value will not change. The only concern with doing this is if the user somehow has the date wrong on their device, the DateUTC will be wrong as well. Hopefully everyone has figured out that having their device date/time set automatically is a good thing.

Update Azure App Service Mobile Apps Beta to GA (General Availability) for Production

Microsoft has gone GA (General Availability) with the new Azure App Services Mobile Apps which means it is available for production use!

To update to the latest NuGet packages, you’ll need to remove the WindowsAzure.MobileServices* packages from your projects and add the new Microsoft.Azure.Mobile.Client* (currently 2.0.0) packages.

No code changes are necessary because even though they changed the NuGet package name, the dll names and namespaces have not changed.

From Xamarin Studio:
Azure Mobile Client SDK

Local Debugging with User Authentication of an Azure Mobile App Service

Local debugging of an Azure Mobile App Service can be a real timesaver, however, using provider authentication such as Facebook or Google throws a wrench in process. In the past, I resorted to logging on the server side and viewing the streaming logs. This was cumbersome and not to mention time consuming. Thankfully, that can be changed. Local debugging with user authentication of an Azure Mobile App Service is now super easy.

Thanks to the documentation, I knew it was possible, but a few things weren’t entirely clear. The steps below bring everything you need to configure local debugging with authentication into one place.

I assume you are working with the following:

In the [Project]/App_Start/Startup.MobileApp.cs file of your Mobile Apps Service, add the following highlighted code:

You’ll need to grab the WEBSITE_AUTH_SIGNING_KEY for your service. This key is highly sensitive and should never be included in a client application. This should be only used on the service side.

  1. Open a browser and navigate to https://{servicename}, replacing the {servicename}. This will take you to the Kudu settings.
  2. If you do not know your Service Name, you can find it as follows:
    1. Login to the Azure Portal.
    2. Navigate to your App Service.
    3. Click on Tools in the top bar underneath Mobile App Code.
    4. Under the Tools, find Develop and then click on Kudu in that section.
  3. You should now be on the Kudu settings site mentioned in step 1. Click on Environment on the top navigation bar.
  4. Search for “WEBSITE_AUTH_SIGNING_KEY” without quotes. It should be under the environment variable section.
  5. Copy this value for the the next section.

Still in your Mobile Apps Service, in the [Project]/Web.config, add the following highlighted code making sure to replace the {} items with their appropriate values:

In your Mobile App using Azure Mobile Services (in my case, this is for a Xamarin Mobile App) you will need the following code where you are currently instantiating your MobileServiceClient:

The key issue I was running into originally was that I did not set the AlternateLoginHost  to the actual service. This had resulted in a 404 error being displayed on my mobile app when clicking an authentication provider. Setting the this value makes all authentication calls still hit your Azure Service while your data calls hit the local service for easy debugging.

Note: This does not allow you to debug your service with authentication without an internet connection. You will still need an active internet connection, especially if your service hits other services. An example would be calling  GetAppServiceIdentityAsync<FacebookCredentials>  which calls out to the login provider service and requires an internet connection.

Being able to locally debug a service that uses authentication is an absolute timesaver. Hopefully this will help you get it up and running.

iPhone 3G with OS 3.1 nearly burned my leg and nether regions

Just thought I’d post this for anyone else having this issue that plans on having kids and is using the iPhone OS 3.1.  My wife and I both have an iPhone 3G and I updated both of our phones to OS 3.1 the day it was released.  We are now getting random iBSoDs (Black Screen of Death) where hitting the home button and/or holding the lock button does nothing.  We have to do a hard reset holding both the home button and the lock button for about 10 seconds and then the phone will reboot.

Well, I’m a pretty patient person and can hopefully wait until they release a fix for this, however, today at work I realized that my leg and nether regions started feeling hot, really hot, and that’s when I hurried and pulled my iPhone out of my pocket.  As I grabbed it, it was so hot that it nearly burned me through the Rebel Serpent case I have on it.  I tried to hit the home button to try to see what was going on and it turns out I was getting the dreaded iBSoD.  I had to do a hard reset to get it to respond.  I had fully charged it the night before and had it unplugged and on only checking my email occasionally, but after the restart I was down to 26% battery life.  In total, it was maybe 2 hours after being unplugged that it was at 26% battery life.  I’m guessing some background process (some people are saying the battery life issue is caused by Push for emails being on) got stuck running like crazy in some infinite loop that caused the non-responsive phone, the battery drain, and the almost sterile male.

I tried to call iPhone technical support but sat on hold for so long that I was afraid that I’d either burn my ear off or end up looking like Two-Face.  Until they get this fixed, I think I’ll stick with using the speaker phone feature.  I think I’d rather have my face than a bunch of money from a lawsuit, but that’s just me.

Anyone else having this wonderful experience?  Is there an iPhone OS 3.1 please don’t burn my face and/or leg petition somewhere that I can sign? Post your feelings on iPhone OS 3.1 in the comments.

WPF application with DropShadowEffect renders incorrectly on nVidia GeForce drivers 185.85 and greater

For those of you who develop using WPF, I ran into the following issue recently:

I developed MuvUnder Cover: The Album Art Sleuth, a WPF application, and with the latest nVidia drivers it displays erratic rendering of the interface. Graphical elements are missing, are half showing, when you mouseover them they appear and then randomly disappear, etc.

I have tested this on a Geforce 7800 GTX and GeForce 7300 LE with the following driver versions: – tested and broken – tested and broken – tested and broken (this was the first of the GeForce/ION drivers)

I tracked it down to the following cause, with a solution:

I had the following DropShadowEffect set on a lot of controls:

<DropShadowEffect x:Key=”DropShadowEffectDefault”
BlurRadius=”5″ />

All of the controls that had that set where the ones that were showing the erratic missing, showing on mouseover, half rendered issue.

I then switched back to the following software rendered dropshadow:

<DropShadowBitmapEffect x:Key=”DropShadowBitmapEffectDefault”
Noise=”0.01″/> <!– Setting Noise forces it so it isn’t automatically changed to DropShadowEffect (nVidia bug with DropShadowEffect)–>

and everything rendered correctly.

You can follow the Microsoft Connect bug I reported to see if/when there is a fix and which side of the fence (nVidia or Microsoft) it comes from at: