i have an app that will be shipped by different providers. So i need to exchange the backgrounds etc, ss there is probably some kind of unique identifier for each app i also need different projects for that. What's the best practice to do this on windows phone ? Do i have to write own "Wrapper"-Projects ? (In iOS there is a concept called targets where i just link relevant branding files, appname, identifiers etc)
Thanks for your help !
In XAML, you can use Styling and Templating to dynamically change the whole look and feel of your application.
The same principal applies to Windows Phone apps as well. Then all you got to do is, maintain different style xaml files and apply them to create unique builds, or once the application launches.
Update: As willmel suggests below, which I forgot to mention, localization techniques mentioned here are a great way to maintain application strings.
Update 2: You can package your 'themes' into separate ZIP files, as demonstrated here and use post build events and VS commands to create different packages. You can always call msbuild from the command line as well and customize your build process even further. You can use different manifests this way as well.
If you have provider information which is language specified, you can download a sample project here:
http://www.pocketpc.ch/windows-phone-7-entwicklung/158405-textbox-string-integer.html#post1381376
or another here, or in VB
Once, you know the provider, you can select your resource file.
That article from Tim Heuer can show how you can work with less work for different situations like used in XCode iOS. Additional to strings you can use image URL as well.
Related
I'm creating a RN app that is meant to be some kind of wrapper. It should have multiple targets (like in Xcode) and all its content (images, text, etc.) should be target dependent. Unfortunately, I cannot find any useful informations about how to achieve this without opening Xcode or Android Studio project and create those targets manually (like here). Is there any other solutions for this?
I was still struggling with described problem but I finally found a solution. It's not easy, needs writing a bit of boilerplate code and looks more like a workaround but I hope it will help someone in the future. What I did is I have completed my wrapper app with the resources for one of my targets so I can have visual effect. In the project's root directory I've created a folder with subfolders for each target. Inside each I have put files (images, source code files, other assets) that are target-dependent. Then I've created bash script that takes one argument - target's name. Based on it, it replaces all the target-dependent files from target's subfolder to the original file's destination in the project structure. In this proces all meta-data informations are also replaced so after firing .sh file I can build the app and upload it to both stores. It's really time consuming to create all these apps separately and publish them and it's maybe not the best solution, but at least it works!
On android, you can edit build.gradle files, java or properties, without having to launch Android Studio (which simply uses Gradle)
You can build different type flavours by only changing app/build.gradle
On iOS, that's another story. Project file (.pbxproj) is a mess,and other Workspace/Scheme files are not easy to read or script. So XCode is the way to Go.
I tried to have dynamic target & Info.plist, there are tools to script that like PlistBuddy
in the end, I saw there are many ways to launch a React Native app for developpers. Some prefer the command line, and only VSCode.
Others want to play with native IDE.
By the way, native IDEs are VERY useful.
e.g. : you want to fine-tune your application performance, using XCode view hierarchy debugger or android Studio Layout Inspector (and be sure you don't use to many views), or use any other performance tools these IDEs offer...
In the end, I used react-native-config along with multiple almost similar configs (Info.plist < target < Scheme for each), here's a post giving an overview of the setup.
I read from MSDN that solutions "contain items that you need to create your application". What exactly does that mean? Does that mean it contains all the code that I need to create my application? If that's the case, why not just call it the application?
why not just call it the application?
Because a solution can contain many applications, many supporting libraries used by those applications, various artifacts used for building and testing those applications. A solution may even contain no application at all, just class library projects.
Think of a solution as a container for projects which are logically grouped in some way, as well as various artifacts which may be used by those projects. A project in this case may be an application, a class library, a set of database scripts, etc.
Solution is just container for projects, the idea is that different projects can share code thus be accessible easier than including outside libraries.
I have created three different solutions for three different clients, but those solutions are for an app that have the same features, classes, methods, resolution, except for the images, XML resource files, and a web service reference, that are specific for each one.
I would like to have just one solution for all those apps, that I could open in VS2010 IDE for edition, without errors. So, when I need to build or publish an specific app, I just set the client which one I need to, and go ahead to building or publishing.
It is important to consider that XML file names will be the same, as classes and images names too. The difference will be the content, but the name will always be the same.
My intention is to reduce my effort to maintain many solutions, having just one solution to work with.
In my company, we will have more than those three clients soon, so I am worried about how to maintain that. The best way will be have just one solution and when I need to generate a new app for a new client, I have just to change/include a few things (like some resources and images) and compile to a new client folder.
Is it possible? If so how?
One option would be to have a master solution which had the following
A "Template" project that contained your actual application and all of the shared code
Projects for all of your clients
In the projects for your clients, you could have links to the files in your files that come from your shared project. Then, in each of those projects, you could add the files that are only specific to them.
With this kind of structure, whenever you made a change to your Template project, all of the client projects would be updated as well because they just have pointers back to the Template project.
A good reference for this kind of setup would be the Json.Net Code Base. There he has a solution and project for all of the different configurations, but they all share the same files.
In terms of ensuring that the xml files are named properly, you might just want to put some checks into your main application to ensure that it has all of the files needed or potentially add a check into your build process.
There are many ways you could look to tackle this.
My favorite would be to run some sort of pre-build step - probably outside of Visual Studio - which simply replaces the files with the correct ones before you do a build. This would be easy to automate and easy to scale.
If you are going to be building for many more than three customers, then I think you should look to switch from Visual Studio building to some other automated build system - e.g. MSBuild from the command line or from something like TeamCity or CruiseControl. You'll find it much easier to scale if your build is automated (and robust)
If you don't like the file idea, then there are plenty of other things you could try:
You could try doing a similar step to above, but could do it inside VS using a pre-Build step.
You could use Conditional nodes within the .csproj file to switch files via a project configuration
You could look to shift the client-specific resources into another assembly - and then use GetResourceStream (or similar) at runtime to extract the resources.
But none of these feel as nice to me!
I have an existing MFC product and am planning on supporting a couple of other national languages thru the use of resource-only DLLs. I've read a number of articles and tutorials on how to go about this, but admit that I don't have a lot of in-depth knowledge of Windows resources (mostly just use VS 2008's graphical interface).
The major area that I am trying to understand is that it seems like all of the resource source files (i.e., resource.rc) for these DLLs -- and the main program -- should be sharing the same copy of resource.h. After all, all those IDD_xxx values have to be consistent, and it seems like making updates to the resources would be even more complicated by having to keep multiple resource.h files in sync!
So am I correct on this, and does anyone have any tips for how to best implement this? Should I modify resource.rc in the DLL projects to point to the "master" resource.h in the main program directory?
Yes, use the same resource.h file for sure.
One way is to just copy the resources you need to be translated into the the new resource project--stuff like menus, strings, dialogs. Bitmaps and icons probably don't need to be translated unless you put some text on them that is language specific. If you know your localse, at program startup you can call AfxSetResourceHandle() with the resource DLL you manually load.
Another way to approach the problem if you have a multitude of DLLs and EXEs is to use binary resource editing tools. What they do is create token files from your resources. Your translators edit the token file with the binary editing tool. When all is done, you run a tool to apply the translation to the binaries. Basically, you don't distribute resource DLLs, but distribute different versions of your DLLs for each language. The tools are smart enough so that if you make a change like add a string or dialog, it will get picked up and your translator can see that he needs to translate something new. The previously translated work will be saved in the token files. This is how we do it at my shop. We used to use Microsoft's Localization Resource toolkit. I don't know if we still use it or not since it is somebody else's responsibility now.
I found the MSDN article ID 198846 a good starting point for sharing of resources via a dll, though it does need updating for newer versions of visual studio, it was quite easy to follow and understand.
http://support.microsoft.com/kb/198846
My paid app has been published on the WP7 marketplace. Now I would like to create a free version of the app.
I figure I would have a constant IsFreeVersion = true; and then based on that disable some functionality.
What would be the best approach to setting up my project for this? I definitely do not want to have two versions of the code. So should I create a new project and link the files?
Also, how do I handle the different application icons? Finally, wouldn't I need a separate GUID for my application Id?
If you want to have a Free and Paid version of your app in the same project without using a 'Trial' version, this is how I do it:
Each project is assigned a single ProductID which distinguishes the app from other apps at install time. You could create a second project and link to all the files in the first project, but that would require maintenance as the project grows. My solution allows using the Build Configuration to select the free or paid app to build.
First you need a separate ProductID for each version of the app. This ProductID is declared in the manifest file 'Properties/WMAAppManifest.xml'. So the first step is to create two versions of WMAAppManifest.xml. I call them WMAAppManifestPaid.xml and WMAAppManifestFree.xml.
In each of these manifest files, provide a separate GUID for the ProductID and also change the Title of the free version so you can tell them apart when they are installed.
Next we need to add two new Build Configurations in the project. I call them ReleaseFree and DebugFree.
Next you add a few Pre-Build Events to all the build configuations to copy the appropriate manifest file:
if $(ConfigurationName)==Release copy $(ProjectDir)\Properties\WMAppManifestPaid.xml $(ProjectDir)\Properties\WMAppManifest.xml
if $(ConfigurationName)==Debug copy $(ProjectDir)\Properties\WMAppManifestPaid.xml $(ProjectDir)\Properties\WMAppManifest.xml
if $(ConfigurationName)==ReleaseFree copy $(ProjectDir)\Properties\WMAppManifestFree.xml $(ProjectDir)\Properties\WMAppManifest.xml
if $(ConfigurationName)==DebugFree copy $(ProjectDir)\Properties\WMAppManifestFree.xml $(ProjectDir)\Properties\WMAppManifest.xml
You should now be able to build either the free or paid versions of the app by simply changing the Build Configuration.
Next, to allow for actually making the free version different than the paid version, such as limiting features, showing different pages etc., you need to add a Conditional Compilation Symbol, such as FREE_VERSION to the two free build configurations.
then you can simply use compiler directives to change the code such as:
#if FREE_VERSION
s = "My App Free";
#else
s = "My App Paid";
#endif
If you want separate apps for the free and paid versions (Presumably you're limiting the functionality of the free app or adding ads) then I'd create a separate project and then link to the exisiting files of the other (use "add as link").
You can then customize the different versions as necessary. When doing things like this I like to use partial methods (and classes) to extend and customize the different versions.
You may also want to use app specific compiler directives to limit functionality to a specific version.
The Trial API is designed to handle such a situation. You can check if IsTrial is true, in which case you can limit functionality all in one code base. I assume you avoided this in order to ensure your app appears in the Free section of the Marketplace. In this case, you'll have to submit it as a new app, which means a new GUID.
AFAIK (maybe someone has another method), you'll have to create a new project and run a separate build. You can include your existing code base for the most part, but you'll end up with two versions if you don't include the Trial API. Since it's a new project, you can change the tile icons to whatever you want.
Jeff Brand has also prepared a very nice TrialManager library which allows you to implement different types of trial management.
Scenarios like:
Expires after N number of use
Expires after T minutes of use
...
http://www.slickthought.net/post/2010/08/30/Managing-Trial-Applications-for-Windows-Phone-7.aspx