The 256MB device difference which isn't documented

The 7.1.1 SDK update allows us to support and detect devices with only 256MB and there are a few noted points of things to avoid on the 256-MB devices. Recently I've discovered another one.

32Bit image support!

256-MB  images only support displaying images at 16 Bits Per Pixel.

For most cases this isn't a problem, but if you're using gradients it may be.

Let me demonstrate with a simple app.
The app just shows an image with a gradient (from red to cyan) and an indication of if we're running in the regular emulator (with 512MB of memory) or the version with 256MB.

Here's what it looks like by default on the 512-MB emulator.

You'll notice the banding of the color in the gradient.
The standard way we'd adjust the app to cope with this would be to configure the app to use 32bits per pixel-which is enough to show the full range of colors in the gradient.

From WMAppManifest.xml:

<App BitsPerPixel="32"

There. Much better. No banding.

But what if we flip over to the other emulator the problem returns.

Oh no. The banding is back. And yes, we have still configured to use 32 BitsPerPixel

But, you may be thinking, perhaps this only affects the emulator.
No. I've tested this on a Nokia Lumia 610 (which is a 256MB device) and the same thing happens there.

So what can we do?

We can dither the image.

Voila. A lot less banding.

Now we can use a gradient image in an app on a 256MB device without banding.

The dithering in the above example was done with the tool from http://adtsai.blogspot.co.uk/2011/03/high-quality-dithering-for-windows.html


On the plus side we can use this same image on 512MB devices without the need for the memory overhead of using 32BPP.

On the negative side the dithered image is larger though.


Presumably, this lack of support for a higher number of bits per pixel, has been done to reduce the amount of memory needed to display graphics and therefore reduce the total memory used by the app.

If you're going to use gradients in your apps this is an important thing to be aware of.

The PhoneGap/Cordova misconception

2 years ago I was in the hotel I'm in right now and PhoneGap for WP7 was born.

In the time since it's come a long way--due to the work of a few very smart people.
I haven't done a lot with PhoneGap/Cordova for a while nor talked/blogged about it. Fortunately those other people have.

There is, however, something that many people still seem confused about and I'd like to try and clear it up now. The confusion is that the impression that the architecture diagram of a multi-platform PG/C app should look something like this.

The assumption is that because the UI for each version of the app will be written in HTML, CSS & JavaScript they should all be the same.

THIS IS WRONG!
That was never the intention.


For each version of the app that is built, it should have a UI that is appropriate to and targets the platform it will run on. The above diagram should actually look something like this.

PG/C allows you to create native apps with "web" technologies. It doesn't mean you should create an app that looks the same on each platform.

If you're building apps with PG/C then please keep this in mind.

4 ways to make money with Windows Phone

I hear lots of complaints about Windows Phone not having many users and developers frustrated that they haven't made loads of money from the apps they've developed.

I think there are 4 ways you can make money though:

1. Get paid to build apps for other people
2. Build apps which allow you to monetize another service
3. Build a targeted app and promote it appropriately
4. Get very lucky

For most people these are listed in order of likelihood of being successful.

Let's look at them in more detail.

1. Get paid to build apps for other people

*disclosure: this is how I make my living*

There are companies that want windows phone apps but don't have the staff, resources or experience to develop them. In this scenario they will typically look to agencies or contractors to create the apps for them. (Note that some agencies look to contractors too, but this is becoming less common as agencies are increasing/improving their Windows Phone development skills and experience.)

This is still a very niche market and the companies looking to hire for these roles want experts who can get things done and have a proven level of experience with the platform. Design and project management skills also come in handy too.

If you have the skills and experience this could work for you.

2. Build apps which allow you to monetize another service

This is the way that provides the most opportunity for the widest number of companies to make money on the platform in the short to medium term.

The idea is that you have an existing service which people pay to use and by building a client app that runs on Windows Phone you can reach more users or increase engagement with existing users. Both of which should increase income (and hopefully profit).

