It was 2009 when I started my first open source project and announced it with this unspectacular blog post. Back then it was developed with Visual Studio 2008 targeting Silverlight and hosted on CodePlex.
Many things have changed and tech comes and goes but during the last 10 years I always adapted, extended it, added bug fixes and reviewed/merged Pull Requests. Even after all the years WriteableBitmapEx is still quite popular, especially with Windows desktop WPF developers.
Version 1.6.2 of WriteableBitmapEx finally adds dedicated libs for UWP and an UWP sample. For WPF it now supports .NET Core, both the .NET Framework and .NET Core libs are part of the NuGet pack.
If you are using the source code and the VS solution directly, you can choose the .NET Framework 4.5 or .NET Core 3 as the target in the VS drop-down.
WriteableBitmapEx supports a variety of Windows platforms and versions.
WPF and Windows 10 Universal Windows Platform (UWP) are actively maintained.
Silverlight, Windows 8/8.1 WinRT, Windows Phone WinRT and Silverlight 7/8/8.1 are not maintained anymore but the latest stable libs are still part of the NuGet package.
You can download the latest via the updated NuGet package. The packages contain the WriteableBitmapEx binaries. All samples and the source code can be found in the GitHub repository.
A huge shout out and thank you to all the contributors, bug issuers and users of the library. ❤
Showing posts with label wpdev. Show all posts
Showing posts with label wpdev. Show all posts
Wednesday, January 23, 2019
Friday, May 5, 2017
Long time no hear - WriteableBitmapEx 1.5.1 is out
Even after all the years WriteableBitmapEx is still quite popular, especially with WPF developers and I always incorporate bug fixes and also accept Pull Requests if I get some time.
Many contributions were integrated and lots of bugs fixed. Among those are some nice additions like a clipped line drawing or a dotted line renderer.
WriteableBitmapEx supports a variety of Windows platforms and versions: WPF, Silverlight, Windows 10 Universal Windows Platform (UWP), Windows 8/8.1, Windows Phone WinRT and Silverlight 7/8/8.1.
You can download the latest via the updated NuGet package. The packages contain the WriteableBitmapEx binaries. All samples and the source code can be found in the GitHub repository.
A big thank you to all the contributors, bug reporters and users of the library who help with feedback.
Many contributions were integrated and lots of bugs fixed. Among those are some nice additions like a clipped line drawing or a dotted line renderer.
WriteableBitmapEx supports a variety of Windows platforms and versions: WPF, Silverlight, Windows 10 Universal Windows Platform (UWP), Windows 8/8.1, Windows Phone WinRT and Silverlight 7/8/8.1.
You can download the latest via the updated NuGet package. The packages contain the WriteableBitmapEx binaries. All samples and the source code can be found in the GitHub repository.
A big thank you to all the contributors, bug reporters and users of the library who help with feedback.
Labels:
.Net,
C#,
Computer graphics,
metro,
Silverlight,
uap,
Win8,
windows 10,
windows 8,
Windows Phone,
windows store,
WinRT,
Wp7Dev,
wp8dev,
wpdev,
wpf,
WriteableBitmap,
WriteableBitmapEx,
xaml
Tuesday, March 31, 2015
Staying Alive! - WriteableBitmapEx 1.5 is out
After a couple of minor updates on top of version 1.0 which lead to 1.0.14, I'm happy to announce that WriteableBitmapEx 1.5 is now available.
Many contributions were integrated and lots of bugs fixed. Among those are some nice new color modifications and also long awaited DrawLine with variable thickness, pen support, better anti-aliased lines, Cohen-Sutherland line clipping, even-odd polygon filling and alpha-blended shape filling... Read the details at the end of this post or the release notes.
WriteableBitmapEx supports a variety of Windows platforms and versions: WPF, Silverlight, Windows 10 Universal App Platform (UAP), Windows 8/8.1, Windows Phone WinRT and Silverlight 7/8/8.1.
You can download the binaries here or via the NuGet package. The packages contain the WriteableBitmapEx binaries. All samples and the source code can be found in the repository.
A big thank you to all the contributors, bug reporters and users of the library who helped to shape this. You rock!
Changes
Many contributions were integrated and lots of bugs fixed. Among those are some nice new color modifications and also long awaited DrawLine with variable thickness, pen support, better anti-aliased lines, Cohen-Sutherland line clipping, even-odd polygon filling and alpha-blended shape filling... Read the details at the end of this post or the release notes.
WriteableBitmapEx supports a variety of Windows platforms and versions: WPF, Silverlight, Windows 10 Universal App Platform (UAP), Windows 8/8.1, Windows Phone WinRT and Silverlight 7/8/8.1.
You can download the binaries here or via the NuGet package. The packages contain the WriteableBitmapEx binaries. All samples and the source code can be found in the repository.
A big thank you to all the contributors, bug reporters and users of the library who helped to shape this. You rock!
Changes
- Added lots of contributions including DrawLine with variable thickness, penning, improved anti-aliasing and Wu's anti-aliasing algorithm
- Added usage of CohenSutherland line clipping for DrawLineAa and DrawLine, etc.
- Added support for alpha blended filled shapes and adapted the FillSample for WPF
- Added FillPolygonsEvenOdd() which uses the even-odd algorithm to fill complex polygons with more than one closed outline like for the letter O
- Added AdjustBrightness(), AdjustContrast() and AdjustGamma() methods
- Added Gray() method which returns the gray scaled version the bitmap
- Fixed regression issue with alpha blending for Blit for non-WinRT
- Fixed bug in Blit Alpha code for WPF when source format is not pre-multiplied alpha
- Fixed bug #21778 where FromStream for WPF needs to be called inside Init scope
- Fixed issue with IndexOutOfRangeEx in DrawLine method
- Fixed Invalidate for Silverlight BitmapContext.Dispose
- Fixed many more reported issues
- ...
Labels:
.Net,
C#,
Computer graphics,
metro,
Silverlight,
uap,
Win8,
windows 10,
windows 8,
Windows Phone,
windows store,
WinRT,
Wp7Dev,
wp8dev,
wpdev,
wpf,
WriteableBitmap,
WriteableBitmapEx,
xaml
Friday, December 19, 2014
The Walking HeadlessHost - WP 8.1 Feedback Feature and Zombies
![]() |
| Photo by Juanedc |
I was recently working on a rather large Windows Phone app project and came across an issue which took many head scratching hours to figure out. Therefore here's a short heads up if you work on Windows Phone apps with background agents and have those running on Windows Phone 8.1 devices: The WP 8.1's Feedback setting can influence how your background process behaves. We are talking about a WP 8.0 app with an UI (TaskHost.exe) and a VoIP background agent (HeadlessHost.exe) communicating with each other through an out-of-process RPC server. This approach follows the WP 8.0 VoIP app architecture. When this 8.0 app runs on 8.1 devices I've seen sporadic issues where an instance of the HeadlessHost background process was kept alive when the app was deactivated, for example with fast app switching. When the app get's activated again another instance of the HeadlessHost is started while the previous zombie HeadlessHost is still not dead, so you will end up with two HeadlessHost processes which leads to issues like endless "Resuming..." screens and app crashes when navigating back. This can be seen even without a debugger attached.
If you disable the WP 8.1 device's Feedback setting that issue is gone and the ForegroundLifetimeAgent's HeadlessHost is quickly exited as expected when the UI gets deactivated.
I'm not sure why the Feedback feature is related, my best guess right now: The WP 8.1 Feedback feature gathers telemetry data and therefore keeps the HeadlessHost undead. The weird part is that the HeadlessHost is even undead after a minute and no crash of the background agent happened which means no Watson data should actually have been collected at all or at least not that long.
I'm not sure yet if Silverlight 8.1 apps on 8.1 devices are affected as well or if it's only an issue with 8.0 apps on 8.1 developer unlocked devices. Nevertheless I still wanted to share my experience since it's a rather unknown case and not much information can be found anywhere else so far.
Labels:
Windows Phone,
wp8,
wp81,
wp8dev,
wpdev
Thursday, September 25, 2014
Matrix of the Universe - Matrix3DEx now available for Universal Apps
Do you know about the semi-3D features of XAML and the UIElement Projection available in WinRT and Silverlight? I know many aren't aware of this feature which enables actually pretty nice semi-3D experiences just with XAML.
To make the handling easier, I created the Matrix3DEx open source project a few years ago which provides helper methods and samples.
It's better described in action than with words, so you should try the live Silverlight sample which is now also available for WinRT.
There were also some cool games developed using Matrix3DEx: Cubemania is a great and highly addictive rigid body physics game and Go Go Racer! is a nice 2.5D retro racing game.
The Matrix3DEx library is now available for WinRT including Universal Apps, Windows Phone Silverlight and goo old Web Silverlight.
You can download the binaries here.
As usual all samples and the source code can be found in the repository.
The Matrix3DEx project description from the CodePlex site:
It's better described in action than with words, so you should try the live Silverlight sample which is now also available for WinRT.
There were also some cool games developed using Matrix3DEx: Cubemania is a great and highly addictive rigid body physics game and Go Go Racer! is a nice 2.5D retro racing game.
The Matrix3DEx library is now available for WinRT including Universal Apps, Windows Phone Silverlight and goo old Web Silverlight.
You can download the binaries here.
As usual all samples and the source code can be found in the repository.
The Matrix3DEx project description from the CodePlex site:
The Matrix3DEx library is a collection of extension and factory methods for the Matrix3D struct. It's available for Windows WinRT including Universal Apps, Silverlight and Windows Phone Silverlight. The Matrix3D struct represents a 4x4 matrix that is used in combination with the Matrix3DProjection to apply more complex semi-3D scenarios to any UIElement than are possible with the simple PlaneProjection. This makes it possible to apply arbitrary model transformation matrices and perspective matrices to Silverlight elements.
The Matrix3D struct is very minimalistic and has only a few members. The Matrix3DEx library tries to compensate that with extension and factory methods for common transformation matrices that are easy to use like built in methods.
Labels:
.Net,
3D,
Computer graphics,
Matrix3DEx,
windev,
Windows Phone,
WinRT,
wpdev
Friday, April 4, 2014
Content for the Modern Camera and Imaging Apps Build 2014 Session
I had a chance to give a presentation at Microsoft's largest developer conference //build 2014 about the great new capturing APIs. The session Modern Camera and Imaging Apps was given together with Jeff Day who's the Windows Camera API lead PM.
The session was recorded and available at Channel 9.
The slides can also be viewed / downloaded here.
The source code of the demos is available here.
The session was recorded and available at Channel 9.
The slides can also be viewed / downloaded here.
The source code of the demos is available here.
Friday, January 31, 2014
No Biggie - How to Query the Available Storage Size in WinRT
![]() |
| Tape drive photo by P. Hollenback |
Unfortunately there's no built-in way to check for the available free storage size / free disk space at those locations, although there are scenarios where that information can be essential, especially when dealing with removable devices. But no worries, the good old Win32 has it covered with the GetFreeDiskSpaceEx function and it can be used with Windows 8 and Windows Phone 8. In order to use it from managed code it just has to be called through P/Invoke or wrapped in a WinRT component which I prefer nowadays, therefore this post provides a short WinRT C++/Cx snippet.
I assume you know how to create a custom C++/Cx WinRT component with Visual Studio, if not go back to my previous blog post which shows just that.
How it works
- Open the generated precompiled header file pch.h of your WinRT component's Visual Studio project and add an include for windows.h:
// pch.h - Header for standard system include files. #pragma once #include <windows.h>
- Open the header file of your component and add the method declaration of GetAvailableBytes to your WinRT component which will internally use the GetFreeDiskSpaceEx, but only takes a path as string parameter and returns a WinRT uint64 (unsigned long) type with the available free space in bytes.
namespace MyNativeStuff { public ref class MyStorageExtensions sealed { public: uint64 GetAvailableBytes(Platform::String^ path); }; }
- Add the method implementation in the source file of the component (.cpp).
The GetDiskFreeSpaceEx function takes a pointer to an ULARGE_INTEGER which is an union from ancient times when compilers didn't support 64 bit types. Our method then returns the filled unsigned long QuadPart of it.
#include "pch.h" #include "MyNativeStuff.h" using namespace MyNativeStuff; using namespace Platform; uint64 MyStorageExtensions::GetAvailableBytes(Platform::String^ path) { ULARGE_INTEGER availableBytesToCaller; availableBytesToCaller.QuadPart = 0; GetDiskFreeSpaceEx(path->Data(), &availableBytesToCaller, NULL, NULL); return availableBytesToCaller.QuadPart; }
- You are now ready to use the component in your managed C# code.
var myNativeComponent = new MyNativeStuff.MyStorageExtensions(); // Create a folder in temp folder of the app and check the available free space var myTempFolder = await ApplicationData.Current.TemporaryFolder.CreateFolderAsync("test", CreationCollisionOption.OpenIfExists); var availableSpaceTempFolder = myNativeComponent.GetAvailableBytes(myTempFolder.Path); // Create a folder in videos lib and check the available free space var myVideoFolder = await KnownFolders.VideosLibrary.CreateFolderAsync("test", CreationCollisionOption.OpenIfExists); var availableSpaceVideoLib = myNativeComponent.GetAvailableBytes(myVideoFolder.Path);
Note, the GetFreeDiskSpaceEx works with any directory path the calling code is allowed to access.
Labels:
C++. Cx,
c++11,
Win8,
win81,
windev,
windows 8,
windows 8.1,
Windows Phone,
windows store,
winprt,
WinRT,
wp8,
wpdev
Tuesday, January 7, 2014
Windows Phone Natives - How to Leverage Native Code on Windows Phone
With Windows Phone 8 the possibility to use native code for development was introduced to the public SDK. It's a powerful feature and it can help to improve the performance for certain heavy computing tasks, reduce the memory footprint or just to leverage certain APIs which are only available in native code. Media Foundation or Direct3D for example are native only, but it could as well be a proprietary library from another third party written in C/C++.
In order to use native code on Windows Phone one has to write a native Windows Phone Runtime Component (WinPRT). Such a WinPRT library encapsulates the native code internally and only exposes WinRT types, therefore it can be consumed through the WinMD projections also in managed C# projects.
This blog post provides an introduction with an easy sample to get started. The MSDN also provides a very good Windows Phone native code overview, a list of the available Win32 and COM APIs on Windows Phone including an index of all supported Win32 functions. It contains such important things like the native sockets API Winsock, the National Language Support (NLS) functions for all things around region, language and culture and much more native APIs.
If you run the sample in the emulator you will see IsNeonSupported() returns false, since it's running on the x86 CPU, but if you execute the sample on a device IsNeonSupported() should return true. Keep in mind you are now using native code so you have to compile a build for ARM (device) or x86 (emulator). AnyCPU won't work anymore.
The presented is just a very easy sample but it already shows how native code on Windows Phone can help you to access information not available otherwise.
In order to use native code on Windows Phone one has to write a native Windows Phone Runtime Component (WinPRT). Such a WinPRT library encapsulates the native code internally and only exposes WinRT types, therefore it can be consumed through the WinMD projections also in managed C# projects.
This blog post provides an introduction with an easy sample to get started. The MSDN also provides a very good Windows Phone native code overview, a list of the available Win32 and COM APIs on Windows Phone including an index of all supported Win32 functions. It contains such important things like the native sockets API Winsock, the National Language Support (NLS) functions for all things around region, language and culture and much more native APIs.
How it works
- First of all you need to create a Windows Phone App 8 project with Visual Studio.
- Then add a new Visual C++ Windows Phone Runtime Component (WinPRT) project to the solution.
- Now you need to add the solution's WinPRT project as reference to the App project. Note that Visual Studio will automatically take care of adding the required ActivatableClass definition to your consuming App project. Refer to this if you ever need to add a WinRT component manually to another project.
- Open the generated precompiled header file pch.h and add an include for windows.h:
// pch.h - Header for standard system include files. #pragma once #include <windows.h>
For this sample we use the Win32 function IsProcessorFeaturePresent to query if certain processor features are supported. This function is defined in windows.h.
- Open the header file of your component (ProcessorInfoComponent.h) and add the method declaration of IsNeonSupported to our WinPRT component which will internally use the IsProcessorFeaturePresent, but only expose a WinRT bool type. The MSDN has a nice Quick Reference which provides a table how Standard C++ types and constructs map to C++/Cx WinRT.
namespace ProcessorInfoComponent { public ref class ProcessorInfoProvider sealed { public: bool IsNeonSupported(); }; }
- Open the source file (ProcessorInfoComponent.cpp) and add the method implementation to our WinPRT component which will call IsProcessorFeaturePresent and return the result.
The IsNeonSupported wrapper method here will provide the information if the processor supports the ARM VFP/Neon: 32 x 64bit register bank. There are many other queryable parameters available beside PF_ARM_VFP_32_REGISTERS_AVAILABLE used here. Those are defined in winnt.h and partly documented at the MSDN.
#include "ProcessorInfoComponent.h" using namespace ProcessorInfoComponent; bool ProcessorInfoProvider::IsNeonSupported() { return IsProcessorFeaturePresent(PF_ARM_VFP_32_REGISTERS_AVAILABLE); }
- You are now ready to use the component in your managed C# code.
private void Button_Click(object sender, RoutedEventArgs e) { var infoProvider = new ProcessorInfoComponent.ProcessorInfoProvider(); var hasNeon = infoProvider.IsNeonSupported(); Info.Text = string.Format("Is ARM Neon supported: {0}", hasNeon); }
If you run the sample in the emulator you will see IsNeonSupported() returns false, since it's running on the x86 CPU, but if you execute the sample on a device IsNeonSupported() should return true. Keep in mind you are now using native code so you have to compile a build for ARM (device) or x86 (emulator). AnyCPU won't work anymore.
The presented is just a very easy sample but it already shows how native code on Windows Phone can help you to access information not available otherwise.
Friday, December 20, 2013
What are you Awaiting for - How to Turn a C/C++ Callback into a C++/Cx WinRT IAsyncAction
Windows and Windows Phone 8 and its WinRT / WinPRT component model provide a nice way to leverage good ol' native C/C++ libraries in all WinMD language projections by wrapping them in a WinRT C++/Cx component. Such a native WinRT component only exposes WinRT types and can therefore be consumed through the WinMD projections also in C# or WinJS.
Often those good ol' native libraries provide events or callback functions for asynchronous calls. This means one would also have to provide a WinRT wrapper for those events and callbacks as well, although the WinRT has the nice IAsyncAction and IAsyncOperation constructs together with the Parallel Patterns Library (PPL) which make the WinRT component way better to use.
This post describes how to plug both worlds together to turn your good ol' C++ code into rose colored C++/Cx consumable through WinMD.
We won't go too deep into C++/Cx in general here. There's a good intro at the MSDN and also a nice Quick Reference which provides a table how Standard C++ types and constructs compare to C++/Cx. I also don't cover how the PPL and WinRT async works here, but there's a great MSDN page: Creating Asynchronous Operations in C++ for Windows Store Apps.
Assuming you have a good ol' native interface like this with a defined callback template:
It could be used like this using a C++11 lambda as callback function:
It's worth mentioning this will also work with C function pointers and you can use a C++ 11 lambda for it as long as the lambda does not capture any variable. Stateless lambdas will just degrade to function pointers.
This is how your C++/Cx WinRT component's method which wraps the above C++ template could look like:
You could then use your WinRT component in C# like this:
And similar in WinJS using a JS Promise:
Way better API for the custom WinRT component if you ask me!
The trick to achieve that is the usage of the PPL's create_async, create_task and especially the task_completion_event which provides a nice way to make that callback-based model work with the proper WinRT modern async Task-based way.
Often those good ol' native libraries provide events or callback functions for asynchronous calls. This means one would also have to provide a WinRT wrapper for those events and callbacks as well, although the WinRT has the nice IAsyncAction and IAsyncOperation
This post describes how to plug both worlds together to turn your good ol' C++ code into rose colored C++/Cx consumable through WinMD.
We won't go too deep into C++/Cx in general here. There's a good intro at the MSDN and also a nice Quick Reference which provides a table how Standard C++ types and constructs compare to C++/Cx. I also don't cover how the PPL and WinRT async works here, but there's a great MSDN page: Creating Asynchronous Operations in C++ for Windows Store Apps.
Assuming you have a good ol' native interface like this with a defined callback template:
template <typename TCallback>
HRESULT StartAsyncOperation(const TCallback &callback)
{
...
}
It could be used like this using a C++11 lambda as callback function:
StartAsyncOperation([this](HRESULT error) -> HRESULT
{
// Do whatever here after the async is done...
// Notify the calling code through an event or another callback
// that the async operation has finished.
return S_OK;
});
It's worth mentioning this will also work with C function pointers and you can use a C++ 11 lambda for it as long as the lambda does not capture any variable. Stateless lambdas will just degrade to function pointers.
// Definition of fucntion pointer and a function expecting it as parameter
typedef void (*SomeOtherCallback)(int param1);
FunctionExpectingSomeOtherCallback(SomeOtherCallback cb);
// Example call using a stateless lambda
FunctionExpectingSomeOtherCallback([](int param1)
{
// Perform some operation with param1
});
This is how your C++/Cx WinRT component's method which wraps the above C++ template could look like:
Windows::Foundation::IAsyncAction^ MyWinRtComponent::RunAsync()
{
// Setup the Task Completion Event and the async Task
Concurrency::task_completion_event<void> tce;
auto tsk = Concurrency::create_task(tce);
Windows::Foundation::IAsyncAction^ asyncOp = Concurrency::create_async( [tsk]()
-> Concurrency::task<void>
{
return tsk;
});
// Run good ol' native code wih callback defined as C++ lambda
StartAsyncOperation([this, tce](HRESULT error) -> HRESULT
{
try
{
// Check for error and wrap in platfrom exception
if (FAILED(error))
{
throw Platform::Exception::CreateException(error);
}
}
catch(...)
{
// Pass exception on to calling code using the
// Task Completion Event's dedicated method
tce.set_exception(std::current_exception());
return error;
}
// Set the Task Completion Event's Result to mark the Task as complete
// If a IAsyncOperation is used the result value is passed
tce.set();
return S_OK;
});
return asyncOp;
}
You could then use your WinRT component in C# like this:
var component = new MyWinRtComponent(); await component.RunAsync();
And similar in WinJS using a JS Promise:
this._component.runAsync().then(function () {
WinJS.log("My component finished the async call! :-)", null, "status");
});
Way better API for the custom WinRT component if you ask me!
The trick to achieve that is the usage of the PPL's create_async, create_task and especially the task_completion_event which provides a nice way to make that callback-based model work with the proper WinRT modern async Task-based way.
Monday, December 2, 2013
Easy Render! - WriteableBitmapEx now with Better Support for Win 8.1 RenderTargetBitmap

