Create initial project, making it easily customizable

[deepiksdev]

This project will be developed using the Wind magazine as an example, but many other similar magazine apps will be created after the completion of this project.
In order to create new apps for each existing and new magazine, a simple mechanism should be suggested and implemented. It is very important that no specific line of code needs to be written for each app. The customisation should be made only by changing specific text, xml and image files.
On iOS, we achieve this by creating different targets in Xcode. On Android, the customization is achieved as explained in the readMe file.

[deepiksdev]

Right now I'm looking for best way to customize application. If I'm right - you need the easily way to create fully separated application for Magazine - it means we need a method or tool to create app based on template app (way used in Android in VS 2012 will take you much more manual operations - like rename - so I'm trying to reduce count of manual operations to zero).
Now I'm investigation 3 ways: manual project customization (that include assets & manifest rewrite and some operations to refractorily), special tool (that simple will got project template & property file with the setting and generate new project, and creation new Visual Studio project template).

At this point, we are not looking for a totally automated solution. We prefer to avoid creating a "special tool". We will develop it if needed later. We prefer something simple, even if it includes some manual operations.

[moskvin]

Later, I think you can use nuget tools

[voyagerj]

Thanks for the advice about NuGet - I think we can use it if we'll use one of it's package or will have to redesign our solution as library/package.

For now, I'm going fix on solution I note as 1.3. But I'll put here all possible solution.

Possible ways to create new Magazine.

1.1 Manual way. Lets say, we have RedApp (app we want to use as a template) and want to create GreenApp.

1. Create GreenApp folder.
2. Copy a whole project RedApp to GreenApp.
3. Delete temp pfx file (RedApp_TemporaryKey.pfx) - ??? Questionable, because it is working without this file.. but possible we'll have some problems in future during deploying/deploying to App Store.
4. Rename RedApp.sln to GreenApp.sln & RedApp folder to GreenApp folder
5. Rename RedApp.csproj to GreenApp.csproj
6. Replace folder/solution name RedApp in .sln file to Green app (replace "RedApp", "RedApp\RedApp.csproj" with "GreenApp", "GreenApp\GreenApp.csproj")
7. Replace namespace RedApp in all *.cs files (replace "namespace RedApp" with "namespace GreenApp") - you also can do this with using VS refactor/rename feature.
8. In App.xaml rename x:Class="RedApp.App" with x:Class="GreenApp.App", and xmlns:local="using:RedApp" with xmlns:local="using:GreenApp"
9. make the same replacing in MainPage.xaml
10. In Package.appxmanifest replace next items:
    RedApp
    voyager
    EntryPoint="RedApp.App">
    DisplayName="RedApp"
    Description="RedApp"
11. Rewrite Assets & Properties & strings folders.
12. Replace package GUID: in Package.appxmanifest, <Identity Name="f0c4d3bd-8333-4b7f-8e47-47e0256a92c1", replace guid with new guild (you can genearte new GUID with using VS Tools/Create GUID).
13. Replace project guild: in files .sln and .csproj reaplce A3053A9C-4834-46C4-9B7B-B8034A7B4CB9 with new GUID (note, this guid differ from package guid!). Don't change ProjectTypeGuids!
14. Remove any temporary files if present (bin, obj, *.suo, *.user)
15. Done

Possible Risks: RedApp_TemporaryKey.pfx. If I'm right - this is compiled version of Package.appxmanifest, but still don't know how to regenerate it.

1.2 We can use the same approach as in previous case, but use tool that will make all replacements & re-generate GUID. Take ~1 day to create.

1.3 Manual way - use OBRATNIY approach - create application we need and only rewrite sources/resources. Lets say, we have RedApp and we want create BalckApp based on it.

1. With the using VS 2012, create Black app (File/New Project/Visual C#/Black APP (XAML)). Name it "BlackApp"
2. Setup project as you need (set up app title, description, package name and so on).
3. Rewrite sources & resources from Red App, except:
   • App.xaml
   • App.xaml.cs
   • Package.appxmanifest
   • Properties
4. In App.xaml.cs rewrite
   if (!rootFrame.Navigate(typeof(MainPage), args.Arguments))
   with
   if (!rootFrame.Navigate(typeof(RedApp.MainPage), args.Arguments))
   (note that RedApp this case doens't refer to certain magazine "RedApp" - it will be general namesapce like LiberioMagazineGeneral.MainPage)

Limitation: we should create app manually, but it seems ok for now.

So, project structure will contain next mandatory elements:

• Assets - the same as in Andorid project + Andorid/res folder. Will divided into 2 sub-trees: general resources and magazine specific resources. Resources specific for each magazine will overwrite
  when create a new project.
• Assets\strings - will include all strings we need in app. All string values in xaml, code or manifest should use resources from this folder.
• Common - styles, general for all magazines. (also used VS for “common” code).
• Styles - folder for magazine specific styles.

Further description under construction...

[deepiksdev]

I am not very comfortable with this approach 1.3, for different reasons:

• it seems to require some code rewriting (point 4) which we want to avoid
• for what I understand, the code is duplicated, which will make maintenance of the different apps very difficult.
• there does not seem to be an easy way to maintain common assets, other than sorting manually

In iOS, we use targets, which works pretty well. See README.md in https://github.com/libreliodev/iOS (authorization required). There seems to be an equivalent feature in Visual Studio (http://stackoverflow.com/questions/5074333/definitions-of-xcode-project-templates-and-approaches-to-cocoa-development), which was not the case in Eclipse. Can't we use it?

[voyagerj]

Sorry for the confusion - it seems I describe approach not very clear. We are not speaking about further maintenance a group of you projects (magazines).
For further maintenance we can use any approach we want: we can use Soltuion with several projects (analog of the targets from XCode) or we can use common folders for the sources
and add links to *.cs instead of adding files, or we can create a library that will contain all sources we need to create a project and small entry point for each magazine.

I tried to describe a way, how to create new magazine for the first time in additional to already existing. We have to create separated entry point for each magazine, but we should make it only
once for each magazine.

Code rewriting - yes, you will have to rewrite some code, but not in our application sources, but in sources that will created by Visual Studio - when you create a new project in it - it is generate
some code that contain Entry point (unique for each magazine). And you'll have to make some correction in this files (generated by VS, not in our core files).

About code duplication - as I wrote above - we have at least 3 different way how to design our full solution for the easily maintenance and we can choose any method we like. It's really painful
to have many copies of the same sources...

About assets - I'm not sure what exactly you mean. Do you able to explain it with simple example? If I'm right - in Android to create new magazine you have to rewrite only 2 folders: assets & res.
At least res contains either common or magazine's assets, right? In VS project we are going to have only 1 magazine specific folder - Assets/magazine. If you are speaking about sharing
common resources for each magazine (to have only 1 copy of the common assets for all magazines) - this is another question and it is depends on a way to maintenance we choose for a whole group of
magazines.

p.s. It is possible will be good idea create a project that will contain not 1 magazine (only wind) but at least 2 different magazine to show customizing mechanism more clear and find out any further pitfalls. I also thought about this when looking through the Android solution. When you have 2 magazines it is better to understand how it is working.

[deepiksdev]

About assets - I'm not sure what exactly you mean. Do you able to explain it with simple example? If I'm right - in Android to create new magazine you have to rewrite only 2 folders: assets & res.
At least res contains either common or magazine's assets, right? In VS project we are going to have only 1 magazine specific folder - Assets/magazine. If you are speaking about sharing

There are actually some specific assets for each magazine (for example the background of the magazines grid view), and some common assets (for example, some buttons).

p.s. It is possible will be good idea create a project that will contain not 1 magazine (only wind) but at least 2 different magazine to show customizing mechanism more clear and find out any further pitfalls. I also thought about this when looking through the Android solution. When you have 2 magazines it is better to understand how it is working.

It's certainly a good idea. Again, if it can be done in a similar way as targets on iOS, it's probably the best option.

[libreliodev]

We need to reorganize the project:

• we should remove the WaterMagazine project
• we should remove the tools directory.
• we should rename the WindMagazine project to LibrelioMagazine (representing the template)
• if possible, we should remove the muPDF project, and keep only the elements required to compile our app
• if possible, we should put all customization elements (icons, splash, application_.xml ...) in a specific directory

cc @dd1804

[libreliodev]

Subject to further investigations, the best way to create multiple customized versions will probably be the one suggested in the 2nd answer at http://stackoverflow.com/questions/1116465/how-do-you-share-code-between-projects-solutions-in-visual-studio

[libreliodev]

@dd1804 After some extra work and tests on the customization process, here is how we intend to make customized version (this will be automated via a bash script or similar):

• duplicate Libreliomagazine.csproj, name the new file [App].csproj
• change ProjectGuid (7th line) in [App].csproj
• change PackageCertificateKeyFile (to be confirmed) in [App].csproj
• change Package.appxmanifest to [App].appxmanifest in [App].csproj
• add the following lines to LibrelioApplication.sln

Project("{[NewId]}") = "[App]", "LibrelioMagazine\[App].csproj", "{[ProjectGuid]}"

    ProjectSection(ProjectDependencies) = postProject

        {56C66C4F-3C21-4929-BAF1-2EDA2EC56823} = {56C66C4F-3C21-4929-BAF1-2EDA2EC56823}

    EndProjectSection
EndProject 

-  duplicate  Package.appxmanifest, name the new file [App].appxmanifest
- make relevant changes in [App].appxmanifest

[dd1804]

I've worked on customization, let me know if this is ok.

[dd1804]

Steps to add a new magazine project:

Step 1: Copy-paste the LibrerioMagazine directory in LibrelioApplication (the folder size is < 1MB)

Step 2: Rename LibrelioMagazine.csproj in the new folder to the new magazine project

Step 3: Add the new project to the LibrelioApplication solution

Step 4: Add all the mandatory customization assets, that have the correct names and covers in the Covers folder. (If there is no WideLogo asset please use the empty image in the Wind project since if there is none the tile will not appear wide in the start screen). If the mandatory assets are not provided under the correct name the project will not compile.

Step 5: Add covers and optional assets to project

Step 6: Edit application_xml, set the active project of the solution and build

Please note that the only thing you need to edit in Package.appxmanifest is the background color.

[dd1804]

I'll work on automating this process as well.

[libreliodev]

@dd1804 The customization process you suggest looks fine. I noticed that the code is not duplicated, which is great. However, this is the case for certain common assets, including localization strings (apparently). I am afraid this could have undesirable effects; for example, if we want to change a translation in the current solution, I imagine we need to update 3 files , which is error prone. Can we avoid this?

[libreliodev]

Also, is there a way to make LibrelioMagazine compilable?

[libreliodev]

Please note that the only thing you need to edit in Package.appxmanifest is the background color.

I believe we will also need to change the package name (otherwise, I think we can install only one app from Librelio on a device) ,the publisher name (Céol, Nivéales ...), the certificate name ...

[dd1804]

Yes, I wanted to say that you don't have to change any information about assets and capabilities. All the specific information about the app will need to be updated in this file.

[dd1804]

Also, is there a way to make LibrelioMagazine compilable?

I removed the assets from LibrelioMagazine. I can put some empty image assets and it will compile.

[libreliodev]

Also, is there a way to make LibrelioMagazine compilable?

I removed the assets from LibrelioMagazine. I can put some empty image assets and it will compile.

Don't bother about this, we'll do it ourselves.

[dd1804]

However, this is the case for certain common assets, including localization strings (apparently). 
I am afraid this  could have undesirable effects; for example, if we want to change a 
translation in the current solution, I imagine we need to update 3 files , which is error prone. 
Can we avoid this?

I've moved the localization files to the common assets folder and linked them to the projects.

[libreliodev]

I've moved the localization files to the common assets folder and linked them to the projects.

There is still an "Assets" directory inside CeolHorizons and NivealesWind, which contains "Strings" and other common elements. Can we safely remove all the contents of this directory?

[dd1804]

I've pushed more work on this and now it can safely be removed

[libreliodev]

OK