JQuery Mobile - Select Controls Populated Dynamically do not Reload

When using JQuery mobile to dynamically populate select controls, you may notice that the options of the control do not really refresh. This is because the native control is in fact replaced by html content when the page loads.   When the options of the select control are updated dynamically, you must rebuild the html content representation to reflect the new state of the native control. This is already supported by the mobile framework by the use of the refresh command.

Use this call to refresh and rebuild the custom content of the select box. The second parameter must be set to true to rebuild the view.

$(mySelectBoxId).selectmenu('refresh', true);

A typical scenario for this is with the use of cascading drop down. The first dropdown filters the options from the second drop which gets populated dynamically. After adding the options dynamically, a call to rebuild the control needs to be made.
I hope this helps.

CodeProject
og-bit.com

Android Emulator - Use Localhost Web Server

If you are using the Android emulator, and you are trying to reach your web pages in your local development machine, you will soon realize that the emulator can't reach your local web server using localhost, the machine IP address or the machine name. There is however a simple explanation for this. The emulator has its own localhost loopback interface (127.0.0.1).  This means that when you type http://localhost/mypage.aspx, the emulator tries to reach its own loopback interface, and this is probably what you do not need.

There is an easy resolution for this. You can reach the development machine using IP address 10.0.2.2 which is a special alias to the loopback interface for the computer hosting the emulator. Your url should then look as follows: http://10.0.2.2/mypage

I hope this helps.

CodeProject
og-bit.com

Use Preprocessor Directives to Support Multiple Web Service Versions

When there is a new version of a web service in a different URI, we usually just need to point to that new URl and get the new reference class for that service. A problem may arise when the new service definition does not keep backward compatibility, and your project will no longer compile because a property or method was either renamed, or it no longer exists.

An approach to address this problem is to create an assembly that provides a facade to abstract the object model of the web service.  In this facade, you can use preprocessor directives to indicate what web service namespace to include and what code to compile. This is a simple scenario:

Version 1	Version 2
namespace mydomain.services.version1 {       public partial class myclass {      public string LName;      ....   } }	namespace mydomain.services.version2 {       public partial class myclass {      public string LastName;      ....   } }

In this scenario,  the namespace and a property have changed. If you try to compile the code that consumes the web service using version two, there will be compilation errors because the namespace does not exists, and there is no LName property. You will then need to change the code to match the new web service definition, and all should work fine. But, what if you need to support both web service versions for different product releases? In this case, you may want to have the implementation for both versions in the same codebase. To achieve this, you can write the following on the facade class:

#if USE_VERSION2

using mydomain.services.version2;

#else

using mydomain.services.version1;

#endif

On the project conditional compilation symbols,you can add USE_VERSION2 as the symbol to indicate what code segment should be included. In this case, version2 wil be used. If not compilation symbol is added, the default will be version1.

To address class members backward compatibility like in the case of the LastName property change, you write a facade property as follows:

public string LastName

{

#if USE_VERSION2

    get {return service1.LastName;}

#else

    get {return service1.LName;}

#endif        

}

The property provides access to the member of the selected version. In this case, LastName when using version2 or LName as the default.

With this approach, the client that consumes the facade is abtsracted from the web service object model. Support to additional versions is done in the facade thus minimizing the impact to the rest of the application.

I hope you find this useful.

CodeProject
og-bit.com