I currently have a native Android AND iOS library that contains different "modules" composed of models (the smallest part), views and controllers (the biggest part).
I would like to start writing apps using xamarin without losing all the work I did on this library. But it seems like if the native library binding is more suited for utilities libraries, or libraries that only contains 1 part of the MVC components, not the 3 which are depending from each other.
So after reading the Xamarin documentation about cross platform development and native library binding, I think that I should rewrite all the model part of my library using a Xamarin C# library, I would drop Core Data on iOS, and ORM Lite on Android, and instead I would use the SQLite library provided. This job does not sounds to big, so it is not a problem (and on long term it will reduce the maintenance effort). But now comes the problem/question, when my models will be C# classes, how will I be able to use these models in my controllers which are still written using Obj-C and Java ? Can I obtain header files from the C# models classes that I can import in the iOS / Android code ? Or do I also need to rewrite the controllers using C# (that would be a no-go to using Xamarin for me) ?
I am open to any migration suggestion/strategy that would avoid losing multiple months of work, so feel free to answer if you have one :)
I currently have a native Android AND iOS library that contains different "modules" composed of models (the smallest part), views and controllers (the biggest part).
That probably means you have currently two libraries, one for iOS and one for Android. One written in Objective-C and one in Java.
I would like to start writing apps using xamarin without losing all the work I did on this library. But it seems like if the native library binding is more suited for utilities libraries, or libraries that only contains 1 part of the MVC components, not the 3 which are depending from each other.
What makes you think this? You can bind whatever you want to bind. And you don't need to bind everything to start with. If for now you only want to bind some parts from your native library that deals with UI, then skip the rest. You can add bindings later.
I think that I should rewrite all the model part of my library using a Xamarin C# library, I would drop Core Data on iOS, and ORM Lite on Android, and instead I would use the SQLite library provided.
That is a valid approach. However then you will not be able to continue using your native code. There is no way to talk from ObjC to C#. Only vice versa. Even if it was possible: you would have to change your controllers to talk to SQLite.Net instead CoreData, or add an abstraction layer, which in turns you will have to bind and implement on the C# side of things. All of this is probably more work than sticking with the native versions or rewriting everything in C#.
Can I obtain header files from the C# models classes that I can import in the iOS / Android code ?
No, you cannot.
Or do I also need to rewrite the controllers using C# (that would be a no-go to using Xamarin for me) ?
You have the choice:
stick with what you have and live with the limitations of maintaining two libraries (and two application code bases)
Bind the libraries and create a managed abstraction around them. Then use this abstraction from a PCL and reference that PCL from your Xamarin C# and Android application. Live with this solution, until you're unhappy enough from maintaining two code bases, and then:
Rewrite your native code and switch to Xamarin and have one code base.
Maybe one more note on bindings: bindings are not meant to exchange part of the native functionality. They transport native functionality into the managed world. They do not enable you to pick the best of both worlds and then create one jack of all trades solution.
You end up with the same result as you would if you stayed in the native world: think what you would have to do if you wanted to change from CoreData on iOS to a Json based storage for instance? You will have to touch all of your controllers unless you prepared everything to support abstraction of the data layer.
Related
Are there any advancements in this area? I want to be able to write purely functional code on Android in Haskell or similar languages. I've tried some examples with Scala but it seems to be a pain to get started. Are there any other functional JVM languages which I can use to write Android applications?
Edit: functional languages that write native android applications. My mistake about the JVM.
I doubt that you can find anything mature for writing Haskell-like code for Android. You do need to implement Java abstractions which are required by Android API (implement activity, etc.).
But if you really want to write for Android in a purely functional style you can try to implement your business logic in a pure functional language that compiles to JVM and call it from your Java classes. That approach would be much simpler than trying to implement it entirely in pure functional style.
As your language choice, you can try
Frege, it even has a library for android - froid
Eta lang, it is very new and probably nobody has tried to use it for Android yet
I you want a painless solution in terms of Gradle builds etc., you have only two options: Java and Kotlin, of which of course you should choose Kotlin ;)
Kotlin has most of the things you need to write in functional style:
functions as first class citizen
higher-order functions
immutable collections
var and val like in Scala
if-else as a statement
elements of pattern matching (where statement)
tail recursion
and more...
If you also include funKTionale and kotlinx.collections.immutable, you'll have all the functional goodies like: Option, Try, currying, memoization, persistent data structures and so on...
To start with Kotlin just install the latest Android Studio 3 Preview, which already has built-in Kotlin support.
BTW, don't be so polarized into "pure" functional ;) After all, being 100% "pure" means no side-effects, which means your app can't interact with the user ;)
Hope this helps :)
I've never tried it personally, but you can do F# programming using Xamarin.Android (and, I believe, with Xamarin Forms too). You can see the guide here. (It also includes sample code).
As some background, F# is the .NET Framework's functional language. It is derived from ML; in fact, many ML scripts can be compiled almost "directly" as F# (with the caveat that you may have to do some renaming because F# has some additional keywords that ML doesn't have in order to support several .NET-specific extensions).
Xamarin allows for native development for Android, iOS, and Windows phone. Xamarin Forms allows for a single code-base for all three platforms (it's a competitor to Ionic).
One more quick point: Android does not use the JVM, even if you're writing apps in Java. (In fact, Android does not even support all Java 8 features yet). Through Android 4.4 it used Dalvik; after that, it started using Android Runtime.
You could also try using a JVM language like Scala to create a JAR file and create a bindings library for it.
Please also note that you'll end up using at least somewhat of a mixed paradigm - for example, things like Activities are objects, and the XML files used to define an Android screen is, for all practical purposes, declarative. Edit: This last point is slightly debatable - see the comments.
One final possibility: I haven't checked this out too closely, but try also this link for a site claiming you can do Scala in Android.
Between Pure functional and Java, there is a way which is IMO Pragmatic functional. For instance Redux achieves that in the React arena.
My goal is to write an app (Activity) having an immutable state that advanced as a result of interactions is functional.
In the browser you can see that done with elm (Haskel like language which is also web platform)
Since we want an Android app, I opened the Android Studio used the wizard to create and app with Navigaton Drawer Action bar (with Drawer, FloatingActionBar),
Then converted it to use Elm concepts of immutable model functional approach into a working POC based on a small ElmBase class and idioms.
The code is written in Kotlin (JetBrains tool of choice for the JVM).
You can find the app at my GitHub https://github.com/saffih/ElmDroid The sweet spot of that approach is that it leverages Kotlin being strongly typed and the editor does code completions very well,
making lot's of the code completed for me in a way I have never seen before - amazing experience (But it require using idioms like the sealed class and when properly).
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'm using the libraries LIBGDX to make an application and be able to run on both Android as a computer. I'd like to introduce a new library to create graphs in android, but do not know if I can add libraries that are for use with Android and libgdx and also running on the computer.
Nor if you can work in a similar way to how you normally program in android, and I want to do the designs from the GUI of android that I'm used to and I find it more comfortable. Also when the xml type strings.xml for example, I wonder if I can use them or not. Thank you.
There are two ways to build libraries (really, any code at all) that runs with libGDX:
Use only the libGDX-provided APIs. For example, if you render your graphs with the OpenGL wrapper provided by libGDX, it will work everywhere. Or if you use the "scene2d" UI APIs, it will work everywhere.
Implement a generic front-end library that uses libGDX APIs, and then calls out to backend-specific libraries that implement platform-specific bits. For your example, that would entail building an Android-based backend that perhaps used Android-specific UI rendering, and then building a separate desktop-based backend that perhaps used Swing or some other Java-desktop-specific APIs.
If all of your code is using the second approach, you're not really getting much benefit from libGDX.
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.
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++.