Archives For Mango

mangoI’ve been spending the last few days reading and testing some of the new features in Windows Phone Mango and also writing a bunch of articles sharing some details.  Here is a summary of the articles I have written so far.  With over 1500 new APIs in Mango, I’m sure I will have some more articles so I will continue updating this list as I write more. 

  1. Windows Phone 7 And Multitasking Revisited
  2. Windows Phone Multitasking – Fast Application Switching
  3. Windows Phone Multitasking – Scheduled Notifications
  4. Windows Phone And Database Support
  5. New Windows Phone Device Status APIs
  6. Windows Phone Launchers & Choosers
  7. Augmented Reality And Windows Phone 7 Part 2

Comments or feedback on any of the articles, feel free to contact me here or via twitter @MarkArteaga!

Launchers and Choosers have been around since the first version of Windows Phone and basically allow the developer to integrate into the operating system.  For example, there is a ‘Task’ to make a phone call or to compose an email.  I like to define Launchers & Choosers as follows

  1. Launchers – ‘Just Launch it and Forget it’ – Basically, you launch something out the the OS, possibly passing some parameters and hand control over to the operating system.  Don’t expect the user to always come to your application and at this point you will be tombstoned or go into dormant state.  For example, you launch a phone call, the user might hit the start button, and go to another application and never return to your app until it’s needed again
  2. Choosers – this lets you pull information from the operating system in a way that keeps the users data secure and private.  For example, you can ask the user to select a contact and it will return contact information.

With Windows Phone Mango tools out, there are some new Launchers and Choosers that can be of use to developers.  You will find all of them un der the Microsoft.Phone.Tasks namespace on MSDN.  I’ll just go through a summary of the new ones for Mango. Continue Reading…

I recently wrote about the updated story on Windows Phone and Multitasking.  Yes, Windows Phone does multitask and gives developers a few options to get things done which are

  1. Background Audio
  2. Background File Transfers
  3. Fast Application Switching
  4. Scheduled Notifications
  5. Scheduled Tasks Continue Reading…

A few months ago I wrote about augmented reality on Windows Phone 7 and how the possibilities are there as the platform supports it but it’s all hidden away to third party developers.

Now that blog post was back on August 24 2010 less than 12 months ago.  Now with Windows Phone Mango, Augmented Reality scenario on Windows Phone is now a “reality”.  Kudos goes out to the Windows Phone team for getting this out in less than 12month! It was already there but my guess is it wasn’t tested enough for general use!

How Do I Use It!

Pre-Mango, we only had access to the CameraCaptureTask which would go ‘outside’ of our application and return us a back picture stream that the user took.  Not the most ideal scenario from a developers point of view but got the job done.

With Mango APIs we now have direct access to the camera and able to stream directly onto a page. You also have the ability take pictures and have various events to tell you what the user is doing, for example CameraButtons.ShutterKeyPressed which tells you when the camera hardware button was pressed. Continue Reading…

In my previous post I talked about some of the new multitasking features available in Windows Phone Mango.  In this article, I’ll go over Scheduled Notifications in a bit more detail.

You will find all API details in the Microsoft.Phone.Scheduler namespace and the main items we will look at are

A Scheduled Notification is fairly straight forward and essentially will popup a dialog box similar to the calendar reminder in the OS. Continue Reading…

When Windows Phone first launched I spoke about Windows Phone and multitasking and how at the core of it, Windows Phone was a full blown multitasking and real-time operating system.

Unfortunately for developers, this was not full exposed to us and the reason for this was to maintain a good user experience which included performance and battery power.

Looking back, the concept of ‘Tombstoning’ was added to allow developers to write their applications to give the user of ‘true multitasking’.  Not the best scenario as is does take some time to get your head wrapped around the Tombstoning concept.  I’m not going to go through Tombstoning here as it has been extensively covered.  Here are a few links from MSDN to help you out in case youa re not familiar with it

Multitasking Pre-Mango

