On the client-side, a Pocket PC application was used. Since this has no guaranteed connectivity, some additional techniques had to be used to improve the end-user experience.

First of all, when calling a webservice from a Pocket PC, it was possible that the call would take a long time. If this would have been done synchronously, the application would lock up as long as the call was being processed. To prevent this, the call was made asynchronously and a progress bar was displayed.

To achieve this, a Timer was used from the System.Threading class, to update the progress bar when it was visible. This caused the timer to run on a different thread from the application, and make call-backs at certain intervals to update the user interface containing the progress bar.

The following code was used to easily start and stop the progress bar:

[csharp]
using System;
using System.Threading;

namespace MediaService.Pocket {
public class MediaForm : System.Windows.Forms.Form {
private System.Threading.Timer progressTimer;
private OpenNETCF.Windows.Forms.ProgressBarEx asyncProgress;
private System.Windows.Forms.Label asyncLabel;

public MediaForm(Int32 userId, String authTicket) {
TimerCallback progressDelegate = new TimerCallback(this.UpdateProgress);
this.progressTimer = new System.Threading.Timer(progressDelegate, null,
Timeout.Infinite, Timeout.Infinite);
} /* MediaForm */

private void StartProgress(ProgressEnum progressType) {
// Reset progressbar and show
this.asyncProgress.Value = this.asyncProgress.Minimum;
this.asyncProgress.Visible = true;
this.asyncLabel.Visible = true;
this.asyncLabel.Text = "Retrieving Content";
this.progressTimer.Change(0, 100);
} /* StartProgress */

protected void UpdateProgress(Object state) {
if (this.asyncProgress.Value + 1 > this.asyncProgress.Maximum) {
this.asyncProgress.Value = this.asyncProgress.Minimum;
} else {
this.asyncProgress.Value++;
}
} /* UpdateProgress */

private void StopProgress() {
this.progressTimer.Change(Timeout.Infinite, Timeout.Infinite);
this.asyncProgress.Visible = false;
this.asyncLabel.Visible = false;
} /* StopProgress */
[/csharp]


After the progress bar was started, an asynchronous call was made to the webservice, preventing the application to lock up, using the following syntax:

[csharp]
AsyncCallback callBack = new AsyncCallback(this.OnGetSongs);
IAsyncResult songsResult = this.GetService().BeginGetSongs(callBack, null);
[/csharp]

This started the call to the webservice on a different thread, and when the webservice call finished, it called back to the OnGetSongs method in this case. In this method, the results were retrieved and the user interface was updated.

[csharp]
private void OnGetSongs(IAsyncResult songsResult) {
this.availableSongsCache = this.GetService().EndGetSongs(songsResult);
if (this.InvokeRequired()) {
this.Invoke(new EventHandler(this.UpdateAvailableSongs));
} else {
this.UpdateAvailableSongs(this, System.EventArgs.Empty);
}
} /* OnGetSongs */
[/csharp]

It was possible that the callback occurred from a different thread. In that case it was not possible to update the user interface, since the thread did not own the form controls. To detect if the callback occurred on another thread or not, the following code was used:

[csharp]
namespace MediaService.Pocket {
public class MediaForm : System.Windows.Forms.Form {
private readonly Thread formThread = Thread.CurrentThread;

private Boolean InvokeRequired() {
return !this.formThread.Equals(Thread.CurrentThread);
} /* InvokeRequired */
[/csharp]

If the callback happened on another thread, the Invoke method had to be used to handle the update of the user interface on the thread that owned the interface. For this reason, the method updating the interface had to have the following signature:

[csharp]
private void UpdateAvailableSongs(object sender, EventArgs e) {
[/csharp]

At this point, it was possible to make a webservice call without locking the user interface, and informing the user something is going on thanks to the progress bar.

After having implemented a data layer in the Data project, it was time to make a real data implementation. A Sql Server 2000 implementation was the default data source, located in the Data.SqlServer project.

Enterprise Library was used to provide the data access to Sql Server. This contained a Data Access Application Block, which allows configuring the connection string through the Enterprise Library Configuration tool.

A reference to Microsoft.Practices.EnterpriseLibrary.Data was needed, together with the Configuration and Common assemblies of Enterprise Library.

Through the Enterprise Library Configuration tool, an existing App.config was loaded, where the Data Access Application Block was added. The database and server values had to be configured to the actual server being used, together with the database containing the data. Additional connection string properties could be added as well, for example, the Integrated Security property, which is set to True.



After saving this file, it was possible to create a data implementation for each Accessor interface previously defined in the Data project, as for example this code:

[csharp]
using System;
using System.Data;
using System.Collections;

using MediaService.Logging;
using MediaService.Objects;
using MediaService.Data.Accessors;

using Microsoft.Practices.EnterpriseLibrary.Data;
using Microsoft.Practices.EnterpriseLibrary.Logging;

namespace MediaService.Data.SqlServer {
public class SongDataAccessor: ISongDataAccessor {
} /* SongDataAccessor */
} /* MediaService.Data.SqlServer */
[/csharp]

Thanks to the Enterprise Library Data Access Application Block, the Sql Server implementation used best practices from the Microsoft Patterns & Practices group, which followed Microsoft guidelines and were optimized for performance.

To get an array of objects from the database, a new Database object had to be created, after which a stored procedure was wrapped, called and read from to get for example Song objects. This was done with the following code:

[csharp]
public Song[] GetSongs() {
Database db = DatabaseFactory.CreateDatabase("MediaServiceSqlServer");

DBCommandWrapper dbCommandWrapper =
db.GetStoredProcCommandWrapper("GetSongs");

Logger.Write("Retrieving songs.", Category.SqlServer,
Priority.Lowest, 1, Severity.Information);

ArrayList songs = new ArrayList();
using (IDataReader dataReader = db.ExecuteReader(dbCommandWrapper)) {
while (dataReader.Read()) {
songs.Add(new Song(dataReader.GetInt32(0), dataReader.GetString(1),
dataReader.GetString(2), dataReader.GetString(3),
dataReader.GetString(4), dataReader.GetString(5),
dataReader.GetString(6), dataReader.GetInt32(7),
dataReader.GetInt32(8), dataReader.GetInt32(9)));
}
}

Logger.Write(String.Format("Retrieved {0} {1}.", songs.Count,
(songs.Count == 1) ? "song" : "songs"),
Category.SqlServer, Priority.Lowest, 1, Severity.Information);

return (Song[])songs.ToArray(typeof(Song));
} /* GetSongs */
[/csharp]

Updating an item by using a stored procedure which uses parameters, was done by using the following code:

[csharp]
public void UpdateSongPlayCount(Int32 songId) {
Database db = DatabaseFactory.CreateDatabase("MediaServiceSqlServer");

DBCommandWrapper dbCommandWrapper =
db.GetStoredProcCommandWrapper("UpdateSongPlayCount");
dbCommandWrapper.AddInParameter("@songId", DbType.Int32, songId);

Logger.Write(String.Format("Updating play count for song: {0}.", songId),
Category.SqlServer, Priority.Lowest, 1, Severity.Information);

try {
db.ExecuteNonQuery(dbCommandWrapper);
} catch (Exception ex) {
Logger.Write(String.Format("Failed to update play count for song: {0}.
Error: {1}", songId, ex.ToString()),
Category.SqlServer, Priority.Highest, 1, Severity.Error);
}
} /* UpdateSongPlayCount */
[/csharp]

Using stored procedures made it possible to have another layer of abstraction. This made it easy changing an existing stored procedure to keep track of statistics, without having to change any code of the implementation. At the same time, using stored procedures also protected against Sql Injection attacks. After all Accessors were implemented, it was possible to use this implementation by deploying the SqlServer dll and selecting it as data source.

Any application using data benefits from having a separate data layer. This enables the administrator to select which data source to use. It also makes your application have an advantage, making it easier to sell.

Besides from the advantages for the end-users, it’s also best practices to separate the data layer from your presentation and business logic layer.

To provide the data layer to the application a Data project was added. The layers above the data layer never accessed the real data implementations, but worked with objects which implemented certain data interfaces. This way, it was possible to define all possible data related methods in an interface and afterwards implement them in a real implementation.

A logical grouping was applied when creating the interfaces, starting from a generic IDataAccessor from which every other interface inherited from.

[csharp]
using System;

namespace MediaService.Data.Accessors {
public interface IDataAccessor {
} /* IDataAccessor */
} /* MediaService.Data.Accessors */
[/csharp]

One of the logical sections was for example everything related to Song objects:

[csharp]
using System;

using MediaService.Objects;

namespace MediaService.Data.Accessors {
public interface ISongDataAccessor: IDataAccessor {
Song[] GetSongs();
Song[] GetQueue();
Song[] GetMostPlayed(Int32 numberOfSongs);
Song[] GetMostPopular(Int32 numberOfSongs);
} /* ISongDataAccessor */
} /* MediaService.Data.Accessors */
[/csharp]

Since the other projects did not have a reference to the real data implementations, but only to the Data project, this project had to take care of loading the correct implementation. Loading the correct class in the real implementation is done by using factories. For every Accessor interface a factory exists, returning an instance of the data implementation, using the following code:

[csharp]
using System;
using MediaService.Data.Accessors;

namespace MediaService.Data.Factory {
internal class SongFactory: Factory {
internal static ISongDataAccessor Create() {
return Factory.Create(Accessor.Song) as ISongDataAccessor;
} /* Create */
} /* SongFactory */
} /* MediaService.Data */
[/csharp]

In the Data project, there was one Factory class, responsible for loading the correct assembly containing the data implementation and instantiating the correct Accessor class. This was done by using Reflection together with Configuration to retrieve the location. The location consisted out of the class name and the assembly name, separated by a comma, as for example the location for the SongDataAccessor:

[xml]

MediaService.Data.SqlServer.SongDataAccessor,MediaService.Data.SqlServer

[/xml]

This location data was retrieved by configuration, after which it was separated into assembly and class parts and loaded with Reflection with the following code:

[csharp]
using System;
using System.Reflection;

using MediaService.Configuration;
using MediaService.Data.Accessors;

using Microsoft.Practices.EnterpriseLibrary.Configuration;

namespace MediaService.Data.Factory {
internal enum Accessor {
Song
} /* Accessor */

internal class Factory {
internal static IDataAccessor Create(Accessor accessorType) {
DatabaseData configData = LoadConfiguration();

if (configData == null) {
throw new ApplicationException("Could not load configuration.");
}

String blockToLoad = String.Empty;
switch (accessorType) {
case Accessor.Song: blockToLoad = configData.SongDataAccessor; break;
}

if (blockToLoad == String.Empty) {
throw new ApplicationException(String.Format(
"Type entry not found for {0}.", accessorType.ToString()));
}

Int32 index = blockToLoad.IndexOf(",");
string typeToLoad = blockToLoad.Substring(0,index);
string assemblyToLoad = blockToLoad.Substring(typeToLoad.Length + 1,
blockToLoad.Length - typeToLoad.Length - 1);
return (IDataAccessor)Assembly.Load(
assemblyToLoad).CreateInstance(typeToLoad);
} /* Create */

private static DatabaseData LoadConfiguration() {
ConfigurationManager.ClearSingletonSectionCache("databaseConfiguration");
return ConfigurationManager.GetConfiguration(
"databaseConfiguration") as DatabaseData;
} /* LoadConfiguration */
} /* Factory */
} /* MediaService.Data.Factory */
[/csharp]

All of the Factories were marked internal because they are just meant for internal workings of the data layer, while all Accessors remain public because they had to be accessible to implement in the real data implementation.

Besides the Accessor interfaces, the Data project also exposed one public class, named Dalc. This class contained static properties for each logical data section, returning an instantiated Accessor from the configured data source.

[csharp]
using System;

using MediaService.Data.Accessors;
using MediaService.Data.Factory;

namespace MediaService.Data {
public class Dalc {
public static ISongDataAccessor Song {
get { return SongFactory.Create(); }
} /* Song */
} /* Dalc */
} /* MediaService.Data */
[/csharp]

After this, it was possible to access data by adding a reference to the Data project, adding a real data implementation assembly to the deployed location and configuring it. For example, the following code retrieved all songs from the data source:

[csharp]
using MediaService.Objects;
using MediaService.Data;
using MediaService.Data.Accessors;

namespace MediaService.Web {
public class Media {
public Song[] GetSongs() {
return Dalc.Song.GetSongs();
} /* GetSongs */
[/csharp]

With this data layer, all details about data access are contained in the real data implementations, while nowhere else there is specific data source code. The entire application works on data objects, which implement the data interfaces, while under the hood, the correct data source is selected through the configuration file.

The Pocket PC I recently received was completely in French, so I figured 'I'll just change this to English'.

It can't be that hard, can it? Apparently it was trickier then I thought.

The Pocket PC has the OS in it's ROM, and it has limited ROM, so no multilanguages in there.

It quickly became obvious to me the ROM had to be flashed with an English version, but where to get it?

I didn't buy the Pocket PC, so asking Dell to give me an English one probably would fail, and from various messageboards I discovered they won't do it anyway.

So, where to get it? From the Dell site I guessed, in the download section there was an English update for Windows Mobile 2003 Second Edition.

Since this update just flashes the ROM and puts the new version in it, I guessed this was ok.

But when trying to flash it, it started complaining about being the wrong language.

Apparently French can only be upgraded to French, and since I don't speak French fluently this wasn't practical :)

So, search engine to the rescue. I found this post on Aximsite, a site dedicated to Dell Axim resources.

It seemed logical, get the English and French ROM, make the updater believe the English ROM is actually a French language, and flash.

The process looked obvious to me, so, let's get started!

I opened up the French ROM and English ROM in a hex editor and located the differences:



Note:
This is different from the forum post! It's not the first 7 lines you have to copy paste.

Pasting the first 7 lines results in an Integrity Check error. It's enough to change everything before the "AXIM30".

After having modified the English ROM with the new header, I saved it to the French updated directory, overwriting the original French ROM update. (So, now you have a filename which indicates it's a French ROM, but it's actually the English ROM with the French header)

I did the same for the other image (there is a C and an N image).

Now I ran the updater, which did not give me an error about Integrity Check anymore, and also not about wrong language.

It successfully updated the ROM and after the Pocket PC restarted, everything was English!

So, now I have an English Pocket PC :)


Of course, the disclaimer on my blog applies especially to this post, as this is not something you should do quickly if you have no technical skills.

So: I (David Cumps) cannot be held responsible for any damage what-so-ever that might come from this post. You do this at your own risk.

A while ago I blogged about Alternate Data Streams and how they are hidden from the users.

At that time, you could presume when an ADS was present, it was something special, because not many normal files have an ADS attached to it.

But yesterday I got an interesting question about XP SP2 showing a Security Warning when you want to execute something downloaded from the internet.

We guessed Alternate Data Streams were used, so I checked this out and it turns out XP SP2 indeed adds an ADS when you download a file from the Internet.

This stream is called Zone.Identifier and contains the following information:

D:\Tmp>more < TestZip.zip:Zone.Identifier
[ZoneTransfer]
ZoneId=3


Since SP2 did this, it probably means it's a modification to Internet Explorer.

So, I got the Firefox 1.0.3 and downloaded a file with the default settings, and as I guessed, no ADS with Zone.Identifier.

(I believe Firefox doesn't have such thing as Zones, but it would be nice if Firefox added this ADS to let the new Security Warning, informing you it's a downloaded file, come up).