If you've got an idea for a service that could extend its reach by being made available via a mobile app Windows Phone is probably not the best platform to start with as you'll probably be better off by targeting a platform where you could reach/get a greater number of users (who you can monetize) for the same level of development effort.

If you do target Windows Phone first it can be a differentiator for you and an opportunity to create a unique marketing/promotional story. I know a couple of companies/apps which have done this.

3. Build a targeted app and promote it appropriately

If you think that the addressable market of total Windows Phone owners contains a large enough subsection that you can market and sell to enough of them with a relevant app that you can make money then this may be an approach that could make you a profit. Remember, you need to consider all the ways that an app can be monetized. Don't just think about an initial sales price. If you have one.

If considering this approach be sure to consider and treat the app you're creating like any other product. Remember: "Think product, not app".

4. Get very lucky

You could release an app with no great level of advance planning or promotion and have it turn out to be wildly successful. You may have heard stories of people who have done just that. Unfortunately though the reason you hear such stories is that they are remarkable and the exception. If it was common it wouldn't be news worthy.

If you're relying on this method you may want to consider a lottery ticket instead. That's not to say that you can't make money from apps, just that you shouldn't rely on luck if that's what you want to achieve.

Have I missed anything else? [How ]do you make money form Windows Phone?

How to read and send text messages on Windows Phone without user input!

It's a popular request from those new to Windows Phone, but with familiarity of other platforms, to want to be able to interact with SMS.
This typically means one or more of the following:

• Access the text messages on the device.
• Be notified when new messages arrive.
• Send messages without the user having to directly do something.

For very good reasons this isn't possible.

Those good reasons are:

• to provide a predictable experience to the user/owner of the phone (so they know what messages are sent and what data apps have access to)
• and to prevent malicious activity

But, you may argue, "I'd never do anything malicious".
Hopefully that's the case, but it's not possible to guarantee that everyone will be so good.

Just ask some android owners who installed applications only to find expensive SMS messages showing up on their bill that they had no record of:

"UK Regulator swiftly resolves Android malware infection"

While in this case the issue has been addressed and those affected will be getting their money refunded, stories like this hurts the platform. While Microsoft are busy trying to grow the platform and attract new users, stories about the security of the platform and how people with those phones can end up with unexpected charges on their bill if they install apps would not be helpful.


While you can't read or be notified of new SMS messages you can compose one for the user to send. See "How to: Use the SMS Compose Task for Windows Phone" for more details.

What do you want from Tombstone Helper?

A little over a year ago I created http://tombstonehelper.codeplex.com/. It was a response to the large number of apps which didn't implement support for saving state during tombstoning and the fact the framework provides little to help.
My aim was to create something that was so simple to use that there would be no excuse, at least in a simple app, for not adding tombstone persistence support. My thought was that if you're up to developing a more complex app you would be capable of adding appropriate persistence support and so not need my help.

The library has been noted amongst the more popular third party libraries in general use and at one point was estimated to be in 3% of all apps in the marketplace. I also know, based on some of the apps it's in, that it's been included in apps on at least several hundred thousand devices.

It's currently at version 2.5.
I've started a version 3.0 several times with a view to adding viewmodel support but each time have failed to find a way I consider suitable for a broad enough number of use cases and which doesn't require too much effort from the person using the library.

As you may have guessed from the tone of this post so far, I'm going to try again but I'm interested to know if there is anyone out there using it who would like extra features, functionality or has a strong opinion on how viewmodel persistence should be handled.

I want to help those who were building simple apps a year ago as they move on to more complex scenarios.

If you have any thoughts, comments or opinions please: leave them in the comments below; email me; or tweet your suggestion.

Thanks

If the customer/user doesn't understand: it's your fault, not their problem

I remember, a few years ago, a client was in the office of the company I was working for at the time and they were showing off the promotional flyers they'd printed and were busy distributing to potential customers.

