However, you DO get a ‘Share’ option called ‘People’ – if you click that, then ‘Connect to Facebook’ is an option.

EVERY time I tried to ‘Connect to Facebook’ from the People app, I got the message “We can not connect to the service you need right now. Please check your network settings or try again later.” You may get similar or other errors when trying to connect Twitter or Google accounts in the same fashion.

The fix (at least for me) was to go to https://profile.live.com/services and authorize the Facebook/Twitter/Google connections from there first.

“Unable to process application Info.plist validation at this time due to a general error ”

Well after redoing my Info.plist twice from scratch, one line at a time, and watching it break eventually after adding all required parts, I finally found some current threads by other people exhibiting the exact same issue, as well as periodic similar issues over the last few years. So I slept on it, and tonight, the package submitted successfully right away. All is right with the world.

When porting mobile apps to Windows 8, I immediately came across the same issue as each of the previous platforms, namely, how to copy my ‘starting’ data files into local storage where they can be modified.

In this case, I have a file in my Assets folder called ‘Prayers.xml’. At application startup I want to verify if the file already exists in the local store – if not, copy it from the Assets folder in the installation directory.

This is how you end up handling it in Windows 8.

        async void CopyPrayerFile()
        {
            //get the storage for your app 
            Windows.Storage.StorageFolder store = Windows.Storage.ApplicationData.Current.LocalFolder;
            StorageFile prayerFile = null;
            try
            {
                prayerFile = await store.GetFileAsync("Prayers.xml");
            }
            catch (System.IO.FileNotFoundException)
            {}

            if (prayerFile == null)
            {
                //get the file from Assets

                StorageFolder install = Windows.ApplicationModel.Package.Current.InstalledLocation;
                StorageFile installFile = await install.GetFileAsync("Assets\Prayers.xml");

                installFile.CopyAsync(store);   
            }
        }

So it’s been a while now since I first purchased MonoTouch, waaaay back in the Novell days. I wanted to do some iOS development, but my daily driver is C#, and it seemed like a great onramp to iOS development.

Now, with Xamarin fully owning the MonoTouch bits, it’s 100 times better and more polished, so much so that I’ll probably never bother touching XCode in any significant fashion. I know it’s lazy, but I’m lazy. Well, lazy in an ‘efficient’ way, not lazy in a ‘slacker’ way. Why bother with yet another language and IDE if I can accomplish the same thing using tools similar to what I already use full-time?

I got an email FROM Xamarin the other day saying something like “Hey Apple changed some of the calls that used to be unrestricted to now be privileged calls, so if you are using X in your app, (in my case Console.Write for debugging messages) your app will crash with iOS 5.1.” … followed by “if you download the latest MonoTouch and recompile this will be fixed”.

So something that would have probably required me to change some code had I been doing the same thing in XCode  was reduced to downloading a MonoTouch update, recompiling, and submitting the updated App to the App Store. I’ll take that any day.

I <3 Xamarin.

So I logged in to my Android Market publisher account, because it’s been a while, and I’m thinking of updating some apps, and trying again to see if I can reproduce some of the fairly major (I admit it) bugs that keep getting reported that I just can’t track down…and lo and behold, there’s a new developer agreement. Normally, like most of the world’s population, I just scroll down and click ‘accept’ these agreements. For some reason this time, I decided to read it first.

Following are a list of concerns that struck me on reviewing this thing…

***SPOILER – I still accepted it – what choice do I really have?****

***DISCLAIMER – I am a pure hobbyist. Yes my personal apps are not polished, and I have nowhere near the appropriate level of QA resources to ship bug-free. The products work on my hardware, and any bugs I have been able to reproduce DO get fixed in my limited time.

3.2 Developer is responsible for determining if a Product is taxable and the applicable tax rate for the Payment Processor to collect for each taxing jurisdiction where Products are sold. Developer is responsible for remitting taxes to the appropriate taxing authority.

• Did I, as a hobbyist selling apps through a required Google-authorized payment processor, just have said payment processor abdicate all responsibility of tax collection and remittance? Isn’t that much more suited to what a payment processor DOES? And now any taxes (even if there aren’t any NOW) that come up in the future, all come directly out of MY share.

