Android screen sizes

For my own reference, but possibly interesting to others. 

Android screen sizes of note:

ldpi: small screens in low numbers
mdpi: range of sizes and quite popular
hdpi: most popular
xhdpi: very few devices

summary: must support normal screens at hdpi and mdpi densities.

See more at http://developer.android.com/resources/dashboard/screens.html

See also, the android guide to supporting multiple screen sizes.

Think mobile at DDD South West

If you're not aware of the DDD (or Developer Developer Developer) series of community events then you've missed out. They provide a great opportunity to learn what's new in the .Net community. Or, officially:

DDD South West is a free one day technical event for developers. It is a day of learning, discussing, contributing and being part of the community in the South West. Our goal is to provide free technical education, the opportunity to mix with peers and to make and develop relationships in the .NET industry.

If you're interested in going to the event then I'd love to be able to talk to you about how an understanding of developing for mobile provides a great gounding for developing for other (non desktop/PC) platforms too. If you'd like to hear it that means voting for my session once you've registered/logged in to the site.

If you're undecided then let me make 2 points.

• When I've talked about this subject before (at DevEvening, Cheltenham, Edinburgh, Dundee & Aberdeen - either on it's own or as part of an introduction to Windows Phone development)  it's always proved really popular, prompted lots of positive feedback and people have been helped to think about new things or think about things in new ways which they've found helpful.
• A full day of technical content can be very challenging and tiring. Sometimes it's useful to take a bit of a break and just listen without having to follow along while someone writes code or explain complex new concepts. Let this session be a welcome break in your day at DDDSW.

So you want some help?

Warning: Rant!

So you want help with something.
Ok.

Now make it easy to help you.

I get a bit annoyed by people posting questions (on SO mainly) with a vague problem or descriptions of what's been tried but no actual code

    Deliberately including no examples to protect the guilty


Before you ask for help, please read the following:
http://stackoverflow.com/questions/how-to-ask
http://tinyurl.com/so-hints 
http://www.codinghorror.com/blog/2012/03/rubber-duck-problem-solving.html

It'll help us to help you.
We want to help, just don't make us jump through unnecessary hoops.


Not just a rant, I also wanted a place I could quickly find the above links again.;)

Ideas of March | #IdeasOfMarch

As prompted by http://shiflett.org/blog/2012/mar/ideas-of-march

I like blogs.
I read the titles of hundreds of blog articles each day and usually end up reading dozens of posts.

There are 2 main reasons (that I can think of right now) that I like blogs though:

1. I like how anyone can write a blog. Yes, even little old me. Blogs have allowed me to read the thoughts, ideas, experiments, plans and more of hundreds of people. And I'd never have even heard of or met most of them if it wasn't for their blog.
Not that this means I think everyone should write a blog though. And yes, I include myself again there sometimes. ;)

2. Blogs are probably the way I learn most new things in the software development world. Yeah, StackOverflow is probably up there too, but all the important and useful information in software dev seems to come from individuals experiences and not from official documentation. I'm certain that if no-one was blogging I'd spend more of my time fumbling through badly orgainsed and ill structured documentation.

Thank you bloggers of the world.

Slides from last months Scottish user group talks

Last month I went to Scotland to talk at some user groups about Windows Phone development and general mobile development principles that can be applied to all platforms.
I've had some requests for the slides from those talks. (The latest evolution of the slides since the last time I gave these talks.) So here they are:

Thinking mobile and beyond (Edinburgh & Dundee)

View more from Matt Lacey

Awesome Windows Phone Development (Aberdeen)

View more from Matt Lacey

NanoIOC - How I do Depenedency Injection on #WP7

When it comes to Dependency Injection / IOC  there isn't a good story for Windows Phone*.

There's nothing built in and lots of people have created their own solutions. Including, but not limited to,: Funq, MicroIoc, TinyIoc, this or this. But none of them work the way I want to.

I want:

• Automatic constructor parameter injection
• Explicit indication of where a dependency exists
• Explicit configuration of how dependencies should be resolved
• Fluent configuration

I don't want:

• Parameter injection
• Automatic resolving of dependencies
• An aribtrary ServiceLocator

I don't care about:

• Letting the container manage singletons
• Nested/chained dependency resolution

There are two factors which influence my requirements:
1. My past experience with Castle Windsor - Chosen after evaluating what was available at the time (about 4 years or so ago.)
2. My experience with working in development teams where there would always be at least one person who wasn't interested in learning anything new, best practices or, seemingly, code quality. I've learnt that if you're working with such people, or anyone new to the industry, that you'll save yourself a lot of work (in fixing up their errors, mistakes and repeatedly explaining things to them) if everything is explicit and clear and not "magic" because if they can't understand it they can't update it or fix it if there's a problem.


So I've written something myself: http://github.com/mrlacey/NanoIoC

As pointed out in the comments, this doesn't provide automatic constructor injection. Unfortunately the platform just doesn't support a way of doing that. This is my next best thing. - Hope that makes it clearer.

