Googles advice to those building Android tablet apps is also useful when porting from Windows Phone to Windows 8

Goolgle has a tablet app quality checklist recommended for anyone wanting to publish an app for Android tablets in the Play store.

It's no doubt useful for anyone porting their first Android app to run on a tablet (from a phone) but most of the points apply regardless of the OS being used and so could apply to those of you making the transition from Windows Phone to Windows 8.

As an idea of how it is relevant, see this partial* list of section headings:

1. Test for Core App Quality
2. Optimize your layouts for larger screens
3. Take advantage of extra screen area available on tablets
4. Use Icons and other assets that are designed for tablet screens
5. Adjust font sizes and touch targets for tablet screens
7. Offer the app's full feature set to tablet users
8. Don’t require hardware features that might not be available on tablets


* Android specific sections ommitted.

Check out the full details: http://developer.android.com/distribute/googleplay/quality/tablet.html

Let me know if you find this useful.

Security and access to SMS

Lots of Windows Phone developers want access to SMS*. It's an interesting data source and can allow the creation of lots of useful, helpful and interesting apps. There are security implications of allowing such access though and, unfortunately, most developers seem happy to ignore this or not take it seriously.

Today I heard about a scam that was only possible due to SMS access and "stole an estimated 36+ million Euros from more than 30,000 bank customers from multiple banks" (emphasis mine).


You can read more about the Eurograbber attack here but I think the important takeaway for developers is to focus on security and not easily dismiss or criticise platform limitations and restrictions that are there to protect the person who's phone it is.


And for everyone entering passwords or security information on a website. Always type in the domain for a website directly. Avoid following links, especially if it's a shortened or redirect link.


* If you don't know, Windows Phone does not allow developers of third party apps to access a phone's SMS history as part of it's strategy for protecting data security.

Found via Simon Judge.

WP8 lock screen alignment issues

Anyone else seen issues with the lock screen alignment? Like above?
It's like it's started to scroll over to kids corner but got stuck part way across. As the image on the right shows, it's staying like that even when scrolling up to reveal the start screen.
It's not a critical issue but I wondered if others have experienced this.

Deployment Error 0x89731800

I got this error today when deploying a XAP file to an emulator and the only reference I could find to it was a 7 year old message in Chinese.

Fortunately I got round this problem by closing the emulator and then reattempting the deployment and all was good.
Just thought this might help out someone else who comes across this issue.

My #AlphaLabsCC developer diary

I was recently involved in a project for Alphalabs.

If you don't know, Alphalabs is a project sponsored by Nokia with the aim to inspire app developers to be more creative.

As part of my work I was asked to keep a diary of thoughts, notes, ideas, problems, etc. while the development was being done. The original plan was that this would be released bit by bit as part of regular (daily?) emails to those who were initially invited to take part in this years project "the always on telephone club".

Plans have changed and my entries have now all been posted at http://alphalabs.cc/matt-laceys-developer-diary/

If you want an idea of what I was thinking during the development or when I got weird errors or my Azure account was suspended when we load tested the app then take a look.

You may also notice that the "diary" entries all have titles, rather than dates (and times). This was just me trying to hide the inconsistent nature of the work and the fact most of it was done in the middle of the night. ;)

More on my opinion about commands

Last week I wrote about  "A bad way to set up commands in your view model".
This prompted a few comments and strong opinions in both the comments and on twitter.

My main intention with the post was originally to rally against creating properties with a private setter when they will only ever be set once and the code that does the setting is kept apart from the property.

All things being equal I'd rather maintain code that looks like my preferred code than the first example.

I do, however,appreciate that this is not optimal in all situations. I've just spent lots of time working with code that does trivial things in the command or are executed occassionally and so the overhead of creating a new command each time it's needed is not an issue.

For the avoidance of doubt, I'm perfectly fine with any of the following when used at an appropriate time.

    public class MyViewModel : ViewModelBase
    {
        private RelayCommand myCommand;

        public RelayCommand MyCommand
        {
            get
            {
                if (myCommand == null)
                {
                    myCommand = new RelayCommand(() =>
                    {
                        // some functionality here
                    });
                }

                return myCommand;
            }
        }
    }

or

    public class MyViewModel : ViewModelBase
    {
        private RelayCommand myCommand;

        public RelayCommand SaveCommand
        {
            get
            {
                if (myCommand == null)
                {
                    myCommand = new RelayCommand(this.Save);
                }

                return myCommand;
            }
        }

        private void Save()
        {
            // do something
        }
    }

and I've used both in the past.


Anyway, moving on...