3.5 Except in cases when multiple disputes are initiated by a user with abnormal dispute history, billing disputes received by Payment Processor for Products sold for less than $10 may be automatically charged back to the Developer, in addition to any handling fees charged by the Payment Processor. Chargeback requests for Products $10 or more will be handled in accordance with the Payment Processor’s standard policy. 

• In my opinion, chargebacks are the WORST part of this whole business for a hobbyist developer. This policy has bounced back and forth a few times at Google, but now it seems that they are landing directly in the camp of “Developer pays all chargeback fees”. In case you’re not familiar, a chargeback is when someone uses a credit card to buy a $.99 app, then decides to dispute the charges on the credit card. So I don’t get paid my $.99, and guess what, I also get dinged a $10 ‘chargeback fee’ by Google Checkout – and I just personally lost $10 on a $.99 sale.

• This ALONE is very close to enough for me to immediately take any non-free apps off the android market, just because some competing schmuck could decide to have all his buddies buy my app, give it a crappy rating, and then do chargebacks and cost me money directly. Unlikely? Sure. But absolutely possible.

• How about this scenario? I can only test on the ONE Android device I own. According to the bug reports, there are people that the app crashes for, but I CANNOT PERSONALLY reproduce the issue, and I have no idea what hardware they are running. I have limited time and resources for this hobby, and if it crashes when you install it, PLEASE just get the 15-minute refund. But, suppose instead the user gets frustrated (totally understandable), and instead of just trying to get a refund, disputes the credit card charge. BAM.

• The $10 price point is just Google thumbing their nose at Android developers. How many Android apps have you bought that have a price > $10? The OLD policy was that if the CHARGEBACK total amount was < $10, Google would NOT pass it back to the developer. Now, it says the developer gets it AUTOMATICALLY, unless the SALE price is > $10.

• I’m sure somebody is probably thinking ‘GREAT, this will get all those useless apps off the Marketplace’ but to me it’s pretty shoddy behavior. If you want to curate the marketplace, then do it.

4.9 Your Products may be subject to user ratings to which you may not agree. You may contact Google if you have any questions or concerns regarding such ratings.

• Translation: If someone decides to post a completely idiotic review (happens ALL the time) there is NOTHING you can do about it. If it’s egregious enough, and you happen to make us a lot of money, we might pursue it, but if you are making that much money, your legit-to-idiot rating ratio is probably not that bad so you’re not as concerned as an indie who is throwing out some proof-of-concept utility apps and getting trashed by folks who want an entire mini-Microsoft Office suite for free.

• No clear, defined policy for trash reviews is a big failure here IMHO.

At this point I kind of just sighed and scrolled down the rest of the text.

“Accept”. Click.

I thought I would take this opportunity to inform the world that, yes, I have relicensed MonoTouch [now by XAMARIN!] after a brief foray into Objective-C. MonoTouch is far too nice a crutch to give up now, especially given that I am developing on Android and Windows Phone as well, and just don’t have the time or patience to step back into the land of pointers and such.

In related news, I also updated my Mac Mini to Lion. And it immediately blew up my finely-tuned Vine Server VNC setup (the mac mini is hidden away on a shelf somewhere, and I access it only via VNC). But, soon after, I figured out ‘Screen Sharing’ at least and am up and running again. [No, I am /not/ a 'Mac' person].

MonoDevelop and MonoTouch have come a long way just in the last several months – I’m feeling motivated to put out some fresh iOS 5 updates!

For the Word version, with some extra pictures and nicer formatting, see here

Generating BizTalk Messages from Dynamics CRM

Otherwise, here’s the quick copy/paste version. Enjoy.

BizTalk – Generating Outbound Messages from Dynamics CRM

[Author’s Note]: Please don’t judge me solely on the quality of this particular post. I’m trying to help someone out by posting this, and as a result I am rushing it far too quickly.

There are several ways you could approach this process, and depending on the requirements, your mileage may vary. In this particular post I’d like to outline one method I have found effective, which is to leverage CRM plugins to do the heavy lifting, and utilize BizTalk purely as a message routing mechanism via receive & send ports. If I were a ‘full-time’ BizTalk expert, it’s entirely likely I would be more comfortable letting more of the logic reside inside BizTalk (complex mappings, orchestrations, etc.) but I have found personally it is far easier FOR ME to keep the BizTalk side very simple and straightforward using simplified custom schemas and routing mechanisms in BizTalk, and leverage .NET to populate the BizTalk-compliant schema objects inside of CRM.

