Copy the working website in another directory (source directory), and remove the database file from the source directory.

Modify the following information in the xml file, directly under the configuration root tag :

• source : the file path

• applicationName : the application name, which will be the same in each device type

• assembyDescription : the assembly description, which will be the same in each device type

• applicationAssemblyName, assemblyConfiguration, assemblyProduct, assemblyCompany, assemblyCopyright, assemblyCulture : the application assembly data as recorded in the Assembly.cs, which will be the same in each device type

• slnName : the solution file name, which will be the same in each device type

For each project to be put in the final solutions, add to configuration add projectFiles tag, with the full project path.

Change the syncClassName to the full classes name for the synchronization class.

Configuration the fake classes : if a class in a custom assembly is used in the web.config file (for instance an Action or Extractor), or is used only in reflection (using the Constructor.Invoke), there MUST be a fake class with an empty constructor. The class name is then referenced in the config file in a fakeClass tag.

For instance, a Activsoft.TestApp.TestAction is referenced in the web.config file, you must create an Activsoft.TestApp.FakeClass with an empty constructor.

This fake class will be instanciated at the starting of the application, forcing the virtual machine to load the assembly and avoiding bugs in IOS and Android especially.

The last part of the common configuration is to configure the XSL generation.

As mentionned in the Zenengo documentation, the XslFilter transforms the XSL files (with the acs controls, the right:, the xml:lang, ...) to create the XSL files that will be used to parse the XML stream.

In a mobile application, this part is done during the conversion, and the final XSL files used are all stored in the offline application.

The only thing to configure are the parameters eventually used to create the transformation, which will be put under the xslFilterParameters tag. The param tag must have the name attribute with the name of the parameter, and a tag value for each possible value.

For example, if the application uses the TranslationXslFilter to have two languages (let's say fr and en), the configuration must contains the following tags :

<xslFilterParameters>
  <param name="language">
     <value>fr</value>
     <value>en</value>
  </param>
</xslFilterParameters

The first step is to prepare the application resources, especially the application icons.

All the file must be stored directly in a directory, which be referenced under the destination tag in a ressourceToCopy tag.

To handle all the cases, the icon file must be in the following formats :

• 72x72

• 144x144

• 76x76

• 152x152

The first step is to prepare the application resources, especially the application icons.

All the file must be stored directly in a directory, which be referenced under the destination tag in a ressourceToCopy tag.

To handle all the cases, the icon file must be in the following formats :

• 72x72

• 144x144

• 76x76

• 152x152

Each icon will be referenced in an applicationIcon tag directly under the destination tag.

The next step is to declare the application in the apple developper program to fill the development profiles, the provisioning profile, the app bundle name.

The steps are described here.

After that it'll be possible to fill the following tags under the destination tags :

• adHocSignatureIdentity and adHocProvisionningProfile : the first is the Signature Certificate name as shown in the keychains manager, and the UUID shown in the mobileprovision file for the ad Hoc certificate (the file can be opened simply with a text editor)

• debugSignatureIdentity and debugProvisionningProfile : same for the debug execution profile

• appStoreSignatureIdentity and appStoreProvisionningProfile : same for the AppStore execution profile

Configure the last parameter tags:

• path : the final solution path, the project will be copied in this directory.

• modelConfigPath : the model directory for this application. In the Yoocan Move pack there is a model for IPhone application and a model for IPad application. It is possible to adapt those models to create personnalized models.

• applicationType : IOS

The first step is to prepare the application resources, especially the application icons.

All the file must be stored directly in a directory, which be referenced under the destination tag in a ressourceToCopy tag.

To handle all the cases, the icon file must be in the following formats :

• 72x72

• 144x144

• 76x76

• 152x152

The first step is to prepare the application resources, especially the application icons.

The ressource directory, which will be referenced under the destination tag in a ressourceToCopy tag, must be structured as it will be in the final Android project, thus must have the drawable, drawable-ldpi, drawable-mdpi, drawable-xhdpi, drawable-xxhdpi, drawable-xxxhdpi subdirectories.

To handle all the cases, the icon file must be all the directories listed above, with the same file name. The file name will be referenced in an applicationIcon tag directly under the destination tag.

The next step is to create the keystore and to create the signin profile for Google Play.

After that it'll be possible to fill the following tags under the destination tags :

• AndroidSigningKeyStore : the keystore file path

• AndroidSigningStorePass : the keystore password (yes, in clear!)

• AndroidSigningKeyAlias : the signing profile alias

• AndroidSigningKeyPass the signing profile password

Configure the last parameter tags:

• path : the final solution path, the project will be copied in this directory.

• modelConfigPath : the model directory for this application. In the Yoocan Move pack there is a model for IPhone application and a model for IPad application. It is possible to adapt those models to create personnalized models.

• applicationType : Android