iOS 4 Persisting Data

I’m thinking of writing a very simple iOS app that has a login control. So a user can register or login with an existing account. While brain-storming how to approach this, I’ve looked in to SQLite that has been around for the longest time or using from the Cocoa Touch Library that was introduced in iOS 3, Core Data Framework. Currently I’m in the middle of researching the difference between the two. But I started thinking more and obviously I want my repository to be at a central location so multiple devices running my simple login app can access it.

Thus, I’m also looking into setting up a web service, perhaps a WFC service and throw it up on a web service I own. Then write some objective-c in my login app using NSURL, NSURLRequest and NSURLConnection classes. While scouring online, there’s a great SDK by Red Gate company, MobileFoo called iSQL SDK that allows you to retrieve data from a SQL Server at http://www.mobilefoo.com/ProductIndex.aspx. Look forward to a future blog post as I’ll play around with their SDK and see how seamless their wrapper classes allow me to hook up my login sample client app with a SQL Server database that will authenticate a user.

No more IIS7 WCF REST 404 Error!

Recently I’ve been trying to host a WCF REST .NET 4.0 service in IIS7. I downloaded the template for VS2010 used for creating REST services as explained here. Running the sample application found on that website worked fine from VS2010. I then switched to hosting the service in IIS7. The result however was a 404 error, not exactly what I was hoping for. My coworker Dan Hanan tried the same thing on his machine with complete success. We looked at the service configuration, IIS7 settings, among other obscure settings without success. Google wasn’t especially helpful since most of the results kept saying things like “add an *.svc file” (which is not required/used in .NET 4.0 REST services), others mentioned changing an IIS7 handler mapping so that the *.svc file would not be required, but none of these solutions helped. Tracing didn’t help me get any closer either.

Still the problem felt like a server issue, so I tried to narrow the search. I eventually came across this blog. There was a link to a question on the MSDN forums that mentions a handler mapping named “svc-Integrated-4.0″. When I looked at my handler mappings in IIS7 it did not contain that mapping. The last post on that question contained a link to the MSDN post One-Time Setup Procedure for the Windows Communication Foundation Samples explaining some steps that need to be taken in order to use the .NET 4.0 WCF services in IIS7. When I tried to run the aspnet_regiss and ServiceModelReg.exe commands explained in the post I only ran into more errors.

Frustrated I talked to my coworker Travis Schilling to see if he had any ideas and to see if his IIS7 contained the mapping. His IIS7 did contain the mapping and he was pretty sure it was installed by VS2010. After a little discussion we decided it would be best to do a repair install of VS2010. After the repair installation the mapping showed up in IIS7 and the REST service ran as expected. I’m not sure why the handler mapping wasn’t installed before, I can only assume it’s because I installed VS2010 before I installed IIS7.

WCF netTcpBinding Through a Router

Today at lunch, we got on the subject of the WCF netTcpBinding and whether or not it was able to traverse routers (and even NAT).  Highly nerdy lunch, admittedly.

So my co-worker Matthew and I decided to spend our RECESS this afternoon proving it out.netTcpBindingMachines_0A851B1E

Here’s a picture of what we setup.  A WCF service sitting out on the internet, and a client using WCF to call the service.  The call goes out through a router that is doing NAT on the internal IP address of the client (192.168.1.*) and sending the message out to the service.

 

Service config:

<service name="NetTcpBindingTest.MathService"
      behaviorConfiguration="DefaultTcpBehavior">
  <endpoint address=""
      binding="netTcpBinding"
      bindingConfiguration="netTcpBuffered"
      name="netTcp"
      contract="Interfaces.IMath">
  <identity>
  <dns value="localhost" />
    </identity>
  </endpoint>
  <endpoint address="mex"
      binding="mexTcpBinding"
      bindingConfiguration="mexTcp"
      name="mexTcp"
      contract="IMetadataExchange" />
  <host>
      <baseAddresses>
        <add baseAddress="net.tcp://localhost:8181/MathService" />
      </baseAddresses>
  </host>
</service>

Client ChannelFactory:

var math = ChannelFactory<Interfaces.IMath>.CreateChannel(
    new NetTcpBinding( SecurityMode.None ),
    new EndpointAddress( @"net.tcp://70.50.y.y:8181/MathService" ) );

Success!  The netTcpBinding definitely makes it through the NAT router.

We weren’t done yet – next we added a callback interface into the mix, so the service could make out-of-band / unsolicited calls back to the client on the duplex channel binding.  A bit surprising that this actually worked as well.

 

WCF Interfaces:

[ServiceContract( CallbackContract = typeof( IMathCallback ) )]
public interface IMath 
{ 
    [OperationContract]    
    int Add( int x, int y );
}
    
    public interface IMathCallback 
{ 
    [OperationContract( IsOneWay = true )]    
    void AnotherAnswer( int z );
}

 

Client DuplexChannelFactory:

var math = DuplexChannelFactory<Interfaces.IMath>.CreateChannel(
    new InstanceContext( this ),
    new NetTcpBinding( SecurityMode.None ), 
    new EndpointAddress( @"net.tcp://70.50.y.y:8181/MathService" ) );

 

Moral of the story:  netTcpBinding is router and NAT friendly.  (MSDN docs actually say that it will work with some NAT routers, and there’s a TON of discussions about this on the internet, so your mileage may vary)