Rule 1: Life is not fair – get used to it!

Rule 2: The world doesn’t care about your self-esteem. The world will expect you to accomplish something BEFORE you feel good about yourself.

Rule 3: You will NOT make $60,000 a year right out of high school. You won’t be a vice-president with a car phone until you earn both.

Rule 4: If you think your teacher is tough, wait till you get a boss.

Rule 5: Flipping burgers is not beneath your dignity. Your Grandparents had a different word for burger flipping: they called it opportunity.

Rule 6: If you mess up, it’s not your parents’ fault, so don’t whine about your mistakes, learn from them.

Rule 7: Before you were born, your parents weren’t as boring as they are now. They got that way from paying your bills, cleaning your clothes and listening to you talk about how cool you thought you were. So before you save the rain forest from the parasites of your parent’s generation, try delousing the closet in your own room.

Rule 8: Your school may have done away with winners and losers, but life HAS NOT. In some schools, they have abolished failing grades and they’ll give you as MANY TIMES as you want to get the right answer. This doesn’t bear the slightest resemblance to ANYTHING in real life.

Rule 9: Life is not divided into semesters. You don’t get summers off and very few employers are interested in helping you FIND YOURSELF. Do that on your own time.

Rule 10: Television is NOT real life. In real life people actually have to leave the coffee shop and go to jobs.

Rule 11: Be nice to nerds. Chances are you’ll end up working for one.

Source: Facebook

Advertisements

Through an email to Windows Phone 7 developers Microsoft has informed that 16 categories and 25 sub-categories of apps will be included to Marketplace for Windows Phone 7.

List of Categories of Windows Phone 7 Apps in Marketplace

  1. Books & Reference
      eReader
      Fiction
      Non-fiction
      Reference
  2. Business
  3. Entertainment
  4. Finance
  5. Games
      Action & Adventure
      Board & Classic
      Card & Casino
      Family
      Music
      Puzzle & Trivia
      Shooter
      Sports & Racing
      Strategy
      Xbox Companion
  6. Health & Fitness
      Diet & Nutrition
      Fitness
      Health
  7. Lifestyle
      Community
      Food & Dining
      Out & About
      Shopping
  8. Music & Video
  9. Navigation
  10. News & Weather
  11. Photo
  12. Productivity
  13. Social
  14. Sports
  15. Tools
  16. Travel
      City Guides
      Language
      Planning
      Travel Tools

Apps for Windows Phone 7 will be approved by Microsoft before they added to Marketplace for users and company will start accepting apps in October 2010.

Capture

In an attempt to start changing this blog from nothing but a platform for me to spout off about projects, or talking aboutcontests :) , and actually try to provide some value to readers, I’m starting a new category on the site called “Quick tips”.  When I can, I’ll be posting small bits of code that I think would be helpful.  If you have a question on how I’ve done anything in the applications I’ve written (more to be posted soon), please feel free to ask, and I’ll answer what I can.

On my last post, Ishmeet asked if I could shed a bit of light on how I was able to play the audio clips in the PhoneTree application, so here goes:

One of the best things about having both Silverlight and XNA at your disposal when developing for WP7 is that you can use the XNA pieces within your Silverlight app when ever you want.

For the MediaPlayer functionality you’ll need to add the Microsoft.Xna.Framework.dll reference.  Once you’ve done that, use the following code:

1  MediaPlayer.Stop();

2  Song song = Song.FromUri("Sample Song", new Uri(txtUrl.Text ) );

3  MediaPlayer.Play(song);

If you try and run the code at this point, it will play, but the application will also crash complaining that FrameworkDispatcher.Update has not been called.  After looking around for a while I finally found a post by Danny on the XNA Team explaining the problem.  He did a better job explaining it then I can so you can read it here.

Basically you’ll need the following class:

01 public class XNAAsyncDispatcher : IApplicationService

