iOS Best Practices – Introduction

As my work gets more and more into mobile development (primarily iOS) I find our typical adoption to best practices (in .NET and Java, for example) not as strong. Whatever the reason, these practices are just as important on mobile platforms as they are on web and desktop platforms. The fact that a mobile device has more constrained resources or has fewer technology choices should have no impact on proper coding and design practices.

There are several books (Apple and otherwise) that I can recommend that cover basic coding conventions and UI design guidelines so i’ll try not to re-hash much of that here. As I encounter references and resources such as these I will link to them in a resources section.

The following series of posts is meant to document iOS design and development best practices as I have encountered them both in practice and as I have found them researching across the Internet. I encourage anyone following along to not only share the practices but to critique and contribute as well.

This introductory post will serve to index all the posted best practices:
1. Avoiding the big ball of mud (part 1) – Singletons –

WCF Web Service Latency on BizTalk 2010

I was recently working with a client to roll-out some WCF web services to BizTalk 2010 which access an Oracle database to facilitate the query (also using the WCF-OracleDb adapter).  As expected, we were getting some pretty serious latency issues (1-2 seconds per request) as BizTalk is tuned for throughput and not low-latency.  This, however, is not really an acceptable solution for web services.

To fix this, we needed to adjust some BizTalk tuning parameters to improve the latency.  Specifically, we looked at the polling interval for messages on a given host.  By default, it is set a 500 ms which means we’ll most likely have a MINIMUM of .5 seconds to process the request and most likely more as the message is sent to the orchestration, to the WCF-OracleDb adapter, and then back to the orchestration.

We decided to create a new BizTalk low latency in-process host to accomodate our web services.  Fortunately for us, BizTalk 2010 makes it even easier to set some of the previously registry-based on inaccessible tuning parameters.  After creating our host and host instances, it was pretty straight-forward:

  1. Open the Admin console, right-click on the BizTalk group and select settings
  2. Under the Hosts node, we selected our low latency host from the drop-down
  3. Now, under the Polling intervals we set both Messaging and Orchestration to 50 ms instead of 500 ms
    1. A better practice would be to have split receive, process, and send hosts and set the polling more specifically.   This was not required in our case.
  4. After selecting the host in the bindings (orchestration and send ports, not needed for the isolated receive port) and restarting we got the average response time down to 300 ms which puts us at the mercy of the Oracle databases response time. 

We also adjusted the internal message queue size for the host to ensure more messages can be kept in memory for even lower latency.

Take a look at this article for more specific details.


TFS 2010 Configuration: TfsJobAgent Won’t Start – Access Denied

While setting up and configuring TFS for a client, the other day, we ran into a strange error during configuration.  The TFS 2010 configuration failed to complete because the TfsJobAgent service could not start.  The error was simple and straight-forward: Access Denied. 

Usually there are several items to check here:

  1. Are the credentials for the service account correct? (The error would have told us Logon Failure anyway)
  2. Does the service account have the Log on as service policy right?
  3. Is the service account NOT in the Deny log on as service policy?
  4. Are these policies being locked/overridden via an AD policy, etc.?

Well … we exhausted all of these options and still could not determine the cause.  We decided to get a fresh set of eye in on the issue and he pointed out the brutally obvious to us by asking: Does the service account have file system rights to the EXE? Check the ACLs.

Brilliant!  Turns out this client restricts folder ACLs on their servers to aid in security and the TFS service account didn’t have access to this folder. 

So now I can add this to my “pre-flight” checklist.

Getting off the ground with the WCF-OracleDB adapter in BizTalk

Time and time again I walk into a client which uses Oracle and I need to connect BizTalk to it.  And … time and time again I run into issues getting the correct Oracle client installed, then getting Visual Studio to pick that up and so forth.  Finally, I think I have arrived at a formula for getting things working.

Step 1: Install the WCF LOB Adapter pack

Ensure that you have installed at least the 32-bit version on a development workstation as well as the 64-bit version for any 64-bit environments.  The BizTalk 2010 installation program does a nice job of walking you through installing the SDK and then the LOB packs so I won’t go into any more details.

Step 2: Obtain and install the ODAC client

Technically, the adapter pack is compatible with an older 11g client but this will be taken care of via a slew of Publisher Policy’s that will “redirect” your client to the installed version.  To get the client you can search for ODAC1110720 or go to Oracle’s Windows download page and locate the ODAC client links and then the specific version listed above.  I honestly have not tested with the newer 11g clients but perhaps the same/similar process will work with them.

Step 3: Update the adapter pack’s assmbly binding