After they'd handed us copies they remarked that the people they were trying to reach just "didn't get it". They were handing out all this information about how clever the technicalities of the system were and all the things it would now enable them to do but everyone they spoke to just asked about price (which wasn't mentioned on the flyer).
As far as their potential users were concerned, all they were interested in was price. All the other whizz-bang features were of no interest to them. The company in question had wasted a lot of time money and effort in trying to tell people about what they were offering but it wasn’t anything their potential customers were interested in.

So what does this have to do with building phone apps?

I think it demonstrates two areas where app developers often make mistakes. They build an app without understanding their desired and potential market and they don't make their value proposition clear. 




Understand your market

If you're not making something people want or that is different from an alternative in a way that is “better” from the users perspective, you’ll find making sales hard.

This means:
- thinking before building an app
- building something that there is a market for. (Yes, this means going and doing some research first.)
- not just building it because you can or it's technically possible

It’s easier to sell something if you build what people want than it is to build what you want and then try and persuade people to buy it.





Make your value proposition clear

Explain what your application does and how that will help, benefit and provide value to the user. This will enable them to make an informed decision about purchasing the application and ultimately encourage them to do so.
Of course, this may mean that you have to explain what the application cannot do. Whether this is through decision or technical limitation. By making this clearer before they have the app and are trying to get it to do something it can't you'll make them happier. No, not everyone will read a long description about the capabilities and limitations of the app so you'll need to be smart about how you communicate this.

I think no customer is better than a disappointed one who is complaining and spreading negative word of mouth. Focus on getting the ones you want and the ones who want your app. It'll make everyone happier in the long run.

At the end of the day it comes down to building what will sell and communicating (marketing) clearly. Do this and you'll have more success with your apps.




 

How to respond to bad apps?

Update: In response to comments below and on Twitter, I've tried to clarify things better below.

What do you do when you find a bad app?

• Engage with the developer to report why?
• Leave a negative review?
• Leave a low rating?
• Uninstall it?
• Just never launch it again?

What do you do?


I've started leaving 1 star reviews to bad apps, rather than just ignoring them.
I figure this helps serve as a warning to others who may download it.

If I know hte develoepr I'll talk to them but I just don't have the time to talk to everyone :(

Do you consider reviews when downloading an app? Is lots of bad reviews worse than no reviews?

I'd love to know your thoughts...



I also uninstall it, but that's just because I've got hundreds (not exagerating) of apps installed and I don't want the clutter.


Of course, if I come across an app which shouldn't be in the, marketplace in the first place I report it.




If you are/were the developer you'll want direct feedback, not a negative review.
That's a given. 
But what if we're talking about another persons app?
Imagine the app has so much wrong with it you don't know where to begin and haven't got the time to get in to a long discussion about why that's the case and all the ways the app could and should be improved.
This leaves 2 options:
1) do nothing
2) leave a low rating

In this scenario, what do you do?
If you do nothing then my theory is that there's a greater likelihood that someone else will waste part of their life tryint to use that app.
If you give a low rating they may think twice.


Yes, in an ideal world there would be the time to help everyone make a great app and developers would avoid the situation in the first place by taking the time to understand what makes a good app and to test their designs, assumptions and quality prior to releasing it. Unfortunately a quick look at any marketplace reminds us that we're not in a perfect world though.

Yes, if you're the developer you'll want a detailed description of why you've got a bad review but reviews aren't written for the developer. They're written to help other people get a feel of what other users think of the app before they download it.
If you're a developer of an app and you're getting bad reviews and don't know why then it's your responsibility to go and find out why. It's not the responsibility of the person giving the review.




 , th

Your app sucks and now I know what to do about it

The Windows Phone marketplace is a semi curated environment. This is both a good and a bad thing.

It makes the app submission process fairly reliable and keeps the very buggy and inappropriate apps out.

It does, however, require a human element in the certification process that can be subject to inconsistency and error.

Sometimes apps pass certification which shouldn't have. This is separate from any quality judgement, I'm referring here to apps breaking the marketplace rules and certification requirements

