This project has moved. For the latest updates, please go here.
 Peter Foot News Feed 
Thursday, February 6, 2014  |  From Peter Foot


I came across this issue with a test app which had been working fine either when debugging
or deploying the XAP file directly. Then I set up a beta and when installed the app
just starts and immediately stops. Since it took me some time to try a few things
to identify the issue I thought I’d share it here. The problem was that the app uses
a background task. The Agent is added to the solution using the project template,
added as a reference in the application project and the code to schedule the task
is set up in App.xaml.cs. As I discovered I had neglected to add in the ExtendedTask
element to my WMAppManifest.xml. Presumably as the .dll was not specified here it
was not being correctly signed as part of the store ingestion and so the published
beta app was in a broken state. Here is what the entry should look like. Remember
you can’t set this through the GUI you have to view the raw XML file and make edits
there:-



<Tasks>


      <DefaultTask Name="_default" NavigationPage="MainPage.xaml">


      </DefaultTask>


      <ExtendedTask Name="BackgroundTask">


        <BackgroundServiceAgent Specifier="ScheduledTaskAgent"
Name="MyAgent" Source="MyAgent" Type="MyAgent.ScheduledAgent"/>


      </ExtendedTask>


    </Tasks>





Please change your news reader to use http://feeds.feedburner.com/peterfoot.

Tuesday, February 4, 2014  |  From Peter Foot


The latest addition to the “Build Charming Apps for Windows Phone” libraries addresses
a couple of properties required to support different screen sizes. I decided I wanted
a simple way to retrieve the DPI and Scale factor (real not emulated) while working
smoothly on devices prior to GDR3 where 1080p support was added. The result is a single
class – DisplayInformation which (true to theme) follows the Windows 8.1 object model.



Some of the properties found in the desktop implementation make no sense – there isn’t
support for Stereoscopic output for example. So just three properties are exposed
– RawDpiX, RawDpiY and ResolutionScale. One additional member is added to the ResolutionScale
enumeration as desktop Windows has no concept of 2.25 scale factor but this is used
for 1080p Windows Phone devices. It’s not always possible to provide a perfect API
match to the desktop and this seemed like a good workaround. These will call into
the extended properties in GDR3 where possible but will equally work correctly on
older devices.



The library is up on NuGet here.





Please change your news reader to use http://feeds.feedburner.com/peterfoot.

Friday, January 10, 2014  |  From Peter Foot


Windows Phone developers have received an email about the upcoming changes to make
mobile operator billing available in more countries. In particular markets from March
2014 this means that there will be an additional deduction from your revenue for these
specific markets when mobile billing is used (not for continued credit/debit card
purchases). The markets in question are:-



Argentina, Chile, Colombia, Cost Rica, Malaysia, Mexico, Peru, South Africa.



For these purchases Microsoft will take an additional 13.9% of the receipt to cover
processing costs leaving you with 56.1% of the "list price" rather than
the usual 70%. A suggestion on Microsoft's "Define
pricing and market selection
" page is to adjust the price for these markets,
but then you'll be penalising the end users and the increased price might deter customers.
Hopefully the potential increase in sales from these markets will show that 56.1%
of something is better than 70% of nothing and overall developers will see a benefit
from reaching these markets.





Please change your news reader to use http://feeds.feedburner.com/peterfoot.

Friday, January 10, 2014  |  From Peter Foot





As part of the New Year tidy up I decided to add a wireless charging pad to my desk
so that I can easily top up devices without too many trailing wires. I saw the new
second generation DT-601 and thought it looked perfect - smaller than the original
pad and with a USB interface which can go into a powered hub or optionally its own
a/c adaptor. I picked the red one expecting bright post office red from the pictures
but on the packaging it is described as neon red. Personally I would describe it as
"Radioactive Salmon", it has certainly brightened up my desk!






I plugged it in and tried a couple of devices on it and it was straight-forward to
use. I have a 1020 with charging shell and this one was odd because you have to put
the phone onto the round pad so the camera bezel sits on the edge of the pad so it's
not quite flat. This feels wrong but works fine - I guess the 1020 was always going
to be a special case because of its unusually shaped derriere. If you have multiple
devices you have to get used to where the charging point is as they seem to vary a
bit. Keeping moving the phone around until you see that it is charging. I don't have
anything which supports QI charging which isn't a Nokia phone but it should support
any QI compatible device.





