I have version 1 of my Windows Phone App (w8.0) in the store which has been running for a while now. The app uses a SQL Server compact database for local persistence on the device.
I'm now ready to release v2 of my app (w8.1), which has a number of database schema changes. The question is how I can formally setup a test environment for the test team where testers can:
1...Install v1 of the app from the store
2...Run it up and do some light activity
3...Then upgrade the app on the phone to v2
4...Continue testing using an upgraded version of the database
Up to now all v2 testing has been done using a shiney new install of the app.
I know i can do this using Visual Studio, but this defeats the objective of the test i.e. a live user upgrading via the store.
I've tried using the app deployment tool, but this deletes v1 of the app (including the database) when it deploys v2. I was surprised it did this - I thought it would recognise the install as an upgrade. I can verify this because it deletes the database. I am using the same names/keys in the manifest, including an incremented version number.
For now I have a new (hidden) TEST app in the store where i've submitted v1 of the app. Once the testers are ready, I submit v2 of the app to the store which the testers then upgrade. Problem here is that it takes upwards of 12 hours for the store to publish the upgraded version.
I am aware that you can install an app from the SD cards, which is pretty close. Has anyone else found a good elegant way to do this?
You could use Windows Phone Power Tools to achieve this.
Here's the link: https://wptools.codeplex.com
Just install the old xap, do some stuff and then update to the new xap using the "UPDATE" button. If you don't change the app ID, it will surely work.
Hope this helps! :)
Related
I'm want to create automated build environment for windows store apps (phone/tablet) & after creating build provide way(link to download) to deploy it on devices. Right now packages for testing needs to manually installed on device and then hand over for QA or upload on Windows beta store for phone apps.
Would like to know what possible tools can be used to serve this purpose. Please guide.
Thanks
It's convenient while developing with the MFP studio (Once any files change, the client will get a update notification which is so-called "direct-update"). But how could make this in a MF production server ?
Do we have to do "Replace project war file" in the MF Server configuration Tool and then the re-select a large version number .wlapp file in the worklightconsole ?
Unlike what Srik wrote - you shouldn't carelessly delete the old .wlapp. By doing so, users who use the version of said .wlapp will not longer be able to connect to the server.
So you if need to trigger a direct update, re-deploy the updated .wlapp file when you need to, don't first delete it.
Do not delete it even if deploying a new version (1.1 instead of 1.0).
You should delete only after you are certain that all of the users of 1.0 have migrated to 1.1.
1.1 constitutes of a new version that was also uploaded to the app store.
You can force users to upgrade by "remote disable"ing v1.0 (and point to download the new version). When everyone migrated, you can then delete the old version if you really feel like it.
Deletion is done via MobileFirst Console.
Load the console URL
Click on Applications
You can delete:
The entire all with all of its environments:
or a specific environment, or a specific version of an environment (if you had for example 1.0 and 1.1):
You can delete the old .wlapp file and put in your new .wlapp file. There is no need to replace the .war file
Agree with what #Idan Adar wrote, and make some addtion IMO:
You are doing iterative development of your app and upgrade your product frequentlyly, but just in UI level and adapter level, you can just update .wlapp files (DO NOT delete it ) which will trigger a direct update;
I don't think version number in WL console is so important to the end user (they cannot see it and they don't care), so you can just define a version number inside the app then update by direct update;
If you changed something big, and changed something platform related ,e.g : in iOS developing you change worklight.plist (in this file, which WL server your app is connecting to or WL platformVersion is defined here), then you have to rebuild your app and publish them to App Store or Android market.
I use Worklight 5.0.6 and can't use direct update for a Windows 8 application.
IBM Worklight Information Center tells that windows 8 app can use direct update.
My way to test direct update as follows.
Please tell me how to use direct update in Windows8.
make windows8 env project
change wlInitOptions.connectOnStartup value "true" (in common\js\initOptions.js )
select [Build All and Deploy]
double click .jsproj file run simulator in visual studio 2012 for Windows8
make app "back ground"
change html file and "re [Build All and Deploy]"
make app "foreground"
This documentation page is misleading (I will open a defect to correct it).
Direct Update (as in the process of updating the web resources of the application after it has already been installed on the device) is available ONLY for iOS and Android. In those environments following your steps will indeed trigger a Direct Update.
The update (or rather, upgrade) of Desktop applications has no relation what-so-ever to the Direct Update mechanism mentioned above.
For Desktop enviornments consider it like updating any other desktop application - where you up the version number, and the app detects that there is an update available or so.
In the case of Adobe Air and Windows 7/Vista Gadgets:
Build your application and install it
In application-descriptor.xml, up the value of the version attribute in the envrionment's element (for instance from "1.0" to "1.1")
Build again
I believe that now you need to go to the Worklight Console and re-download the installer, and it will detect that it needs to upgrade rather than install afresh).
Note: iGoogle, Facebook, Windows 7/Vista Gadgets and Dashboard environments will be removed in the next version of Worklight. All have ample replacements with other supported Worklight environments.
In the case of Windows 8:
Direct Update most certainly does not exist for it
The steps above are also not relevant as it is not a downloadable executable
I prepared a simple quiz app for Windows 8 store. My app successfully passes on WACK just after building and creating local packages without login to store account, however it fails (perf test: launch was not detected) when I login to my store account, associate the app with a reserved app name and create packages to submit.
So, I submitted my app three times and it always failed requirement 3.8 since those packages fail. What should I do? Is there anything I miss? I'm dealing with this issue for many days but I can't find the right solution.
Regards,
Hakan
I downloaded and installed Visual Studio 2012 Update 1. WACK tool I use is the latest one. My Windows 8 account and Windows 8 Store account are same. However; I still have the problem.
That's what I'm doing;
I recreated my app project. Successfully builded the app and created (not store associated) app packages without login to store account on Visual Studio. After creating those packages, I started WACK on Visual Studio and app passed successfully. Then; I cleaned the solution and created the packages to upload store (I logged in to my store account on visual studio and chose the app name I reserved). After creating packages I started WACK again, but this time app failed with; "Launch was not detected" error.
I don't think there is anything else to do. I get bored after each unsuccessful submitting. What should I do? Does anyone have any idea?
Requirement 3.8 is very specific, and has nothing to do with your app's name. From the App Store Requirements:
3.8 Your app must meet the basic performance criteria on a low-power computer
The app must launch in 5 seconds or less
The app must suspend in 2 seconds or less
Did you test your app on an ARM based device? How much time does your app take to start up/ suspend?
Update:
If you are using the standalone WACK, it is possible that you are trying to certify the old version of your application. As I recall, when you associate your app with the App Store, your app's name AND package ID change. However, bits of the old app may still be around, which can cause the certification to be run on an app that no longer exists.
Something that may help is to first uninstall your app prior to creating the package. The other thing to try is to run the certification from within Visual Studio. I have found it to be more reliable than the standalone app.
i'm looking for a way to manage application upgrades for my compact framework app.
let's say i have v1 of the app installed on my device, and v1.1 has been released. I want the app to make a call to my server to see if there is a new version. since a new version is found, i want to send down the new version of the app to the device and have it installed, replacing the old version.
my first thought was just to have the app download the .cab file and kick off the cab file just before exiting the app. this would mostly get the job done but it would prompt the user to pick the installation location if they have a storage card or other partitions on their device. i would like to prevent any user input and just have the new version of the app installed, replacing the old app.
i'm certain that there are others doing this already and i don't want to reinvent the wheel, here. what application management tools and systems exist for this type of process? how can I facilitate this type of process?
...
EDIT:
in spite of my previous searches before posting this, i just now found this question: How to Auto-Update Windows Mobile application
When I wrote one I relied on launching the .cab file. It was definitely the path of least resistance.
Otherwise, I'd write a simple "upgrade.exe" executable that gets distributed with your app. When upgrading, you'd download the new package, launch your upgrade.exe just before exiting your app, then have that program copy over the new files to your app.