This example is based on a 4.0 implementation so any code snippets you see may not be up-to-date for CRM 2011, but the concepts are exactly the same.

1. Utilize your existing (or new) custom BizTalk schemas

In your BizTalk project, you will have various schemas (.xsd) that you want to populate from CRM. For this example consider two schemas in our BizTalk project/application that we want to populate and send to BizTalk from CRM plugins – Account and Contact. These custom schemas containing the general fields we are interested in, with whatever data types we choose (irrelevant of CRM, we will have to translate/map them as necessary later in the plugin), are built/defined within a BizTalk project and are deployed to our chosen BizTalk application (beyond the scope of this example)

1. Define the plugin component

The next thing we will do is create a ‘BizTalk Plugin’ that will do all the heavy lifting of populating and sending our BizTalk messages, and use our source control provider of choice to ‘share’ the schemas that we want to expose in the plugin from the BizTalk project. This will give us the hook to be able to refresh our plugin if the BizTalk Schema changes.

So, under our BizTalk Plugin source code, we might have a folder structure something like below:

SchemaBuilders: This is the set of classes containing logic that handles the population of the schema classes from CRM data. Each BizTalk schema you generate a class file for will have a corresponding ‘SchemaBuilder’ responsible for populating that schema with CRM data properly when passed the entity context. The schema builders leverage the generated schema classes by mapping and assigning properties from the entity context and returning a ‘populated’ schema class to be sent to BizTalk.

Here is a snippet of the kind of code that would be inside the schema builder’s primary method ‘BuildSchemaObject’:

//name fields

//Salutation

contactSchema.Contact_Detail.Name_Complete.Name_Salutation = contact[‘salutation’];

//first name

contactSchema.Contact_Detail.Name_Complete.First_Name = contact[‘firstname’];

//last name

contactSchema.Contact_Detail.Name_Complete.Last_Name = contact[‘lastname’];

Note that the left hand side corresponds to properties in the schema class, and the right hand side represents data in the triggering entity. We are just mapping one to the other.

Schemas: This folder contains the generated .cs files for each linked .xsd ‘source’ schema from the BizTalk project. In this case you see the BizTalk schemas under ‘SourceFiles/CRM Outbound’ and the generated .cs files CRM_Account.cs and CRM_Contact.cs in the root of ‘Schemas’.

GenerateClasses.bat: This file is a simple batch script that uses xsd.exe to regenerate the .cs files if the schema files change. When the underlying BizTalk project schemas are modified, you need to ‘get latest’ from those shared source schema files in the plugin, then use the batch script to regenerate the .cs files, and make any required logic changes to the logic and schemabuilder files. Each line of the batch script will look something like:

xsd.exe -c -n:CRM.Plugins.Schemas.CRM_Account -l:c# “CRM Outbound\CRM_Account.xsd” /outputdir:../

where CRM.Plugins.Schemas.CRM_Account is the desired namespace of the generated class, c# is the desired language of the class file, ‘CRM Outbound\CRM_Account.xsd’ is the relative path of the schema file, and the parent folder of the batch file location (../) is the desired output location for CRM_Account.cs

Plugin.cs: The main body of the plugin now simply implements branching logic to determine what the triggering entity is, and based on the triggering entity, invoke the appropriate schema builder and send the result to biztalk. [In this example, ‘send to Biztalk’ means pushing an XML message into an MSMQ queue that BizTalk has been configured to monitor]

//Based on the entity that is triggering the plugin, we will need to generate different

//BizTalk messages. This switch statement allows us to branch to the appropriate Builder

//based on the triggering entity.

