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.
Related
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.
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.
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.
My setup for a mvvmcross project supporting iOS, Android and Win8 is to have two separate .sln files, one including the core, iOS and Android projects (for development in xamarin studio on mac) and one including core and winphone projects (for development in vs2012 on win8). However, I don't know which mvvmcross binaries (https://github.com/slodge/MvvmCross-Binaries) I should reference from my different .csproj files in this situation as there are two versions. Question is: what exactly is the difference between the two builds (XS-iOS-Mac and VS2012) and which binaries should I include for a working cross-platform setup? Thanks!
The difference between the two sets of binaries is that PCLs built on the Mac using the current Xamarin Stable releases are not true portable class libaries - see http://slodge.blogspot.co.uk/2013/01/almost-portable-binaries.html
This situation is currently 'in flux' - the latest alpha release from Xamarin is starting to produce real PCL binaries - see http://deapsquatter.blogspot.co.uk/2013/07/xamarin-pcl-support-hoorah.html
Until this transition is complete, if you want to work off of the pre-built binaries, then one easy method is to:
link to binaries in a folder - e.g. in : /lib/Mvx/
on the PC, fill this folder from https://github.com/slodge/MvvmCross-Binaries/tree/master/VS2012/bin/Release
on the Mac, fill this folder from https://github.com/slodge/MvvmCross-Binaries/tree/master/XS-iOS-Mac/bin/Release
Alternatively, the nuget packages attempt to do this for you - and seem to work with one exception (a problem with using MvxCommand which is easily worked around using your own MyCommand in your Core project)
My development platform is windows 7 x64. I have installed VS2012 and I'd like to compile a project that includes some Dx11 code.
Specifically, it includes the following files:
#include <d3dx11.h>
#include <d3dx10.h>
and links to
#pragma comment (lib, "d3dx11.lib")
#pragma comment (lib, "d3dx10.lib")
I already have VS2011 installed on my development machine, but I wanted to try the unit testing facilities in VS2012 for native C++.
Due to having VS2011 installed and working on DirectShow code, I have the Windows 7.1 SDK installed.
VS2012 picked this up and had references to the 7.1 SDK, but compilation of my project under VS2012 with the 7.1 SDK referenced gave errors:
"warning C4005: '__useHeader' : macro redefinition"
I googled this and found a query like mine on social.msdn.microsoft.com. and the solution recommended linking with the Windows 8 kit instead of the 7.1 SDK in order to solve this problem.
The Windows 8 kit includes headers like d3d11.h, but not d3dx11.h.
How can I include d3dx11 (from the Dx SDK) along with the windows 8 kit, but without getting multiple "macro redefinition" errors?
I found the following rather annoying quote in this MSDN page.
D3DX is not considered the canonical API for using Direct3D in Windows
8 and therefore isn't included with the corresponding Windows SDK.
Investigate alternate solutions for working with the Direct3D API.
For legacy projects, such as the Windows 7 (and earlier) DirectX SDK
samples, the following steps are necessary to build applications with
D3DX using the DirectX SDK:
Modify the project’s VC++ directories as follows to use the right
order for SDK headers and libraries.
i. Open Properties for the project and select the VC++ Directories
page.
ii. Select All Configurations and All Platforms.
iii. Set these directories as follows:
Executable Directories: (On right-side drop-down)
Include Directories: $(IncludePath);$(DXSDK_DIR)Include
Include Library Directories: $(LibraryPath);$(DXSDK_DIR)Lib\x86
iv. Click Apply.
v. Choose the x64 Platform.
vi. Set the Library directory as follows:
Library Directories: $(LibraryPath);$(DXSDK_DIR)Lib\x64
Wherever "d3dx9.h", "d3dx10.h", or "d3dx11.h" are included in your
project, be sure to explicitly include "d3d9.h", "d3d10.h" and
"dxgi.h", or "d3d11.h" and "dxgi.h" first to ensure you are picking up
the newer version.
You can disable warning C4005 if needed; however, this warning
indicates you are using the older version of these headers.
Remove all references to DXGIType.h in your project. This header
doesn't exist in the Windows SDK, and the DirectX SDK version
conflicts with the new winerror.h.
All D3DX DLLs are installed onto your development computer by the
DirectX SDK installation. Ensure that the necessary D3DX dependencies
are redistributed with any sample or with your application if it is
moved to another machine.
Be aware that replacement technologies for current uses of D3DX11
include DirectXTex and DirectXTK. D3DXMath is replaced by DirectXMath.
FFS Microsoft, please don't change the API's mid-version like this!!!