Fortunately, there is a place to report such occurrence: Reporting a Concern about an App in the Marketplace

If you're interested in and concerned about the general quality of what's in the marketplace - presumably because you want to see high quality, predictable apps which bring value to the overall ecosystem then I'd like to encourage you to report any such apps that break the certification rules too.

!!! This is not a place for reporting "bad" apps, just ones that break certification rules !!!

This isn't a substitute for also reporting such issues to the creators/publishers of such apps and engaging with them also. So that they can address the issues and learn what they shouldn't be doing.

13 ways to improve the performance of your app

There are lots of ways you can improve the performance (and the perceived performance) of your app.
This is not a complete list, just what came to mind right now.

The important (though unfortunate) thing to take from this is that great performance doesn't come easily and there are lots of things you can (or have to) do to give your users an awesome experience.

Note that some MVVM purist may dispute some of these but they're based on real world experience.

1. Get off the UI thread - Don't use it when you don't have to. Keep the UI responsive.
2. Don't use value converters - They have a much greater performance impact than direct properties.
3. Don't use dependency properties when you don't need to - If regular properties will work for your needs then keep it simple as they're much faster to read
4. Have fewer external dependenices - Loading fewer third party libraries saves time
5. Split up your assemblies - Don't load all the pages (and code) in your app when you don't need to
6. Cache images (and data) - Downloading external resources takes time. Don't repeat it unnecessarily. The same goes for processing or reformatting data.
7. Use a "boot loader" - If you have a large app or a complicated start up process, only have the bare minimum in the app and push everything else to separate assemblies. This will help you get as animated loading page up as quickly as possible.
8. Preload/prefetch data - If you can, get the data before you need it so that when you do need it the user doesn't have to wait.
9. Lazy load data - If there is a large amount of data, only load it as you need it. Don't waste time forcing your user to wait while it's all loaded.
10. Reuse [data] templates (load less xaml) - Loading fewer templates is faster. Make sure you don't reload the same ones repeatedly
11. Have less XAML - Don't use any more XAML than you need to. I often see slow apps which have unnecessarily complicated, nested controls when the same thing coudl have been created with fewer controls.
12. Avoid nested margins - Reduce the amount of work the loyout engine has to do measuring the elements in creates.
13. Don't use XAML - Yes, it's extreme but you can get better performance from a UI created in code than in XAML (you save the parsing time) This can make supporting the code and making changes harder though.

The above has helped me in the past. Hopefully it may help you too.

In the interest of balance: 101 Reasons Not to Buy A Windows Phone 7.5

I've been alerted by Tomi Ahonen about a list of 101 reasons NOT to buy a Windows Phone 7.5.

My initial response was to roll my eyes but some of it is insightful about how some people are perceiving the platform.
There's a few points I'd disagree with and plenty that are purely criticisms because it's not the same as other devices or platforms.

It seems to have been written by a disappointed (frustrated?) Symbian user.

What I know though is that I like it ;) and only one person I know who's used a WP device didn't like it, compared with many who upgraded from or changed their plans to buy an iPhone after using mine for a short while.

Diversion over, normal developer related content will resume shortly.

BitsPerPixel and 256MB devices

At some point (I think it was with the mango tools release) we gained the ability to specify that an app should use 32 bits for each pixel when showing a color, compared with the default 16. This enabled the ability to show smooth gradients and avoided "banding".

It just takes a setting in the manifest file.

Based on my experiences with the new 256MB emulator (which is included with the 7.1.1 SDK update) the new, lower spec devices don't appear to support the 32bit option. This would make sense as it would mean the device would need to use less memory to load/display the image and could also mean a cheaper screen.

This is currently only tested in the emulator but as soon as I can get a real device I'll check there too.
Do you have a device you can check this on? If so, do you see this behaviour?

Need to do some dithering of images to wrok around this? Check out http://adtsai.blogspot.co.uk/2011/03/high-quality-dithering-for-windows.html