There might be a case where you need to set the background color of a button in code rather than in XAML. Or you might define a style in XAML with a particular button background color, but would like to change the background color in an event handler. For example, let’s say you created the following button in XAML:
<Button Content=”My Button”
Now let’s say that when the user clicks the button you want to change the button’s background color to give another way of indicating the button has been selected. You can do the following in C#:
private void RegisterSelection_Click(object sender, RoutedEventArgs e)
Button btn = (Button)sender;
btn.Background = App.Current.Resources[“PhoneChromeBrush”] as SolidColorBrush;
I am using this in an app I am currently working on and it works well. Give it a try.
I think we tend to take design for granted. Sure, when we use a product that is particularly well designed, like the Windows Phone operating system, we’ll take special notice. But generally speaking we just expect things to work well and look pretty. This applies as much to software as any other product. But it doesn’t just apply to the look of applications, it also applies to the code used to build them.
I am currently working on a number base converter for Windows Phone. It is the second application I have ever built. What I’ve learned is that building functionality is one thing, but design is a completely unique animal and can be just as difficult, if not more so. After all, what good is a method to convert one number to a bunch of other bases without a user interface to make it easy to use and to look pretty doing it? I know, obvious, but for a beginner it’s not that simple. I/you don’t have the experience yet to make it easy.
So I thought I’d share a few things I’ve learned so far that may help you along:
- Think through your design before you start coding: You don’t build a house without a blueprint, so don’t build your applications without one. Layout how would you like the user interface to look, what functionality you want your app to have, etc. You won’t think of everything during the design phase, but laying out what you think you want will save you tons of time in the end. Use whatever design tools you want, pencil and paper, Sketch, Illustrator, it doesn’t matter. Use what you’re comfortable using. And make the design process appropriate for the complexity of your app. Don’t spend 4 weeks laying out an app that does nothing more than hyperlink to your Facebook page. At some point you just have to start coding.
- Design is an iterative process: For my base converter, I thought I had figured everything out during the design phase. But as I started building I realized there were quite a few things I had never even considered. For example, I have a pop-up keyboard that allows the user to easily enter the base of the number they want to convert to another base. When this keyboard pops up the primary keyboard is hidden to give focus to the task at hand, entering a base. The “base” keyboard only disappears after the user has selected a base to convert from, which seems logical. But what if they decide not to enter a base and just want to close the keyboard? Do I add a Close button? That would disrupt the look of the keyboard. Plus, the natural thing to do in most cases with Windows Phone is to use the back key to get out of something. Users would likely press the back key before they tried anything else. Ok, fine, no problem. But my app is a single page app and pressing the back key exits the app. That’s not good. So I instead need to reprogram the back key to close the base keyboard when it is visible. Seems simple now I have thought of it, but it never even crossed my mind before. It’s likely you’ll come across all kinds of little nuances you never thought about until you go through the testing phase. “Ok, press this, that works. Press this, nope that’s not what I want. Fix that. Ok fixed. Press this. Nope, it should do this instead. You know, I think if we made this change colors instead of doing this other thing that would be better. Hmmm…which color?” You get the idea. Oh…TEST OFTEN!!!!! Don’t wait until you think you’ve finished your app to start testing. Test along the way. Build a new method, test it. Add some buttons, test them. It’s easier to build and test in pieces than it is to slap it all together and hope everything works.
- Well designed code is just as important as a well designed UI: Writing code is an interative process just like design, particularly for new programmers. Oftentimes what I do is write a method or put together a design element using my current knowledge just to see if I can get everything to work. Once I get things like I want them, then I go back and try and learn a better way to put it all together. For example, if I want 10 buttons on a screen, I might start by building a button in XAML and then duplicating that XAML code 9 times. Hmmm…but I see that all 10 buttons have the same font, and the same margins, and the same background color, etc. There has to be a better way to do this to reduce the amount of code duplication. I wonder if you can create a button template? Bing search. Yep, you can. Sweet. So then I create a style template, apply that style template to each button, and delete all of the duplicate XAML code. Hmmm…this is a pretty simple layout, I wonder if I could create these 10 buttons using a for loop in C# rather than doing all of this XAML stuff? Yep, apparently I can. So let’s try that. Awesome. Instead of having 100 lines of XAML, I now have 15 lines of C#.You’ll also want to spend time commenting your code. Yes, I know, it’s your code, you know how it works. Yeah, but by next week you’ll have forgotten. Why not spend a few minutes now making notes of how and why you did something rather than have to guess later? Certainly at some point you’ll update your app, so make things easy on yourself and use comments liberally. I don’t care if you have to write a paragraph to help you remember how a function works, just do it.
There have been hundreds, if not thousands, of books written on user interface and code design. And I can tell you to go read them all. But I just wanted to share with you a few experiences I’ve had as a beginner, demonstrating to you that, at least for a beginner, application development is a dirty, iterative process. I want you to understand that a simple, pretty end product can be a complete pain in the ass during the design and development stage. And I most importantly want you to understand that the more you design, the more you code, the easier everything will become.
Keep your chin up and happy coding!
Here’s another good blog post from the Windows Phone Developer Blog, with 8 on designing Windows Phone apps. Check out the post for all of the details, but here are the highlights to whet your appetite:
- Focus: what makes your app unique and what is your mission statement for your app.
- Plan: do some upfront leg work on your app’s layout and flow to make sure it makes sense and to save time later.
- Love the grid: the Windows Phone emulator grid is your friend when it comes to design, use it in Visual Studio and in Blend (Expression Blend). It’ll save you tons of time putting together your layouts.
- Theme it: take advantage of the built in themes of Windows Phone to style your apps.
- It’s alive: use Live Tiles to kept your app in focus even when it’s not open.
- Let content breathe, never fear the scroll: don’t cram, this isn’t a final exam, give your content room.
- Be inspired: embrace Windows Phone’s simple and clear design language.
- Sell it: designing and coding are one thing, getting people to use your app is another. Present yourself well in the Windows Phone Store.