02 {

03       private DispatcherTimer frameworkDispatcherTimer;

04

05       public XNAAsyncDispatcher(TimeSpan dispatchInterval)

06      {

07           this.frameworkDispatcherTimer = new DispatcherTimer();

08           this.frameworkDispatcherTimer.Tick += new EventHandler(frameworkDispatcherTimer_Tick);

09           this.frameworkDispatcherTimer.Interval = dispatchInterval;

10      }

11

12        void IApplicationService.StartService(ApplicationServiceContext context)  { this.frameworkDispatcherTimer.Start(); }

13        void IApplicationService.StopService() { this.frameworkDispatcherTimer.Stop(); }

14        void frameworkDispatcherTimer_Tick(object sender, EventArgs e) { FrameworkDispatcher.Update(); }

15 }

and then add it to the Application Lifetime Objects like so:

1  this.ApplicationLifetimeObjects.Add(new XNAAsyncDispatcher(TimeSpan.FromMilliseconds(50)));

Once you’ve done that, your good to go.

Here is a sample showing off this technique.

Source: 4MK Mobile Dev Blog

Windows Phone 7

Here’s a quick post to document something I am seeing with the Windows Phone 7 emulator. When you are running your application and you want to test it tombstoning (e.g. deactivating), you should notice thatVisual Studio stops debugging when that happens. When you return to your applciation (via the back button or in the case of a chooser, once you’ve choosen something), you’ll get a black screen. This isn’t a bug…its a feature!

This black screen is giving you a few seconds (I think Pete Brown said 10 seconds) to run your application to activate and continue your debugging session. I found this in a Windows Phone 7 team blog about the tombstoning cycle, but it was buried in a comment so I thought bringing it as a first class topic might help.  Remember, see the black screen on the emulator (or on hardware), just re-run your phone app in Visual Studio to continue debugging!

Source: Shawm Wildermuth

With such a long and promising title, this series of posts better be a good one – you’ll be the judge of it. However, the real reason for this long title is rather simple. All these “big” words simply represent different aspects of the execution model. There are a few things that you need to know if you want to maximize your user’s experience. This post explains the Windows Phone (WP) application execution model by taking you step-by-step through the different aspects of launching, running, and closing a Silverlight application. Note that for XNA games the terms and ideas remain the same with some minor implementation differences. In following posts we’ll cover deactivation, reactivation, and how launchers and choosers work with tombstoning.

With the latest Beta release of the Windows Phone developer tools, applications running on WP employ an updated execution model. Now, when your application is removed from the phone foreground (a different application occupies the phone foreground like incoming phone call, or the lock screen being activated), it is actually being terminated (more on this later). In earlier version of the WP tools, you could get into all kinds of strange scenarios if you went from one application to another. That is because in the previous version of the tools, the WP operating system didn’t terminate your application, it “parked” it. However that led to some issues regarding launching a new instance of your application vs. navigating back to the instance on the back stack. Adding to the confusion, the events and API were less than perfect. I guess that is one of the reasons we have technical previews—to test and fix such “issues.”

A Few Ground Rules

Just to make sure we are all on the same page, by now you probably already know that the WP operating system doesn’t allow any 3rd party applications to run in the background. To be more specific, there can be only one application running in the foreground at any given time, and if your application is not running in the foreground, it means that your application is NOT RUNNING. The main reasons for not allowing 3rd party applications to run in the background are to preserve battery life (see Push Notification post) and to ensure a responsive and consistent user experience.

All WP devices feature a hardware Back button. This button allows the user to navigate back in a given application and even between applications. This is a rather cool feature, mainly because unlike other phones, you can navigate from your application to the browser or to another application, and then press Back to seamlessly return to your application. This yields a much more consistent user experience across different applications, whether they are 3rd party applications or part of the phone’s built-in application suite. This also implies that WP operating system is maintaining a journal of you navigation actions to support the Back button functionality. This is also known as the back-stack.

The Basics – Launching, Running, and Closing Applications

