This is pertinent to a phone.

I see many websites that use some kind of scripting to essentially disable the back button of your phone.
This is bad design because hardware and phone behavior should not be messed with.

There is a simple workaround for this.

Simply, refresh the page and hit the back button (while the page is loading).

Why does this work?
This is because you are hitting back before the javascript is loaded and takes over.

Many software developers are looking to develop mobile apps and companies want to jump on the mobile phone bandwagon.

I do not want to debate the reasons; that is a business decision of companies. I want to help fellow developers by talking about the various possibilities; of course the ultimate choice is the developers; only they know the situation they are in.

Unless you live under a rock, the 2 growing platforms out there are iOS and Android. The Windows Phone is the dark horse, but it is a target as of today.

So, here are the possibilities:
In the past, there were only native apps, so a company made 2 or 3 identical version, 1 for Android, 1 for i OS and maybe 1 for Windows.
Companies like Apple, Google, etc. had SDKs, but then you also had to know Java, Objective-C (how quaint) and maybe C#.

Then, along came a company called Xamarin, which enabled to write in C# and output binaries for all major platforms.
This was good because now you did not need to know multiple languages.
But, Xamarin was not cheap.

Then a company introduced Phone Gap as an option, which essentially separated the UI layer from the lower layers. The UI was in HTML, one could use various native clients (that the company provided) that understood HTML. This later became Apache Cordova, and it is offered by the Apache foundation.

So, the first option is Native or HTML?
If Native then should one torture oneself and write in Java, Objective-C, etc?
Or use Xamarin, if the budget allows.

If HTML, then currently Cordova is the only option. Remember, there are some native things of your phone that cannot be accessed via HTML, but these are rare and it finally depends on your app.


It might help the community, that if you have developed a mobile app, to state its name, provide links to it and briefly state the technology you used, in the comments.

Thanks from all of us!

CMSes are an overhead for any organization and a Marketing Manager always wants them but Product Managers (PMs) hopefully understand that Developers dislike the drudgery of doing all that work. But then, that’s life.

Big CMSes add to a Product lifecycle and the overall infrastructure and might end up even governing which technology to use because you remember the last time you got burnt by it and so want to avoid using the CMS but one has to, so you opt-out if you can.

Nowadays, light-weight CMSes are preferred by PMs, because they are more localized and do not need a buy-in from the major players.

One resource I found helpful in evaluating these was http://www.cmsmatrix.org
It is an extensive look various CMSes and what all they support or provide.

in a Windows Phone application, sometimes you might have a long operation , and you do not want to freeze the User Interface (i.e. block the UI thread).

One way to avoid blocking the UI is to use a background worker thread to run the Operation asynchronously and tell it what method to call when it completes processing.

The pseudocode for it…

Start with declaring a background worker.
Tell it what do when finished.

Tell it what method to invoke (which is the long task).
Pass in the argument if any (as an object), so you can have a simple string or a custom object that holds a set of params.

Here is the code for it:

            BackgroundWorker bw = new BackgroundWorker();
            bw.RunWorkerCompleted += new RunWorkerCompletedEventHandler(DoneWork); 
            bw.DoWork += new DoWorkEventHandler(DoWork); 

Note: This concept is applicable to Silverlight in general, and if you are using .NET 4.0 (and not only the Phone), you can use a generic Tuple object for the argument and then type-cast your argument to whatever you passed in.

The signatures for DoWork and DoneWork have to be of the required delegate type, for e.g.:

private void DoWork(object sender, DoWorkEventArgs e)

private void DoneWork(object sender, RunWorkerCompletedEventArgs e)

e.Argument will give you the argument arg1, which you had passed in.

You can store objects you want to send back to the caller as e.Result.

Use this technique to show a progress bar or a wait state in the UI.

Remember, UI operations like updating a list or it’s bindings while done from either delegate need a context switch and are not directly possible because the UI thread is different from the one we might be running on.

This is a pain to code but unavoidable, and to do this, wrap your calls with an anonymous method and call it like this:

             () => {
                     this.listBox.ItemsSource = items;
                     this.PageTitle.Text = text;             

Hope that helps…

Virtual Earth 6.1 was released recently and I thought I’d give the whole mapping thing a try.
VE has the best iSDK I’ve ever seen, period. It has the demo, source, reference all in synchronized tabs. Real slick!

For those of you who don’t know, Virtual Earth (VE) is a mapping platform by Microsoft, that comes with a map control and its kitchen-sink infrastructure.
Live Maps built on top of it is a competitor to Google Earth and I, personally, find it richer and easier to use.

Anyway, back to a quick app to get started…
Let’s start with a .NET C# website project and use default.aspx.

Jump into your aspx source and add:

<asp:ScriptManager ID="ScriptManager1" runat="server">
<asp:ScriptReference Path="http://dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=6.1" />

This basically adds a reference to the VE service.

Add a container element for the map:

<div id='myMap' style="position: relative; width: 800px; height: 800px;"> </div>

To actually show the map, we need to execute a couple of javascript lines on the Body load.
Either add an onload event handler in the body tag or (I recommend) add a .js file
and add

function pageLoad()
map = new VEMap("myMap");

and add a reference to the js file in your HEAD tag or via the ScriptManager tag:

That’s all it takes to have the map show up on your page. Pretty cool, huh?

In the next posts, I’ll show you how to make your project setup more efficient and do some more stuff like finding/adding locations, etc.

Meanwhile, go check it out: http://dev.live.com/virtualearth/ and play with the iSDK: http://dev.live.com/virtualearth/sdk

Our SEO team recently asked us to fix an issue with a client website that we built, whereby a 404 error was being returned as a 200 (ok) response.

As you may know, any decent website has custom error pages to give the user more information, support and to avoid a browser displaying the default ugly page for the error. In .NET, we define custom errors in web.config or at the IIS level. a custom page is a redirect and would return a 200 response since the page was loaded fine although the original response to the invalid URL was a 404.

We needed to fix this because a search engine would keep the missing URLs in its index and these invalid URLs would end up in search results which is a bad user experience from a search perspective (you might say who cares about the search engine) but also from a website perspective (I guess a user may tend to click other domain links if they get 404s on your domain).

Also, Google for example states: “Don’t create multiple pages, subdomains, or domains with substantially duplicate content.” If it finds many of these, it will remove them from the index (which is fine, they were error pages anyway) but could lower the site ranking (which is real bad) because crawl times increase.

So, how can this issue be fixed?
In the case of .NET, just add: <% Response.Status = “404 Not Found” %> in the page and you’re good to go.
Of course, this could be done in the code-behind too.

You could apply this to all your custom-error pages if you want to be diligent.

I came across an issue while trying to submit html content in aspx.net, whereby an error stating: A potentially dangerous Request.Form value was detected from the client…

This was a little perplexing and I realized it is a security validation check done by the asp.net engine and can be bypassed with the ValidateRequest attribute in the Page (add it in the <@ Page tag). You can alternatively add this is the web.config but that would make it site-wide with its potential consequences and I would make it page-specific as a best practice.

Now, in my scenario, all I was doing was displaying snippets of html in a text-box. I did not care about submitting back the html. So, now I am trying to figure out how to populate the text-box on the server (using runat=server) but not have it submit back…

Next Page »