Has anyone used Casablanca on Android or iOS?

Sep 21, 2013 at 6:48 AM
We are facing an existentialist impasse right now with this SDK. My POC was for win32 but some mobile folks used cURL to accomplish http agent part. I really need to know if Casablanca can be made to work under Android and iOS.

This will come down to mobile platform support where all this REST stuff is the most useful. I personally think this SDK has great potential (given the right features and support) but without Android/iOS support the dream of cross-platform SDK is down the drain. it would be sad that after that many month it has to come to this (but your Linux https support made a big different in my argument for this SDK; otherwise it would have been a death blow by now).

The key features that still keeps this one alive:
1) Linux support with https; there is hope it can work under Android/iOS (will try soon enough)
2) WinRT certifiable (curl/openssl are not yet I believe but it's a matter of time before it does)
3) part of next visual studio library (is this a sure thing?)

When it comes to high level architecture decision features like JSON, pplx or C++11 won't make much difference if the SDK can't support the platforms we need (cross-platform is what's missing out there; if you can do it, and officially specified in the release note, everyone will use this; I mean this is like the holy grail of smart device era). Right now cURL is a very popular choice in this area (known to work under Android/iOS/win/Linux/etc).
Sep 21, 2013 at 5:02 PM
Edited Sep 21, 2013 at 7:11 PM
c2c,

I'm sorry to hear that, after all this time, Android support is getting in the way. I don't believe that you will find us officially supporting Android any time soon. Currently, our plans are to officially support Windows (desktop, server, Phone, and RT), as well as Linux. We encourage you and/or others to fork off a branch to do an Android port, or (if the Contributor License Agreement works for you) contribute back to the main Casablanca repo.

Given that Android is a Linux derivation (as far as I know), I would hazard to guess that it is a fairly straight-forward port. We have, in fact, ported Casablanca to OS X (we're not ready to announce support for that), and that was very straight-forward, except for some things that were missing in Boost on Mac forcing changes to be made in the unit test framework.

And yes, the Casablanca v1.0.0 library will be part of the next version of Visual Studio (as evidenced by the Preview), desktop and RT. It will also be available for next-generation Phone when the time comes. If you need/want something more recent than v1.0.0, you will continue to have to get it from CodePlex or NuGet.


Niklas
Sep 21, 2013 at 5:18 PM
Can you share with us any experimental port to Android or iOS (or Mac OS). I stared a port to Android last night but i was having problem building Casablanca. If I can port this over there is still hope.

I am able to use android's own port of libxml2 and OpenSSL for NDK. Also got a git project for boost 1.53 for NDK. So far so good for dependencies.

When it comes to Casanblaca I had to create my own Android.mk based on src/Makefile but there are too many errors with stdlib include file. I could be missing some basic configuration but I don't know what they are.

If you guys have a good version of *.mk files that would help.

C2C

Sep 21, 2013 at 6:38 PM
Edited Sep 22, 2013 at 3:19 PM
I will provide some steps into what I did so far so people can spot issues or take it further:

Prerequisite
1)prerequisites for NDK dev(except cgywin); Since this was a Windows guide I tried it first on win7 but path was causing issue so I switch to Ubuntu (much easier); either should work with different level of difficulties/frustration)
2) also need to install these pkg (gcc, wget, patch, git, make) some or most might be installed by default - will need them for building boost


Dependency building
3) boost (latest 1.53)
3b) ./build_android.sh <path to NDK>, if something is wrong fix it (it will download, untar, setup and build boost for you). If BCP can be used to reduce output size it would be great. In the script there is a check for NDK_RN (reading from RELEASE.txt from NDK folder). In my case I was using r8 (64 bit). For r9 that logic is wrong
if you want to build for 64bit since it's using 9*. I remember under Windows I had to fix that (hard code if need to be).

//these two are straight forward
4) OpenSSL 1.0.1e (if you need https)
5) libxml2 v2.7.8

Common issue is to honour the build format:
1) Move all source to "jni" folder.
2) Create a Application.mk (similar to a solution file; I place it beside Android.mk although they can in different folder)

in Application.mk:
NDK_APPLICATION_PATH := <path to source> #if ndk-build doesn't go there export that variable, use "env" command to see if it's defined there.
APP_MODULES := <output module list> # separated by space
APP_PLATFORM := android-8 # whichever version you are using
3) For Android based external lib you will see entries with host. You can remove these entries or replace them depending on the case. Some host output won't be used by us so you can remove them completely. Some entry you can change like BUILD_HOST_STATIC_LIBRARY to BUILD_STATIC_LIBRARY.

