Where did the SystemTray vanish with #WinPRT #wpdev?

With Silverlight WP8 API, SystemTray is exposed in PhoneApplicationPage through Microsoft.Phone.Shell.

<phone:PhoneApplicationPage
    shell:SystemTray.IsVisible="True" 
    shell:SystemTray.BackgroundColor="AliceBlue"
    shell:SystemTray.ForegroundColor="Black"
    shell:SystemTray.Opacity="0.75">
    <shell:SystemTray.ProgressIndicator>
        <shell:ProgressIndicator />
    </shell:SystemTray.ProgressIndicator>
</phone:PhoneApplicationPage>
SystemTray.BackgroundColor = Colors.Cyan;
SystemTray.ForegroundColor = Colors.White;
SystemTray.IsVisible = true;
SystemTray.Opacity = 0.8;
SystemTray.ProgressIndicator = new ProgressIndicator() { IsIndeterminate = true, IsVisible = true };

it was very easily done through xaml itself. You could do it from codebehind by accessing static properties of SystemTray class.
However with WinPRT, the Page class does not expose SystemTray and now it lives as Windows.UI.ViewManagement.StatusBar.
No xaml declarative business here.

var statusBar = StatusBar.GetForCurrentView();
statusBar.BackgroundColor = Colors.Black;
statusBar.BackgroundOpacity = 0.8;
statusBar.ForegroundColor = Colors.White;
statusBar.ProgressIndicator.Text = "loading";
await statusBar.ShowAsync();

If I find anything declarative, I will post those at a later date.

Backbutton handling with #winprt and Windows Phone 8.1 #wpdev

Back with WP8 and Silverlight API, handling hardware back button was easy peasy. By default, PhoneApplicationPage exposed an eventhandler called BackKeyPress. Developers could chose to subscribe to this event handler and handle the back button.

<phone:PhoneApplicationPage shell:SystemTray.IsVisible="True" BackKeyPress="PhoneApplicationPage_BackKeyPress">
...
...
...
</phone:PhoneApplicationPage>
private void PhoneApplicationPage_BackKeyPress(object sender, System.ComponentModel.CancelEventArgs e)
{
    if (this.DrawingCanvas.Visibility == System.Windows.Visibility.Visible)
    {
        this.DrawingCanvas.Visibility = this.ColorSlider.Visibility = System.Windows.Visibility.Collapsed;
        this.piWords.IsLocked = false;
        e.Cancel = true;
    }
}

As you can see, in the back key press, I check to see if certain view is being shown and if so, I hide it that rather than navigating page backstack.

That was Silverlight / WP API.. how would we do that in WP8.1 / WinPRT API ?
Windows.Phone.UI.Input namespace contains a class called HardwareButtons. just remember this is WP8.1 WinPRT API only – not supported on Windows store apps. Sadly no XAML wiring up.. lets go to codebehind and subscribe to it


public MainPage()
{
    this.InitializeComponent();

    this.NavigationCacheMode = NavigationCacheMode.Required;

    HardwareButtons.BackPressed += HardwareButtons_BackPressed;
}

void HardwareButtons_BackPressed(object sender, BackPressedEventArgs e)
{
    if (some_condition)
    {
        e.Handled = true;
    }
}

That’s about it.. thank goodness I still have Dev preview documentation lying around :)

Certification Requirements update: Location Services Access #wpdev

Every since I can remember (at least 2 years now), the windows phone store’s certification requirements required:

  1. A store link to privacy policy
  2. Option to disable app’s use of location services.

If you didn’t do either of those two, the certification would fail (after about 7 days) and you would start again. However a fortnight back my Cineworld app failed a tiny update why ??? cause the update to certification requirements dictate that you also provide in app privacy policy (or a link) – not just on store.

Here are the new set of requirements:

App Policies: 2.7.2 Location Services Access

The privacy policy of your app must inform users about how location data from the Location Service API is used and disclose and the controls that users have over the use and sharing of location data. This can be hosted within or directly linked from the app. The privacy policy must be accessible from your app at any time.

Notification/Action Requested:

