We've begun to build Cross platform Android/iOS apps, having built exclusively in MonoTouch before. We're evaluating MonoDroid.
Our apps need to consume JSON and we'd like to use ServiceStack. Xamarin has a ServiceStack branch which we're using - https://github.com/xamarin/ServiceStack
We'd like to have a common project responsible for GETting and POSTing JSON. ServiceStack by Xamarin has different DLLs for Android and iOS. How do we have a single project and use ServiceStack to get at our JSON?
We're open to other options to get at JSON in a unified way?
By and large, managed *.dll's compiled for MonoTouch that don't have a dependency on MonoTouch specific types are compatible with Mono for Android projects.
ServiceStack is a great example of this. I've personally used it for multiple projects across the Xamarin mobile framework offerings.
As a general rule I tend to encapsulate all invocation to my web services using a partial class with async methods, like FooProjectRestClient. And then if there ever is any sort of segmentation that needs to occur it can happen in a shared class using #if defs.
The reason why there are MonoTouch and Mono for Android specific libraries is often because of the (smaller, Silverlight-like) profile available (e.g. things that depends on new FX4.0 features needs to be cut out). They are often the same code re-compiled with SILVERLIGHT (or MONOTOUCH, MONODROID) defined.
The reason for MonoTouch only specific librairies are generally because its environment (iOS devices) do not allow JIT'ing. So there's no code generation (e.g. System.Reflection.Emit) or dynamically (down)loading code... However it's often possible to provide (less performant) workarounds or skip a few features and keep a special version of the library for MonoTouch.
Now back to having a single shared assembly/project. The special MonoTouch assembly (generally the same code re-compiled with MONOTOUCH defined) is still a valid .NET assembly and often can be used in Mono for Android, Mono or .NET (once recompiled, even with MONOTOUCH). It's definitively not optimal but it's something you can try.
Another one is having the same projects (e.g. MyLib), across several solutions (e.g. MonoTouchApp, M4AndroidApp) and use special configurations (just like there's an iPhone|Debug one) to set different defines (e.g. MONOTOUCH on iPhone*|*). That can allow you to keep the best feature implementation in each platforms (e.g. in case the same feature is implemented differently).
I would try the later first (config), then sharing the MonoTouch special assembly and finally (if it really does not work) look for other alternatives.
Related
I am currently planning the development of a multiplatform app, and I am not sure wich way to do it fits my requirements best, since all possibilties I could think of failed to satisfy me.
First I want to write an app for android, which should feel like a normal typical android app. So I want to use the standard actionbar and android design look and feel in my other gui elements. After finishing the android app I am planning on developing an ios app, which should have a different design, so i am going to redevelop the gui for this anyway.
But I don´t want to rewrite the other code wich represents the intelligence of the app, independent from the gui. I came up with the following possibilities:
1. Java GUI With native library
Here I abstract all the code of my app in a C++ library (since as far as I know ios supports the usage of c++ libraries too) and develop the gui android typically in java. The library would than have a function to start and would inform the gui about every change via callback functions.
Pro
I can reuse all the code that would be the same on both platforms. I just would implement the gui seperately
The design of the android gui is straightforward as I want it to be. It looks like typical android because it is typical android.
Cons
I dislike the usage of JNI very much. Especially the signature and names of the callback functions (calling java functions from c++) are not checked at compile time and require a lot of manual work. If I rename a function and forget to rework the native part I only notice this mistake at runtime.
2. Build the GUI on the native side
Here I had difficulties finding out what is possible, especially for 2.2
2.1 Use Qt
I have only a few first step experiences with Qt in general but as far as I understood i would have the following pros and cons:
Pro
Reuse most parts of the code for ios and Android. I would than redesign the gui for each platform to make them feel natural. I can´t evaluate how much qt may even assists me at doing that
Cons
I have to copy the android gui by using other qt widgets. This is more effort and I don´t know if one can replicate the android gui elements (like the actionbar) so that the user wouldn´t notice it.
2.2 Using the android framework from the native side
I dont know if this is possible at all, I wasn´t able to find this information. Can I use the class "NativeActivity" and use the android framework to build the gui and use e.g. the actionbar? If this is possible somehow it would have the pros from 1. and maybe wouldn´t have it cons?
Do you have any feedback to my ideas or maybe even new approaches I didn´t think of? How do other multiplatform apps like WhatsApp solve this problem? Do they have redundant code for each platform?
Thank you,
Tobi
I would say that it depends very much on your application requirements. By my opinion, a better solution is to develop a separate application for each platform using recommended SDK's for that platform, and implement in native C++ only the time consuming data processing algorithms.
Application runtime on mobile platforms is not so straightforward as on desktop platforms. You should take into account background and foreground processing, specific application life cycling, accessing system resources such as network, file system, etc. And all these issues do differ on iOS and Android.
Regarding possibilities that you listed.
Qt/QML is ok only in case two requirements are met:
1.1 Your application is a foregroud application without any background operations.
1.2 You purchase a commercial Qt license because only commercial Qt can be submitted to Apple iTunes app store (even GPL apps are under
question).
Using NDK Native Activities on Android with cross-platform C/C++ backend. Android NDK API offers much less API then Android Java SDK, so a lot of things you will have to implement or wrap manually. It is a hard road.
Mixing Java code and C/C++ using JNI gives you more of Android SDK API. But you should remember that an Android activity's life cycle is not somewhat that you're used to deal with when developing on C/C++.
Approach that we are using
We've been developing an application with a huge amount of cross platform functionality that should work on Windows/Linux/Mac OSx/Android/iOS. We're using the approach as follows.
Cross-platform core is written in pure C++.
We have adaptors to GUI interface for each platform.
On desktop we use Qt as it reaches all desktop platforms with minor adapting to each platform.
On iOS the GUI is built using iOS SDK with Objective-C and C++ core is linked as a Framework. Still, we had to patch our core in some way for iOS background requirements and so.
On Android we wrap our C++ core in a background process and build all the GUI using only Android Java SDK. Foreground GUI activities interact with the core via local sockets, so we don't need to bother with activities life cycling in our C++ core. But the adaptor is a litle bit complicated.
Nevertheless, both mobile platforms often require workarounds and adaptations in C++ core which add a number of #ifdef'ed branches in code for each platform.
I've been searching solutions for my enterprise apps, at least 3 platforms need to be supported, which are iOS, Android and Window Phone. After a whole day's search, I finally set my eyes on 2 promising cross platform solutions, one is monocross and the other phonegap.
monocross seems to use c# and .net at all, is it possible to access native libraries and languages? I read somewhere it's compiled directly into binaries that can execute on target platforms.
And about phonegap, it uses webviews on each platform to provide the capabilities of presenting user interfaces to final users. As it's implemented via interpreted language and high level apis, the performance may not meet our needs.
Finally, we(my team) decide to give it a try with mono, the architecture is illustrated as bellow:
+++++++++++++++++++++representation layer++++++++++++++++++++++++++
[monotouch,monodroid,silverlight]or [native gui calls] or [html5/js/css]
+++++++++++++representation controller/business logic layer+++++++++++++++
[ mono/c# ]
++++++++++++++++++++++++++++server side+++++++++++++++++++++++++++
[ the cloud ]
I want to use mono/c# to write some common purpose business logic and data structures, and when it comes to some common platform features, like storage service, notifications, I'd like to wrap them up on each platform and expose uniform apis for c#(business logic layer) to use. As to the representation layer, we decide to choose from the 3 optional solutions listed above.
To make this happening, first I have to figure out if it is possible to call native frameworks.
So, my questions are:
1, How does mono work, I mean, are the c# codes compiled into binaries that can be executed directly on iOS, Android and Windows Phone?
2, Is there a mechanism to make native invocations? Like in cocos2d-x, I can call java methods via JNI, and in iOS, c++ can call oc directly. Can I call cocoa touch stuffs in mono with c#?
3, Is it possible to manage all these stuffs in one single project, and how to build them?
4, Are there any better solutions?
Any suggestions will be appreciated, thanks for your patience!
I wonder why Xamarin does not land on the first page of your search result,
http://xamarin.com/features
But that's what the Mono guys created for the C# developers that want to target mobile platforms. MonoTouch and Mono for Android are there each featuring a common library base with Microsoft .NET, and also platform specific bindings.
Your non-UI code should be able to be used in portable libraries and share among them. Microsoft's portable library is Windows specific, and right now I am not sure how much Mono guys can embrace that, but even if PCL fails, you can create multiple platform specific projects based on the same copy of source files (which I did in #SNMP). The remaining task is to develop platform specific UI for Windows Phone, iOS, and Android.
There are tons of articles showing the features,
http://docs.xamarin.com/
and also many successful apps
http://xamarin.com/apps
The best way to learn a product is to try it out (for free in Xamarin's case). This also applies to MonoCross (which is a framework built upon Mono).
I am not familiar with PhoneGap, so you need someone's advice on that.
Disclaimer: this is not a complete answer - but I do hope it answers at least part of your question
I encountered a similar problem when I started cross-platform dev using the Mono products 18 months ago.
The approach I've built since is called MvvmCross - it forked off of MonoCross a long time ago - now shares no code with it (but maybe we'll team up again one day!).
The approach uses PCLs to share code. This is not entirely painless, but is easy after you've done a few setup steps - http://slodge.blogspot.co.uk/2012/12/cross-platform-winrt-monodroid.html
You can learn more about this approach on this video: http://slodge.blogspot.co.uk/2012/12/mvvmcross-video-presentation-xaminar.html
We have a program that we wish to deploy across multiple devices.
Standalone Captive AIR
Web based flash app
iOS app
Android app
The code other than some UI stuff is identical in a lot of parts. I'm wondering what's the best approach. Should we have a shared library project or should we have one big project with different complier settings controlled through ant or some other method.
Accessing and using Shared Library Project is the best way to be implemented for cross platform Projects. Other than this Approach you can use ant Build.
The answer would ordinarily have a lot to do with the "UI stuff" that's different, but since it sounds like you're Flash/AIR, that's probably not a big concern. If it were me, I would go w/ the "one big project" approach, and get a serious CI/NI and SCM suite that was compatible w/ my IDE. If you're using Eclipse/Aptana, I like Husdon/Surround. (Full disclosure: I used to work # Seapine.) If you're not using Eclipse, you should check out the CI/SCM options that integrate w/ your IDE (and themselves; e.g., Hudson has a Surround module and vice versa). The shared library thing works, but since Flash is Flash darn near everywhere, I don't see the need for the increased division of separate projects. A full-featured CI can manage the compiler differences for you quite effectively.
We're using this combination of approaches for a large scale mobile/web project that currently exists in the IOS AppStore, and will soon be released on Android and the web:
One main project that uses compiler directives to handle specific platform logic and elements
Compiler directives to handle specific platform logic within the main project codebase
A separate project for our video and interactivity engine, which is mostly platform independent, using switch statements for platform specific logic
One shared SWC for graphical assets. Platform specific elements are prefixed with the platform and an underscore. Compiler directives are used to specify which movieclips get displayed on screen
Ant scripts to do the compiling for the various platforms
Native Extensions to interface with hardware specific features
We use some commercial, some open source, and some homemade ANE's for things like AppStore integration, social media features, network monitoring, notifications and inter-app communications.
com.adobe.extension.NetworkInfo.ane
com.milkmangames.extensions.EasyPush.ane
com.milkmangames.extensions.GoViral.ane
com.milkmangames.extensions.StoreKit.ane
(I have no affiliation with milkmangames)
I'm currently writing an Android ANE to handle inter-app communication using Intents. It's a project I'm open sourcing at:
https://github.com/interactivenyc/ANESampleProject.
I'm currently stuck on a problem there and will be posting a question very soon with the details if anyone is interested in following that project. The project setup is fairly well described in the ReadMe file displayed on the front page of the project.
If you use git for versioning take a look at submodules. I used it to keep everything in one project, but versioning each module separately, and it resulted a fine solution.
I've been hired to develop a mobile framework for a webservice created by my employer. Ideally management would like to have some reusable components that can be shared across mobile platforms (initially iOS & Android, probably Windows Phone 7 at some later point).
I've been wondering how feasible this is. One of the requirements is a native interface, so we would use Cocoa Touch on iOS & whatever (Java-based) toolset is used to create a native UI for Android. The application will interact with webservices, mainly the ones that we've been creating internally. The webservices have been developed in .NET.
As far as reusable components go, I guess we could use some C++ code to make webservice calls and perhaps even more of the backend of an application, yet I wonder if this would be a good approach. Apple's Foundation Framework has some excellent capabilities build-in to access webservices, not to mention other open-source libraries, e.g. ASIHttpRequest, SBJSON, etc... I guess the same would be true for Android (though I have no real Android experience for now). Also, when looking at projects done by companies like Google, Twitter & Facebook, each of these companies offers native libraries built for the major mobile OS platforms. If the big companies take this approach, it seems logical for us to follow suit.
Perhaps we should focus more on a general architecture that we should offer across platforms instead of an implementation that can be shared.
Would anyone advise us to make use of C/C++ to develop such a framework (shared library) for the mobile site of our webservices? If so, why?
It really depends on what level of customized code you want to have. I worked at a game company previously, and we made two games for both iPhone and Android, and at least 90% of the codebase was shared between the two platforms in c++ code. Sometimes it is significantly easier to implement elements with specialized third-party libraries, like for Facebook and the like, but maintaining that code means continually doing it for both platforms. That was one of the reasons why we even implemented our own UI objects in c++ for our games. Because even though the initial setup would have been easier to do with Interface Builder and Android's XMLs, the maintenance and tweaking necessary ended up being significantly less because we went with a shared codebase.
In short, I would highly recommend writing any shared customized code in C/C++, and things that are significantly easier in their native codebases (java for android, or obj-c for iphone) and you don't expect to change much, to keep separate.
Depending on which WS protocol you use it may be more or less hard to do, but anyway I see little advantage in doing that in C/C++ for a mobile platform.
If you were using SOAP, I'd never consider C/C++, even for a desktop app. I already used SOAP libraries for C++ and they are a lot harder to use than their Java/.net counterparts, and the way they are implemented (mapping SOAP objects to C structs) is very prone to crashes if the format changes. Not to mention that you have to recompile your client when the WSDL changes.
As I understood in your case you plan to use REST. I never found a good REST library for C/C++, but recently I did a desktop project in which I implemented a C++ REST client using simply WinHTTP (in Windows) and libCURL (in Linux). Of course, they provide just the HTTP part, so I had to add cppdom for XML parsing. If you use JSON, there are many good libs like jsoncpp, libjson.
I'd say to you that even in a desktop environment it was harder to do than would be in .net or java, and was only done this way because it was part of a larger application already written in C/C++.
Anyway, you'll have more work and not much advantage since all those modern mobile platforms provide rich libraries that do the same thing, and probably the user of your API will develop in the platform's main language, so you'll have the double extra work of implementing the WS access code AND the binding code. As I assume all (or at least most) of your logic is in your server, not the client, there's not much common code between the platforms to justify using C/C++.
Is there a way to develop classes for Android and BlackBerry ? In this I mean that BlackBerry and Android have different collections.
So I would like to know what is the best way to develop such files (reflection, different files, ...)
Your best bet is to write to a common interface, so that your higher-level code can be consistent, and the parts that will be different, will be abstracted into their own libraries. This way you can write applications that use a common codebase, though most of the work will take place in your libraries, as that is where you connect to the platform.
This way you can try to minimize redundant work, but take advantage of each platform more completely.
If you limit yourself to what each can do then you are shortchanging your users as there are a great deal you will not be able to do, or do well.
We have common code for Android and BlackBerry. You know that BlackBerry is J2ME based so its Java 1.3 compatible, and Android is Java 1.6 I think. This places significant limitations. I will list what I remember below.
All common modules you code has to be Java
1.3 compatible if you want it to work on both platforms. This means
no collections framework, no
reflection, primitive string
handling/localization with strings
in class files etc.
It will be very hard to have ALL code that is works on both platforms. So it is better to have some common packages, then BlackBerry and Android packages that work on those platforms.
Nightly build system is really helpful as it will catch errors that break one platform build, caused by changes for the other platform.