Subscribe: Method ~ of ~ failed by Tim Heuer
http://feeds.feedburner.com/timheuer
Added By: Feedage Forager Feedage Grade B rated
Language: English
Tags:
app  file  library  location  phone  public double  public  set public  set  sqlite  string  update  windows phone  windows  xaml 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Method ~ of ~ failed by Tim Heuer

Tim Heuer's Blog



The web site and blog of Tim Heuer, Program Manager for Microsoft XAML and author of Callisto, a WinRT XAML Toolkit. A resource to learn how to develop software with XAML technologies. This blog provides information on how to get started with XAML, S



Copyright: Tim Heuer
 



Implementing a type converter in UWP XAML

Wed, 15 Feb 2017 22:04:24 GMT

Verbose XAML, we all love it right?  What?!  You don’t like writing massive amounts of angle brackets to get to define certain properties?  I mean who doesn’t love something like this: 47.669444 -122.123889 What’s not to love there?  Oh I suppose you prefer something like this? In the XAML dialect this is what we refer to as a ‘type converter’ or more affectionately at times ‘string to thing’ as the declarative markup is just a string representation of some structure.  In WPF and Silverlight this was implemented through requiring to use the System.ComponentModel.TypeConverter class model where you would attribute your class with a pointer to an implementation of TypeConverter that would override the common things you need, most of the time ConvertFrom capabilities. In UWP where we currently could not rely on the exact same implementation of System.ComponentModel.TypeConverter as it is not a part of the API exposure to UWP apps at this time as well as being a .NET concept which wouldn’t be available to other WinRT developers.  In looking at ways to achieve the same primary scenario, we can now look at the Creator’s Update to deliver the functionality for us.  In the markup compiler for Creator’s Update we now leverage the metadata CreateFromString attribute in WinRT to generate the correct metdata to do the conversion.  The responsibility lies in the owner of the class (looking at you ISVs as you update) to add this metadata capabilities. NOTE: To enable this capability, the consuming app must currently have minimum target to the Creator’s Update. Let’s use an example following my pseudo map control I used above.  Here is my class definition for my MyMap control using Windows.UI.Xaml.Controls; namespace CustomControlWithType { public class MyMap : Control { public MyMap() { this.DefaultStyleKey = typeof(MyMap); } public string MapTitle { get; set; } public Location CenterPoint { get; set; } } } Notice it has a Location type.  Here’s the definition of that type: using System; namespace CustomControlWithType { public class Location { public double Latitude { get; set; } public double Longitude { get; set; } public double Altitude { get; set; } } } Now without a type converter I can’t use the ‘string to thing’ concept in markup…I would have to use verbose markup.  Let’s change that and add an attribute to my Location class, and implement the conversion function: using System; namespace CustomControlWithType { [Windows.Foundation.Metadata.CreateFromString(MethodName = "CustomControlWithType.Location.ConvertToLatLong")] public class Location { public double Latitude { get; set; } public double Longitude { get; set; } public double Altitude { get; set; } public static Location ConvertToLatLong(string rawString) { string[] coords = rawString.Split(','); var position = new Location(); position.Latitude = Convert.ToDouble(coords[0]); position.Longitude = Convert.ToDouble(coords[1]); if (coords.Length > 2) { position.Altitude = Convert.ToDouble(coords[2]); } return position; } } } As you can see in the highlighted lines, I added two things.  First I added an attribute to my class to let it know that I have a CreateFromString method and then provided the fully qualified name to that method.  The second obvious thing is to implement that method.  It has to be a public static method and you can see my simple example here. Now when using the MyMap control I can specify the simpler markup: And the result would be converted and my contr[...]



Write your Amazon Alexa Skill using C# on AWS Lambda services

Sat, 24 May 2014 04:51:21 GMT