Yes, the name is a tounge-in-cheek reference to MicroIoc & TinyIoC but hints that mine has much less code. (It's less than 90 LOC.)
Yes, I know it's more of a DI framework than an IOC one but the terms are used fairly interchangable out in the real world so I'm happy with this.

How to use it:

For the class that has some external dependencies, we declare this by marking them up with an interface "ISupportInjectionOf<T>". As an example, if we wanted to indicate a page had a dependency up an "IRepository" and an "IDateTimeHelper" we'd do this:

    public partial class MainPage : PhoneApplicationPage,
                                    ISupportInjectionOf<IRepository>,
                                    ISupportInjectionOf<IDateTimeHelper>
    {

Then within our constructor we'd resolve these dependencies:

        private IRepository repository;

        private IDateTimeHelper dateTime;

        public MainPage()
        {
            InitializeComponent();

            repository = this.GetDependency<IRepository>();
            dateTime = this.GetDependency<IDateTimeHelper>();
        }

Yes, we could resolve the dependencies at any time, but in my code it'll always be in the constructors.
This is important for maintaining testability and maintainability. (I'm establishing a convention.)
In the above example I'd also include a constructor overload for directly injecting the dependencies during testing:

#if TEST
        public MainPage(IRepository repo, IDateTimeHelper dateTimeHelper)
        {
            InitializeComponent();

            this.repository = repo;
            this.dateTime = dateTimeHelper;
        }
#endif

Simple!


Configuration:

Configuration is simple and done at app level. We can declare how each dependency should be resolved separately:

    NanoIocConfig.RegisterDependency<IRepository>(new ViewModelRepository());
    NanoIocConfig.RegisterDependency<IDateTimeHelper>(new DateTimeHelper());

Or via a fluent interface:

    NanoIocConfig.RegisterDependency<IRepository>(new ViewModelRepository())
                 .And<IDateTimeHelper>(new DateTimeHelper());

Obviously these examples all use interfaces. But we don't have to. Assuming that we didn't want to hide "DateTimeHelper" behind an interface, we can just do this (note the type is inferred):

    NanoIocConfig.RegisterDependency(new DateTimeHelper());

    dth = this.GetDependency<DateTimeHelper>();

The above examples are all creating an instance to use for every time the dependency is resolved.
Instead, we could pass an instance of a singleton in the traditional way:

    NanoIocConfig.RegisterDependency<IRepository>(ViewModelRepository.Instance);

If you want different instances each time a dependency is resolved simply pass a factory and get the new instances that way.


What do you think?

Useful?
Interesting?
Something you may consider using?
Want it bundled into a NuGet package? (Either as a library or the single source file)

I'd love to know what you think.


* It would be awesome if in a (prefereably near) future version of the Windows Phone SDK, it included tooling to allow it to be easier to implement good development practices in our Windows Phone code. It's awesome that they've made it easy for people to get started with developing for the platform but those beginners need, in time, to know how to write better code and if the tools stop them there's no incentive for them to learn. And for those of us who consider ourselves professionals and do this for a living, we want to be able to apply best practices to our code (work) and not have the SDK and the tooling get in the way and stop us doing basic things.

Metro designs require imagination but provide endless possibilites.

I've heard it claimed that due to the restrictions that are imposed on Metro style apps "they're all going to end up looking the same" and "there's no opportunity to differentiate".

I'm calling BS on this.

Not only are people making such claims forgetting about the myriad applications which were all battleship grey and/or seemed to want to copy Outlook regardless of whether it made sense or not.
Such claims are focusing on the restrictions and ignoring the opportunities. Metro is intended to "inspire innovation".

Let's consider some other design opportunities which may be considered restrictive:
Watches are simple things. They have a strap and a face. If digital they'll show some numbers. If analog they'll have two or three hands. In theory that's very limited, but there are thousands of different looking watches available.

Or consider shoes. They have an upper, a sole, a heel and possibly some kind of fastening. Again, that's a very simple set of components but again, there are thousands and thousands of shoes available and they can look wildly different from each other.

Within an application we have many more options and possibilities when compared with something simple like a watch or a shoe.

If you find apps are starting to look the same then it shows a lack of imagination and creativity by the person(s) creating the app. It's not a limitation of the platform. It's a limitation in the imagination of the people creating them.

Debugging deserialization errors in JSON.NET

Ever have a problem handling deserialization issues with JSON.NET?
Did you know it has built in functionality to help debug deserialization errors?
Well, it does.

To help debug such scenarios you can do something like this:

   if (!string.IsNullOrEmpty(json))
   {
       var settings = new JsonSerializerSettings
           {
               Error = (sender, args) =>
                       {
                           if (System.Diagnostics.Debugger.IsAttached)
                           {
                                System.Diagnostics.Debugger.Break();
                           }
                       }
           };
 
        result = JsonConvert.DeserializeObject<T>(json, settings);
   }

I find that being able to get into the debugger when something won't deserialize I can quickly and easily identify the cause of the issue.

Hope this is useful to someone

Want help with Tombstoning?

I originally built TombstoneHelper to try and make it a bit easier to handle tombstoning in Windows Phone 7 apps. It covers some of the basics but doesn't go as far as most people need and their is still lots of confusion, amongst many, about how to handle tombstoning in an app.

I think I've finally got a good enough idea about the best practices for how to handle tombstoning for almost all situations and, probably more importantly, I've got some time to update the TombstoneHelper library.

But I have a couple of questions:
Is anyone interested in an updated TombstoneHelper? which would handle ViewModels too.
Are you usingthe current version?
How else do you handle tombstoning in your apps?