Please change your news reader to use http://feeds.feedburner.com/peterfoot.

Monday, December 30, 2013  |  From Peter Foot


In the latest update to the Windows Phone Tasks app I’ve added in some API features
for other apps to hook into. This is facilitated by Windows Phone 8’s support for
custom Uri schemes – the app supports the tasks: scheme and allows you to do a couple
of useful things with it. You can use it both to launch the app and also to pre-populate
the New Task dialog. This allows the user to save a new Task as they can a Calendar
event or Contact from your app. Full details on the Uri scheme are maintained here:-



http://appamundi.uservoice.com/knowledgebase/articles/299428



In addition to this and following the example of Nokia, I’ve created an API library
for Windows Phone which is available
now on NuGet
. This simplifies the creation of a new Task by providing a SaveTodoTask which
has a model which should be instantly familiar to any Windows Phone developer. I chose
to name this SaveTodoTask rather than SaveTaskTask as that sounded clunky and task
items are interchangeably known as to-dos as well.



This functionality follows swiftly on the heels of the 1.80 release which added a
New Task optional start tile as a short-cut to this functionality. 1.81 also includes
numerous bug fixes and sync improvements along with support for Lock Screen notifications.



If you have feedback for the Tasks app remember you can submit it to our
Uservoice site
which will help us plan future updates.





Please change your news reader to use http://feeds.feedburner.com/peterfoot.

Sunday, December 22, 2013  |  From Peter Foot


Using the Windows Phone SDK the only method to return a list of your other published
apps (e.g. for your About page) is to use the MarketplaceSearchTask and specify your
company name in the search criteria. The problem with this is that it doesn’t return
the actual publisher list but does a keyword search so you may find that a few other
apps appear if other devs have used your company name in their descriptions or keywords.



The solution is to use a Uri and the LaunchUriAsync method in Windows Phone 8. The
zune (yes it’s a throwback from the olden days) Uri scheme includes the ability to
specify a publisher name e.g.