The app uses location services, however one or more of the following is missing:

  • A persistent privacy policy in-app
  • A privacy policy URL that is accessible through the Windows Phone Store
  • A privacy policy that is unique to the app

If you encounter certification failure, add a hyperlink button and point it to online privacy policy at the very least. Oh and in case you are wondering,  this used to be a Window 8 Store requirement – one store coming to devices near you ???

Nokia Normandy Take 2 ?

Last week I blogged my thoughts about Nokia Normandy and how unlikely it is.. since then (and not because I had anything to do with it) there has been talk about Nokia / Microsoft forking Android. The Verge posted about it.. so did WSJ so did Reuters.. Ed Bott wrote a nice summary as well :).

Ignoring all that.. I still think forking android is pretty big deal.. but what about this ?

* Asha as it stands today has a few Microsoft services and a few Nokia services. Post buy out, Nokia services will transition to Microsoft versions of the same ?

Android itself is a patent minefield and so is Dalvik but what if Nokia just forked Dalvik ? not the whole Android stack, just the runtime that will enable many apps to run ? Blackberry has done it.. so has Jolla.. so why can’t it be done for Asha ? Is it that big a deal ?

That would make Normandy Android like yet retain most of Microsoft driven services..

Nokia Normandy – a cause for concern ?

A Nokia Android device would be mean a wet dream for many :) Being a ‘softie at heart, I was very glad to have Nokia joining Microsoft as a Windows Phone Partner. Now and again I see examples of how they might have contributed to certain API

Of course I have read umpteen number of times that Nokia would have been better off had they gone with Android. Every 2nd person would tell you that they love Nokia’s industrial design and if offered a choice,  they would jump to Nokia’s android offering (if there was one). Enter Normandy – an extensively leaked device that has generated much marketing for Nokia – Metro UI skinned over Android. This has left many salivating…

So will Normandy see the light of the day and what happens when Microsoft completes the purchase of Nokia Devices division ? Is it really a Trojan horse like many would like to believe ?

The more I think about it, the more unlikely it seems – every decision whether its short term or long term is based on economics. Lets start with licensing

Licensing cost:

Google’s Android source is freely available and anyone can fork it and use it create a custom android distro. Most stock android apps are a part of Google services and that has to be licensed. While OS can be used freely, getting a forked distro at part requires considerable work.

Additionally from the approximately $220 million income, a guestimate mentioned something in the region of $200 million as patent related income from Android device manufacturers etc. If Microsoft itself adopts Android, I doubt it can continue to collect patent licensing fees – must read on reciprocal licensing terms of android later.

Its all about Services:

That is an interesting notion. Apple primarily makes money off device sales and all supporting services generally break even – even with multi billion downloads, the App Store and related income just breaks even. In Android world, Samsung makes more money from Android than Google primarily because its hardware margins that generate most revenue.

Of course google does have plenty of services and in addition to licensing them, Search is the only service that makes most contribution.

What would Nokia in the short term and Microsoft in intermediate term bring forward for Normandy ? Well Microsoft’s Bing and Xbox related services. Whilst Bing is great for English language results, I don’t know any non-English speakers who use Bing. Xbox Live doesn’t really work on Phones, Music / Videos are just that – they provide an option just like iTunes or Google Play. Office would be nice but again it doesn’t earn any money on devices.

Having Office and a few other core application would sweeten any Microsoft offering however would generate little revenue Oh and there’s Skype – it offers better products on iOS and Android than Windows Phone

Flood market with cheap device:

Normandy’s spec are very much like those of Lumia 520. While that is one of the most selling windows phone, I always advice people to buy 720 or better. One of the newest / cheapest Android Devices – Moto G has a substantially capable hardware. If Nokia / Microsoft take on Android, they will spend a good amount of time optimising runtime to make it run on poxy hardware. Again if the expectation is to win the market with low end devices, there is little money to be made from devices.

Final thoughts