After a sick day a few weeks ago and writing my first Alexa Skill I’ve been pretty engaged with understanding this voice UI world with Amazon Echo, Google Home and others.  It’s pretty fun to use and as ‘new tech’ it is pretty fun to play around with.  Almost immediately after my skill was certified, I saw this come across my Twitter stream: You can now write your AWS Lambda functions in C#! #reInvent https://t.co/LDOK0S1VwF pic.twitter.com/FpRUODgucv— Amazon Web Services (@awscloud) December 1, 2016 I chuckled but I also knew that David and others were going to be the key to helping me find the fastest path here.  I started emails with the PCL team, including David and Daniel, who are incredibly knowledgeable and responsive.  I finally got most working and then my colleague and I started chatting about my frustrations.  He worked on XLinq for a bit and basically told me to suck it up and do the conversions and that it wasn’t that bad.  We walked through a few of the scenarios and indeed it really ended up all being isolated into one area that I could quickly scan through.  I could now remove my dependency on XmlDocument and have no other dependencies for this portable library. Hooray for helpful people!  Even when you vent, the good peeps will still help out! Changes to TagLib# for portability After the full conversion, a few things remain.  Right now I have #ifdef’d out come of the interfaces and attributes that weren’t working.  Once I get to a point of porting all the tests over, I’ll decide if they are even needed.  Perhaps the biggest change though for users of this lib will be the removal of the default string path of file access.  In discussing with some folks, I could have tried to make a portable storage layer work, but it started to make less sense quickly to do that in the library and leave that simple task to the app developer.  This provides flexibility for the app to do what they want without the library trying to work around how different platforms do their file IO routines.  What that means is that the default way of reading a file’s tags changes from: var tagFile = File.Create("ironlionzion.mp3"); var tags = tagFile.GetTag(TagTypes.Id3v2); string album = tags.Album; to ' file is a StorageFile var fileStream = await file.OpenStreamForReadAsync(); var tagFile = File.Create(new StreamFileAbstraction(file.Name, fileStream, fileStream)); var tags = tagFile.GetTag(TagTypes.Id3v2); string album = tags.Album; in a simple case.  Yes, you as the app author have to write a bit more code, but it puts you in control of ensuring the file location you are reading.  You can see here that I did add my StreamFileAbstraction class to my fork by default, which was the key in the Silverlight port and is actually the key for WinRT as well.  Any app developer can create their own IFileAbstraction implementation and substitute it in the ctor of the create functions and be ready to read.  I actually did this in the test project to re-implement a LocalFileAbstraction for test purposes and used the System.IO.File classes to achieve that, which are available when running VS unit tests. Summary What started out as a frustrating exercise turned out to be helpful for me to better understand PCLs and hopefully add value to those who have been asking for this.  As mentioned, this isn’t fully tested and still a ways to go, so if you use it please log bugs (and help fix them) to complete the implementation.  I won’t be working on this full time of course, but do hope to get the test suite ported over as well.  Here are some relevant links: TagLib.Portable – source code repository for my fork TagLib.Portable NuGet Package Hope this helps! tags: taglib, id3, pcl, winrt, wpdev, silverlight, mp3This work is licensed under a Creative Commons Attribution By license.[...]



Using SDK/library references in Universal Windows Apps

Thu, 17 Apr 2014 21:43:23 GMT

I’m just coming back from Build 2014 and it was a great pleasure to talk to customers/developers.  It is one of the best parts of my job right now in seeing how customers use the technology our team represents.  If you are a XAML developer and didn’t have a chance to go to Build or haven’t watched all the sessions, here’s a quick short list of recommendations I’d have: Common XAML UI Platform overview (Tim Heuer) XAML UI Controls (Shawn Oster) Developing across multiple form factors (Peter Torr) What’s new with Windows Phone Silverlight apps (Sam Jarawan and Harini Kannan) Using VS to build universal Windows apps (Navit Saxena) There are many more (app model, localization, accessibility, tiles, notifications, etc.) so please do look at the event site and download/watch your favorites.  I think the list above gives you a good intro to the UI area changes and introduction to the concepts of Universal Windows apps.  If you haven’t heard of that concept yet, you can jump to the Keynote from Day 1 for the quick demo. Add Reference The last session above is one that I want to write about today in this post.  In current form, a Universal Windows app in Visual Studio Update 2 allows you to maximize your sharing of code/assets across your Windows Store and Windows Phone app.  If you are like most developers, you rely on a great ecosystem of libraries and SDKs to augment your app and add functionality, UI or make things easier to develop.  In our keynote sample, the app we migrated (SportsLeague app) used JSON.NET and we showed that we are able to re-use the same library (which in this case happened to be a Portable Class Library, aka PCL) across the different endpoints. One thing that is important is that you will need to add these references to each of your project ‘heads’ (the term we use to describe each endpoint in a shared project solution).  For some that are using direct binary DLL references to PCL libraries should be okay.  For others that are using Extension SDKs and/or NuGet packages, you may find yourself into some scenarios where either the SDK is different or the NuGet package isn’t updated yet to understand the Windows Phone 8.1 project type.  There are a number of these that are already updated like JSON.NET, Caliburn.Micro, etc.  If you find yourself using a library that isn’t updated yet, you may want/need to prod the author to update.  Better yet, if it is Open Source, submit a pull request with the update yourself! SQLite or other native Extension SDKs The other category are things that might be platform-specific and/or native.  These things are generally more complex than something that might work in a PCL and have dependencies on various native compiler/linker options or have been compiled in such a way that are different for the Phone device versus a tablet device.  One such example is SQLite. SQLite is an in-process library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine. The code for SQLite is in the public domain and is thus free for use for any purpose, commercial or private. SQLite is currently found in more applications than we can count, including several high-profile projects. SQLite links against the C++ Runtime and as such needs to make sure the right linking happens for the phone and tablet CRT profiles.  Right now, the SQLite for Windows Phone Runtime 8.1 is in some testing, but since a lot of people have been asking me about it, I’ll share my private build from source of the SDK.  This comes with a “works on my machine” guarantee :-).  This is a build of SQLite from their source, which is Open Source, and modified to compile/link against the Windows Phone 8.1 SDK.  When the official version comes out you should update to that version from their site.  For now, you can download my build of  UPDATE (12-MAY-2014): SQLite team put out their official build for Windows Phone 8.1: SQLite for Windows Phone 8.1 her[...]