I'm trying to get information about license info of my app and MSDN docs (http://msdn.microsoft.com/en-us/library/windows/apps/hh694065.aspx) advice to use Windows.ApplicationModel.Store.CurrentAppSimulator class for that purposes during development/testing and when submitting app to store replace that class with Windows.ApplicationModel.Store.CurrentApp.
I wonder if there is any way to check in code (javascript in my case) if app is already installed from store so my code should use proper class and I won't have to remember every time I submit update of app to store to replacing those classes properly.
As far as I know, I could not find such thing. In fact, LicenseInfo is what provides information about the store listing.
I use a config.js file to keep settings at place which change between development and production. For example - if your app talks to a service, service URL also will likely change between development and production; the service might be running at localhost for development and for production in azure environment. I keep a bool in here and change by hand.
I have not automated it fully. but it is likely possible. need to dig through the msbuild logs for the build created for the store. if there is configuration setting found, then project can have two config.dev.js and config.release.js and msbuild need to conditionally pick the right file. I haven't looked into this yet.
I think I found at solution as described here WinJS are there #DEBUG or #RELEASE directives? . Not ideal, but works for me.
Related
My searches have turned up nothing concrete. My extension uses Google's file picker to allow the user to browse their sheets and choose a desired file to write some data to, which manifest v3 breaks because of some GAPI limitations. Unless I've missed something obvious, there does not seem to be a simple workaround or method for this to migrate to v3 -- it just seems to be disallowed.
I'm not asking if there's a way to do something that they intend to not be possible (even though I doubt such a thing would exist with Google) but I'm optimistically hoping that maybe there is some hacky/annoying workaround that still fits within their rules. If I absolutely have to just allow them to set a sheet URL manually I will...I'm just trying to avoid it.
Any tips or suggestions would be appreciated.
You may have to test it yourself to make sure there are no weird behaviors, but Google has some recommendations regarding this in their migration guide:
In Manifest V3, all of your extension's logic must be included in the extension. You can no longer load and execute a remotely hosted file. A number of alternative approaches are available, depending on your use case and the reason for remote hosting. Here are approaches to consider:
Configuration-driven features and logic
In this approach, your extension loads a remote configuration (for example a JSON file) at runtime and caches the configuration locally. The extension then uses this cached configuration to decide which features to enable.
Externalize logic with a remote service
Consider migrating application logic from the extension to a remote web service that your extension can call. (Essentially a form of message passing.) This provides you the ability to keep code private and change the code on demand while avoiding the extra overhead of resubmitting to the Chrome Web Store.
Bundle third-party libraries
If you are using a popular framework like React or Bootstrap, you can download the minified files, add them to your project and import them locally.
For your case, option #3 seems like the easiest. Looking at the Google Picker API documentation it only uses two relatively small script files, https://apis.google.com/js/api.js and https://accounts.google.com/gsi/client. You could try to bundle these in your Chrome extension and call the methods locally.
I have created a application and about to release in few days
After searching online I understand there is nothing like app.config for Xamarin.
Please suggest better place to save api keys
Also is there any environment where I can test my application before it goes live.
So I can see how it looks and functions in many devices
You have a few options, for example:
Resource file (resx);
Constants file;
Api endpoint that retrieves config on startup. Huge benefit is that
your config is dynamic. So if you change something in the config,
it is automatically updated when user restarts the app.
For testing the app on multiple devices, try TestCloud.
I'm developing an app with IBM MobileFirst Platform and I find an issue with Worklight.js file. Worklight.js is extending Function prototype defining several methods like bind, curry, wrap and so on.
My app is built with aurelia framework an after upgrading the framework to the last version I'm facing a funky issue related to bind extension.
If I comment the bind extension in worklight.js everything seems to work like a charm (don't know why worklight implements its bind version).
Worklight.js file seems to be added to the wlapp package at build time. Is there a way I can override this file so I do not have to modify .wlapp file each time app is built?
Thanks
The direct answer to the specific question you've asked is, no, there is no way provided to override worklight.js. This is the core JavaScript code needed for the MobileFirst Platform client-side to function, and as such the user isn't given any means to modify it - it's injected into your app (i.e., into the WLAPP file) during the build process.
I'm not aware of any specific issues with Aurelia, but have certainly seen cases in the past where an app that uses two different frameworks (e.g., MobileFirst Platform / Worklight, and something else) "fight" with each other because they both want to implement extensions that are not compatible with each other - in which case, one framework or the other usually needs to change to accommodate the other.
If you are a customer with paid support, I'd suggest opening a PMR so we can get our developers to take a look at the issue.
I have the same problem with Angular. Worklight bind makes Angular controller fail to instantiate. The solution is to recover the bind function after worklight is loaded.
var bind = Function.prototype.bind;
window.wlCommonInit = function() {
Function.prototype.bind = bind;
};
We're developing a solution which uses Ektron. As part of our solution we all have local IIS instances (localhost) and deploy to this local instance as part of the development life cycle.
The problem is that after a deployment and once dll's are replaced IIS restarts and the app pool is recycled, this means that Ektron dll's need to reload themselves.
This process takes an extended amount of time.
Is there anyway to improve the loading time of "Ektron"
To some extent, this is the nature of a large app running as a website rather than a web application. Removing the workarea from your local environment is one way to get this compile time down, though this will naturally not work depending on your workflow, for example if you are not using a separate dev DB or if you are storing the workarea in source control.
I have seen some attempts to pre-complile the workarea and keep the working code in a separate project (http://dev.ektron.com/forum.aspx?g=posts&t=10996) but this approach will only speed up your builds, not the recompilation of individual pages that will occur after a build as a result of running as a web site.
The last (and least best-practice) solution is to simply avoid making code changes that cause a recompile, like modifying app_code. Apps running as websites are perfectly happy to recompile a single page's codebehind without regenerating DLLs, which is advantageous for productivity but ultimately discourages good practices like reusing code in libraries. Keep in mind that this is terrible advice, but if you have a deadline and are staring at an ektron page loading every 30 minutes it can be useful to know.
Same problem here. I found this: http://brianpereras.blogspot.com/2013/06/ektron-85-86-workarea-is-slow-compared.html
That says that the help documentation was moved to be retrieved from an online source (documentation.ektron.com). We're running Ektron 9, and I just made this change and it seems much faster on first load (after iisreset).
The solution is to set documentation.ektron.com to 127.0.0.1 in your hosts file.
There is not, this is just how IIS works. Instead of running a local instance of Ektron it's a good idea just to point your web.config file to the database of your test database and copy the /workarea folder to your local PC. You can't edit ektron locally but you can change the data on your test server and it will show up locally.
Is there a way to determine if the App is running locally or has been deployed through the App Store?
I would like to test the trial mode functionality using Windows.ApplicationModel.Store.CurrentAppSimulator during development but default to Windows.ApplicationModel.Store.CurrentApp if the app has been downloaded from the store by a regular user.
I don't believe this is easy to do. I suspect the easiest way is through conditional compliation, and produce a specific build for submission. You can use Ajaxmin for this, but that would require a little bit of setting up.
Given that an application when deployed is supposed to be in distinguishable no matter it's mechanism, I don't think this:
http://msdn.microsoft.com/en-us/library/windows/apps/windows.applicationmodel.package.installedlocation.aspx
Will help. It will plausibly tell you if you've been deployed from VS (which deploys loose files), rather than as a package.