It is time to jump into the Windows Phone execution model, and the best way to do this is to start looking at some code. Simply start a new Windows Phone application and look at the auto-generated code of a new WP Silverlight application template, and you will find four new methods in the App.xaml.cs file that are directly related to the execution model:

  • Application_Launching
  • Application_Activated
  • Application_Deactivated
  • Application_Closing

As a side note, all these events (the functions are the event handlers) are members of thePhoneApplicationService class in the Microsoft.Phone.Shell namespace.

I think the names of these methods are rather self-explanatory, but just to be on the safe side, let’s review them. We’ll address the Activated and Deactivated methods later; for now, let’s focus on the simple events: Launching and Closing. I’ve added a single line of code to each method:

// Step 1 - Util is helper class for logging
Util.Trace("***** in MainPage CTOR\t\t ( " + DateTime.Now.Ticks + " *****)");

Util is a simple helper class that we’ll use to help us with debugging. The text in each method changes according to the event but you get the idea. I log the time of each event in order to prove a point later when we talk about Activated and Deactivated events.

Running the application in its current state yields the expected result. Upon launching your application the “Launching” method is called. As expected, after that event, your application runs. Press the Back button (not the Windows button) and your application terminates and the “Closing” event is raised, as you can see in the following image (copy of the output window from Visual Studio).

image

As we said, by pressing the hardware Back button, the navigation model allows the user to “step back,” or navigate backwards through the application pages, and even across applications. However once you reach to the application’s first page (the first page, and its first instance) pressing the Back button raises the Closingevent and terminates your application. You can see that from the above image, where it clearly states that the “program” exited. If you are following this post while coding in Visual Studio you will also note that the emulator exits your application and returns to the Start window.

Understanding Activated and Deactivated Events and Tombstone

So far so good, I mean there is nothing new here. However, let’s try the following trick. From Visual Studio, start your application in debug mode (so we can see the traces). As expected, your application starts and you should see the Application Launching trace in the log. Now, instead of pressing the Back button (which if you do, will terminate your application), press the Windows button (the middle button).

You should notice the following:

  1. The emulator returned to the Start screen and your application doesn’t occupy the phone’s foreground, which means it is no longer running!
  2. The debugging session in Visual Studio was terminated. This means that Visual Studio is not debugging your application, which makes sense since the application is no longer running.

Note: At the end, your application gets terminated. That is super easy to see in the Visual Studio Output window, as the last line in the Output windows states, “The program ‘[220921918] taskhost.exe: Managed’has exited with code 0 (0x0).” No worries, this is by design. However, unlike our previous example, this time the event that followed the Launching event is “Deactivated,” and NOT Closing. But in both cases your application gets terminated (at the end). So what is going here? What is the difference between Closing and Deactivated and more important, why?

image

  • Application Closing is simply the outcome of the user pressing the hardware Back button enough times to navigate backwards through the pages of your application, past the application’s first page. Currently, this is the ONLY way for a user to exit your application. Once your application is closed, its process is terminated, and the operating system removes any trace of that application from its memory (RAM).
  • Application Deactivated occurs when a different application takes control of the foreground – for example, an incoming phone call, launching a chooser, or the user pressing the Windows button. In both cases, your application will be deactivated (not closed). Before we step into the subtleties of the Deactivated event, let’s make sure we all understand that upon Deactivation, your application gets terminated (at the end). It’s that simple; your code can’t run in the background, therefore your application gets terminated. However, unlike an application that is closed, a deactivated application gets tombstoned. Don’t get confused, a tombstoned application’s process still gets terminated. But unlike a closed application, where the WP operating system removes any trace of the application, when an application is deactivated, the WP operating system stores a record (a tombstone) of the application’s state. Basically, the WP operating system keeps a tombstone of the application that becomes part of the phone’s application back-stack, which is a journal that enables the use of the hardware Back button to enhance navigation functionality.

There are several ways in which applications can become tombstoned. An application will be tombstoned and deactivated if:

  • The user presses the Windows button (as you just did)
  • The device timeout causes the lock screen to be engaged (again, a different application takes control of the foreground)
  • The user invokes a Launcher or a Chooser – which we will cover later