With some minor changes you will be able to compile without issue. Now we need to compile for Casablanca (still WIP)

1) git clone https://git01.codeplex.com/casablanca <restsdk>
2) move all folders under <restsdk>/Release to <restsdk>/Release/jni
3) create Android.mk and Application.mk

I am getting a lot of compilation error at this point because I think my include paths are not setup correctly. There are a lot of different version of the stdlib include path (due to different platforms). It should be able to pickup the correct one based on some settings.

I will update with Android.mk in another post.
Sep 23, 2013 at 7:43 AM
Edited Sep 23, 2013 at 10:39 AM
I guess default compiler of is NDK gcc4.6, which does not play C++11 ball very well
can you list few errors you received to give an idea of problem size?
Sep 23, 2013 at 3:26 PM
That's right, it needs to be at least GCC 4.7.3 (or 4.8) in order to have any chance of working.

Niklas
Sep 23, 2013 at 5:04 PM
Edited Sep 23, 2013 at 6:13 PM
I use NDK_TOOLCHAIN_VERSION=4.7 , I think 4.8 also exist. NDK has prebuilt compiler binaries for use. I don't think that's the issue. The most problematic is that some error indicate a compiler flag issues. I build using ndk-build, you can also build using eclipse (maybe have more success). My co-worker told me but I haven't personally gone that far.
jni/casablanca/include/pplx/pplxtasks.h:956:9: error: 'exception_ptr' in namespace 'std' does not name a type
jni/casablanca/include/pplx/pplxtasks.h: In constructor 'pplx::details::_ExceptionHolder::_ExceptionHolder(const int&, const pplx::details::_TaskCreationCallstack&)':
jni/casablanca/include/pplx/pplxtasks.h:909:34: error: class 'pplx::details::_ExceptionHolder' does not have any field named '_M_stdException'
jni/casablanca/include/pplx/pplxtasks.h: In member function 'void pplx::details::_ExceptionHolder::_RethrowUserException()':
jni/casablanca/include/pplx/pplxtasks.h:948:13: error: 'rethrow_exception' is not a member of 'std'
jni/casablanca/include/pplx/pplxtasks.h:948:36: error: '_M_stdException' was not declared in this scope
/eclipse/android-ndk-r8e/sources/cxx-stl/gnu-libstdc++/4.7/include/bits/exception_ptr.h:40:4: 
              error: #error This platform does not support exception propagation.
 
This happens because of  a macro called              
#if !defined(_GLIBCXX_ATOMIC_BUILTINS_4)
#  error This platform does not support exception propagation.
#endif
I was having library compilation error during Casablanca build.

Things like

uuid.hpp: swap_range is not part of std
xxpublic.h: FILE does not name a type

and whole a bunch of stuff from pplxlinux.h that shouldn't fail. Maybe include paths are missing.


