How to set Android SDK target in Worklight Studio - ibm-mobilefirst

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.

Related

Update Tools For Apache Cordova in Visual Studio

I am new to apache cordova and i'm trying to build a client app for my asp.net mvc website, using apache cordova in visual studio.
but visual studio 2017 tools for apache cordova installs cordova 6.3.1 and some plugins like onesignal can't work on it.
Could you please help me?
That is a known issue but it can be fixed following these steps:
Assuming you have already installed Cordova 7.1.0 gobally using npm install -g cordova#7.1.0
In Visual Studio 2017 go to File > New > Project > Blank App (Apache Cordova)
Open config.xml in View Code mode and find this:
<vs:toolsetVersion>6.3.1</vs:toolsetVersion>
<engine name="android" spec="5.2.1" />
Replace with:
<vs:toolsetVersion>7.1.0</vs:toolsetVersion>
<engine name="android" spec="6.3.0" />
Where 7.1.0 is your global Cordova version.
Note how cordova-android has been increased to 6.3.0 as well.
Feel free to try using cordova-android 6.4.0 or cordova-android 7.0.0, however they may or may not introduce some issues (with Gradle for example). I have tested 6.3.0 but certain plugins may require a newer version.
Select Device as target.
Now Build > Build Solution
Save, close and reload the project. When you access config.xml in designer mode you'll see Global Cordova 7.1.0 as the selected toolset.
In order to build you may need to use the external Android SDK Build Tools (API 26) instead of the ones provided by Visual Studio (API 25).
Use the Android SDK Manager to manage versions, no need to get Android Studio for this.
Remember to follow the guidelines from Microsoft when changing the CLI on existing projects. However I strongly recommend creating a new one and then importing your files and adding your plugins to avoid potential problems.

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.

Error while upgrading worklight project from V6.1 to V6.1.0.01

I am trying to upgrade worklight project built using v6.1 to v6.1.0.01 and getting following error :
An internal error occurred during: "Upgrade Worklight Projects".
com.worklight.upgrader.versionGraph.VersionGraph.isKnownVersion(Ljava/lang/String;)Z
The version of studio is 6.1.0.01-20140418-0637
This could happen if your imported project is missing
either the complete org.eclipse.core.resources.prefs file in the .settings folder of your project (this is hidden file; you can see it using the Navigator view in Eclipse for example),
or if this file exists but it is missing the wl_version property.
You can fix this by creating a new project and copy over this file to your 6.1.0.0 project and then try to upgrade again to 6.1.0.01 - which you should be using 6.1.0.02 anyway by now and not 6.1.0.01.
One workaround you can do is to create a new project with the same name, etc in the Studio belonging to 6.1.0.01 and copy over your web resources and native code to the newly generated files.
You can also take a blank app in 6.1.0.0 and try to import that one to 6.1.0.01 to see whether it fails still or not. This will help in focusing the issue.

IBM Worklight 6.1 - Adding the optional Analytics feature has no effect

I have installed the Eclipse Juno SR2 client for Worklight 6.1 EE and when I add the optional analytics feature to the application-descriptor.xml file, I do not see any Tealeaf libraries added to the project.
I am running on Mac v10.9.
Any ideas?
Using Eclipse Java EE 4.3.1 ("Kepler" SR1) and Worklight 6.1 Developer Edition* on a Mac running OS X 10.9, I have done the following:
Created a new Worklight project and application
Added the Android, iPad and iPhone environments
In the application-descriptor.xml's Design view I chose Optional Features > Analytics
Re-built the project
Outcome:
For iPad and iPhone, the existing empty Tealeaf folder under native\Tealeaf now got populated with library and bundle files
For Android, the native\libs folder got populated with uicandroid.jar
Similarly, for JSONStore and FIPS 140-2, files were added to the projects upon build.
Make sure these are the steps you've been following.
If you have any related errors in the Errors view in Eclipse while adding the optional features, do mention this.
*There is no (technical) difference between the various Worklight editions other than the exclusion of App Authenticity from the Developer Edition.

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.