I have been working on a Windows Store app where I have to support multiple configuration parameters for my app. One of the parameters is the URL the app is talking to.
For example development environment, test, acceptance and finally production.
One of the things i'm currently thinking about is what is the most efficient way of supporting all these environments with the least effort. Because there isn't some kind of config file that we can change to update these parameters I came up with some ideas. I'm curious about other options that I might have not seen.
Here are the things I came up with:
1
Adding multiple configuration to the app and than using them in code to get the correct parameter like this:
private string webserviceUrl;
#if DEV
webserviceUrl = "devUrl";
#elif TEST
webserviceUrl = "testUrl";
#endif
2
With the approach in number 1 there are a few more options available like including a config xml file bases on the configuration, or fetching configuration settings from a webservice the first time the app is running.
3
Using a branch/merge strategy and update the config files in the branch. Advantage is that the code is clean and only contains the settings it needs for the build it's created for. And the package can be build by the build server. Disadvantage is that you need to branch/merge alot.
The last option feels like the most 'clean' solution to do this. Am I missing any options, or do you have experience with any of these methods? What would you prefer?
I think the assumption is that apps in the store will always point to production.
But, in saying that, I'm facing the same issue as we're side loading the application onto devices that we control, and not using the Windows Store at all.
To answer your question, I prefer option 1.
Option 2 and the xml/json config file seems like the best option though.
The webservice option probably won't work. What webservice URL do you use? And how will it work if you want some instances pointing to different environments as they will all be fetching the config from the same URL.
Another option you might want to consider would be options in the settings charm menu. For example, use radio buttons for the environments, and allow the user to configure which environment they want to target.
The issue would be locking it down in production for end users so that it isn't modifiable any more. Perhaps once "PROD" radio is selected, all the radio buttons are then hidden.
If you're deploying the application through side loading, then these settings could probably be configured during the install process.
I'd be interested to hear other opinions as well. This is also an old question, so I'd like to know what solution you decided on implementing.
Related
This is incredibly niche, but in case somebody knows I'm wondering if it's possible to get that "unsaved" marker to show in VS Code for the Web . I'm writing an extension with a custom FileSystemProvider to communicate with a remote storage service. As multiple people may have access to these files this auto-save behaviour is not appropriate.
Turns out auto save is on by default. Had to add .vscode/settings.json in the FilesystemProvider. I'll edit this answer if I find another place to override this default.
When we dev/test our add-in, we need to request request http://dev.xx.com. and after release, in production we need to change the url to http://prod.xx.com.
How can we do this?
===
I'm new to vsto development and c#. I looked config file(in fact Settings.settings) way. But in fact i don't want the users to "config" it. It't better if I can build out two different versions in one click ervery time, and give one to testers and another to the end user.
When I devloping server-side springboot applications, I use 3 different config file and one single jar. And give the different config file and same sigle jar to different persons. This way at least we can confirm that the applicaiton (jar) is the same for test and deploy.
But the "Settings.settings" seems binded to the "solution" in vs. The pre processor seems not good enough, seems that it binded to the "solution" too. I have to change it in the "Properties" every time before I build the project? Or I need to create more "Solutions"?
Maybe I did't look that deep enough, I will keep looking
=== SOLVED
We finaly solved (partly) using Conditional compilation
#if DEBUG
const string baseUrl = "192.168.20.101:8001/api";
#endif
#if (!DEBUG)
const string baseUrl = "xxx.com/api";
#endif
one small issue is that we need to distribute debug package to our test team.
Does anybody know what if direct update updates everything that lives in the common directory structure. I used the same code base for multiple apps, the only change being certain settings within a js file that tells the application how to act. Is there a directory i can put that js file that would be safe from the direct update feature?
I cant seen to find any specific information on IBM's website.
I think you guys need to be careful which terms you are using in order to not confuse people who may be looking for similar help.
Environments are specific to the OS you are using. iOS, Blackberry, Android, and etc. environments.
Skins are based on the environment, and aren't generic to all platform. When you create a skin you must choose which environment you are running in.
So to correct some, direct updates will update all skin resources in targeted environments.
For example: You have an app with Android and iOS versions
When you create skins, you are creating essentially a responsive type of design to your parameters. For instance, if you have a 2.3 vs 4.2 Android OS, you can set a look and feel for both. However, these utilize a single web resource base. The APK would be the same for both versions of the app (by default) and have 2 available skins. On runtime utilizing IBM Worklight's 'Runtime Skinning' (hence the name) it goes through the parameter check for the OS and loads that skins overriding web code.
You could technically override all of the web code to be completely different for both skins, but that would be bulky and inefficient.
When you direct update you are updating all the resources of that particular environment (to include both skins), not the common folder/environment.
So an updated Android (both skins) would have updated web resources (if you deployed the android wlapp) and an iOS version would stay the same.
If you look at the Android project after build (native -> assets -> www -> default or skin) you can find the shared web resources generated by the common environment. However that is only put there every time you do a new build.
In the picture, I have an older version of the Android built for both skins on the left. On the right is a preview of the newer common resources after deploying only the common.wlapp. So you can see that they are separate.
Sorry if it was long winded, but I thought I would be thorough.
To answer the original question, have you thought of having all the parameters of the store loaded from user input or a setup? If you are trying to connect to 3 different store, create some form for settings control that will access different back ends or specific adapters. You could also create 3 different config.js that load depending on the parameters that you set so that you set. The other option is to set different versions of your apps specific to the store.
Example. Version 1.11, 1.12,1.13 can be 3 versions of the same app for store 1, 2, & 3. They can be modified and change and have 3 sets of web resources. When you need to update, jump up to version 1.21, 1.22,1.23. It seems a bit of a work around, but it may be your best bet at getting 3 versions of the same app to fall within the single application category. (keep 3 config.js types for modifying for the 3 stores).
To the best of my knowledge Direct Update will update every web resource of the skin you're using (html, css, js). However, I'm no expert with it.
If you're supporting only Android and iOS applications and need a way to store settings I recommend JSONStore. Otherwise look into Cordova Storage, Local Storage or IndexedDB.
Using a JSONStore collection called settings will allow you to store data on disk inside the app's directory. It will persist until you call one of the removal methods like destroy or until the application is uninstalled. There are also ways of linking collections to Worklight Adapters to pull/push data from/to a server. The links below will provide further details.
the only change being certain settings within a js
Create a collection for your settings:
var options = {};
options.onSuccess = function () {
//... what to do after init finished
};
options.onFailure = function () {
//... what to do if init fails
}
var settings = WL.JSONStore.initCollection('settings',
{background: 'string', itemsPerPage: 'number'}, options);
You can add new settings after initCollection onSuccess has been called:
settings.add({background: 'red', itemsPerPage: 20}, options);
You can find settings stored after initCollection onSuccess has been called:
settings.findAll({onSuccess: function (results) {
console.log(JSON.stringify(results));
}});
You can read more about JSONStore in the Getting Started Modules. See Modules: 7.9, 7.10, 7.11, 7.12. There is further information inside the API Documentation in IBM InfoCenter. The methods described above are: initCollection, add and findAll.
Since version 5.0.3 I think, direct update will not update all the webresources, only those of the skin you are using.
say you have skin def and skin skin2
you are on def
make change to def on the server -> you will get a direct update for
def only
make change to skin2 on server-> no direct update for you.
you are on skin2:
make change to skin2 on server -> direct update for skin2 only
make change to def javascript which also resides on skin2 ( and therefor end result is def+skin2 concatination), update only skin2
make change to def,just to a picture(also checking pic extension from application-descriptor: ") -> no direct update
Thats how direct update works.
Please also share some more details about what is the problem, I see you use a js file, where do you change it? what do you mean excatly, give a better (simplified) real life example, because it is unclear what you are trying.
I'm working on something that needs to install files periodically into a folder in /Library.
I understand that in the past I could have used one of the Authenticate methods but those have since been deprecated in 10.7.
What I've understood from my reading so far:
I should create a helper that somehow gets authenticated and have that helper do all of the moving tasks. I've taken a look at some of the sample code, including some involving XPC and one called Elevator but I'm a bit confused.
A lot of it seems to deal with setting up some sort of client / server model but I'm not sure how this would translate into me actually installing my files into the correct directories. Most of the examples are just passing strings.
My question simply: How can I create my folder in /Library programmatically and periodically write files to it while only prompting the user for a password ONCE and never again? I'm really not sure how to approach this and there doesn't seem to be much documentation.
You are correct that there isn't much documentation for this. You'll basically write another app, the helper app, which will get installed with SMJobBless(). Not surprisingly,
the tricky part here is the code signing. The least obvious part for me was that the SMAuthorizedClients and SMPrivilegedExecutables entries in the info plist files of each app are dependent on the identity/certificate that you used to sign the app with. There is also a trick with the compiler/linker to getting the info plist file compiled into the helper tool, which will be a single executable file, rather than a bundle.
Once you get the helper app up and running then you have to devise a way to communicate with it since these are two different processes. XPC is one option, perhaps the easiest. XPC is typically used with server processes, but what you are using here is the communication side of XPC only. Basically it passes dictionaries back and forth between the two apps. Create a standard format for the dictionary. I used #"action", #"source", and #"destination" with 3 different action values, #"filemove", #"filecopy", and #"makedirectory". Those are the 3 things that my helper app can do and I can easily add more if necessary.
The helper app will basically setup the XPC connection and event handler stuff and wait for a connection and commands. The commands will just be a dictionary so you check for the appropriate keys/values and do whatever.
I can provide more details and code if you need more help, but this question is 9 months old so I don't want to waste time giving you details you've already figured out.
I've hit a bit of a roadblock, and I'm hoping someone can help!
I've written a metro application that serves as a unit test runner, and I now need to be able to call this application headlessly so that it can be used for validation in the build process. The way the metro app works is it runs a bunch of unit tests, generates an XML file that contains the test results, and displays the results to the user.
Ideally, I would have a simple script that would run the metro app, execute the tests, exit the app, and then have the ability to read the results in the generated XML file. Is this possible, and if so, what's the best way to do it?
Here are some more specific questions:
How can one start a metro app headlessly, and in the metro app is there a way to detect this so that it does not wait for user input?
Is it possible to access files within the package of a metro app from an outside process?
EDIT - A workaround would be to create a custom Visual Studio test runner and then find a way to run the tests automatically with each build. I know this can be done within the IDE, but I'm not sure if there's a way to do this with a script.
I imagine you've long since moved past this problem, but for the sake of anyone else looking to do this, I got it to work without too much hassle. To execute a Metro app in an automated/headless fashion, I wrote a simple desktop command-line utility that takes the name of a metro app and makes use of the IApplicationActivationManager interface to launch it. I can then call that utility from a script.
The second argument to that inteface's ActivateApplication method is a string that gets passed in to the activated app, kind of like command-line arguments. It shows up as the Arguments property of the LaunchActivatedEventArgs that is received by the app's OnLaunched handler. The default implementation of OnLaunched in the Visual Studio template projects passes this value to the MainPage when it first navigates to it, where it comes through into the OnNavigatedTo handler as the Parameter property of the NavigationEventArgs. You could catch it in whichever place is more convenient.
My launcher utility passes a hard-coded flag through there, as well as forwarding its own command-line arguments. That allows the top-level script to pass arbitrary data down into the Metro app. The app can use that data to realize that it's running headless and run its tests. It can spit out whatever kind of result data you like into one of its folders (like its LocalFolder), which a desktop app can then read from %LOCALAPPDATA%\Packages\APPNAME\LocalState. I setup my launcher utility to wait for the result files to appear after launching the app, and then use them to determine its own exit code. The launcher utility can't kill the app afterward, but the app can kill itself when it's done via CoreApplication.Exit.
That setup worked great for a while, but a problem that I'm running into now is that the app isn't always launched to the foreground, and the runtime will suspend/terminate the app after it hasn't been the foreground app for some amount of time (currently ~10-15 seconds). So any tests that take too long won't work with this approach, barring some workaround that I haven't discovered yet (which I was searching for when I came across this question).
I doubt you'll be able to do it.
It's the same sort of problem as trying to run a WPF app headlessly, but harder since you'd also have to deal with the Metro sandbox security model.
P.S. Happy to be proven wrong!
No, sorry. You hit a wall with your first requirement of a script that runs the Metro application in "headless" mode in the first place. Your second requirement would be your next wall. One application cannot see, let alone monitor, another application/thread/process. Then your third requirement is also impossible. Files inside an application are isolated. It sounds to me like you found a good candidate for a desktop app. Having said that, don't mistakenly think that you can't have a companion Metro application that is your dashboard. It's just the execution core can't be hosted inside the WinRT sandbox.