It’s possible to use C# keywords for variable names, etc.
For example if we wanted a variable called “namespace” (which is a C# keyword) we can prefix the declaration with an @ and use this prefix whenever we refer to the variable:
var @namespace = "hello";
@namespace += " world";
More...
SHARE:
If you want to prevent the default action happening when a user presses the back button on a Windows Phone you can override the OnBackKeyPress method in your page. To prevent the default back behaviour (e.g. navigating to the previous app page) you can set the Cancel property of the CancelEventArgs to true.
The following code shows how to prevent the back button from navigating to the previous page if a UI element called “ShareChoices” is visible:
protected override void OnBackKeyPress(System.ComponentModel.CancelEventArgs e)
{
if (ShareChoices.Visibility == Visibility.Visible)
{
HideShareChoices();
e.Cancel = true;
}
}
When deciding to override (and cancel) the default back button behaviour, be sure that it’s sensible and intuitive to the user. Incorrect use may result in certification failure.
One use that I’ve seen is in data entry apps. On the main page, the back is intercepted and if there are unsaved data entry changes an “are you sure” dialog is displayed. You shouldn’t do this “are you sure you want to exit app” on apps where there is no loss of data if a user exits. In these cases this kind of “exit prompt” will be annoying and pointless to the user.
SHARE:
A Desire Line (or Desire Path) is the shortest or easiest way to get from where you are to where you want to be.
In the physical world we can see these in parks or grassed areas as paths worn away by people’s feet.
Take this photo:
This was taken not long after the opening of a new building. The photo shows part of an entrance area to an office building and mall entrance.
More...
SHARE:
So the project or release or iteration is done. We’ve “finished”. The customer and users are (hopefully) reasonably satisfied, and we say that we’ve delivered the software.
There’s a second hidden deliverable that we don’t usually think about and that’s the malleability of the thing we’ve just delivered. How easy it will be to modify the software in the future.
We can think of it as the “potential cost of future change”.
Even though we cannot measure productivity and estimating this future cost is likely to be either impossible, pointless, or both; it still may be a useful concept.
Once we start to treat the potential cost of future change as a deliverable in its own right, we can have important conversations with the team/customer/user. We can trade off the potential cost for future change against getting the next thing released as soon as possible.
More...
SHARE:
So the big news of the moment is that Nokia is selling it’s Devices & Services business to Microsoft.
The deal is “expected to close in the first quarter of 2014, subject to approval by Nokia shareholders, regulatory approvals and other customary closing conditions”.
After the deal has taken place (according to the press release) Nokia will focus on network infrastructure, mapping and location services and “Advanced Technologies”.
After the deal closes, it will mean about 32,000 people will transfer to Microsoft which includes about 4,700 people in Finland. Microsoft will own “all Nokia Devices & Services production facilities”.
Microsoft will also get a 10 year non-exclusive license to Nokia patents.
More...
SHARE:
When we’re formatting numbers we can use a format string that allows us to specify a different format to be used whenever the number is positive, negative or zero.
To do this we separate the 3 parts by a semicolon.
For example the format string "(+)#.##;(-)#.##;(sorry nothing at all)" will output:
- (+)99.99 if the value was 99.99
- (-)23.55 if the value was -23.55
- (sorry nothing at all) if the value was zero
You can also use a two part conditional format string where the first part will be used if the number is positive or zero; the second part will be used if the number is negative.
Check out the MSDN page for more info…
If you want to fill in the gaps in your C# knowledge be sure to check out my C# Tips and Traps training course from Pluralsight – get started with a free trial.
SHARE:
Take a look at this photo I took of a contactless style of payment terminal at a local grocery store. This is the kind of terminal that, with a compatible credit/debit card you can just tap, hover, or wave you card in front of the machine rather than inserting and keying in a pin number.
Notice the extra handwritten instruction taped to it: “HOLD CARD BELOW”.
The fact that the staff of the store had to modify the machine in this way gives us a clue that there may be a problem with the design. It suggests that some customers were holding their cards in the wrong place, perhaps at the top of the machine, and thus not initiating a payment.
We can see that the only perceived affordance of where to hold your card is the little diagram in the middle.
Whilst I’m not a hardware designer (and without perhaps performing some usability studies) I thought it would still be fun to mock-up some changes.
More...
SHARE:
If we’re copying arrays where the types may be different, sometimes we may want to do an atomic copy; that is if any of the elements in the source array can’t be converted to the destination array type, the whole copy operation will “rollback” and the target array will remain unchanged.
The Array.ConstrainedCopy method can do this for us.
Consider the code below where an array of objects (containing a string and and an int) is copied to a target array of type string.
Using .CopyTo will result in an exception and the target array being partially affected (the target array element 0 will have already been populated with the string).
Using .ConstrainedCopy will ensure that if an exception occurs the target array will be “rolled back”, i.e. none of it’s elements will have been changed.
var things = new object[] { "Sarah", 1};
var strings = new string[2];
// this will throw an exception because of the 2nd element conversion error (int to string)
// but, the target array "strings" would have been changed (the 1st string element will have been copied)
things.CopyTo(strings, 0);
// this will throw an exception because of the 2nd element conversion error (int to string)
// BUT, the target array "strings" will NOT have been changed
Array.ConstrainedCopy(things, 0, strings, 0, 2);
The constrained copy has the following parameters (from MSDN):
public static void ConstrainedCopy(
Array sourceArray,
int sourceIndex,
Array destinationArray,
int destinationIndex,
int length
)
If you want to fill in the gaps in your C# knowledge be sure to check out my C# Tips and Traps training course from Pluralsight – get started with a free trial.
SHARE:
One way of thinking or planning colour is to think in terms of relative expansiveness, that is, the proportion of the use of different colours.
One way to describe this proportionality is to think in 3 groups:
- The Dominant Colour: proportionally the largest expanse of colour, e.g. the ground
- The Subdominant (or subordinate) Colour : the second largest expanse of colour after the dominant
- The Accent Colour: the colour with the smallest relative area
This doesn’t mean that we can only ever use just three colours, but it’s a nice conceptual model. We could, for example, have a single dominant colour and a single accent colour; but we might have 3 shades of a subdominant to create a greater range of visual possibilities.
A simple way to visualise this is to use a subdivided coloured square.
More...
SHARE:
Sometimes the display and formatting of information in the Visual Studio debugger is less than optimal.
The DebuggerDisplay attribute allows us to customise how an object is portrayed in the debug window.
Imagine a Person object p with an AgeInYears and an Name property.
By default, in the debugger this would look like:
At the “root” level for the object we just get the type name.
If we override ToString() then we would get that output here instead.
If we want to override ToString() but have a different output at the root debug level we can apply the DebuggerDisplay attribute at the class level:
[DebuggerDisplay("This person is called {Name} and is {AgeInYears} years old")]
class PersonWithDebuggerDisplay
{
[DebuggerDisplay("{AgeInYears} years old")]
public int AgeInYears { get; set; }
public string Name { get; set; }
}
In the string we supply to the DebuggerDisplay attribute we can reference properties, fields, and methods in the class by wrapping them in {}.
This produces the following in the debugger:
Note that in the sample code above, the DebuggerDisplay attribute is also added to the AgeInYears property which produces the following when the object is expanded in the debugger:
The DebuggerDisplay attribute can be applied to:
- Classes
- Structs
- Delegates
- Enums
- Fields
- Properties
- Assemblies
While this is not something we’d use on every class as a matter of course, it may be helpful when we are doing a lot of debug work and we want to make life easier for ourselves. For more info on usage check out MSDN.
If you want to fill in the gaps in your C# knowledge be sure to check out my C# Tips and Traps training course from Pluralsight – get started with a free trial.
SHARE: