Microsoft’s patterns & practices group has put together some mighty fine guidance for Azure. Enjoy!
A client recently (as in a couple of minutes ago) asked me about resources for building apps on the Universal Windows Platform. For your reading pleasure, here’s the list I quickly compiled (thank you BING):
Windows Dev Center: https://dev.windows.com/en-us/
Get started with Windows apps: https://dev.windows.com/en-us/getstarted
UWP platform guide: https://msdn.microsoft.com/library/windows/apps/dn894631.aspx
Microsoft Virtual Academy free training on mobile development: http://www.microsoftvirtualacademy.com/training-topics/mobile-app-development
UWP code samples: https://dev.windows.com/en-us/samples
Dev Center developer programs: https://dev.windows.com/en-us/programs
How-to guides for Windows 10 apps: https://msdn.microsoft.com/library/windows/apps/xaml/mt244352.aspx
Move from iOS to UWP: https://msdn.microsoft.com/en-us/library/windows/apps/xaml/mt238320.aspx
I’ve been working with Xamarin.iOS for Visual Studio for a while now, and I’ve always wondered what the “Identifier” field really does. I heard something about using reverse domain name naming convention, but didn’t know why. Not having an iOS device, I’ve always tested on the iOS simulator, and I’d make up some random Identifier, such as “com.foo.bar”. The simulator didn’t complain, so I carried on in ignorance.
(Even though I simply made up an Identifier, while working in VS 2012 with Xamarin.iOS I quickly learned to always populate that field, plus the Application name and Version fields. If they’re empty when you send the app to the simulator, the simulator will barf all over you. Then you’ll have to dig around in Finder to weed out the bad app from the simulator folder structure. Ick. Nice recent update with Xamarin.iOS — it now will give a compiler error if those fields are empty when you build. Thanks, Xamarin!)
I found out this evening while digging around that the Identifier field is important when you want to test your app on a physical device, or want to publish the app to the App Store.
To use a physical device or publish to the App Store, you have to register an app profile in the Apple Developer site and download / install the profile on the Mac that has the Xamarin Build Host and Xcode. There are 2 ways to go when creating an app profile – one is explicit, defining the app name you’re going to use; the other is “wildcard” which allows you to use a single app ID to match multiple apps.
I create lots of demo apps, so I chose to go with a wildcard app id. That way I don’t have to create a new profile for each and every app I want to demo on a device. I created the app ID using the domain I own, as “com.snowstormlife.*” which allows me to use “com.snowstormlife” followed by any app name I want to give an app.
The Xamarin site has a pretty good set of instructions about all this here: http://docs.xamarin.com/guides/ios/getting_started/device_provisioning/
Note that if you’re simply going to use the simulator instead of a device, it doesn’t really matter what you use in the Identifier property. It’s only important when you’re sending to the physical world or the app store.
Happy cross-platform coding,
Here are some notes about downloading and setting up Xamarin’s Field Service sample app in Visual Studio. (It’s one of Xamarin’s cross platform sample apps. It includes a project for WinRT, iOS, Android, all of which leverage the same core set of business logic.)
I assume you already have Visual Studio 2012 and Xamarin installed on your Windows 8 dev box (and Xamarin on a Mac if you’re going to build / run the app on an IOS simulator).
Download Xamarin’s prebuilt apps from their public git repository
c:\repos> git clone https://github.com/xamarin/prebuilt-apps.git xamarinPrebuilt
Also download SQLite-net from their public repo
c:\repos\xamarinPrebuilt\fieldservice\dependencies\sqlite-net> git clone https://github.com/praeclarum/sqlite-net.git
Open the VS version of the Field Service solution (FieldService.VisualStudio.sln).
Set the WinRT project as the startup project.
Build and deploy the app and kick the tires.
Looks nice, eh?
You’ll have to manually add the IOS project to the FieldService solution. (Not sure why it wasn’t already a part of the solution, but it’s easy to add.)
If it’s not open already, open the Field Service solution (FieldService.VisualStudio.sln)
Add the FieldService.IOS project to the solution
Add the Bing Maps SDK for Windows RT via NuGet
Before you run the IOS version in the simulator, be sure to enter something in the IOS project’s properties for application name, identifier, and version. Otherwise the simulator may go crazy.
Set the IOS project as the startup project
Debug toolbar should have Debug, iPhoneSimulator, iPad 6.1
Yep. It really works. C# and Visual Studio for Windows 8, IOS, and Android.
Handy reference for the IOS Simulator gestures:
As I step out onto the docks and smell the salty air, hear the tapping of halyards on masts, the rest of the world eases away. I am at peace and breath deeply.