Windows.System.Launcher.LaunchUriAsync(new Uri("zune:search?publisher=APPA Mundi
Ltd"));



In case you don’t want to hard-code your publisher name (to create a shared component
for example) you can add this from the metadata of your app using Charming
ApplicationModel
e.g.




Windows.System.Launcher.LaunchUriAsync(new Uri("zune:search?publisher="
+ InTheHand.ApplicationModel.Package.Current.PublisherDisplayName));



The equivalent functionality in Windows 8 is implemented through the ms-windows-store
Uri scheme:-




ms-windows-store:Publisher?name=APPA%20Mundi%20Ltd



or again using package information:-




Windows.System.Launcher.LaunchUriAsync(new Uri("ms-windows-store:Publisher?name="
+ Windows.ApplicationModel.Package.Current.PublisherDisplayName));




Please change your news reader to use http://feeds.feedburner.com/peterfoot.

Friday, December 6, 2013  |  From Peter Foot


There are a number of steps when translating a Windows Phone app. Hopefully
you are using the Microsoft Multilingual App Toolkit (http://msdn.microsoft.com/en-us/windows/apps/bg127574)
which supports the standard XLIFF format. Often you will start with your own language
string resources and then add other languages, possibly first with machine translation
and then passing them to a native speaker to correct. Since Windows Phone (and Windows
8) adopt quite an informal conversational style it is likely that colloquialisms will
enter your text which won't necessarily translate literally. Also there will be times
when you want to use a phrase for a system feature or action where there are existing
strings which appear throughout the system. You'll want to match these to avoid confusing
the user. Take for example "Pin to Start" - if translated literally it would imply
that you must use a pin to start some action (e.g. French "broche pour commencer"),
when actually you want to place a link on your start screen, the OS uses the following
string "épingler sur l'écran d'accueil". The good news is all of these
are available publicly for all of the supported Windows Phone languages. The Microsoft
Languages site (http://www.microsoft.com/language)
has a search tool which allows you to look up phrases for particular products and
in specific languages. For example a deep link to the "pin to Start" string would
be:-



http://www.microsoft.com/Language/en-US/Search.aspx?sString=pin+to+start&langID=fr-fr



Don't be surprised if the search returns multiple identical matches, I've noticed
this happens frequently. An example of where I used this was in my NFC Share Task.
In order to be instantly familiar I wanted exactly the same text and appearance as
activating the feature from built in apps, and I wouldn't be able to call on native
speakers from every possible language for Windows Phone 8. You get the advantage here
of Microsoft's own user testing and provide consistent wording to features the user
will already be familiar with.





Please change your news reader to use http://feeds.feedburner.com/peterfoot.

Tuesday, December 3, 2013  |  From Peter Foot


In Windows Phone we have a number of Launchers and Choosers for interacting with system
features. For the most part the approach used in Windows Store is to use special URI
schemes to achieve the same end result and launch platform features. I've collated
together a list below of some known ones. Some like maps are documented in detail,
others not. All can be launched with Windows.System.Launcher.LaunchUriAsync() (which
also exists in Windows Phone 8 for launching other apps via a uri).



 



ms-windows-store: - Windows Store "Hub"



ms-windows-store:PDP?PFN={your package family name} - App detail page. Get your PFN
from Windows.ApplicationModel.Package.Current.Id.FamilyName



ms-windows-store:REVIEW?PFN={your package family name} - Write a review page



ms-windows-store:Search?query={query term} -Remember to URI escape your query term
text



 



xboxgames: - launches the games hub



 



The following launch Microsoft/Bing apps (if installed)



bingfinance: - Finance



bingfoodanddrink: - Food & Drink



binghealthnfitness: - Health & Fitness



bingmaps: - Maps. Full details here:- http://msdn.microsoft.com/en-us/library/windows/apps/jj635237.aspx



bingnews: - News



bingsports: - Sports



bingtravel: - Travel



bingweather: - Weather



microsoftmusic: - Music



microsoftvideo: - Video



ms-mail: - Mail



windowsreadinglist: - Reading List



wlcalendar: - Calendar



wlpeople: - People



xboxsmartglass: - Smart Glass



 



Jumping back to the first set which cover the Store. In order to make these simpler
to call and help with porting existing code from Windows Phone I've added a new library
to the Charming suite. This is the first library to go the other way - provide a phone
style API for Windows Store.



https://www.nuget.org/packages/InTheHand.Phone.Tasks.RT/



This library provides the MarketplaceHubTask, MarketplaceDetailTask and MarketplaceSearchTask
which we know and love from Windows Phone and launches the equivalent functionality
on Windows. The key differences beside the namespaces are that the content identifier
for the MarketplaceDetailTask is a Package Family Name and there is no ContentType
property to distinguish between apps, games and music. For the purposes of Windows
Store all apps and games are treated the same and there is no music in the Windows
Store. Code and documentation will be updated on the CodePlex site shortly though
if you've used these features under Windows Phone you already know how to use it!





Please change your news reader to use http://feeds.feedburner.com/peterfoot.

Monday, November 11, 2013  |  From Peter Foot


The Windows Simulator is a deployment target for Visual Studio which allows you to
run your Windows Store apps in a simulated device. This allows you to test touch interaction
and different screen sizes and orientations on your development machine. The way this
works is that it creates a Remote Desktop session into your PC. This is why when you
run it you'll see your own start screen and user account. The problem with this is
that some APIs fail on the simulator such as setting up a Push Notification channel.
We need a way to detect if we are running in the simulator so that we can react accordingly.
If you try to poke around for hardware information you'll find it returns the same
as running directly on your machine. This makes sense when you know it's a Remote
Desktop session. Luckily there is an API specifically designed for this scenario:-



bool isRemote = Windows.System.RemoteDesktop.InteractiveSession.IsRemote;



This will return true in a Simulator session. We can use this to avoid calling any
code which will fail on the simulator and can easily switch between local machine and
simulator deployment to test various aspects of the app without touching the code
or using different project configurations and conditional compilation.





Please change your news reader to use http://feeds.feedburner.com/peterfoot.

Wednesday, November 6, 2013  |  From Peter Foot


A tweet by @martinsuchan earlier reminded me of an issue I faced porting some code
from Windows Phone to Windows Store. Moving from the Isolated Storage API to the new
Windows.Storage namespace there was nothing built-in to determine if a file/folder
exists prior to Windows 8.1. This meant the only supported option was to try and access
the file and catch an exception. This is in itself horrible but even worse if you're
trying to use the same code on Windows Phone and Windows 8, because these exceptions
have an even worse impact on the phone. My solution was to create an extension method
for StorageFolder which would use the Isolated Storage API under the hood to call
FileExists() or DirectoryExists() on Windows Phone and only the try/catch method when
compiled on Windows 8. I had this code sitting around for a while and following 8.1
I reworked the code to add a TryGetItemAsync extension method for Windows Phone and
I didn't need the Windows 8 version any more. This functionality is packaged up in
"Charming Storage" which is available on NuGet:-



https://www.nuget.org/packages/InTheHand.Storage/



Add the package, insert:



using InTheHand.Storage;



At the top of your code file and then you can use the extension method in exactly
the same way as the Windows 8.1 method. Checking for file existence is as simple as:-


if(await Windows.Storage.ApplicationData.Current.LocalFolder.TryGetItemAsync("cheese") != null)


The Charming Storage library also adds a local settings API which is code compatible
with Windows 8 and stores settings in the package's local storage. This offers a replacement
to IsolatedStorageSettings and gives you the same code as Windows Store (just the
namespace is different).





Please change your news reader to use http://feeds.feedburner.com/peterfoot.

Thursday, October 31, 2013  |  From Peter Foot


The last post showed how to get the current app's tile colour in Windows 8. What about
Windows Phone? There isn't the concept of a tile colour - you provide a full image
for your app icon and tiles and this can be whatever colour you choose or transparent
in which case the user's accent colour is used. In terms of a theme colour for phone
apps the application icon is probably a better place to start. The vast majority of
apps use a solid colour background, this is seldom the case with games but since this
post focusses on apps let's not worry about that.



The Charming ApplicationModel library contains a more complete implementation of the
Windows.ApplicationModel.Package class for reading app metadata at runtime - on Windows
Phone most of the properties are not implemented. This has been updated with a number
of new Windows 8.1 properties such as Logo which returns a Uri to the application
logo file within your package. We can then use a WriteableBitmap to read an individual
pixel from the image and create a solid colour brush to be used inside the app. This
allows you to change the appearance of your app without any code or XAML changes,
and is also useful for custom controls where the code might reside separately from
the application itself. Below is the equivalent code to the Win8 version posted before.
This creates a resource "AppAccentBrush" which can be used within the app UI.



System.Windows.Resources.StreamResourceInfo sri = Application.GetResourceStream(InTheHand.ApplicationModel.Package.Current.Logo);



System.Windows.Media.Imaging.BitmapImage img = new System.Windows.Media.Imaging.BitmapImage();

img.SetSource(sri.Stream);



System.Windows.Media.Imaging.WriteableBitmap wb = new System.Windows.Media.Imaging.WriteableBitmap(img);

int rgb = wb.Pixels[0];

           


byte r, g, b;

r = (byte)((rgb & 0xFF0000) >> 16);

g = (byte)((rgb & 0xFF00) >> 8);

b = (byte)(rgb & 0xFF);

System.Windows.Media.Color c = System.Windows.Media.Color.FromArgb(0xff, r, g, b);

Application.Current.Resources.Add("AppAccentBrush", new System.Windows.Media.SolidColorBrush(c));



There is currently no check here for transparent backgrounds as we'd probably want
to default to a solid colour in this case (perhaps fall back to PhoneAccentBrush).
I'm looking at improving this code and integrating it into the charming libraries,
to provide customisation to some of the UI such as the settings screens. You can grab
the Charming libraries from Codeplex (http://charming.codeplex.com)
or NuGet (http://www.nuget.org/packages?q=charming).





Please change your news reader to use http://feeds.feedburner.com/peterfoot.

Monday, October 28, 2013  |  From Peter Foot


When you define your package manifest for a Windows Store app you can specify the
background colour used for your tile. Chances are this is a brand colour which you
want to use throughout your app. You could specify it twice - once in the manifest
and once in a XAML resource. However imagine the scenario where you are creating a
custom control and need to use this colour without actually having access to the executing
app code. The solution is quite simple and involves reading the compiled manifest
from within your executing app package. The file in question is called AppxManifest.xml.
We can use an XmlReader to locate the specific attribute we need. I wouldn't poke
around for too many things in this file as most of this information is accessible
through the Windows.ApplicationModel.Package class. The code below (error checking
removed for clarity) shows the steps to open the file for reading, locating the required
Element and reading the "BackgroundColor" attribute. This string contains an RGB value
in HEX notation so we can extract the Red, Green and Blue values and save to a Color.
I've saved this to the apps Resources dictionary with the name "AppAccentBrush".


Stream s = await Windows.ApplicationModel.Package.Current.InstalledLocation.OpenStreamForReadAsync("AppxManifest.xml");
System.Xml.XmlReader reader = System.Xml.XmlReader.Create(s);
reader.ReadToDescendant(<"VisualElements", "http://schemas.microsoft.com/appx/2013/manifest");
string attr = reader.GetAttribute("BackgroundColor");
byte r, g, b;
r = byte.Parse(attr.Substring(1, 2), System.Globalization.NumberStyles.HexNumber);
g = byte.Parse(attr.Substring(3, 2), System.Globalization.NumberStyles.HexNumber);
b = byte.Parse(attr.Substring(5, 2), System.Globalization.NumberStyles.HexNumber);

accentColor = Windows.UI.Color.FromArgb(0xff, r, g, b);
this.Resources.Add("AppAccentBrush", new SolidColorBrush(accentColor));


What else might you want to use this for? Well one feature we found annoying was that
regardless of your colour scheme the indeterminate progress bar uses a default colour.
As it turns out this is defined in the ProgressBarIndeterminateForegroundThemeBrush
resource. You can access this Brush and modify its colour to match your tile colour.


if(this.Resources.ContainsKey("ProgressBarIndeterminateForegroundThemeBrush")) 
{
 var brush = this.Resources["ProgressBarIndeterminateForegroundThemeBrush"] as SolidColorBrush;
 brush.Color = accentColor;
}



Please change your news reader to use http://feeds.feedburner.com/peterfoot.

Friday, August 16, 2013  |  From Peter Foot


If you want to determine the space used for a particular folder in Isolated Storage
you have to work recursively through the files in the folder (and sub-folders) and
determine their sizes. In the Windows API the StorageFolder gives the indication that
you can get the BasicProperties for a folder and use this to get its size. Unfortunately
this just returns zero for folders. Therefore you have to use the same basic approach
but modified for the new API (and async code). Below is an example of a method to
do that. Simply pass in the StorageFolder of interest and it will return the size
e.g.



ulong size = await GetFolderSize( await Windows.Storage.ApplicationData.Current.LocalFolder.GetFolderAsync("cheese"));



The method looks like this:-



public async System.Threading.Tasks.Task<ulong> GetFolderSize(Windows.Storage.StorageFolder
folder)

{

    ulong size = 0;



    foreach (Windows.Storage.StorageFolder thisFolder in await folder.GetFoldersAsync())

    {

       size += await GetFolderSize(thisFolder);

    }



    foreach (Windows.Storage.StorageFile thisFile in await folder.GetFilesAsync())

    {

       Windows.Storage.FileProperties.BasicProperties
props = await thisFile.GetBasicPropertiesAsync();

       size += props.Size;

    }



    return size;

}



You can use this across both Windows Phone 8 and Windows Store projects.





Please change your news reader to use http://feeds.feedburner.com/peterfoot.

Tuesday, August 6, 2013  |  From Peter Foot


Microsoft have today announced Windows Phone App Studio Beta (https://apps.windowsstore.com/default.htm).
This is a web based tool which allows you to build your own app by putting together
data sources and customising the look and feel. The instructions list just four basic
steps and there is a library of templates to start from. This might not be of huge
interest to hardcore developers but it does allow non-developers to build and test
apps and get a feel for what the platform is capable of. One of the interesting features
is that once you've created your app you can download the source code as a Visual
Studio solution and then customise it however you see fit.



To investigate this I picked a couple of the Charming libraries (http://charming.codeplex.com)
to add Search and Sharing functionality to a ready-made app. I'll be following up
with a detailed step-by-step approach of adding Search support to a generated app.





Please change your news reader to use http://feeds.feedburner.com/peterfoot.

Tuesday, August 6, 2013  |  From Peter Foot


My previous couple of posts have been related to the Sharing functionality provided
by the Charming libraries. This one looks
at a smaller (but no less exciting) component. For Windows Phone development if you
want to retrieve the app information at runtime you have to read the WMAppManifest.xml
file included in the package. In Windows 8 an API was provided (Windows.ApplicationModel.Package
and related classes) to provide a strongly typed API around the Windows Store metadata.
Although these classes are present in Windows Phone projects they aren't all implemented
and you can waste a lot of time getting exceptions assuming that the functionality
will work.



Enter Charming ApplicationModel. This replicates the same object model you see for
Windows Store apps but in a way which actually works and reads information from the
xap. In addition to this there is an added property - Capabilities which
returns the combination of capabilities requested by your package. This has been especially
useful in developing the other Charming libraries as it makes it possible to add functionality
only when certain capabilities are added in the consuming app. For example you won't
get any nasty surprises if you add the Share library and not the Proximity capability
- the library won't include the "Tap+Share" option.



Beyond the other Charming libraries you can use this library yourself - for example
write a generic About page which is populated at runtime by the app metadata. The
library is tiny, you won't need to mess about with XML parsing and it gives you the
potential of sharing more code between Phone and Store projects.



ApplicationModel is the only one of the Charming libraries which doesn't expose any
UI. As already stated it is used by Charming Share, and also Charming Settings and
as of 8.1 it will also be used by Charming Search but more of that in the next post...





Please change your news reader to use http://feeds.feedburner.com/peterfoot.

Thursday, August 1, 2013  |  From Peter Foot


The Charming libraries for Windows Phone
are a set of (currently) six components for Windows Phone development with the mission
of providing more code consistency with Windows 8. Following on from the NFC component,
this post will cover its cousin the Share component.



Windows Phone provides a number of classes in the Windows.ApplicationModel.DataTransfer
namespace but there is no Share charm or sharing functionality here. The Charming
Share library replicates this functionality with a sharing component which can be
called in the same way as on Windows 8 and yet exposes the various platform sharing
mechanisms. Because this is not an OS feature it is not possible to create share targets
and share data with other apps. I am looking at the possibility of making the providers
extensible so that you can add items to the list of targets.



You can currently share three types of object - Text, Uri and Image. The available
targets will vary depending on the data you pass. Image is a special case as it uses
the ShareMediaTask which means you have access to all the system targets including
other apps registered as Photo Extras. This also means you can share an image via
Email which is not possible with the EmailComposeTask. The table below shows the supported
targets based on data type:-












































<o:p> </o:p>




Text<o:p></o:p>




Uri<o:p></o:p>




Image<o:p></o:p>




Tap+Send<o:p></o:p>




<o:p>
 
</o:p>




Yes




Yes




Bluetooth<o:p></o:p>




<o:p>
 
</o:p>




<o:p>
 
</o:p>




Yes<o:p></o:p>




Messaging<o:p></o:p>




Yes




Yes




Yes




Email<o:p></o:p>




Yes




Yes




Yes (Individually Listed)




Social
Networks<o:p></o:p>




Yes




Yes




Yes (Individually Listed)




Photo
Extras<o:p></o:p>




<o:p>
 
</o:p>




<o:p>
 
</o:p>




Yes





 The Tap+Send functionality for Uris is provided by the separate Charming NFC
Share component. It will only appear in the list if you add the NFC library as a reference
in your project (and add the Proximity capability). The share dialog shown when passing
a Uri is designed to look familiar and uses page transitions from the Phone Toolkit:-






I'm working on localised resources for these components so that they will be supported
in all Windows Phone 8 languages. Because the Image sharing dialog is system provided
this is already localised into the device language. In early testing the NFC and Share
components are looking good with localised text and supporting LeftToRight and RightToLeft
layouts.



If other formats can be supported I'm looking at the possibility of adding a
Bluetooth provider to beam files using OBEX, again trying to stick as closely to the
system provided Bluetooth sharing for images. Another possible target is a Clipboard
provider for Text or Uri, the source code is in there but the provider is not currently
used.





Please change your news reader to use http://feeds.feedburner.com/peterfoot.

Saturday, July 27, 2013  |  From Peter Foot


In my
talk this week
I demonstrated a simple library for sharing a single Uri over NFC.
I've now completed packaging it up and it is available on NuGet - https://www.nuget.org/packages/InTheHand.Phone.Nfc/



This is a very simple component to use in your app requiring just three lines of code
to call. It requires the Windows Phone Toolkit from which it uses page transitions,
if you don't already have this in your project NuGet will add it for you. It also
requires you to add the Proximity capability in your app metadata. The Windows Phone
Emulator exposes a null NFC device so it is possible to interact with this feature
on the emulator (it just won't send anything). The look and feel of the task has been
designed to match the platform so it will look instantly familiar and supports both
the light and dark themes.






To share a Uri from your app you'll need to execute the following:-



Add the InTheHand.Phone.Nfc package via NuGet



Add the ID_CAP_PROXIMITY capability to your WMAppManifest.xml



Add the following code when you want to share a Uri:-



<divre>
</divre>
InTheHand.Phone.Tasks.ShareNfcLinkTask snlt = new InTheHand.Phone.Tasks.ShareNfcLinkTask();



snlt.LinkUri = new Uri("http://peterfoot.net");



snlt.Show();





Obviously setting the LinkUri to whatever URI you want to share.
This could be a web link or a custom URI which performs some task in your app.



At the moment the resources in the library are not localised beyond English although
I hope to add this soon.



This is the first in a set of related "Charming" libraries for Windows Phone. I'll
be adding more to NuGet shortly. Hopefully the reason for the name will become clearer
too...







Please change your news reader to use http://feeds.feedburner.com/peterfoot.

Wednesday, July 24, 2013  |  From Peter Foot


As promised here are the resources from yesterday's session on Bluetooth and NFC.
I've begun uploading the slides and code to this SkyDrive folder:-



http://sdrv.ms/143OZD7



I have a few finishing touches to put on the sharing library for NFC - it will be
up on NuGet and CodePlex shortly.



 





Please change your news reader to use http://feeds.feedburner.com/peterfoot.

Tuesday, July 23, 2013  |  From Peter Foot


The page header is the small text you see across the top of most apps, often in all
uppercase. When you create a new Windows Phone app from the default templates you'll
get something like this created in your MainPage.xaml




<TextBlock Text="MY APPLICATION" Style="{StaticResource PhoneTextNormalStyle}"
Margin="12,0"/>


>


The annoying thing about this is this is not the same format as built-in apps. The
font size is wrong and so is the weight. Rather than manually fixing up every instance
I define the following style in the App.xaml:



<Style x:Name="PhoneTextPageHeaderStyle" BasedOn="{StaticResource PhoneTextNormalStyle}"
TargetType="TextBlock">

   <Setter Property="FontSize" Value="22"/>

   <Setter Property="FontWeight" Value="SemiBold"/>

   <Setter Property="Margin" Value="12,0"/>

</Style>



Then my page XAML becomes:-



<TextBlock Text="MY APPLICATION" Style="{StaticResource PhoneTextPageHeaderStyle}"/>



My app is now consistent with built-in apps!





Please change your news reader to use http://feeds.feedburner.com/peterfoot.

Sunday, July 21, 2013  |  From Peter Foot


Version 8.1 of 32feet.NET for Windows Phone is now available via NuGet. This package
adds some helper functionality for Bluetooth development. In particular this version
includes the RfCommServiceId (designed to match the Windows 8.1 API) to provide information
about various standard RfComm profiles. You can use this when connecting a StreamSocket
or to filter devices in the BluetoothDevicePicker.



Speaking of which the BluetoothDevicePicker has been updated to more closely follow
the appearance of the dialog displayed when you use the built in Bluetooth photo sharing
feature. Currently the library is built with localized resources in mind but has only
English text. If you are interested in providing localized text in your own language
please contact me.



The CodePlex project contains the source and the Serial sample app. I'm working on
some additional sample apps which will be added soon.





Please change your news reader to use http://feeds.feedburner.com/peterfoot.

 Peter Foot News Feed 

Last edited Dec 7, 2006 at 10:16 PM by codeplexadmin, version 1

Comments

MMMScott Dec 25, 2014 at 10:56 AM 
I've been using customer service software called Helprace (http://helprace.com) - it's not open source, however.