Web Page Rank Check Tool

I found one web page rank checking tool: Google PageRank Checker. It is very easy to use. Just type in a URL and then verification code, you will see the rank for the web page. Here is the detail explanation about PageRank at WikiPedia with the formula how a rank value is calculated.

Here are results of my blogs. All are either 0 or N/A. Here is only one with 0:

This blog:

Read More...

Collapse...

Add Custom Managed Object Class

I use Core Data in my first iPhone application. During the development, I have many occasions to change/update my entity objects in my managed data model. For each change, I have to update the custom managed object class. XCode provides a template to create custom managed object class I generated before. However, it is very tricky to use this template. The key point is that you have select an Entity in Data Model first. Here are the steps to that.

Managed object classes are by default located in Resource group. The first step is to remove the old managed object class. For example, I added a new property "note" to entity "paymentType". Therefore, the first step is to remove the paymentType.m and .h files from Resource group.


Next, select the entity in .xcdatamodel, "paymentType". Then from the menu File, select "New File...".

Choose the template Managed Object Class in Cocoa Class:


All the next steps are very straightforward. Continue next to finish.

Apple's developer's web page provides similar information about this issue.

Another very critical thing to do is to remove the application in both device (iTouch or iPhone) and simulator. Since the managed data model has been changed, the updated .sqlite database most likely may not be compatible with the previous version. Therefore, the sqlite file has to be removed.

Read More...

Collapse...

MEF and IoC/DI (6)

Let's look my third API class - MEFWrapper.

MEFWrapper Class

The above two classes not only make the DI mappings easy, but they also try to expose MEF rich infrastructure as minimum as possible. How to load this DI information to MEF? This comes to the third class, MEFWrapper. The same applies to the MEFWrapper class. This class encapsulates the logic of how to create MEF's container and how add composable parts to the container.

Steps to Load DI Information

With this class, there are three steps to load DI information to MEF. The first step is get an instance of MEFWrapper through the static method CreateInstance(). This follows singleton pattern, to create a single MEF container instance per application.

The second step is to add DICatalog instances through Add() or AddRange() interfaces.

After all the DI information are added to MEFWrapper, the third step is to call the method of InitialzeDIMappings(), which encapsulates the logic of loading DI parts and catalogs to MEF container.

Get Mapped Instance

Now your MEF framework is ready for use. You can use MEF's Import attribute to let MEF to inject instances for your usage. MEFWrapper also provides static methods of GetInstance() and GetInstance(key) to explicitly retrieve a mapped instance from MEF.

Dispose MEFWrapper Instance

After your usage or your application is going to be terminated, you should call the method of dispose() (IDisposable implementation) of the MEFWrapper instance.

Here is an example of using this wrapper class in a DIRootCatalog class:

public class DIRootCatalog : DICatalogBase {
  private static MEFWrapper _instance = null;

  # region CTOR
  private DIRootCatalog() :
    base (Assembly.GetExecutingAssembly())
  { }
  # endregion

  public static void LoadDIMappings(){
    // Create instance and load DIs only once
    if (_instance == null) {
      _instance = MEFWrapper.GetIntance(new DIRootCatalog());
      // Exampels to add DIs to instance
      // Assume DIs are based on DICatalogBase
      _instance.Add(new DIDataReader());
      _instance.Add(new DIProcessorController());
      _instance.AddRange(
        new DICatalogBase[]{
          new DILog(), new DIDBService() }
        );
      _instance.Add(new DICatalogBase("DIExtensions"));
      // Initialze MEF Container with DI parts through catalogs
      _instance.InitializeDIMappings();
    }
  }

  public static void UnLoadDIMappings() {
    if (_instance != null) {
      _instance.Dispose();
      _instance = null;
    }
  }
}

...
internal class DIResolver : DIResolverBase {
    // Define Import and Export properties
  ...
}

And there is an example of a console application where the above DIRootCataLog is used:

