I am getting 'update is available' message from MFP after installing a new build via TestFlight. This only happen the first time.
This my steps
Build by app with cordova build command
Open Xcode and add the Push entitlement and deploy to the TestFlight
execute the mfpdev webupdate command
After installing the update from TestFlight I get the 'Web update is available' message from MFP..
I have not change any html,css since I deploy to TestFlight. So, I am not sure why the update message
All I am changing in step 1 is build# "android-versionCode" and "ios-CFBundleVersion"
I am using MFP V8
Direct Update is based on checksums. A checksum value is stored in the client whenever it is built. This checksum value is sent to the server as part of calls made to the server and is being compared to the client checksum value that is also stored on the server.
When performing mfpdev app webupdate, if there are any web resources changes in the application since its last state, the checksum value on the server will change.
Thus, the next time an application with an older checksum value attempts to connect, the checksum values will not match and a Direct Update will trigger.
That said, a change of a bundle identifier happening in the config.xml file and I am not sure if changes to this file are supposed to affect the checksum. Also note that changes to this file cannot be "updated" or "reflected" in the application by using Direct Update either. If you change something in this file then are you very much supposed to re-build the application and potentially release it with a new version number to the App Store / Google Play Store.
That said #2, as a workaround, simply do not execute the webupdate command and your issue should be resolved.
I do encourage you though to open a PMR to see if changes to the config.xml should or should not affect Direct Update.
Related
I'm working on an IBM MobileFirst Platform 7.1 project where there are many name value pairs in the worklight.properties file.
Say for example,
HOST_NAME = www.google.com
I access these variables form the MobileFirst adapter.
var hostName = WL.Server.configuration["HOST_NAME"]
There will be cases where I'll have to change the HOST_NAME in the worklight.properties to a different value. But sometimes, even after the value is changed in the worklight.properties file, they are not getting updated in the adapter.
Every time when I change the values I do the following,
Clean the project
Restart the server
Deploy the adapter again
Nothing seemed to change the value.
I suspect, the MobileFirst server caches the values and reuses the old values without updating the new ones. I say this because, I tried deleting the values in the worklight.properties file, and even tried deleting the file itself. Still the adapter was using the old value.
I tried deleting the MobileFirstServerConfig Folder in my workspace. Even that didn't work.
It would be great if someone could help me clear the cache or find a work around to this issue. Thanks in advance.
I kind of followed the above method but initially it didn't work.
But later I tried to follow these steps in this exact order and it seemed to work.
Stop Worklight Server.
Remove your project from Mobile First Development Server.
Go to the "bin" directory and remove your project war.
Clean and Build the entire workspace.
Start the server
Deploy the adapters
Run your app.
The worklight.properties file is embedded into the project runtime WAR file. So, if you change anything in worklight.properties, you must rebuild the WAR file and redeploy it. Based on your description, it sounds like you're only building the adapter (and not the app). At minimum, I would suggest to remove the runtime WAR file from the project "bin" directory (just to ensure that it gets rebuilt) and build all app environments. That should build / redeploy the WAR file and restart the server, and then what you're doing should work.
Here are the steps to follow:
1. If worklight server is up and running, stop it or restart your system.
2. Clear bin folder.
3. Do Clean Project and Build for enviournment.
4. Open Mobile first Console(Start server)
5. Deploy All adapters
6. Run your app.
If wlq or wl error is comming we can give an alert message 'test' in our main file where we have all the javascript files.
I need suggestions on how to update my application. The form application is going to be put on a drive for many users to be using non stop all day. What are ways to update the program or allow updates to the program while it being use? If I update the program and recreate a new build for it, trying to copy paste over the old application will not let me if someone else has it open. Open to any suggestions.
Option 1: Deploy the app with ClickOnce and set it to check for updates every time it runs.
ClickOnce:
In your project settings, click on the Publish tab.
From here you can configure where the app publishes to and if it should be installed or available online only.
Once you have it all configured you will use the Publish Now button to compile and upload your update to the publish location. Each time your users open the app it will check for updates at your set location. To have your app check for updates programmatically use code like the one found at this MSDN link - https://msdn.microsoft.com/en-us/library/ms404263.aspx
You should note that users will no longer run an exe directly and you won't copy your exe to the publish folder. Your users will have to click on a file that has the extension of .application. The users could create a shortcut to this .application file to place on their desktop or wherever they want.
Also note that if using ClickOnce and you publish a bad version (with a bug for instance) then your users have the ability to revert back to the previous version so that they can continue using the app while you fix the bug. Your users also have the option to skip an update so you'll want to inform them to never skip the updates.
Option 2: Create an app that publishes your main app
I'll admit that this answer is not a great way
You could create another exe for the purpose of publishing the main exe. The publishing exe will simply try to copy the new exe over the old one and keep trying until it is successful. It will be successful when all instances of the program are terminated.
Option 3: Use a database
Have your app check a database value that indicates an update is available. Prompt users using the app to shutdown and don't allow other instances to startup while the database value is set to update available.
You could use nUpdate, a free and open-source .NET-library for updating applications that also cares about the safety of your update packages which is an important fact. Many update routines do not validate the packages they downloaded, which can result in serious damage, if updates are replaced by malware (as it happened to the puush-service some time ago).
nUpdate is especially designed for Windows Forms-applications.
It is still being improved at the moment and the support for WPF-applications will be added soon, but the current version is very stable, yet.
I cannot select the latest version I have uploaded to seed to beta in external testing. First of all whenever I upload a build two version appearing, that have upload time difference of 5 to 15 minutes between them. One of them gets changed from processing to normal available state, but other does not. But now selecting the available build also selects the processing one and my selection is blocked and I cannot select the OK button because probably my selection is blocked by the processing one. I think it is UI frontend issue at itunesconnect side but it could be something I am doing wrong. Please help me if anyone has been able to tackle this issue if they faced. Please see checkout the attached image.
Update:
I Included <key>ITSAppUsesNonExemptEncryption</key><false/> in my subsequent builds that I uploaded according to the new Export compliance message on the iTunes Connect home page. I am still facing the issue. I have contacted Apple Dev support, will keep you updated if I find a solution.
The issue has been mysteriously solved by uploading the application from Application Loader with Aspera turned off instead of using Xcode's organizer window as suggested by Apple Developer support. Make sure you add: <key>ITSAppUsesNonExemptEncryption</key><false/> in your info.plist file before archiving the build. Although mysteriously my previously uploaded builds have also become available for external testing.
Body of email that helped solve the issue:
After further research, it looks like their may be an issue from your
end with your network while trying to upload to this app record in
iTunes Connect.
First, for the best upload experience make sure that all ports and IP
addresses are accessible. Additionally, it’s important to make sure
the internet connection is very good, and that there are no firewalls
blocking the uploads. More information can be found here:
http://help.apple.com/itc/apploader/#/itc8e7ec5a60
Second, it may be beneficial to try using the latest version of
Application Loader. Please note that you can export your project from
Xcode to upload through Application Loader. As a temporary workaround,
once you have Application Loader open, you can go to the File menus
and select the following:
Application Loader > Preferences
Then, select Advanced, and as a temporary workaround you can try
deselecting Aspera and upload the build again. You can follow the
steps below to use the latest version of Application Loader.
Download the latest version of Xcode from the Mac App Store:
-http://help.apple.com/itc/apploader/#/itc8e7ec5a60
Open the latest version of Xcode
Go to the File menu and select Xcode > Open Developer Tool > Application Loader
Lastly, try uploading again to see if the issue persists.
Hello my dear friend there,
I am also having your issue yesterday, I have this similar screen with yours:
The build is duplicated which one of them are processing forever until today.
My personal problem solving was:
Increase my build number in Xcode so that I can reupload my build
Rearchive the build then export for iOS App Store Deployment in Xcode Organizer
Reupload the build using Application Loader
Then try to reconfigure the build in iTunes Connect. For a while it is processing like usual, but it will not take forever, after one hour, the build will be available for testing.
Hope my personal troubleshooting can be applied to your issue too.
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.
The command bees app:list shows names of the applications, status, URL and instance count, but is there a way to see the latest commit message?
We set the commit message to be the Git revision of the sources that produce the deployed WAR and it would be nice to see which version is currently running of each app without having to look it from the RUN console wep application.
bees app:info shows a bit more information but not that deploy message, unfortunately. That may be a nice addition to it thought, I will pass that on.
bees app:info will show exact deployment time, if that helps.