In the documentation for the FileSavePicker, it states:
Warning If you try to show the file picker while your app is snapped the file picker will not be shown and an exception will be thrown. You can avoid this by making sure your app is not snapped or by unsnapping it before you call the file picker.
I'm currently checking to see if the app is snapped or not, and my app responds differently in each case. My default behavior isn't showing the FileSavePicker, either, so I can't just try and then fall back to something else. Nor do I want to force the app to unsnap.
However, ApplicationViewState is deprecated post-8.1. In that documentation and related searching, developers are advised to access the window size directly in order to determine proper behavior. However, if the view state is no longer available, how do I know if the file picker will throw an exception or not? At what size is the app considered 'snapped'?
Also, I'm using C++, so an answer compatible with C++ would be splendid. I wouldn't mind seeing the C# solution, too.
In regards to the FileSavePicker documentation - I believe that it is just an oversight. The text you quote was from the Windows 8 version, and to me it looks like it didn't get updated for Windows 8.1.
If you look at the FileOpenPicker documentation, you see that it was updated:
Important In Windows 8 if you attempt to display the file picker while your app is snapped, the file picker will not be shown and an exception will be thrown. You can avoid this by making sure your app is not snapped, or by unsnapping it before you call the file picker. ...Note that Windows 8.1 does not define a specific snapped window size. Instead, users can resize apps to any width, down to the minimum. Therefore, if your app will deploy only on Windows 8.1, you can ignore the EnsureUnsnapped function and calls to it in this topic's example code.
The last sentence (in bold) above essentially says that you can ignore state and safely open the file dialogs if you are running under Windows 8.1.
To test the above, I used VS 2012 to create a Windows 8 application with a file save picker (in C#). I believe the outcome will be the same with C++, but I am not 100% certain.
I should note that my test application does not check for view state and always tries to open a file dialog.
When the application is run under Windows 8 in the snapped state, the application causes an error. That same application (same binary) when run under Windows 8.1 allows the file save dialog to open without issue. As mentioned previously there is no snapped state in Windows 8.1, so the way I tested the application was to open the application to the minimum width (320 pixels).
To summarize:
If you are targeting Windows 8.0, you will have to make sure the application is unsnapped prior to opening the file picker dialogs.
If you are targeting Windows 8.1, you do not have to worry about state, as the file picker dialogs no longer throw any exceptions.
Related
I am writing my Windows Phone 8.1 Silverlight App (NOT RunTIME framework).
I have to questions:
Which is the App manifest file for Windows Phone 8.1 Silverlight? WMAppManifest or Package.appxmanifest? as my project contains both
I created a method in Mainpage of application which detects that is it the first time this application is running or not. If it is first time execution of this app, registry of 120 keys (IsolatedStorageSettings.ApplicationSettings) is created and app moves to WelcomePage.If the execution is not the firsttime, means user has opened this app before, it skips the registrycreation method and directly goes to homepage.
When I upload this version 1 of app to store and users install and use it. What when I add more keys to registrycreate method in version 2 and upload version 2 to store. How will be those new keys get created? Even, when user updates the app, the registrycreation method will never run.
The "Silverlight" app manifest is WMAppManifest.xml, but you still need to include the "RT" manifest Package.appxmanifest and, if you ever use any of the RT namespaces that require certain capabilities, you should check those capabilities in the Package.appxmanifest too. Eg "Internet (Client & Server)" if you are using things like Windows.Networking.BackgroundTransfer.
You'd need to add some code to check if the information or information structure has changed every time the app is run (or resumed), so that in the event of an update (and change in the keys), they get added, even if your "first run" code doesn't fire. Make sense?
If you know the keys numbers will always get bigger then watching the key count will work. You could also include a key with the version so you can tell which version the data was created with.
You can use Windows.Storage.ApplicationData instead of IsolatedStorageSettings in Windows Phone Silverlight 8.1. ApplicationData supports versioning with the ApplicationData.SetVersionAsync method so you can change the data format safely when you update the app.
Either way, when the app runs check if the data's version is the latest that the app knows about. If not then run your setup and migration code to add the new keys and replace the out-of-date ones.
The data version doesn't have to match the app version (you may update the app's version without changing the data). You can compile a data version constant into the app's data handling code and bump it whenever you change the data format.
We have a SPA web application that we're trying to convert into a WinJS project as a native Windows Store app. For most part, the Javascript is working except for DOM manipulations deemed unsafe.
One thing that does not appear apparent is, how can the start page of the app (e.g. index.html) be supplied with query string and hash parameters? Our site main page is designed to behave differently based on parameters.
e.g. index.html?contextId=xxxxx#enviroment=xxxxx
I tried adjusting the value in package.appxmanifest to no avail. It will throw errors on query strings, and hash parameters will silently not persist.
UPDATE: Project background
A brief about what our app does, and then why the above naive desire won't work and the answer below how we went about this issue.
Our web app is a highly-dynamic data-driven application that completely relies on data to figure out what to render. Therefore the ?contextId=xxxxx parameter is so crucial as it tells our system to load the data which further informs what kinds of visual components to load and it goes on recursively to form wildly different UIs.
We were looking to therefore find some means to supply these parameters like traditional command-line parameters to the same executable to produce different UIs. And thus different "apps" by mere changes in those parameters. Like a "config transform" mechanism for web.config in ASP.NET web projects, that would be most welcome.
However further testing showed it is not possible; a single Windows store app project has a GUID that is supplied into the packaged app bundle. Building the same project multiple times with different "build config" would just mean overwriting a previous installation since they are the same app with increasing version numbers. The answer details how we went about this.
Windows Store apps don't work with URI parameters when launched from their primary tile. In that case, you should make sure that the app defaults to suitable values, e.g., if you were thinking to supply defaults in the manifest, then default to those in the app's activation handler for the ActivationKind.launch case when eventObject.detail.arguments is empty.
There are two other ways to launch an app that can supply other arguments.
First is to launch via a secondary tile. When you create the tile from the app (which is subject to user consent), you supply the launch arguments. In your activation handler, for ActivationKind.launch, those args will be in the eventObject.detail.arguments property.
Second is to launch the app through a URI association. You use a custom schema for this, which is declared in the manifest. The app will then see ActivationKind.protocol and eventObject.detail.uri will contain the full URI including any parameters. A URI launch can be done from another app, by entering the URI into a browser address bar, or through a shortcut that a user could configure on the Start screen.
The first step is to convert our Windows (8.1) Store project into a Universal app structure, which would then spin off a separate Windows Phone WinJS project (this is nice when we wish to target Windows Phone later) and a shared project.
Practically everything from the Windows Store project is moved to the shared project (including default.html or index.html). What remains in the Windows Store project is a customised config.js carrying the parameters
window.customWin8 = {
contextId: xxxxxxxxxx,
customParam: 'xxxxxxxxxx'
};
The downstream modules that sense for query string/hash parameters would then fall back to this alternative object if it exists to pick up the data it needs.
Now, for every differing app we wish to deploy, that would for now seem to require a separate Windows Store project so it gets its own GUID and won't conflict with other apps. All these projects would reference the very same shared project thanks to the Universal structure Visual Studio affords. The only down side is it seems Visual Studio 2013 does not have a direct UI method to make this referencing to the share project and has to be hand code into the jsproj file.
<Import Project="..\Common.Shared\Common.Shared.projitems" Label="Shared" />
With this adjustment they can all build and package with their isolated "build config".
I'm developing a Windows Phone 8.1 app that also targets Android(Xamarin)
As ever I added my string resources(.resx) on a PCL and referenced them on my launcher project to use it on my views, this all works fine on WP 8.1 silverlight but on the WinRt when I configure the project to release and run it on a device, for some reason I always get a MissingManifestResourceException. I've tried every solution for this problem out there without any success.
Note that on the emulator everything works fine, when the solution configurator is set to Debug it also works on both device and emulator. The only combination here is device and Release.
The app source code is on Github.
I was able to create a simple project to replicate this issue, basically it is a WP 8.1 app and a PCL project with the embedded resources, Download Link
Anyone has any ideas?
EDIT: After making some more testing I tried running an old Windows 8.1 app that I've done with the same localisation model and the same issue appeared so it seams to be a tool issue and not a configuration issue, since the Windows 8.1 app is on the market and everything went fine back there.
Our team ran into a similar issue which was tracked down to the runtime and not the PCL, WinRT component, or application package. That is, the resources exist within the PCL assembly, within the application package resources.pri file, but just cannot be found at runtime.
There is an active Microsoft Connect report here:
https://connect.microsoft.com/VisualStudio/feedback/details/991028/issue-using-resx-files-on-winrt-apps-windows-phone-and-windows
Our workaround was for the WinRT component to inject into each generated Resources class of each referenced PCL our own derived ResourceManager which redirected the call to the WinRT ResourceLoader instead. I've written a blog post that describes that workaround:
http://blogs.msdn.com/b/philliphoff/archive/2014/11/19/missingmanifestresourceexception-when-using-portable-class-libraries-in-winrt.aspx
I got to the bottom of this today. While bundling the app package, resources in dependencies that are not for a language being used by the app are stripped out. To prevent this from happening, add the following assembly-level attribute to your application.
using System.Resources;
[assembly: NeutralResourcesLanguage("en")]
I had the same behaviour. Today I created a new PCL Library (with another name) and copied the resx file to this project. I modified all references and everything just works fine in my WinRt (Windows Store) App now!
There was the string 'resources' in the portable class library name. Perhaps this was the problem!
I am able to reproduce this issue launching DVD sample and unfortunately in my project. I have an WP Silverlight 8.1 project registering a Windows Runtime Component Background Task and both of them using a Portable Class Library sharing some common localized strings as resources (.resx), among other things. The exception is thrown from Background Task when calling any property to get strings on generated .Design.cs class (only Release + Device).
In order to fix this I tried, without success, to use directly ResourceManager and/or to add .resx files directly into the Background Task.
I ended-up porting needed strings to .resw files and use the new "WinRT preferred" way via Windows.ApplicationModel.Resources.ResourceLoader in the Background Task project.
Seems to me that ResourceManager is not compatible with Windows Runtime anymore in release.
This is not necessary an answer, but is better than nothing since I do not have 50 reputation points for a comment.
Something weird happened to one of my C# Windows Phone 8 Silverlight projects.
It's a simple page with one TextBox I'm experimenting with, building a customized style for it. First I placed a TextBox on the PhoneApplicationPage, generated a style template for it using the 'Edit Template\Edit a Copy' command from the context menu in the designer. Now I'm changing some setters and property values in the style, but when I hit F5, an old version of my project is launched in the emulator - all my recent changes aren't taken into account. The latest changes are reflected in the launched app only after I issue the 'Rebuild Solution' command from the Build menu.
The XAML markup has no errors, and it seems all stuff is correct. Other WP8 projects are built and deployed to the emulator ok too. The problem does not depend on the selected emulator (WVGA 512Mb, 720p, etc). Restarting VS/emulator has no effect too.
What it can be and how to fix it?
Some more info. For any normal project I see this in the Output window when I hit F5 (the app full path was shorten to save space):
But for the problem project, the output log ends on the line '1> Xap packaging completed successfully' and the old version of the app is opened in the emulator immediately.
It seems, I have managed to find the reason of this strange issue. This can happen if the name of a WP app includes spaces! I noticed that if we create a new project and use the space character in its name, the spaces are replaced with the underscore characters on the phone (for instance, "WP Test App" is deployed under the name "WP_Test_App"). I also found this while searching for a solution of this problem:
App doesn't get updated then debugging - incrmental update not correctly working?
I played a little bit with the names of my project and solution, i.e. removed the spaces in them, and it helped to solve my puzzle.
BTW, as the author of the question under the above link states, this problem never occurred in the WP 7.1 SDK - it is specific only for the WP 8 SDK.
I created an Air desktop app with Flash CS 5. Usually Windows (XP) is opening an application (like Firefox) with the latest set size and position.
For my installed Air app it's always just the default one.
How to start it with the latest used size and position?
Thanks.
Uli
hope this will work for you:
http://cookbooks.adobe.com/post_Using_the_FullScreen_functionality_in_AIR-8004.html
http://blog.ochodurando.com/2010/04/adobe-air-e-fullscreen/
You need to save a record somewhere that remembers the window's size, and possibly position. If your app has a preferences file, this would be an ideal place to store that information. Then, whenever your app starts, it checks for this information and resizes the window if any values are found.
Most popular programs include this feature (and don't even mention it, since it's pretty basic UI), but it's done intentionally and not as a default for every application. Thus if you want it, you have to program it in.
You can read and write to application.xml. You'll find there and nodes.
file = new File( File.applicationDirectory.nativePath + "/META-INF/AIR/application.xml" );
Adobe restrict writing access to application diractory but this trick is useful if you don't want to create a separate config file in app-storage:/ folder, which is of course prefered.