Android.mk (I only added one source file from Makefile for debugging since that's not even compiling)
Boost output from above steps are used below you might need to specify the full path to the file (or some include path; full path works; in order to include by name other steps might required that I am not familiar with so use full path name to the file is the easiest here). My include paths is pretty messy, maybe there is a better way to do this (oh well)
LOCAL_PATH := $(call my-dir)
LOCAL_CFLAGS += -std=c++11 

include $(CLEAR_VARS)
LOCAL_MODULE    := test
LOCAL_SRC_FILES := src/streams/linux/fileio_linux.cpp


LOCAL_LDLIBS := -llog
LOCAL_LDLIBS += -lz

LOCAL_PCH := src/pch/stdafx.h

LOCAL_CFLAGS += -I/etc/dev/Boost-for-Android-master/boost_1_53_0
LOCAL_CFLAGS += -I/etc/dev/Boost-for-Android-master/boost_1_53_0/boost
LOCAL_CFLAGS += -I/etc/dev/android-ndk-r9/sources/cxx-stl/gnu-libstdc++/4.7/include
LOCAL_CFLAGS += -I/etc/dev/android-ndk-r9/sources/cxx-stl/gnu-libstdc++/4.7/libs/armeabi/include
LOCAL_CFLAGS += -I$(LOCAL_PATH)/src/pch
LOCAL_CFLAGS += -I$(LOCAL_PATH)/include
LOCAL_LDLIBS +=  -llibboost_system-gcc-mt-1_53.a -llibboost_thread-gcc-mt-1_53.a -pthread -lm -l/etc/dev/android-ndk-r9/sources/cxx-stl/gnu-libstdc++/4.7/libs/armeabi/libgnustl_static.a
LOCAL_CPPFLAGS += -H -g -Wall -Winvalid-pch
LOCAL_CPPFLAGS += -fPIC -fexceptions -frtti
LOCAL_CPPFLAGS += -std=c++11
include $(BUILD_SHARED_LIBRARY)
Application,mk
APP_PROJECT_PATH := /etc/dev/casablanca/Release
APP_MODULES := test
APP_PLATFORM := android-8
APP_OPTIM := debug
NDK_TOOLCHAIN_VERSION=4.7
APP_GNUSTL_CPP_FEATURES := rtti exceptions
I have given up on this for now and I don't have much time to spend on this (and we have given up Casablanca for Android for now). I hope to see this SDK to be truly cross-platform (ie: Android/iOS/win) in the future.
Jan 20, 2014 at 9:40 PM
c2c wrote:
I use NDK_TOOLCHAIN_VERSION=4.7 , I think 4.8 also exist. NDK has prebuilt compiler binaries for use. I don't think that's the issue. The most problematic is that some error indicate a compiler flag issues. I build using ndk-build, you can also build using eclipse (maybe have more success). My co-worker told me but I haven't personally gone that far.
jni/casablanca/include/pplx/pplxtasks.h:956:9: error: 'exception_ptr' in namespace 'std' does not name a type
jni/casablanca/include/pplx/pplxtasks.h: In constructor 'pplx::details::_ExceptionHolder::_ExceptionHolder(const int&, const pplx::details::_TaskCreationCallstack&)':
jni/casablanca/include/pplx/pplxtasks.h:909:34: error: class 'pplx::details::_ExceptionHolder' does not have any field named '_M_stdException'
jni/casablanca/include/pplx/pplxtasks.h: In member function 'void pplx::details::_ExceptionHolder::_RethrowUserException()':
jni/casablanca/include/pplx/pplxtasks.h:948:13: error: 'rethrow_exception' is not a member of 'std'
jni/casablanca/include/pplx/pplxtasks.h:948:36: error: '_M_stdException' was not declared in this scope
/eclipse/android-ndk-r8e/sources/cxx-stl/gnu-libstdc++/4.7/include/bits/exception_ptr.h:40:4: 
              error: #error This platform does not support exception propagation.
 
This happens because of  a macro called              
#if !defined(_GLIBCXX_ATOMIC_BUILTINS_4)
#  error This platform does not support exception propagation.
#endif
I was having library compilation error during Casablanca build.

Things like

uuid.hpp: swap_range is not part of std
xxpublic.h: FILE does not name a type

and whole a bunch of stuff from pplxlinux.h that shouldn't fail. Maybe include paths are missing.


Android.mk (I only added one source file from Makefile for debugging since that's not even compiling)
Boost output from above steps are used below you might need to specify the full path to the file (or some include path; full path works; in order to include by name other steps might required that I am not familiar with so use full path name to the file is the easiest here). My include paths is pretty messy, maybe there is a better way to do this (oh well)
LOCAL_PATH := $(call my-dir)
LOCAL_CFLAGS += -std=c++11 

include $(CLEAR_VARS)
LOCAL_MODULE    := test
LOCAL_SRC_FILES := src/streams/linux/fileio_linux.cpp


LOCAL_LDLIBS := -llog
LOCAL_LDLIBS += -lz

LOCAL_PCH := src/pch/stdafx.h

LOCAL_CFLAGS += -I/etc/dev/Boost-for-Android-master/boost_1_53_0
LOCAL_CFLAGS += -I/etc/dev/Boost-for-Android-master/boost_1_53_0/boost
LOCAL_CFLAGS += -I/etc/dev/android-ndk-r9/sources/cxx-stl/gnu-libstdc++/4.7/include
LOCAL_CFLAGS += -I/etc/dev/android-ndk-r9/sources/cxx-stl/gnu-libstdc++/4.7/libs/armeabi/include
LOCAL_CFLAGS += -I$(LOCAL_PATH)/src/pch
LOCAL_CFLAGS += -I$(LOCAL_PATH)/include
LOCAL_LDLIBS +=  -llibboost_system-gcc-mt-1_53.a -llibboost_thread-gcc-mt-1_53.a -pthread -lm -l/etc/dev/android-ndk-r9/sources/cxx-stl/gnu-libstdc++/4.7/libs/armeabi/libgnustl_static.a
LOCAL_CPPFLAGS += -H -g -Wall -Winvalid-pch
LOCAL_CPPFLAGS += -fPIC -fexceptions -frtti
LOCAL_CPPFLAGS += -std=c++11
include $(BUILD_SHARED_LIBRARY)
Application,mk
APP_PROJECT_PATH := /etc/dev/casablanca/Release
APP_MODULES := test
APP_PLATFORM := android-8
APP_OPTIM := debug
NDK_TOOLCHAIN_VERSION=4.7
APP_GNUSTL_CPP_FEATURES := rtti exceptions
I have given up on this for now and I don't have much time to spend on this (and we have given up Casablanca for Android for now). I hope to see this SDK to be truly cross-platform (ie: Android/iOS/win) in the future.
Hi,

What's about your errors? Did you achieved to use casablanca within Android NDK.

Should I wait for an official release for Android?

I also need to use a REST library with Android

Thanks!!
Jan 21, 2014 at 3:28 PM
We have abandoned Casablanca due to its lack of mobile support (MS not serious about non Windows platforms; same mistake Intel is facing; wintel legacies).

The approach we took (if it can help).

1) build a communication protocol class (in this case REST) that suits your need but make communication logic pluggable (define your communication interfaces)
2) implement your communication interfaces with platform dependent code (in theory cURL/openssl should work everywhere)
3) build your application logic on top of this communication protocol class

