I am trying to upgrade the user settings if my app gets updated. I am storing settings ins
Properties.Settings.Default. As suggested in other answers a way to merge settings between version is to can create a bool setting UpgradeRequired and do the following.
if (Properties.Settings.Default.UpgradeRequired)
{
Properties.Settings.Default.Upgrade();
Properties.Settings.Default.UpgradeRequired = false;
Properties.Settings.Default.Save();
}
I tried to make a minimum example with this code in a desktop bridge app without any success. Does this method not work for them?
Yes, unfortunately this does not currently work in desktop bridge apps. This is a known bug that the team is aware off.
As a possible workaround you could move to the new localsettings API in your desktop bridge app:
https://learn.microsoft.com/en-us/uwp/api/windows.storage.applicationdata.localsettings#Windows_Storage_ApplicationData_LocalSettings
Related
Recently we get the need for work on the same apigee proxy more than one developer. So we are trying to use the apigee-emulator to allow us to use git as version control
We already have everything setup for VScode as it says on the documentation.
The problem is with an `extension callout we have inside one of our proxies that we need to access to salesforce. When we try to push our proxies to the apigee-emulator we get this error
If we search for the callout we can see it's the one that try to access to salesforce
How can we add this extension to be used inside the apigee-emulator?
From the error it looks like you are using Apigee Edge ExtensionCallout policy.
The vscode extension and the emulator cater towards the features available in the X and hybrid versions of Apigee. More information here
The extensions feature you are using has been replaced by the Integration callout policy.
Hope that helps
I need to create two different versions of the app.
- debug
-prod
for debug, version i need user to select the test environment before anything else begins. i need some way to know what environment user has selected and then load API endpoints config file accordingly.
what's the best way to handle this in flutter?
I have seen in some apps that for iOS, debug options are available in app settings under the standard iOS settings menu , select the app and then see those options in there.
You might want to use Flutter Flavours. As the name suggests, you can practically make flavours of the same app based on your need - debug, test, production etc. And not only API end-points, but you can also configure everything else such as app icon, different labels on the screen etc.
As suggested in this link, you can have different main.dart file for each flavour. You can read different configuration from JSON file (such as API end-point) and rest of your app will remain same. For example, see below :
This is another helpful link.
We are using Firebase to setup different toggle-able features based of whether the app is currently pointing at Beta, Staging or Live so we can test gradually without fully going live with a feature.
We do this by setting 3 conditions inside Remote Config based on how the user property 'ios_environment' is set within the app.
Inside the Development version of the app we can switch between the environments easily which calls the following code to switch which condition the app is currently running under:
Analytics.setUserProperty(environment.rawValue, forName: "ios_environment")
Which sets it to either, "beta", "staging" or "live".
What happens in the app is for a particular Remote Config parameter it only ever decides to go with whatever the Default value is and never seems to pickup on the condition that is set:
So for the Parameter in the image above, we want it to be true only for the Beta environment but it only takes whatever the Default says.
I hope I've made my issue clear, it's hard to get what is wrong across.
It's an issue that's recently fixed in v4.2.0. https://firebase.google.com/support/release-notes/ios
Is your Firebase version early than that?
Is there someway to determine the Chrome platform version in order to verify that I can use APIs that are marked v37 and later? If there is an alternative way of verifying that these new parameters are supported by the current install that works as well. My current solution is to check for the existence of a different v37 API which seems to be working, however if there is a sanctioned way that would make me feel a bit better about the whole thing :).
I need to use the 'scopes' portion of this API:
chrome.identity.getAuthToken.
In its Cog Chrome App, François Beaufort is using userAgent with a regex to get the chrome version:
window.alert(
navigator.userAgent.match('Chrome/([0-9]*\.[0-9]*\.[0-9]*\.[0-9]*)')[1]
);
But there is maybe a better way to check if some html/js API are available or not...
Try adding a minimum version to your manifest, so you don't even have to check in your code. This will prevent the app from webstore installs who are on older versions.
"minimum_chrome_version": "37",
I am currently debugging my apps so they can run with the KBX extension. KBX extension runs the last deployed version so everytime I change some code in the appbuilder I need to redeploy to see the changes. Could the Kynetx team give us a modified KBX extension that uses the last saved version instead?
We do have plans to make the KBX more developer friendly, but in the meantime, there are a few tricks.
We recommend spending most of your development time testing with bookmarklets, as these give you greater control over when your actions fire, allowing easier inspection between the state of the page before and after your rules fire. Applications can be tested with bookmarklets with no change to the code, and are easy to use.
This does not help debugging in the rare case that your application behaves differently while running in the KBX, but it should get you past most troubles you are currently experiencing.
Here is a solution for Chrome and Firefox: a modified KBX extension that targets the latest version of apps: http://blog.lolo.asia/technology/kynetx/2011/04/16/debugging-with-kbx-extension-how-to-avoid-having-to-deploy-at-every-code-modification/
In short, I replaced :
KOBJ.add_config_and_run({‘rids’:response.apps});
with :
//patch run_latest_app_version_in_kbx
var run_latest_app_version_in_kbx= true;
var run_msg_json={‘rids’:response.apps};
if (run_latest_app_version_in_kbx===true){
for (var i=0;i<response.apps.length;i++){
run_msg_json[response.apps[i]+’:kynetx_app_version’]=’dev’;
}
}
KOBJ.add_config_and_run(run_msg_json);
//
in page_interaction/pages.js inside the Chrome extension and
in resources/jid0-njkmo4quo4rc8p9kcuemahnyiku-kynetxforfirefox-data/page_interaction.js inside the Firefox extension