I personally feel that all these considerations make it very unlikely that Microsoft will ever touch Normandy. Microsoft has agreed to purchase Devices division and both Asha and Lumia brands will come over to Microsoft. There is no mention of Normandy and that would have to be an additional consideration. I think Normandy was means to make Microsoft take Nokia seriously. Nokia itself (once transaction goes through) can only release anything mobile on 1st Jan 2016.

If you want me to speculate, i’d say there is a greater probability of Normandy staying hidden until 2016 – of course weird this have happened.

Photo / Camera API – 1 #wpdev

My memory of Windows Phone NoDo API set is pretty bleak. I distinctly remember presence of CameraCaptureTask and PhotoChooserTask. I think I used PhotoChooserTask with my first app Scribble. So what’s this post about ? well Photo / Camera options available on Windows Phone 8.

Since I started with the two tasks, they still exist in Windows Phone 8.

CameraCaptureTask: this fires the stock camera app – ability to navigate to camera roll and use other lens is blocked but otherwise it is the stock windows phone app. Tap to focus / capture or use dedicated shutter button. On capture you are presented with a preview and you have the option to accept or retake the capture.

wp_ss_20140130_0005 wp_ss_20140130_0006 wp_ss_20140130_0007

PhotoChooserTask: this is a different beast. This opens photos hub and presents user with list of albums allowing user to select a photo. The Task has a parameter that toggles visibility of camera icon – ability to not just select a picture but also initiate CameraCaptureTask from within.

While both of these are very basic, let me point out that Instagram BETA still uses a layout very similar to Photochooser task and obviously uses Camera Capture Task.

Its very likely that Instagram could get away with murder. Most of us – 3rd party developers however do not have such luxury. We would be termed as lazy if not worse. And you might not want the stock camera UI. So what can you do ? I am still in old API mode so let me mention an API that was part of Mango – I don’t know if NoDo had it or not – I only used it after Mango public release in my Cool Camera app.

PhotoCamera Class: this class provides raw access to camera and exposes a few options like resolution, flash and focus. Apps render live view by means of using a video brush whose source is set to an instance of photo camera class. How to create a base camera app for Windows Phone provides a great sample to kick start camera app development using this class

PhotoCamera

For a camera app, call CaptureImage. Others might not need a full blown capture – something like QR scanning app would just use focus and can do with GetPreviewBufferArgb32.

Whilst this is a good start, the API is not extensive enough for anything beyond basic. In the next post, I will discuss PhotoCaptureDevice class. This class though simple, exposes enough API to create a full blown camera app allowing you to control every single aspect of camera. If you hardware supports it, you should be able to utilise it

Camera / Imaging fragmentation #wp8 #wpdev #windowsphone

This post has been long coming… should be started it back when I first heard of Nokia Music API prior to new of Microsoft’s purchase of Nokia Devices division.

We all know Microsoft Windows Phone Dev team isn’t the fastest beast when it comes to pushing out new API. Many (myself included) welcomed Nokia’s SDKs with open arms as they can turn things around much faster.

We know that public 3rd Party Windows Phone API is fixed and involves querying for supported values – this makes supporting various bits of functionality across manufacturers easy. I am not referring to fragmentation of this.

When Nokia announced 1020, they pushed for a concept of reframing. They take two pics, high resolution and a low resolution. you as a user can only see low res on device. It doesn’t just end there, even the OS itself even through it can handle high res images is only aware of low res images. Wait!! What are am I going on about ? The OS doesn’t know about high res images even through they physically reside on the same physical directory.

If you ever wondered about how the images are stored.. let me give you a clue. according to Windows Phone, the camera roll points to “C:\Data\Users\Public\Pictures\Camera Roll” something the shared Windows NT kernel gave WP8 :)

If you try to programmatically access this location, you are greeted with System.UnauthorizedAccessException.

With Lumia Black update, Nokia is bringing DNG support to devices. Whilst this is good news on the surface, it uses the same hack as the one used for high res – the device is unaware of it.

This leads to multitudes of device tiers hardware and software capabilities which are carefully controlled outside of public API and outside of Microsoft WPDev team itself.

At some point last year, I did ask Stephen Elop if APIs will merge once Devices division merges.. sadly all he replied was that he couldn’t comment on future.