Faster approach (to use what works):
Windows (desktop, RT, phone): Casablanca
Android/iOS: cURL/OpenSSL

More generic implementation: boost/OpenSSL for all platforms (check Casablanca for REST on Linux side)

open source JSON should be easy to find online or use the one provided by Casablanca (I don't see why not).
Coordinator
Jan 21, 2014 at 5:25 PM
Hi c2c,

Sorry to hear you have decided to stop using Casablanca due to lack of mobile support. While yes we have unfortunately been slow to add support on additional platforms it is important to us. In our next release, 1.5, we will be adding official support for MacOS and iOS.

Steve
Feb 9, 2014 at 3:40 PM
Hi Steve,

Do you have any news regarding the next official release (1.5) ?

I am currently evaluating technologies for a new project and would like to assess if working with this project would be ideal for us.

Our requirements are iOS and Android, although other platforms may be added in the future.

Thanks
Lior
Coordinator
Feb 10, 2014 at 2:30 AM
Hi Lior,

No news for Android, but in our next release, 1.5, we will have support for MacOS and iOS. We are targeting the release for end of February. One thing to note our implementation for Linux, Mac, iOS is nearly all the same code so there aren't any fundamental reasons why Casablanca can't work on Android. We just haven't had the time to take a look at it.

Let us know if you have any other questions.
Steve
Feb 10, 2014 at 8:00 AM
Thanks, iOS support is indeed 50% good news for us :)

Since i am not familiar with the code at all (yet), i have no way of determining the efforts it will take us to port it over to Android.

I believe you when you say most of the code can be reused with no modifications. I am wondering about the efforts that will be needed (messing with make files, compiler issues, minor code changes), etc.

If anyone (or you) can provide an ESTIMATE regarding how hard or easy that might be, it would be great for us to check it out, maybe we can look at this library for our purposes.

--Lior
Feb 10, 2014 at 4:31 PM
I think this is really a build/configuration issue with Android integration. We tried and failed (abandoned). I think if Android support can be added it would put this library on the roadmap for many projects.

As you know Android has two distributions: ARM based default Android distribution and Intel based Android-ia (Intel built distribution based on original and for dual boot systems; these device already exist in the wild). There is also a community based Android-x86 distribution that runs Android on Intel machine but I don't know if anyone use it beyond testing - you can install it on VMware for example instead of using the emulator. I don't know if by default Google distribution works on both ARM and Intel out of box.

android-x86: http://www.android-x86.org/
android-ia: https://01.org/android-ia/
Coordinator
Feb 11, 2014 at 1:35 AM
Hi Lior,

We don't really know exactly how long and I agree with c2c that it looks mostly like a build configuration issue. At a quick estimate, my guess is it would take maybe 2 to 3 weeks to figure it all out and get it working. If you are going to take this on we really would like to take your changes back into the codebase so everyone can benefit.

Thanks,
Steve