class Program {
  static void Main(string[] args) {
    // Load MEF framework with DI mappings
    DIRootCatalog.LoadDIMappings();
    // Get process controler instance from MEF
    var mainProcess = MEFWrapper.GetInstance<IProcessController>();
    // Start process
    mainProcess.Start();
    // Unload MEF framework
    DIRootCatalog.UnLoadDIMappings();
  }
}

Here is the library of DICommonLibrary project.

Note: the project depends on two library files: one is MEF library and another is a related open source library for MEF. Both are available from CodePlex:

System.ComponentModel.Composition.dll
Microsoft.Practices.ServiceLocation.dll

Read More...

Collapse...

MEF and IoC/DI (5)

Let's look my second API class - DICatalogBase.

DICatalogBase Class

The second class I use in my practice of DI library is the DICatalog class. The main purpose of this class is to provide APIs load DIs as parts to MEF and to pass information to customize Export instances. DICatalog is a customized API class for public usage. Therefore, it is an optional class if the customization is required.

Add Parts

To facilitate loading DI parts to MEF, a base class of DICatalogBase with several CTORs (constructors) is provided, which correspond to load one or a list of libraries as assembly catalog, directory catalog, type catalog and aggregate catalogs.

Here are some examples. First one is to load DI by an executing assembly. In the base class the assembly is converted to assembly catalog instance to MEF:

public class DICatalog : DICatalogBase {
  public DICatalog():
    base(Assembly.GetExecutingAssembly())))
  {...}
}

internal class DIResolver : DIResolverBase {
    // Define Import and Export properties
  ...
}

The following is another example to use a base CTOR with a collection of two DICatalogBase instances. The first one is load the executing assembly as DI part and the second to load all the DI parts in a directory ("DIExtensions" under the executing assembly location).

public class DICatalog : DICatalogBase {
  private const string DIExtensions = "DIExtensions";
  public DICatalog()
    : base(new DICatalogBase[] {
      new DICatalogBase(Assembly.GetExecutingAssembly()),
      new DICatalogBase(DIExtensions)
      })
  {...}
}

internal class DIResolver : DIResolverBase {
    // Define Import and Export properties
  ...
}

Since the inherited instances based on DICatalogBase are created by clients and then loaded to MEF; therefore, the inherited classes have to be public.

Pass Customized Information

The customized information is passed through a customized CTOR of DICatalog class. For example, if some exported instances have to be created based on a configuration file, a customized CTOR can be used to input the configuration information.

Here is an example of DICatalog class with a Configuration class as CTOR's parameter:

public class DICatalog : DICatalogBase {
  [Export]
  private static LogConfig _logConfig { get; set; }

  internal static DataReaderConfig _readerConfig { get; private set; }

  public DICatalog(Configuration config)
    : base(Assembly.GetExecutingAssembly()) {
    _logConfig = config.LogConfig;
    _readerConfig = config.ReaderConfig;
    ...}
}

internal class DIResolver : DIResolverBase {
    // Define Import and Export properties
  ...
}

The configuration is passed as CTOR's parameter to the DICatalog class. How is this information passed to MEF's parts? Here I use two ways to achieve it.

The first one is by using Export attribute for a private property value, i.e., to export LogConfig. The DICatalog class has a customized CTOR, therefore MEF cannot create an instance of it. Even MEF could create an instance of the class if the default CTOR were defined; we would not be able to set the property value for the instance. In order to set the Export property value, the property has to be static and it can be set in CTOR. Fortunately, MEF does pick up the exported value from a static property. Here LogConfig is an exported property known to MEF.

The advantage of using Export attribute is that the exported value can be injected to anywhere in other DI libraries, components, or application through MEF Import attribute. If a piece of information is only used within a library, by using static property may be good enough. Here the second property of DataReaderConfig may be used within the DIResolver class, to customize a DataReader class instance as Export.

Read More...

Collapse...