Locate the Microsoft.Adapters.OracleDB.Config file in the Adapter Pack’s install directory (c:\Program Files\Microsoft BizTalk Adapter Pack\bin) and add the following XML snippet in the <assemblyBinding…> element:

<assemblyIdentity name="Oracle.DataAccess" publicKeyToken="89b483f429c47342" culture="neutral" />
<bindingRedirect oldVersion="" newVersion=""/>

Now this will redirect all 11g calls to th 11.7.0 client version to the installed version.

At this point, the Add Generated Items->Consume Adapter Service wizard should work to connect to your Oracle server.  Depending on your standards, you may need to get a tnsnames.ora file in the correct location OR skip TNS resolution and use the server’s direct settings in the binding configuration.

Please leave a comment if this does (or does not) work for you!

New TFS Build Extensions

Per Brian Harry:

Mike Fourie just published a bunch of workflow activities/actions for TFS builds.  It’s a great set of extensions that makes TFS builds even more powerful with less work.

While there doesn’t seem to be any true documentation on the actual extensions themselves, looking at the bundled/generated CHM it looks like we have some new extensions in the following categories:

  •  IIS7 Integration – looks like creating components in IIS to roll-out a web application (application, site, app pool, etc.)
  • VB6 Builds
  • Hyper-V/VirtualPC Integration – Tools to manage Virtual PCs and to interact with Hyper-V
  • SQL Server command execution
  • WMI script execution
  • PowerShell script execution
  • ZIP Integration (one that is frequently asked of me from our customers)
  • Sending emails
  • Code Metrics integration
  • StyleCop integration
  • NUnit integration
  • File system, assembly info/update, RoboCopy and more

Seems like a pretty decent list of enhancements for free!  Grab them here:

BizTalk Schema Inheritance Practices / Examples

Frequently I find myself at clients explaining BizTalk best practices and one of the items I always try and push forward is proper schema inheritance practices.  Much like object-oriented design, schema inheritance can help create a nice canonical domain model.  However, there are always questions as to which type of inheritance to use.  While these practices go beyond just BizTalk, I wanted to focus this on implementation within the BizTalk tools.

Microsoft (and others) do put out documentation on this very subject but it doesn’t really go into any good examples of each type so I plan to plug that gap here.  The first few sections go into some background and other practices … if you are just looking for examples and practices for the given types feel free to skip ahead.

Types of Schema Inheritance

To summarize, there are three ways to re-use schemas within your BizTalk solution:

  • XSD Import – Importing types from another schema/namespace
  • XSD Include – Importing types from another schema within the SAME namespace
  • XSD Redefine – Importing types from another schema with the intent on extending/overriding the types

These all sound very similar in definition but there are some key usage scenarios for each in practice.

Organization of Schemas

Before going into the re-use of schemas it is important to think of re-use of your schemas beyond just your solution and extend into the greater collection of BizTalk applications at a given organization.  This becomes even MORE crucial in the realm of BizTalk when dealing with dependency, deployment and maintenance issues.  Without getting into too much detail, here are some quick pointers:

  • When creating canonical schemas to be shared with multiple BizTalk applications they MUST be isolated in their own project/assembly.
  • Treat yourself like a 3rd party vendor when consuming these schemas: add a reference to a well-known, strongly versioned DLL of these schemas
  • Remember that BizTalk only allows a given schema message type to be defined once in the entire BizTalk group so sharing these at the source code level won’t work
  • Track these central schemas as a separate project/lifecycle so that there is a clean separation between your consuming application and these soon-to-be highly shared schemas
  • Enforce schema versioning (especially in the namespace) from the beginning.  When you roll out an update you’ll not only have to version the .NET DLL but also the schema namespace
Creating ComplexTypes

The first step in re-using other schemas is to define the reusable schema itself (obviously) but then to create actual schema types (ComplexType) out of the bits to re-use.  This is the simple part: Simply select the “record” node which you want to re-use/share and set the DataStructureType property to the name you wish to use for the type.  The following screen shot shows the data structure type property.

BizTalk - Schema Data Structure Type

BizTalk - Schema Data Structure Type

It would be a good idea to define a naming standard/practice for these types … I generally use something like the node name plus the word type.  For example if I were creating an Order schema I would create a complex type named simply: OrderType.

The following sections define a typical usage scenario for each type of schema inheritance.

XSD Import – Composition

Frequently, you have the same type of information repeated throughout your projects and solutions.  A classic example is the Address.  When defining a schema like Order, you can have several addresses all containing the same fields but representing different locations.  For example, you may want to have a shipping and billing address in your order and ensure the addresses are consistent. This is very simple to accomplish:

  1. Create a schema which represents your address, and create a ComplexType out of it as in the above example.
  2. Create a schema called Order and ensure it has a different target namespace than the Address schema
  3. Click on the <Schema> node, then open the Imports collection in the properties window
  4. In this windows you’ll now be able to “XSD Import” the address schema into the Order schema