In Pre-Mango devices, you again have the concept of Tombstoning to give the user the illusion of multitasking.  Another option made to developers is UserIdleDetectionMode and ApplicationIdleDetectionMode.  What exactly are they?

UserIdleDetectionMode mode allows you to force the screen to stay on.  So if you are create an application that will track a user as they drive and show their location on a Bing Map control, this is the property you will want to use. But be cautious when using it as it could drain the battery life extremely fast depending on your scenario. To use it is fairly simple and can be achieved with the following code. Continue Reading…

Windows Phone Mango introduces some new APIs to help get device status.  In pre-Mango APIs, we would have to use the Microsoft.Phone.Info.DeviceExtendedProperties to get different status such as device total memory, device manufacturer and the code was a bit messy.

One of the key ones is DeviceTotalMemory which allows you to see how much memory your application is currently consuming. This is especially useful since one of the Marketplace Certification Requirements says that you cannot consume more the 90MB of memory on devices with 256MB of memory or less.

For example, to get the DeviceManufacturer details you would use something like the following Continue Reading…

After developing quite a few applications for Windows Phone both personally and via my company RedBit, one of the biggest challenges is database support.  I’m not the only one complaining about this and if you have developed apps for Windows Phone 7, you probably have encountered this challenge and come up with workarounds to get data inside your application. 

There are many reasons why you want database support but my biggest reasons are it makes life a little easier to support offline scenarios for apps and to maintain code.  Currently, we have used a combination of methods such as binary, JSON and XML Serialization/DeSerialization.  Not the greatest solution but does work.

For the next version of Windows Phone, codenamed Mango, storing data in particular structured data, is now possible and is pretty easy.  With Silverlight for Windows Phone you are going to use LINQ to SQL for database operations.  You will also use LINQ to SQL to define your database schema in code.

How to access data?

Windows Phone DataContext and Local DatabaseWell the main namespace you will require is the System.Data.Linq which contains the main class to access data called System.Data.Linq.DataContext.  Combining DataContext, ‘plain old CLR objects’ (POCOs) and attributes, you can perform your CRUD operations on your data.  If you want a more thorough explanation, check out Local Database Overview for Windows Phone on MSDN.