In any of these cases, the running application will be deactivated, the Deactivated event is raised, and your application gets terminated shortly afterwards.

At this point in the application life cycle (while your application is tombstoned), a few things can happen. The user might return to a tombstoned application. This can happen if the user completes the chooser or launcher activity and returns to the application, or if the user presses the Back button enough times to return to the tombstoned application. Regardless of how users return to the tombstone application, the application will be reactivated (raising the Activated event) and magically show the last page viewed by the user before the deactivation.

You don’t believe me, let’s try it together. I’ve added a second page to the basic WP Silverlight application, and added a trace to both constructor pages. Next, I added a button to the first page that navigates to the second page.

In Visual Studio, start debugging your application and click the button to navigate to the second page. From the second page, press the Windows button. As expected, your application is deactivated and then terminated, as you can see from the following screen capture of the Visual Studio Output window.

image

Note the sequence of the trace (and the corresponding time-code). First your application launches, then the main page constructor is called, and after pressing the button on page one, the application navigates to the second page (DetailsPage), after which you press the Windows button raising the Deactivated event, which indicates that your application is tombstoned.

In the next post you’ll learn about returning to a tombstoned application and managing your state between tombstoning.

You can download the code for the code samples.

Windows Phone 7 Training Kit for Developers includes a full lab dedicated to the Windows Phone Application Lifecycle.

MSDN documentation includes a topic – Execution Model Overview for Windows Phone

Source: The Windows Phone Developer Blog

As you know, Windows Phone 7 devices support theming: they allow you to pick Dark or Light backgrounds and choose an accent color. It’s really easy to configure your application to use predefined styles like “Disabled” or “Active” – they react to theme changing and you always get a well-colored UI. The real question is how to use different images for each theme. There is no standard way of detecting a theme and distinguishing resources based on it. I’ve surfed the web and found a solution proposed by Derik Whittaker – it detects theme by checking the color of the background. But what to do with obtained theme? The variants I’ve found at MSDN forums was not nice enough so I had to write something myself. My solution is resources-based and allows you to distinguish UIs for each theme just by adding two dictionary entries with same key. So let’s start.

Here we define ApplicationTheme enum that will distinguish our themes:

Enum

Then we implement a solution by Derik Whittaker:

Whittaker

It’s rather simple: it takes current PhoneForegroundColor property from application resources and determines theme based on it.

Now we’re going to organize an access to theme-specific resources via the ThemeResources class:

ThemeResources

Right after first call to ThemeResources they will initialize ResourceManager based on ApplicationTheme. Files used for resource storage should be it the same namespace with ThemeResources file:
Files

These .resx files should be named appropriately for each valid ApplicationTheme enumeration value: Dark or Light.

That’s it! All is left is using our ThemeResources class. Let’s define a property with some text and then bind to it:

Property

Binding

This code will automatically determine what theme is enabled and will pick appropriate application title:

DarkLight

You can easily store not only application titles but also for image URLs (what this solution was really intended for). You may need to show a white image in Dark theme and black image in Light theme – use this solution to achieve this cleanly and easily.

Download sources from our Deviation Alliance Codeplex project.

Source: Deviation Alliance

Shortly after Yahoo launched its HTML5-based version of Yahoo Mail for iPad, Google has refreshed its version of Gmail for Apple’s popular tablet.

The update boils down to one feature, albeit an interesting one: the app now has a new “stacked card” interface for selecting and managing multiple conversations. Before this latest update, one had to manage selected conversations and currently open conversations with two separate (and similar) toolbars. Now, when you select multiple conversations, you’ll see them “stacked” on the right, and you can archive, trash or move them easily.

The new version of Gmail for iPad also features some sleek new CSS3 transitions, described in detail on Google’s code blog.

To try the new Gmail for iPad, open gmail.com in your iPad’s Safari web browser.