I have a WPF application and I want to have it on android systems. Is there any possible way to run beautiful rich graphical WPF applications on android? I heard about mvvmcross but I have no idea of possibility. I need to be sure to make any effort on this
"Is there any possible way to run beautiful rich graphical WPF applications on android"
Basically: no, because WPF need the .NET framework.
What you can do is, if your WPF application is design in MVVM, to keep the Model and ViewModel code, and redesign the View Code to be compatible with Mono or any Framework running on Android.
This is for example what allow Xamarin. It will easily Build your .NET code for Android or IOS as long as it is MVVM.
MvvmCross is a bit different, as it is built on top of other frameworks (including WPF and Mono for Android). In other words: you will have only one codebase for the différents platforms, but this code is not in WPF, it is in MVVMCross :)
Anyway, it will be possible only if your code is MVVM. Otherwise it will probably be faster to code it again on Android depending on the application.
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 am a ios developer , We have a requirement where we have to develop an app (with Maps,GPS tracking,Charts) in both ios and android, We are planning to use Xamarin cross platform to develop so that we can write common business logic for both the projects,
As per my research its not recommended to use xamarin.forms for the apps which needs more platforms specific functionalities like Maps,GPS tracking,Charts
by my research I found Xamrin.ios and xamarin.android are best approach to implement more platform specific functionalities
My question is , Xamarin.ios and xamarin.android are they 2 seperate projects? could I able to share business logic between those? As per my understanding in xamarin.ios and xamrin.android we will be calling our native ios/android APIs and frameworks hence we cant share the code , am I right?
Can we share code in xamarin (Xamarin.ios/xamarin.android) if we dont use Xamarin.forms?
Wat are the benefits we will get if we use xamarin.ios/xamrin.android instead of Native development with obj c / Java ?
You can have a Xamarin.android and Xamarin.iOS project in a single solution and have code sharing with a common business logic using MVVM design pattern , PCL (Portable Class Libraries) and linked source files. For the case of platform specific code in a shared code , inversion of control can be used
You try to squeeze as much as common code behind as possible , so you will only have to implement the GUI twice (Android and iOS)
We are developing an app in our organization where we have to implement charts,maps,GPS, If we Develop in Xamarin.ios/xamrin.android can developers able to share business logic of the app? since both android/ios projects will be in c#.
I'm doing exactly the same thing.
Do not use Xamarin Forms. It is not designed for nor capable of doing heavily customised UIs.
If you are going to require integration with Maps and also producing any kind of non-standard rendering or "User Controls" Xamarin.Forms is not going to work for you.
Go down the route of using a framework like MvvmCross to further abstract away the platforms and keep your core code / logic and user experience flow within the realms of a Core.Pcl type library.
Also I wouldn't try doing this on Windows 7 based bachines if you are doing this on Windows. Most of the components you will find yourself wanting to use will be targetting Profile259 and since Windows 7 doesn't support Windows Phone 8 you'll have all manner of oddities, even if you do the Profile259 hack.
Go with MvvmCross, Windows 8 and ignore Xamarin Forms.
I wrote a bit of it up on my blog.
Read this from Xmarin, they clearly state that Forms is for run of the mill business apps or for prototyping. It's not mature enough yet.
Yes, you can write your core app logic (services, data, domain, etc) in a PCL library that is shared by both your Android and iOS apps.
From my experience, you can build most apps in Xamarin Forms. The main hurdle is that doing anything not included in X.Forms requires that you write Custom Renderers. The thing is, writing custom renderers is much more straightforward if you have a solid grasp of vanilla Xamarin (Xamarin.iOS & Xamarin.Android).
What I think happens is that developers getting into Xamarin go directly to Xamarin.Forms and then become frustrated when they are unable to write custom renderers to accomplish some custom requirements.
So my recommendation is that if you have experience building apps using Xamarin.iOS and Xamarin.Android, Xamarin.Forms is awesome for getting an application developed rapidly for multiple platforms. Being able to use MVVM + XAML + Data Binding is a huge win.
If you are new to Xamarin or even mobile development, build the app using Xamarin.iOS and Xamarin.Android.
We are starting the development of an Android and IPhone app and wanted to know if the best practice on developing the UI for both environments.
We have developed the core (functionality) for both the environments as common classes. The core does not have dependency on the UI at all.
Is the best practice to have separate UI code for IPhone and Android or should they be combined together and where required conditionally written?
I would like to understand this as you may have come across situations like this.
Appcelerator has two recommended methods for creating cross-platform UIs - branching and platform-specific commonJS.
In my experience the use of platform-specific commonJS has been the easiest to maintain, although it does require a little extra work up front.
The section on supporting multiple platforms in a single code base in the Titanium 2.0 documentation goes into greater detail on this subject and should be helpful in choosing the path that's right for you.
A good example of creating cross platform UIs is the community app created by Appcelerator's Titans program.
I know C# rather well and just love Visual Studio as IDE. :) Yet now I want to start developing for android...
I found out about MonoDroid and wanted to ask if it has any downsides to it that would make Java more preferable, or should I uninstall Eclipse and dive straight into MonoDroid?
If I understand right, MonoDroid deploys/compiles native android applications and does not need any additional .net-like framework or anything?
Are there any significant limitations to what I can do with MonoDroid? For example, having the app run in the background or using some external .net libraries for image editing, etc. ?
I've been worrying about the same thing - productivity in C# instead of playing with an unfamiliar language, vs developing how the OS developers intended it to be.
Its easy to list pros vs cons -
pros (of monodroid, for C# developers)
familiar dev environment, can develop using Visual Studio
C# instead of Java
Reusable code assets - you can use a lot of code in your iphone project or Windows phone 7 project using monotouch and the WP7 SDK.
cons -
debugging could be difficult, due to lack of api documentation from Google. Will have to depend solely on monodroid documentation.
there could be a lag when it comes to latest cutting edge features - safe to assume that the monodroid team will require some time to wrap around the latest android features every time there is a new OS release
availability of libraries - I am not sure how you can use the open source libraries that would have evolved around the android platform, that could cut down on development time
Much of the documentation available is in Java: so if you run into difficulties with phone behavior when using MonoDroid you won't really find that much help or debugging information so you may want to stick with Eclipse.
There's a lot more than just a set of wrappers running under davlick, truth to be told, there is much more of a horizontal relationship between MonoDroid and Android;
When did using the same language as the OS developers become a big issue? There's lots of C++ programmers wondering how to use BSD or SVR5 and many C programmers who want to know what the heck to do on Windows++...
If you will write in c# anyway you will be have to wrap it into a Java code, so what's the point ? Also you may head with a very difficult issues while trying to understand the APIs who written for Java programming...
Here are some points that you can mull over:
Android applications are predominately written with Java. The Android SDK itself is natively written in Java.
Working in Mono may not provide all the functionality available in the Java SDK.
If you are a C# Developer you wont be able to find, in Java, some of the (cool) features available in C# (like Property Delegates etc).
Code written in .NET can be re-used for other environments - this may save a lot time that would have been spent learning a new language/environment (like Objective C), and coding in it.
.NET extends the Android development stack with it's existing libraries and API's.
I think both are good for certain reason. It will be very hard to say which one is preferable for Android development - in the end that is up to you too decide.
Also note that any release build using monodroid adds an additional 4mb to the apk filesize and increases app startup time with a few seconds.
For simple apps this can mean a 500-800% increase in filesize - whic is pretty bad in my book.