But I’m Old School
old_schoolIf your are coming from Compact Framework world (and used to using SQL Compact, access to the data is not same.  For example, if you like using table direct to optimize data access (like I did Smile), well, you can’t do that with Windows Phone 7.  I’m assuming it’s because it’s V1 of SQL on Windows Phone but we’ll have to wait and see till next version.  From my preliminary testing and talking to the product group, they have focused on making things fast so for now I’m not worried.

What’s The Difference
If you are going to be using a local database for Windows Phone, you are going to have to be aware of some of the differences from using SQL Server. These are

  1. The database runs in process meaning, that it’s not running as a service like SQL Server but instead is only accessible only when you app is running.
  2. The database is when created is only accessible from the application that created it. The reason for this is it is created in Isolated Storage which is only accessible by the app that created it for security reasons. Think of it as a silo and other applications can’t access the data.

If you are coming from the desktop, then there are a few things you need to be aware of when using LINQ to SQL.  These are items that jump at me but all details can be found on the LINQ to SQL Support for Windows Phone on MSDN:

  1. There is no support for the ExecuteCommand which means you can run and Transact-SQL, DDL (Data Definition Language), or DML (Data Modeling Language)
  2. You cannot use LINQ to SQL to directly access ADO.NET objects such as the DataReader.  Any LINQ to SQL query will return an object collection defined by the DataContext
  3. BinaryFormatter is not supported – This basically means you will have to do some manual work here.  For example, if you are storing an image as binary in a column, you will only get binary back so conversion is not automatic.  You will have to use byte[], System.Data.Linq.Binary, or a LINQ to SQL CustomType

A few other things to be aware of

  1. If you are deploying a SQL Compact Database with your XAP (or it’s included in your project), the file is still accessible but it is read only.  If you want to write to it you will have to make a copy of it to Isolated Storage.  This might be use full if you are making a lookup table that never changes (for example drink mixes)
  2. You can update the database schema on the fly using the Structured Data API. Basically it will allow you to update Tables, Columns, Indexes, Associations/Keys but only basic updates. Complex upgrades might require a full database migration and custom code might also be required
  3. You cannot encrypt a database after it has been created. 
  4. You cannot share database across applications
  5. You can connect to a database from a Scheduled Task

What’s Next
Next up, I’ll follow up on a quick sample on creating a database and accessing the data on Windows Phone 7.  If you have already tried Local Database storage on Windows Phone let me know your experience by commenting below or via twitter @MarkArteaga

We are starting to build out Windows Phone 7.1 (Mango) support for some apps using the Windows Phone 7.1 (Mango) Beta tools available on create.msdn.com.  After installing the tools, I noticed that 7.0 projects (NoDo) were running in the 7.1 emulator which was not the ideal scenario for testing. 

Since there are obviously no 7.1 devices in market yet, it didn’t make sense to test our 7.0 app on a 7.1 emulator since there are obviously API improvements in 7.1.  Take for example the web browser control.  With Windows Phone 7.1 (Mango) is the IE9 browser where in 7.0 (Nodo or RTM) IE9 is not available, so there will obviously be differences.

So how will you know if the Mango emulator is running, just take a look at the icon list and if you see a search button then it’s Mango.

image

To work around this you will have to follow some steps.

If you have not installed the Windows Phone 7.1 (Mango) Beta tools do the following

  1. Make a backup of %ProgramFiles%/Microsoft SDKs\Windows Phone\v7.0\Emulation directory.  Primarily you will need the WM70C1.en-US.bin in the Image directory
  2. Install the Windows Phone 7.1 (Mango) Beta tools (you don’t need to uninstall the 7.0 tools)
  3. Rename WM70C1.en-US.bin to NODO_WM70C1.en-US.bin
  4. Copy NODO_WM70C1.en-US.bin to %ProgramFiles%/Microsoft SDKs\Windows Phone\v7.1\Emulation\Images

Now if you have installed the Windows Phone 7.1 (Mango) Beta tools you will somehow need to get a copy of the WM70C1.en-US.bin file.  My recommendation would be to

  1. Uninstall the Mango Beta Tools
  2. Re-install the RTM tools (don’t forget all the updates)
  3. Then follow steps 1-4 above

PLEASE NOTE: I followed the initial steps 1-4 but I’m assuming the second part will work but I have not tested.  Remember these are beta tools so do at your own risk!

If you have everything installed and running you will get the Mango ROM image running whenever you debug an application. 

So how do we get NoDo image running?

  1. If the emulator is running shut it down
  2. Open up a command line window
  3. Type the following
    "C:\Program Files (x86)\Microsoft XDE\1.0\xde.exe" "C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v7.1\Emulation\Images\NODO_WM70c1.en-US.bin" /boardid 0 /vmid {906C7DEB-4F8E-4006-BC37-D25BC8313C0A} /language 1033
    image
  4. Deploy your application from Visual Studio and VS will start debugging in the Emulator you just launched.
  5. To verify your are running NoDo, just go to the app list and if you don’t see a search button, you are good.

image

The key thing in the command line to note is the VMID parameter as this must be {906C7DEB-4F8E-4006-BC37-D25BC8313C0A} and the BOARDID must be 0.

Now you want to make sure you are doing this with a Target Windows Phone Version set to 7.0 (check your project properties).

image

I have not tried running this with a project targeted at 7.1 but I imagine things may ‘blow up’.

Please remember, this is a hack so try at your own risk.  We need to do this to support our products and customers and accept the risk of messing up our dev machines.  Also, don’t try to launch multiple emulators with the same VMID as it just won’t work.  Remember, these are beta tools so this may or may not make it into RTM but most likely this scenario will not be supported.

Next step is to get Visual Studio to launch the command line above so I don’t have to manually launch the NoDo emulator image.  That’s a task for another night!  If you are reading this and you know how to make that happen, please leave your comments!