Switching to Firefox again

The other day I stumbled upon the article Windows Timer Resolution: Megawatts Wasted and to make long story short, I ran powercfg -energy duration 5 on my system and found that Chrome, Spotify and Naver’s Line client for Windows were making my system to increase timer resolution to 1 ms, wasting energy and making my laptop run warmer than expected.

So I’ll be switching back to Firefox after quite a while using Chrome as my main browser, at least for regular browsing. Let’s hope Google fixes this soon.

Also, I’ve switched to Windows Store App version of Line client (my system runs Windows 8.1), and I’m considering what to do with Spotify.

UPDATE: maybe I’ve switched browsers too fast: now I’m seeing Firefox also increasing timer resolution to 1 ms! Possible causes:

  • Plugins (Flash, maybe?)
  • Google Mail
  • donno…

I’ll keep you posted.

Disabling right click and swipe on Windows Store Apps without using code-behind

A month ago I was working on a Windows Store project and I needed to disable right click and swipe for some grid controls. Of course, the property to disable/enable swipe is well known: IsSwipeEnabled. Just put a false there and you’re ready to go! But I could not find an equivalent property to disable right-click, and IsSwipeEnabled does exactly what it says: disable swipe touch gesture, but has no effect on right-click (which you may expect it will, because right-click is the equivalent manipulation using mouse).

Anyway, I found that the only way to disable right-click was to handle the right-click event, using code. So, my first thought was using code behind, and add an event handler and tell the remaining handlers that I handled the event already. So an event handler like this one should do it:

private static void RightClickEnabledProperty_RightTapped(object sender, Windows.UI.Xaml.Input.RightTappedRoutedEventArgs e)
    e.Handled = true;

But then, I thought I rather had a property implemented to be able to use it whenever I wanted without having to add more code behind to each XAML. So, here is the implementation for this property:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Windows.UI.Xaml;

namespace App.Properties
    public class RightClickEnabledProperty
        public static readonly DependencyProperty IsRightClickEnabledProperty =
            DependencyProperty.RegisterAttached("IsRightClickEnabled", typeof(bool), typeof(RightClickEnabledProperty),
                                                new PropertyMetadata(true, IsRightClickEnabledPropertyChanged));

        public static void SetIsRightClickEnabled(DependencyObject attached, bool value)
            attached.SetValue(IsRightClickEnabledProperty, value);

        public static bool GetIsRightClickEnabled(DependencyObject attached)
            return (bool)attached.GetValue(IsRightClickEnabledProperty);

        private static void IsRightClickEnabledPropertyChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
            bool? value = e.NewValue as bool?;
            if (!value.HasValue || value.Value)
                (d as UIElement).RightTapped -= RightClickEnabledProperty_RightTapped;
                (d as UIElement).RightTapped += RightClickEnabledProperty_RightTapped;

        private static void RightClickEnabledProperty_RightTapped(object sender, Windows.UI.Xaml.Input.RightTappedRoutedEventArgs e)
            UIElement control = sender as UIElement;
            if (control == null)

            if (!GetIsRightClickEnabled(control))
                e.Handled = true;


The downside of this is that the property must be defined in the item itself (usually in the top-level control or container inside the ItemTemplate), while the IsSwipeEnabled property is defined in the Grid or ListView itself.

See an example (remember to define the namespace in the root node of the XAML, like: xmlns:properties="using:App.Properties"):

    ItemsSource="{Binding ElementList}"
    SelectedItem="{Binding SelectedElement, Mode=TwoWay}"
                Text="{Binding ElementName}"

Hope this helps to keep your XAML a little more clean, with less code-behind.

Showing a rotation-locked activity programatically in Android

Sometimes you need an activity showing in a locked orientation (i.e. no rotation allowed), but you need to decide which orientation should be the activity display dynamically by code. In my case, I had to implement a chroma-keyed camera app and the backgrounds where either landscape or portrait. When the user tapped the background to use I had to decide the orientation and lock the new camera activity to this orientation.

My first thought was using setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_x); on the onCreate() in the activity, but I found that was not reliable. In some cases the screen didn’t lock and rotated freely. I was doing my tests in a Honeycomb Galaxy Tab, so I’m not sure if in 4.x this method should work.

Finally, the method I used and that worked flawlessly was declaring two different activities in the manifest, using android:screenOrientation attribute:

 android:theme="@style/AppTheme.NoActionBar" />
 android:theme="@style/AppTheme.NoActionBar" />

The trick is not duplicate the whole class code, but to put all the logic in a base class ActivityCameraBase and derive two subclasses with the names ActivityCameraLandscape and ActivityCameraLandscape. Also, there will be a single layout file, for both orientations.

Activities detail

package com.xrubio.retrats.activity;

// imports here

// This class is used to be able to have two different orientations,
// locked at manifest level, so we're able to select which orientation
// we want the camera be locked at programatically, without having to
// reimplement everything again.
public class ActivityCameraBase extends Activity {

  public void onCreate(final Bundle savedInstanceState) {

    // remaining initialization stuff...

  // remaining activity logic...
package com.xrubio.retrats.activity;

public class ActivityCameraLandscape extends ActivityCameraBase {
  // Look, ma, the class is empty!
package com.xrubio.retrats.activity;

public class ActivityCameraPortrait extends ActivityCameraBase {
  // Look, ma, the class is empty!

Notice, however, that you can have two different layouts if you need your layout to be different in landscape and portrait, but keep the logic the same. In this case you will put your portrait layout in the regular layout directory, and your landscape layout in the layout-land directory, using the same name.

Different layouts detail