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.
Related
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".
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.
I have completely rewritten one of my Windows phone 8 app. I use IsolatedStorageSettings to store user specified settings in both "old" and "new" versions of my app. In my new app version I just convert the old settings structure to new one.
Now I want to test the app update case. So far I have tried the following.
Build "old" and "new" xap files using VS (same app id and publisher id).
Install the old xap using WP Power Tools
Save some settings in app, check using WP Power Tools that the settings are saved to __ApplicationSettings
Update the app xap file using WP Power Tools
Check that the __ApplicationSettings is still there with "old" data
Launch the new app, __ApplicationSettings is now empty and all old data has gone.
What im doing wrong? Ho should I test the app update case, and how to keep the old __ApplicationSettings in place?
Is there some id's (?) which are now different in my old and new app and the platform thinks that the old __ApplicationSettings does not belong to new version and deletes it? Im using completely new namespace in my new app.
UPDATE
Im still struggling with this issue, how how to keep old isolated storage settings (__ApplicationSettings). In the file itself there is references to my app namespace. For example I have saved collection of MyCollectionItem's, in the __ApplicationSettings I find line:
System.Collections.Generic.List`1[[MyOldApp.MyModels.MyCollectionItem,
MyOldApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]],
mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=xxxxxxxxx
Now as my new app uses completely new namespace, this is not working?
Also I noticed that when I first time save something to IsolatedStorageSettings with my new app, the old settings (__ApplicationSettings) are erased.
Any idea how to migrage the IsolatedStorageSettings from old app to new one, as basically my new app is completely new app.
Theres two part to this question,
Using persistent storage like IsolatedStorage to share data between two versions.
testing the versions upgrade keeping data.
This might help you with 2nd part,
submit a Beta version of your older app.
install it and add data > will be stored in isolated Storage
submit a beta for new version, while submitting choose Add New, DO NOT replace.
you will get notification on mobile that the new version is available, choose to upgrade.
after installation, you should see your data.
lengthy process, but worked for me. hope it helps
I'm getting an error when I try to create a directory (i.e. snapshots) in my wp8 app but I don't understand why it works fine when in my emulator and when I transfer my app directly from my laptop onto my phone but when it's coming from the wp8 store, it generates the following error:
System.UnauthorizedAccessException: Access to the path 'Snapshots\' is denied.
I don't know if this is ok to do but everywhere I deal with files, I don't bother specifying a path but just a folder as I assume that it will go into the "app path\". Is this not the case?
2 Questions arising from the problem:
Why does it work with local app and not app downloaded from the store? Are access rights different?
If I'm not allowed to create files directly into the app's folder (no path provided, just a filename i.e. data.xml) or sub-folder (sub-folder only + filename provided i.e. Snapshots\test.jpg), where should I store my data (xml, jpg, etc...)
Thanks.
I found out the hard way that you should not try to write data directly in the root folder of a wp8 app as it is an "install folder". I found this interesting article/pdf from Microsoft Files and Storage in Windows Phone 8. Check out page 7, where it clearly explains the difference between installation and local folder.
The question originally originate trying to figure out why my live tile would not update and there were numerous reasons, so while unrelated to this question, I'll include them anyway as it may help someone in the future.
Folder creation problem: See above. Still can't explain why it works when app is transferred from pc to phone but when coming from the app store, it doesn't. Point is that I was going about it the wrong way and you should not be storing files in the root folder, even in a sub-folder as it can't be created in this location. You should use isolated storage or data storage.
Files still failed to update the live tiles when storing them in StorageFolder (LocalFolder). I then found these 2 articles which clearly state that images used by the Live Tiles should be stored in Isolated Storage but in a specific location i.e. Shared\ShellContent
WP8 Tip: Creating Live Tiles with Dynamic Images
Capturing image from camera and updating live tile
The minute I applied what was suggested i.e. use the specific path and use isolated storage, it sorted all my problems i.e. creating folder, creating file, etc...
Please note that while it states that you should store the file in \Shared\ShellContent, it also highlights that it can be stored in any sub-folders within that folder, so in my case, I've got \Shared\ShellContent\\Snapshots and it work as expected.
Again, if time permits I'll investigate the StorageFolder some more as I'd like to get it to work as it is the recommended method to use with WP8/WP8.1 by Microsoft and Isolated Storage appears to be recommended for WP7.
I hope it will save you some time if you encounter similar problems.
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.