The lack of WriteableBitmap.Render in Windows WinRT 8.0 was quite an issue for many apps, but fortunately did WinRT 8.1 (re-)introduce the RenderTargetBitmap class which provides the functionality of rendering the visual tree of the UI to a bitmap. The new update of WriteableBitmapEx makes it even easier to use with a WriteableBitmap by introducing the FromPixelBuffer method.
WriteableBitmapEx is available for 4 platforms: Windows Phone 8 and 7, WPF, Silverlight and Windows Store WinRT .NET XAML 8 and 8.1.
You can download the binaries here or via the NuGet package. The packages contain the WriteableBitmapEx binaries. As usual all samples and the source code can be found in the repository.
How to use
The below code snippet shows how a part of the UI can be rendered into a WriteableBitmap via RenderTargetBitmap, how it can be modified and then finally presented back into the UI by using an Image control.
// Render some UI to a RenderTargetBitmap
var renderTargetBitmap = new RenderTargetBitmap();
await renderTargetBitmap.RenderAsync(Panel);
// Get the pixel buffer and copy it into a WriteableBitmap
var pixelBuffer = await renderTargetBitmap.GetPixelsAsync();
var width = renderTargetBitmap.PixelWidth;
var height = renderTargetBitmap.PixelHeight;
var wbmp = await new WriteableBitmap(1, 1).FromPixelBuffer(pixelBuffer, width, height);
// Modify the WriteableBitmap
wbmp.FillEllipse(10, 10, 256, 256, Colors.Salmon);
// ... More drawing including writeableBitmap.Blit(...) might go here
// Assign WriteableBitmap to an Image control to present it
ImgMirror.Source = wbmp;
Labels:
.Net,
C#,
Computer graphics,
metro,
Silverlight,
Win8,
windows 8,
Windows Phone,
windows store,
WinRT,
Wp7Dev,
wp8dev,
wpdev,
wpf,
WriteableBitmap,
WriteableBitmapEx,
xaml
Quick! - How to Open WP Settings from Code
The Windows Phone File and Uri associations are very useful for implementing custom cross-app functionality like Pictures Lab and other apps provide. Windows Phone also provides uri schemes for many built-in apps and settings which can be very handy.
The Windows Phone 8 update GDR3 introduced a new setting to lock the screen rotation. This setting is quite useful especially when reading in bed or for providing on-screen QR codes to scanners.
This useful screen rotation lock is unfortunately hidden in the settings and it takes a few taps to access it. Therefore I've written a tiny free app called Screen Rotation Lock. It provides quick access to the screen rotation settings through a pinned secondary tile.
The relevant code in the MainPage is rather straight forward but there are some details which are worth sharing and which apply to any shortcut uri navigation:
The first if statement tests if the navigation comes from the secondary tile with the associated key UriQueryStringKeyPage. If it's a back navigation, the user was actually forwarded already to the setting and tapped back. In that case we don't want the user to land in our app, but rather go back to the start screen where she/he comes from, so we close our app. If it's not a back navigation the forward to the setting takes place using the Launcher API and the LaunchUriAsync method with the right uri for screen rotation.
The last if statement tests the version of the device and shows an error message if the device does not have GDR3 installed. This is done as last statement since it's actually only needed when the user wants to pin the secondary tile shortcut and opens the app itself.
The Windows Phone 8 update GDR3 introduced a new setting to lock the screen rotation. This setting is quite useful especially when reading in bed or for providing on-screen QR codes to scanners.
This useful screen rotation lock is unfortunately hidden in the settings and it takes a few taps to access it. Therefore I've written a tiny free app called Screen Rotation Lock. It provides quick access to the screen rotation settings through a pinned secondary tile.
The relevant code in the MainPage is rather straight forward but there are some details which are worth sharing and which apply to any shortcut uri navigation:
protected override void OnNavigatedTo(NavigationEventArgs e)
{
base.OnNavigatedTo(e);
// Actual shortcut navigation?
if (NavigationContext.QueryString.ContainsKey(UriQueryStringKeyPage))
{
// If coming from setting than skip here
if (e.NavigationMode == NavigationMode.Back)
{
Application.Current.Terminate();
}
// Otherwise go to setting
Windows.System.Launcher.LaunchUriAsync(new Uri("ms-settings-screenrotation:"));
}
//Check for support
var gdr3Version = new Version(8, 0, 10492);
if (Environment.OSVersion.Version < gdr3Version)
{
MessageBox.Show(String.Format("Sorry, your phone does not support the screen rotation lock feature yet. You need to have the Windows Phone version {0} installed (WP 8 GDR 3).\r\nThe app will now exit.", gdr3Version), "Not supported version", MessageBoxButton.OK);
Application.Current.Terminate();
}
}
The first if statement tests if the navigation comes from the secondary tile with the associated key UriQueryStringKeyPage. If it's a back navigation, the user was actually forwarded already to the setting and tapped back. In that case we don't want the user to land in our app, but rather go back to the start screen where she/he comes from, so we close our app. If it's not a back navigation the forward to the setting takes place using the Launcher API and the LaunchUriAsync method with the right uri for screen rotation.
The last if statement tests the version of the device and shows an error message if the device does not have GDR3 installed. This is done as last statement since it's actually only needed when the user wants to pin the secondary tile shortcut and opens the app itself.
Thursday, July 4, 2013
Just call us, we'll might call you - How to add Pictures Lab to your App
Windows Phone 8 introduced a nice new feature called File and Uri associations. This feature makes it possible to register an app for certain file extensions and Uri protocols. A couple of apps already support it and Nokia has a nice site which lists a couple.
Pictures Lab recently added support for that as well and uses it to call the app Instagraph. This means with the help of that app Pictures Lab now provides posting / sharing on Instagram. But that's not all, Pictures Lab also supports inbound Uri associations, so you can pass an image to Pictures Lab through the mechanism of an Uri association pretty easily.
How it works
In order to call Pictures Lab from an app this scheme has to be used:
pictureslab:edit?Name=fileNameinthemedialib[&ClientId=ProductIdFromStore]
or
images:edit?Name=fileNameinthemedialib[&ClientId=ProductIdFromStore]
or to just launch Pictures Lab without passing an image:
pictureslab:launch
Note, it's not necessary to UrlEncode the Uri, the Windows Phone platform handles it automatically. If the user has Pictures Lab not installed and the above Uri is called, the Windows Phone OS is also smart enough to show the user a dialog which asks to search for an app in the Store that can handle the protocol. This will bring up Pictures Lab.
Conclusion
The concept of Uri associations is like the little brother of Windows 8's Share Charm, but it's still quite powerful and gives us app developers a nice way to combine our apps and make it a seamless UX. It's a win for the user and therefore it could be a win-win situation for the involved apps.
Future
For a next version I'm also thinking about a callback scenario. The user story would be: A user opens app A and wants to edit an image, this will open Pictures Lab, when the user is done with editing, Pictures Lab will call app A again. The user is back in app A with the edited image.
This callback mechanism would probably use a Callback parameter in the scheme above where app A can provide the UrlEncoded callback Uri with a placeholder for the edited pictureName. Something like that:
images:edit?Name=MyInputImageName.jpg&Callback=myapp%3Apost%3FName%3D%7B0%7D
The Url decoded part of the Callback: myapp:post?Name={0}
This callback format string will be used in Pictures Lab to call app A and pass the edited picture back.
Makes sense?
Please let me know your thoughts and if that would be useful. Feel free to comment or reach out to me through any channel.
Pictures Lab recently added support for that as well and uses it to call the app Instagraph. This means with the help of that app Pictures Lab now provides posting / sharing on Instagram. But that's not all, Pictures Lab also supports inbound Uri associations, so you can pass an image to Pictures Lab through the mechanism of an Uri association pretty easily.
How it works
In order to call Pictures Lab from an app this scheme has to be used:
pictureslab:edit?Name=fileNameinthemedialib[&ClientId=ProductIdFromStore]
or
images:edit?Name=fileNameinthemedialib[&ClientId=ProductIdFromStore]
- fileNameinthemedialib:
This is the filename of the image in the Media library / Pictures Hub. It does not matter if the file extension like .jpg is provided or not. - ClientId:
This is an optional parameter. If it's provided then it should be the GUID that also matches the store product Id. It's not used in Pictures Lab now, but might be useful in the future to know the source of the protocol call and one could also use it to build a link like that: http://www.windowsphone.com/s?appid=ClientId
or to just launch Pictures Lab without passing an image:
pictureslab:launch
Sample code:
var photoChooser = new PhotoChooserTask();
photoChooser.Completed += async (sender, e) =>
{
// When the user selected a photo, pass the filename on to Pictures Lab for editing
var uri = string.Format("images:edit?Name={0}&Clientid={1}",
System.IO.Path.GetFileName(e.OriginalFileName),
"9902dac1-c001-440b-add5-f38446b35676");
// uri = "images:edit?Name=WP_20130527_009&Clientid=9902dac1-c001-440b-add5-f38446b35676"
var wasSuccess = await Windows.System.Launcher.LaunchUriAsync(new System.Uri(uri));
};
photoChooser.Show();
Note, it's not necessary to UrlEncode the Uri, the Windows Phone platform handles it automatically. If the user has Pictures Lab not installed and the above Uri is called, the Windows Phone OS is also smart enough to show the user a dialog which asks to search for an app in the Store that can handle the protocol. This will bring up Pictures Lab.
Conclusion
The concept of Uri associations is like the little brother of Windows 8's Share Charm, but it's still quite powerful and gives us app developers a nice way to combine our apps and make it a seamless UX. It's a win for the user and therefore it could be a win-win situation for the involved apps.
Future
For a next version I'm also thinking about a callback scenario. The user story would be: A user opens app A and wants to edit an image, this will open Pictures Lab, when the user is done with editing, Pictures Lab will call app A again. The user is back in app A with the edited image.
This callback mechanism would probably use a Callback parameter in the scheme above where app A can provide the UrlEncoded callback Uri with a placeholder for the edited pictureName. Something like that:
images:edit?Name=MyInputImageName.jpg&Callback=myapp%3Apost%3FName%3D%7B0%7D
The Url decoded part of the Callback: myapp:post?Name={0}
This callback format string will be used in Pictures Lab to call app A and pass the edited picture back.
Makes sense?
Please let me know your thoughts and if that would be useful. Feel free to comment or reach out to me through any channel.
Wednesday, December 12, 2012
Robot Work - Reducing the Windows Phone Localization Friction a bit
Windows Phone 8 now supports 3 different screen resolutions which is very nice since there are some great high resolution devices out there and the user has the choice and isn't forced into a one fits all model. However there's also a downside for Windows Phone developers since now also 3 times the amount of screenshots have to be submitted to the Store. If an app has localized versions this adds up very quickly. For example, Pictures Lab supports 11 languages and the soon-to-released v5 update for WP8 also all 3 resolutions: 11 x 3 x 8 screenshots = 264! That's a crazy amount of mindless click-through work to take all those screenshots, not to mention the Dev Center submission process.
Unfortunately there is no automated way or better support by the tools, so one has to do this ridiculous amount of manual work. In a future version of the tools I'd really love to see some kind of macro recorder which records certain steps including screenshot actions and can then use the recorded steps to play this for all supported app languages and generate the remaining screenshots automatically.
In this quick post I want to share some practices I used in order to reduce the work at least a bit for the Pictures Lab v5 update:
Unfortunately there is no automated way or better support by the tools, so one has to do this ridiculous amount of manual work. In a future version of the tools I'd really love to see some kind of macro recorder which records certain steps including screenshot actions and can then use the recorded steps to play this for all supported app languages and generate the remaining screenshots automatically.
In this quick post I want to share some practices I used in order to reduce the work at least a bit for the Pictures Lab v5 update:
- Only create screenshots for the 720p (720 x 1280) and the WXGA (768 x 1280) resolution. The WVGA (480 x 800) screenshots can be generated from the WXGA images by scaling those down by 1.6. In contrast to upscaling, are the downscaling artifacts hardly visible if a good algorithm is used. I used my favorite image viewer IrfanView and its batch processing feature which can scale down by the longest side, rename by a pattern, convert, etc.
- Add some code to easily switch between UI languages in your app so you don't only rely on the system language and need to reboot the emulator to switch languages. An app's UI language can be set globally by using
System.Threading.Thread.CurrentThread.CurrentUICulture
For example:System.Threading.Thread.CurrentThread.CurrentUICulture = new CultureInfo("de-DE");in the App.xaml.cs Launching event. - Use a macro recorder / scripting to save a bit time with the repetitive tasks of taking screenshots only with different UI languages. I used a little free tool called Mouse Recorder Pro. This tool records your mouse and keyboard actions and can then play it back also with up to 40% faster playback speed. Of course this doesn't work for all apps and only when using the emulators, esp. uncontrollable live content would likely not work, but it worked for my scenario quite well and saved me from creating all 264 screenshots manually. In fact I watched the magic ghost mouse do its job most of the time and worked on other stuff.
A few gotchas when using the Mouse Recorder Pro with the WP emulators: - Don't click on Pivot headers and rather use the swipe gesture to change between Pivot items. The header texts will have different lengths in different languages.
- Try to avoid the bounce effect of the ScrollViewer, it would result in random offsets and the Mouse Recorder playback will then have non-matching offsets recorded.
- Do a dummy save in the destination folder for the screenshots before each playback so the playback will save the files to the right folder. This will avoid file name collisions which would need manual input.
Of course there's a lot of room for improvements, but maybe the described practices help to reduce the friction that comes with localization at least a bit until a better solution is known.
Labels:
Windows Phone,
windows phone store,
wp8dev,
wpdev
Tuesday, October 30, 2012
Faster! - WriteableBitmapEx for Windows Phone 8 and WinRT Updated
The Windows Phone 8 SDK is now available and with that WriteableBitmapEx was updated too. The performance of the WinRT XAML version was also improved dramatically and an update is highly recommended.WriteableBitmapEx is available for 4 platforms: Windows Phone 8 and 7, WPF, Silverlight and Windows Store WinRT .NET XAML.
You can download the binaries here or via the NuGet package. The packages contain the WriteableBitmapEx binaries. As usual all samples and the source code can be found in the repository.
Labels:
.Net,
C#,
Computer graphics,
metro,
Silverlight,
Win8,
windows 8,
Windows Phone,
windows store,
WinRT,
Wp7Dev,
wp8dev,
wpdev,
wpf,
WriteableBitmap,
WriteableBitmapEx,
xaml
Wednesday, August 29, 2012
Update WriteableBitmapEx for WinRT RTM, WPF, Windows Phone and Silverlight
The RTM version of Windows 8 is now available and with that WriteableBitmapEx was updated too. WriteableBitmapEx is now available for 4 platforms: WPF, Silverlight, Silverlight for Windows Phone and Windows Store Style WinRT .NET.
You can download the binaries here or via the NuGet package. The packages contain the WriteableBitmapEx binaries. As usual all samples and the source code can be found in the repository.
Since the last WinRT release preview version, a couple of bugs were fixed and a new FromStrean method was added which loads an image stream into a WriteableBitmap. The project was also updated for the Windows 8 RTM version. Please read this blog post for more details about the WinRT version.
Labels:
.Net,
C#,
Computer graphics,
metro,
Silverlight,
Win8,
windows 8,
Windows Phone,
windows store,
WinRT,
Wp7Dev,
wpdev,
wpf,
WriteableBitmap,
WriteableBitmapEx,
xaml
Thursday, June 14, 2012
It's Alive! - WriteableBitmapEx 1.0 for WinRT Metro Style, WPF, Windows Phone and Silverlight
After a few preview versions, I'm happy to announce that the final version of WriteableBitmapEx 1.0 is now available.
A couple of weeks ago we added official WPF support and WinRT Metro Style support. With that WriteableBitmapEx is now available for 4 platforms: WPF, Silverlight, Silverlight for Windows Phone and Metro Style WinRT .NET.
You can download the binaries here or via the NuGet package. The packages contain the WriteableBitmapEx binaries. All samples and the source code can be found in the repository.
Since the last WinRT preview version, a new WinRT sample was added, a couple of bugs were fixed and a new FromStrean method was added which loads an image stream into a WriteableBitmap. The project was also updated for the Windows 8 Release Preview. Please read this blog post for more details (about the WinRT version).
A couple of weeks ago we added official WPF support and WinRT Metro Style support. With that WriteableBitmapEx is now available for 4 platforms: WPF, Silverlight, Silverlight for Windows Phone and Metro Style WinRT .NET.
You can download the binaries here or via the NuGet package. The packages contain the WriteableBitmapEx binaries. All samples and the source code can be found in the repository.
Since the last WinRT preview version, a new WinRT sample was added, a couple of bugs were fixed and a new FromStrean method was added which loads an image stream into a WriteableBitmap. The project was also updated for the Windows 8 Release Preview. Please read this blog post for more details (about the WinRT version).
Labels:
.Net,
C#,
Computer graphics,
metro,
Silverlight,
Win8,
windows 8,
Windows Phone,
WinRT,
Wp7Dev,
wpdev,
wpf,
WriteableBitmap,
WriteableBitmapEx,
xaml
Monday, May 7, 2012
One Bitmap to Rule Them All - WriteableBitmapEx for WinRT Metro Style
A couple of weeks ago we added official WPF support to
WriteableBitmapEx. Today I'm happy to announce that WriteableBitmapEx now also officially supports Windows 8 Metro Stlye WinRT .NET XAML. With that WriteableBitmapEx is now available for 4 platforms: WPF, Silverlight, Silverlight for Windows Phone and Metro Style WinRT .NET.
Although Direct2D is the best solution for fast 2D graphics with Windows 8 Metro Style, I think there are scenarios where the WriteableBitmapEx could be helpful, esp. when using C# with XAML. I also know that some devs were waiting for this to port their Windows Phone apps to Windows 8 Metro Style.
WinRT Differences
Unlike the Silverlight WriteableBitmap, the Metro Style WriteableBitmap doesn't provide the pixel data directly. Its IBuffer PixelBuffer property doesn't have an interface to get the color information. Fortunately there are a few C# extension methods available which provide the pixel data as byte array or stream in the BGRA pixel format. Yes, BGRA and not like all the other platforms supported by WriteableBitmapEx as ARGB. The BGRA format is mainly used by Direct2D, which might be the reason for this hidden, but important difference of the Metro Style WriteableBitmap.
The WriteableBitmapEx algorithms are written for the ARGB pixel format. Fortunately I was able to keep the details away from the library user by leveraging the BitmapContext concept we introduced with the WPF support. This approach makes it possible to share almost the same code for all 4 platforms without being cluttered with #if directives all over place. Actually the most significant WinRT adaptation inside the WriteableBitmapEx methods was done in the FromContent method, which loads an image from the app content and provides it as WriteableBitmap. See this StackOverflow question I answered if you're interested in the details.
Nothing comes for free, but if the BitmapContext is used the right way, the performance hit won't be that much thanks to an internal reference counting WriteableBitmapEx' BitmapContext uses. No worries, you don't have to change all your WriteableBitmapEx calls, just wrap your calls in a simple using(writeableBmp.GetBitmapContext()) and you will only have one buffer conversion instead of one for each draw call.
It's really simple to use:
All samples were tested with the new version, but due to the refactoring more testing is needed. Please test this version with your projects and report the bugs you encounter. You can download the binaries here. Note that this package only contains the WriteableBitmapEx binaries for Silverlight, Windows Phone, WinRT Metro Style .NET and WPF. All the samples can be found in the source code repository in the branch "WBX_1.0_BitmapContext". If all goes well, this branch will become the trunk and the 1.0 RTM in a few weeks.
WinMD / Windows Runtime Component
There's also a WinMD version available which makes it possible to consume the WriteableBitmapEx library from all the WinRT Metro Style projections, although only C# and C++ XAML make actually sense.
I had to move some parts and leave some functionality like the ForEach out, but it contains 99% of the library's features. Unfortunately the C++ sample I created crashes when the WriteableBitmapExWinMD library is loaded. So for now this WinMD version can be found in a separate branch "WBX_1.0_WinMD" in the source code repository and it won't be part of the trunk and release until it works with the sample. I'm a bit running out of time and don't know where to look for, since it seems all is wired up correctly and compiles fine. If you are a WinMD wizard and have a few minutes, I'd appreciate if you could look into the WinMD version.
Although Direct2D is the best solution for fast 2D graphics with Windows 8 Metro Style, I think there are scenarios where the WriteableBitmapEx could be helpful, esp. when using C# with XAML. I also know that some devs were waiting for this to port their Windows Phone apps to Windows 8 Metro Style.
WinRT Differences
Unlike the Silverlight WriteableBitmap, the Metro Style WriteableBitmap doesn't provide the pixel data directly. Its IBuffer PixelBuffer property doesn't have an interface to get the color information. Fortunately there are a few C# extension methods available which provide the pixel data as byte array or stream in the BGRA pixel format. Yes, BGRA and not like all the other platforms supported by WriteableBitmapEx as ARGB. The BGRA format is mainly used by Direct2D, which might be the reason for this hidden, but important difference of the Metro Style WriteableBitmap.
The WriteableBitmapEx algorithms are written for the ARGB pixel format. Fortunately I was able to keep the details away from the library user by leveraging the BitmapContext concept we introduced with the WPF support. This approach makes it possible to share almost the same code for all 4 platforms without being cluttered with #if directives all over place. Actually the most significant WinRT adaptation inside the WriteableBitmapEx methods was done in the FromContent method, which loads an image from the app content and provides it as WriteableBitmap. See this StackOverflow question I answered if you're interested in the details.
Nothing comes for free, but if the BitmapContext is used the right way, the performance hit won't be that much thanks to an internal reference counting WriteableBitmapEx' BitmapContext uses. No worries, you don't have to change all your WriteableBitmapEx calls, just wrap your calls in a simple using(writeableBmp.GetBitmapContext()) and you will only have one buffer conversion instead of one for each draw call.
It's really simple to use:
private void Draw()
{
// Wrap updates in a GetContext call, to prevent invalidation overhead
using (writeableBmp.GetBitmapContext())
{
writeableBmp.Clear();
DrawPoints();
DrawBeziers();
} // Invalidates on exit of using block
}
private void DrawPoints()
{
foreach (var p in points)
{
DrawPoint(p, Colors.Green, PointVisualSizeHalf);
}
}
private void DrawPoint(ControlPoint p, Color color, int halfSizeOfPoint)
{
var x1 = p.X - halfSizeOfPoint;
var y1 = p.Y - halfSizeOfPoint;
var x2 = p.X + halfSizeOfPoint;
var y2 = p.Y + halfSizeOfPoint;
writeableBmp.DrawRectangle(x1, y1, x2, y2, color);
}
private void DrawBeziers()
{
if (points.Count > 3)
{
writeableBmp.DrawBeziers(GetPointArray(), Colors.Yellow);
}
}
| Screenshot WinRT Metro Style sample running in the simulator |
All samples were tested with the new version, but due to the refactoring more testing is needed. Please test this version with your projects and report the bugs you encounter. You can download the binaries here. Note that this package only contains the WriteableBitmapEx binaries for Silverlight, Windows Phone, WinRT Metro Style .NET and WPF. All the samples can be found in the source code repository in the branch "WBX_1.0_BitmapContext". If all goes well, this branch will become the trunk and the 1.0 RTM in a few weeks.
WinMD / Windows Runtime Component
There's also a WinMD version available which makes it possible to consume the WriteableBitmapEx library from all the WinRT Metro Style projections, although only C# and C++ XAML make actually sense.
I had to move some parts and leave some functionality like the ForEach out, but it contains 99% of the library's features. Unfortunately the C++ sample I created crashes when the WriteableBitmapExWinMD library is loaded. So for now this WinMD version can be found in a separate branch "WBX_1.0_WinMD" in the source code repository and it won't be part of the trunk and release until it works with the sample. I'm a bit running out of time and don't know where to look for, since it seems all is wired up correctly and compiles fine. If you are a WinMD wizard and have a few minutes, I'd appreciate if you could look into the WinMD version.
Labels:
.Net,
C#,
Computer graphics,
metro,
Silverlight,
Win8,
windows 8,
Windows Phone,
WinRT,
Wp7Dev,
wpdev,
wpf,
WriteableBitmap,
WriteableBitmapEx,
xaml
Friday, January 13, 2012
Breakdown of Windows Phone App Download Statistics
![]() |
| Line Graph by Scott Lewis, Noun |
The graph below shows the download statistics of my Pictures Lab app during the last 9 months. The green line represents the daily downloads and the orange are the accumulated downloads. I blurred the numbers at the scales, since I don't release the download number for various reasons. Please note, Pictures Lab offers a trial mode which means users can try the app for free. Therefore the download numbers aren't equal to the number of sold licenses! Although the app has a pretty good conversion rate from trial-to-paid of ~32% worldwide average and in December it even was 97% in Norway! I noticed that all the Scandinavian countries seem to have a great conversion rate in general. Worst seems to be Hong Kong, but that's a story for a different blog post. Just to be clear, Pictures Lab provides me with a solid extra income each month and the trend is positive, but it's not enough to make a living out of that yet.
The absolute download numbers actually don't matter that much for this blog post. The important part of the graph are the text labels I manually added. Those labels mark events I tracked and noted at that time and are usually followed by a download peak.
![]() |
| Pictures Lab download graph from 04-01-2011 to 01-07-2012 (click on the image for the original size). |
My conclusions
- Steadily releasing updates with new functionality and being featured at the Windows Phone sites has a big impact on the downloads. Keep in mind the major Pictures Lab updates were featured at least at 3-5 of the top Windows Phone sites.
- Being featured at the Marketplace also has a significant positive impact on downloads. Of course this depends on how big the local Marketplace is. Unfortunately does the AppHub not provide the information when an app has been featured. There is the Distimo service which tracks that too, but that service needs your live id credentials and I won't give a 3rd party site my live id to store it in their database. Fortunately some of my friends ping me when they see my apps being featured in their local marketplace. I think it's pretty much safe to say that all the graph peaks without a label nearby are related to a Marketplace feature.
- The base line increased not only after the 3.0, but also after the peak of the 4.0 update. The 4.0 update brought the multi-language support with 10 languages. The steady download jump after 4.0 is a pretty good indication that localization can help to increase downloads.
- The price drop to $0.99 was followed by the highest peak in the graph, but after that it went down pretty quickly. I think the price point is the hardest thing to get right and it largely varies for different kind of apps, so the above Pictures Lab pricing information shouldn't be generalized.
- Of course Christmas, the holidays and New Year also resulted in nice peaks. Customers have time to browse the marketplace or just want to fill up their brand new Windows Phones with some apps.
What about the Windows Phone 7.5?
The first Windows Phone 7.5 (previously known as Mango) devices and Nokia hit the market in October and November 2011. This fact also needs to be considered when interpreting the graph. Although from looking at the statistics of my other apps I see that Windows Phone 7.5 didn't have such a huge impact like the updates had. The downloads definitely increased due to the Windows Phone 7.5 launch, but the tracked events align very well with the peaks in the graph and the increase of the base line after.
Let me try to clarify this and my conclusion #3 with the graphs of my successful Helium Voice Free app and my not so successful Benchmark Free app.
Helium Voice Free got a nice update in November, but I didn't inform the Windows Phone sites, so there are no peaks in the graph. You can see that the release of Windows Phone 7.5 slightly increased the downloads and the downward trend turned into an upward trend.
![]() |
| Helium Voice Free graph from 04-01-2011 to 01-07-2012 (click on the image for the original size to see numbers). |
In the Benchmark Free download graph there's also this small increase of the average downloads around the Windows Phone 7.5 device launch, but it's not as much as after the updates of Pictures Lab.
![]() |
| Benchmark Free graph from 04-01-2011 to 01-07-2012 (click on the image for the original size). |
Considering all that information, I think this means the Windows Phone 7.5 launch of course raised the downloads base line, but the Pictures Lab updates had a bigger impact on the downloads and it's not only the Windows Phone 7.5 launch which raised the average downloads of Pictures Lab.
Keep in mind that such a statistical analysis isn't bullet-proof at all, esp. when there's not all the information available like the date of all marketplace features and more. Please also note not all apps are the same and things that work for Pictures Lab or Helium Voice Free don't necessarily need to be valid for other apps.
Makes sense?
What are your conclusions?
What is your experience?
Thank you!
I would like to thank all the users of the app, the great group of translators who helped me to translate Pictures Lab, the beta testers and not at last all the great Windows Phone sites which keep us informed about all the things happening around Windows Phone and help us developers by informing the world about our apps. Keep it up!
Thursday, January 5, 2012
Let me out - Facebook Logout in a Windows Phone App
A while ago I implemented the Facebook photo endpoint into my Windows Phone Pictures Lab app. The implementation of the login was quite straightforward thanks to OAuth 2.0. Only the logout was way harder than one might expect. This post describes how to logout from Facebook using the Facebook API.
In my Pictures Lab app you can edit photos, make them look awesome and then save or share those with your friends at Twitter or Facebook. The Windows Phone Mango API provides the ShareLinkTask and the ShareStatusTask which can be used by an app to share an URL or text using the social services the user has connected the device to. Unfortunately there's no built-in SharePhotoTask to share a photo using the services the user has already authorized. That's why I had to implement it in a custom way where the user has to authorize again. This blog post by my mate Nick Randolph describes very well how to login to Facebook from a Windows Phone app.
For some situations it might make sense to allow the user to logout from within the app. One might think this can't be hard and in most cases it's pretty easy. Logging out from Twitter is very easy for example. You just have to start the authorization process again. However, logging out from Facebook is way harder since they store a cookie and the WebBrowser control doesn't provide a way to clear the cookies, so just starting the authorization process again doesn't work.
One way to log out from Facebook uses a special Uri that contains a part of the access token which was queried during the app authorization process.
Here's the snippet I use in Pictures Lab to split the access token to get the session key which is then used to build the custom Uri:
That logout Uri is then used to navigate the WebBrowser control to it which then correctly triggers the log out process.
That's it. You just have to know their trick. Hope this helps.
In my Pictures Lab app you can edit photos, make them look awesome and then save or share those with your friends at Twitter or Facebook. The Windows Phone Mango API provides the ShareLinkTask and the ShareStatusTask which can be used by an app to share an URL or text using the social services the user has connected the device to. Unfortunately there's no built-in SharePhotoTask to share a photo using the services the user has already authorized. That's why I had to implement it in a custom way where the user has to authorize again. This blog post by my mate Nick Randolph describes very well how to login to Facebook from a Windows Phone app.
For some situations it might make sense to allow the user to logout from within the app. One might think this can't be hard and in most cases it's pretty easy. Logging out from Twitter is very easy for example. You just have to start the authorization process again. However, logging out from Facebook is way harder since they store a cookie and the WebBrowser control doesn't provide a way to clear the cookies, so just starting the authorization process again doesn't work.
One way to log out from Facebook uses a special Uri that contains a part of the access token which was queried during the app authorization process.
Here's the snippet I use in Pictures Lab to split the access token to get the session key which is then used to build the custom Uri:
public Uri GetLogoutUri(FacebookCredentials credentials)
{
var sessionkey = ExtractSessionKeyFromAccessToken(credentials.AccessToken);
var url = String.Format("http://facebook.com/logout.php?app_key={0}&session_key={1}&next={2}", EndpointData.FacebookAppId, sessionkey, EndpointData.FacebookLogoutCallbackUrl);
return new Uri(url);
}
private static string ExtractSessionKeyFromAccessToken(string accessToken)
{
if (!String.IsNullOrEmpty(accessToken))
{
var parts = accessToken.Split('|');
if (parts.Length > 2)
{
return parts[1];
}
}
return String.Empty;
}
That logout Uri is then used to navigate the WebBrowser control to it which then correctly triggers the log out process.
Browser.Navigate(FacebookService.GetLogoutUri(EndpointData.Settings.Facebook));
That's it. You just have to know their trick. Hope this helps.
SLARToolkit Samples Updated
Please note the changed security model in Silverlight 5, which is a big bummer. My Silverlight MVP friend Morten wrote a few true words about it here.
As usual you can find a list of the samples on the project site and also get the code there.
Labels:
3D,
Augmented Reality,
C#,
Computer graphics,
HLSL,
Mango,
Mobile,
Open Source,
Shader,
Silverlight,
Silverlight 5,
SL53D,
SLARToolkit,
Windows Phone,
wp7,
Wp7Dev,
wpdev
Subscribe to:
Posts (Atom)



