The following screenshots depict the XSD Import of the Address schema:

BizTalk - XSD Import

XSD Import

Next, create a couple of Child Records nodes for holding a Billing and a Shipping address. In the properties window for each record, set the Base Data Type to the complex type created above.

BizTalk - Base Data Type

Base Data Type

Now as the address type is changed, it will be reflected in your Order schema as well.

Another, perhaps more useful, example is adding additional context details to a schema.  Take, for example, the Order Schema created above.  If you wanted to add additional process context items you could wrap the order schema into another schema (call it: MyProcessOrder) where a child record node represents the Order and additional items are added as sibling nodes.  Using this method isolates your Order schema as the “Order entity” without poluting it with non-Order related attributes.

XSD Include – Batch Schemas

XSD Includes are slightly different from Imports in that the target namespaces of the schema and the included schema must match.  The primary use case I have used here is when creating envelope schemas used for debatching.  Continuing the above Order example, convert the Order schema to a ComplexType (using the Data Structure Type node) so it can be included in another schema.

Use the following steps to create an Orders schema containing one or more Order records:

  1. Create a new schema called Orders
  2. Ensure the target namespace of the Order and Orders schema are IDENTICAL
  3. Open the Imports collection (same as above) and now you can “XSD Include” the Order schema
  4. Now, add a child record and set it’s type to the OrderType created above

The following screen shots show including the Order schema into the Orders envelope schema:

XSD Include

XSD Include

And then creating the Order record …

Order Record

Order Record

Since this will be used for debatching, a few more properties need set at:

  • Envelope: Yes
  • Root Reference: Orders
  • On the Orders node, set the Body Xpath property to point to the Order node
  • On the Order node, set the maxOccurs to unbounded
XSD Redefine – Embrace and Extend

The XSD Redefine is probalby the least uses type of schema reuse for me as I genreally find myself using it to “hack” around another schema or trying to over-simplify something … and actually making it more cumbersome in the end.

An easy example of this is to take the AddressType above and create a new type from it to include some phone numbers:

  1. Create a new schema called AddressPhoneType
  2. Ensure the namespace on AddressPhoneType matches that of AddressType above
  3. As above, use the Imports property to “XSD Redefine” the Address schema
  4. Add a new child record and set its Data Structure Type property to AddressType (this is different from earlier where the Base Data Type property was used)
  5. Now, add a new Sequence Group to the new child record and customize!

The following screen shot depicts the AddressPhoneType schema:

XSD Redefine

XSD Redefine

Now you can change the Address schema without affecting other “consumers” of it.  Very useful if you want to embrace the re-usability of the Address type but not break aa bunch of other schemas which inherit it as well.

Now, with the above examples BizTalk developers can embrace re-usability in their BizTalk schemas along with other best practices!

Test Flight: Simplified Beta Deployments for iOS Apps

One of the more challenging things in creating iOS applications is the whole provisioning and deployment process.  This becomes especially true during beta testing of your application using Ad-Hoc distribution.

The process is something like this:

  1. Gather all the UDIDs from your test subjects
  2. Enter these into the iOS Provisioning Portal
  3. Create a distribution certificate (if you haven’t already)
  4. Create an Ad-Hoc provisioning profile
  5. Download the profile and certificate
  6. Configure and build your app signing with these credentials

Then, your testers need to get the application and install it.  Generally like this:

  1. Email the testers the provisioning profile and app bundle
  2. The tester need to drag both to iTunes (or Organizer) and then tether and sync

This makes it a little cumbersome for most testers and difficult for non-tech savvy users.  One could post the app bundle to a website with a manifest and then create a launch page (like an internal app store) and then notify the users.  This is where Test Flight ( comes in … managing the web-delivery of your application in a really easy-to-use process.

Remembering the above, now I do this:

  1. (optional) Ask your test users to register their devices
  2. (optional) Create a team out of these testers and download their device IDs
  3. (optional) Upload all of these device IDs at one time to the Provisioning Portal
  4. Follow the same process as above to create a provisioning profile and build
  5. Now upload the IPA bundle to Test Flight and I am done

At this point, the testers can receive a notification of the new build (and subsequent builds) and simply visit Test Flight on their device.  They will be able to install your beta app straight from the browser.  Further, I can report on who has installed the app and who has not.

All this and the website has a nice easy to use design on top of that!