switch (this.EntityName)

    {

        case “contact”:

        //Step 1: Contact message

        //create the Schema Object and populate it

        Schemas.CRM_Contact.Contact_Information contactObject = Builder_CRM_Contact.BuildSchemaObject(this,context);

        sendToBizTalk(BuildSchemaXml(contactObject));

                  …

Helpful Tricks:

I borrowed most of these from a series of blogs and trial and error – apologies to anyone I am referencing without attribution, any links I used are long lost to me

• BuildSchemaXml method – BizTalk is extra-picky about namespaces in your xml. As it should be. In order to serialize our populated schema classes properly to put the message in MSMQ, we found the following approach very VERY helpful when turning the schema class into an XML string to be pushed to MSMQ.

/// <summary>

/// Handles the serialization of our schema classes to the underlying xml text for transmission to BizTalk

/// We use this to modify a couple of the default behaviors of the schemas with respect to serialization

/// </summary>

/// <param name=”schemaObject”>The populated schema class we wish to serialize</param>

/// <returns></returns>

public string BuildSchemaXml(Object schemaObject)

{

    StringWriter output = new StringWriter(new StringBuilder());

    //Create our own namespaces for the output

    XmlSerializerNamespaces ns = new XmlSerializerNamespaces();

    //Add an empty namespace and empty value

    ns.Add(“”, “”);

    //Serialize the object with our own namespaces (notice the overload)

    XmlSerializer serializer = new XmlSerializer(schemaObject.GetType());

    //we use this to extract some of the header data we don’t want to be serialized.

    XmlWriter writer = new XmlTextWriterFormattedNoDeclaration(output);

    serializer.Serialize(writer, schemaObject, ns);

    return output.ToString();

}

• XmlTextWriterFormattedNoDeclaration class: This goes along with the BuildSchemaXml serialization method to suppress all the ‘stuff’ that typically gets written into the serialized xml and helps the schemas be recognizable to BizTalk.

    /// <summary>

    /// This is a special custom override class to assist with the formatting of the serialized xml going to BizTalk

    /// Specifically, to eliminate header/namespace overhead in the message body.

    /// </summary>

    public class XmlTextWriterFormattedNoDeclaration : System.Xml.XmlTextWriter

    {

        /// <summary>

        /// Constructor

        /// </summary>

        /// <param name=”w”></param>

        public XmlTextWriterFormattedNoDeclaration(System.IO.TextWriter w)

            : base(w)

        {

            Formatting = System.Xml.Formatting.Indented;

        }

        /// <summary>

        /// Do Nothing (instead of the default behavior)

        /// </summary>

        public override void WriteStartDocument() { } // suppress

    }

• SendToBizTalk method (MSMQ-based) – this is what pushes the serialized xml generated from our populated schema class into a message and drops it into a monitored MSMQ queue, where BizTalk can now pick it up, see it as a recognized schema, and process it accordingly within BizTalk. Don’t be frightened if you manually look at the message from within the MSMQ queue and the content appears to be a foreign language, that is a side effect of BodyType = 8, but that’s what we had to do in order to make things align.

void sendToBizTalk(string serializedXml)

{

   try

   {

       //declare a new message queue object pointing to our configured queue

       MessageQueue crmBTMQ = new MessageQueue(QueuePath);

       //since we are writing our own message content, we need to use a message

       Message crmXmlMessage = new Message();

       //to avoid re-formatting our nice xml message, we write directly to the bodystream of the message

       crmXmlMessage.BodyStream = new MemoryStream(Encoding.UTF8.GetBytes(serializedXml));

       //and tell the message it’s content is a string

       crmXmlMessage.BodyType = 8;

       //now send the message to the configured queue where biztalk will soon go and grab it.

       crmBTMQ.Send(crmXmlMessage);

                …

I know this may seem woefully inadequate, but hopefully it will help point someone in the right direction and avoid some of the issues that we had to work through the first time.

Are spent waiting for mobile application marketplaces to process…

Full disclosure, I submitted an app to the WP7 marketplace that had a fairly glaring bug, that I myself never came across. This is all my own fault at the core.

So I noticed today that I have negative ratings piling up due to said bug, and can’t do anything about it because there is a whole submission process that takes a few days to clear. I decide to try to change the metadata to at least tell potential new users that it’s being worked on and how to workaround the issue…but there is a ‘mini-approval’ process for even the metadata change. DOH.

So now I have FIXED said bug, but I can’t submit the actual update to the application (which will take a few days to process) until my METADATA update gets approved!

Honestly, it’s not that big a deal, but I wish there could be more real-time editing of metadata (app description, etc) – but I can also accept that someone has to review it…maybe they could implement some kind of random peer review for pure metadata changes.

Score one for Android, where I can modify both metadata AND deploy new versions of the application INSTANTLY. I have become a spoiled mobile developer due to their instant gratification.