WORKLIGHT_NATIVE_VERSION in IBM MobileFirst - ibm-mobilefirst

Will the value of "WORKLIGHT_NATIVE_VERSION" in (www-->default-->index.html) .wlapp ever changes?
If yes, what's the triggering event? (e.g. changes in .html, .js, .css, .xml, .m or .h file)
I'm using the same source code and same MobileFirst Platform Studio on 3 different MacBooks
1) 1st macbook and 2nd macbook has the same "WORKLIGHT_NATIVE_VERSION"
2) 3rd macbook has a different "WORKLIGHT_NATIVE_VERSION"

WORKLIGHT_NATIVE_VERSION is a checksum value of the native portion of the client SDK.
When installing an update to the Studio plug-in (or CLI), and this new build contains changes to the native layer of the client SDK, then this value will change accordingly in the generated index.html file of the application.

Related

Error submission app update: packages Windows 8.1 (desktop and Phone bundle) + Windows 8.0

I try to send an update for my app to Windows Store by Windows Dev Center Dashboard, this update contains 3 packages: 2 for Windows 8.1 (Desktop and Phone) as a bundle and 1 for Windows 8.0 that does not support any bundle.
Before the new dashboard the package for Windows 8.0 was accepted too in this configuration... not now and it reports this error:
A previous submission for this app was released with a Windows Phone 8.1 appxbundle. Subsequent submissions must continue to contain a Windows Phone 8.1 appxbundle.
but it isn’t a Phone package and for Windows 8.0 I can’t make a bundle! there is a solution? with the old dashboard that worked great.
Best regards,
Claudio
Not sure if it is applicable here. But in my case I've got the same error when updating UWP version of the application on the store where I had UWP, WP81 and W8.1 apps. The error was signaling the fact that the existent store UWP package was build with as a bundle but the new package was not.
So the solution was to replace in .csproj the <AppxBundle>Never</AppxBundle> with <AppxBundle>Always</AppxBundle>. If you publish from Visual studio directly you can do that from UI as described here.
I had this problem. I deleted all the files in the folder where the package is building to the store. Then I created a package for store. This problem is solved.
I had the same error message appearing from nothing (just making a new build, no changes to platform). When I checked the box "do not automatically increment" (in UI, lead to <AppxAutoIncrementPackageRevision>False</AppxAutoIncrementPackageRevision> in csproj) and filled in my own number, the package that came out was called:
1.3.0.0_AnyCPU_bundle.appxupload
If I did not do it it looked like:
1.3.0.17_AnyCPU.appxupload
The latter did not work for some reason. So setting own build number fixed this particular problem for me. Why it fixed it? No clue.

From where is the worklight folder inside the wlapp file copied from when we perform a Mobilefirst build?

I just wanted to know how the worklight folder is compiled and copied inside the wlapp file. I am referring to the worklight folder which consists of the cordova plugins folder, worklight.js, cordova_plugins.js, etc.
These files are used during build-time by the Worklight Build Engine. They are located in the TMPDIR of your OS. Since you're using OS X you can open Terminal and run the command open $TMPDIR/wlBuildResources (> your-WL-version\jslibexpanded).
I am guessing you are asking this because you are thinking of altering these files pre-build time? You must not do that as it may generate a faulty application (it does not go only to the wlapp file but also to the generated native project of any mobile environment you may have added to your application).
These resources are also deleted and re-created on each launch of Eclipse (with Worklight Studio installed).
This will of course also void any support requests.
Since this is probably related to your other question about using the Ionic Keyboard Cordova plug-in, note that in the upcoming MobileFirst Platform Foundation 7.1 there is Cordova application support, enabling you to create either an iOS or Android application with MPF as a plug-in like any other, thus you can also leverage any Cordova plug-in that you would like. More on this, soon, once 7.1 is released.

How to set Android SDK target in Worklight Studio

I just installed a new Worklight 6.1 environment (Studio).
I got a brand new Eclipse 4.3.1 and installed Worklight 6.1 plugin on top of that.
Then I downloaded Android SDK and Tools.
When I created my first sample project and added Android environment, automatically the tool set the Android target SDK to 19, which I actually I don't have installed, so I got an error.
I then changed the following line in AndroidManifest.xml to my desired target SDK:
<uses-sdk android:minSdkVersion="9" android:targetSdkVersion="15"/>
but building Android environment, I receive following message:
It is recommended that your Android application will target the same API level used to build the android project. The API
level used to compile the project is specified as the Project Build Target in Project / Properties / Android dialog. Configure your application
to target the same API level by setting the same value in android:targetSdkVersion attribute in AndroidManifest.xml.
So it seems that changing the target SDK in AndroidManifest.xml is not enough, but I can't find this : Project Build Target in Project / Properties / Android dialog.
Any advice is most welcome.
Giovanni
The Project Build target you are referring to appears in the properties of the Android project and not the Worklight project.
Alternative, you may update in the main project
apps/appName/android/native/project.properties.
You'll also need to take care of AndroidManifest.xml.
project.properties has this contradictory notice (as pointed out by this question), but it is safe to edit it.
# This file is automatically generated by Android Tools.
# Do not modify this file -- YOUR CHANGES WILL BE ERASED!
#
# This file must be checked in Version Control Systems.

Linker error when adding frameworks to native worklight project

We are using Worklight Developer Edition v6.0 with XCode v5.0.2 on Mac OS X 10.9.
Newly built Worklight hybrid apps works fine on the iOS 7 devices running from XCode, but when we add a new native framework into XCode, it results in a Linker error related to Worklight libraries during builds (image below). I've tried this with multiple frameworks that worked fine with my previous version of Worklight 5.0.5. Please advise.
I think you're facing same xcode problem I've recently faced. Once I'm adding new frameworks/libraries xcode breaks framework search path by adding extra slashes.
In your project properties to go Build Settings and look for Framework Search Path. It should have several entries, one of them is $(SRCROOT)/Frameworks. Make sure that after you add your framework this entry remains unchanged. In my case xcode added several extra quotes and slashes making framework files unreachable.

Silverlight OOB updates when using MEF / PRISM

I am working on a prototype for Silverlight OOB application. To modularize the application either PRISM or MEF or both will be used. When a new version of the application is available, CheckAndDownloadUpdateAsync can assist in downloading the latest version in OOB scenario.
How does updates work if only a new version of an application module is available? Is there a known functionality and/or strategy to be used to download new modules?
You can roll your own update detection, by having a small file on your server next to the XAP for your app, that contains the latest version. For example:
http://localhost/myawesomeapp.xap
http://localhost/myawesomeapp.xap.ver
When you want to check for updates without downloading them, you can always hit the .ver file, check the version listed in it and if newer then the current running app, show the Update button to the user.
Note that this approach also would allow you to create more advanced scenarios, like prompting the user to upgrade to a different version of the app (Pro for example) or that they need to upgrade their Silverlight to get the latest.
And if you have multiple apps, you can list all of them in that file and do cross-promotion between your apps.