So, one of the main features of coding using the native SDK provided by Android and iOS is the fact that you get not only a better performance, but also the look and feel of each platform: for example, on iOS, a tab-navigation bar would be located at the bottom of the screen, while in Android it is located at the top (yeah I know it also can be top and bottom, but you get my point), or also the Navigation Drawer dock is an Android navigation style while (as far as I know) there is nothing similar in iOS native sdk. My point being, you can feel the difference of platforms by their design guidelines which is a good thing, since it makes your app looks professional.
So taking that into account, in terms of performance and maintaining the feeling of your app, using JS-based frameworks like Titanium or PhoneGap will not make a wise choice.
Then comes Xamarin. As I read in here: Xamarin how it is getting the Native Look and Feel? it seems it is a C# wrapper for native SDK, which as far as I understand, it should not affect performance. But where's the look and feel part. Since XML layouts are not entirely what gives Android or iOS apps their feel, but also the navigation (which comes from the controller classes) how does Xamarin deals with these? It is said in their website that you can share code between platform, but will that also means I have to share navigation system and similar?
Finally, for the sake of "not writing code for each platform" , is it worth NOT to use native SDK and go with Xamarin (I don't really have a problem writing code for both iOS and Android), or is this framework target for C# developers so they won't have to learn Objective-C or Android.
Any extra explanation would be awesome, and thanks in advance.
I built a large application within the last year (2013) with different components: mainly an API (ASP.NET Web API => C#), a Website (ASP.NET MVC => C# + AngularJS), and both an app for Android (Xamarin.Android => C#) and iOS (Xamarin.iOS => C#). The decision to use Xamarin had its advantages and its disadvantages, but all in all I am more than happy with it.
As you can see in my list above, almost everything was done with C# (okay, the Website is mainly written in JavaScript ;-)). It's a wonderful mature language with really nice features (as LINQ). In my scenario it becomes clear: I did not have to learn and to perfect four languages (Swift/Objective-C, Java, C#, JavaScript) but only two: C# and JavaScript.
That comes especially into play regarding the code sharing aspect: our client applications aren't really thin clients because of some offline functionality which requires a lot of synchronization logic, so the UI part of the two apps is only one side of the medal. As it turned out, I could really use 90% of that non-interface code on both iOS and Android. This is an incredibly huge benefit, as it's not only about some language originalities of Swift/Objective-C or Java, but also about the different frameworks you are using on iOS and Android. To use the .NET Framework/Mono as foundation of every Xamarin app enables you to abstract things like data access or network communication from the underlaying OS.
In terms of speed and UI you don't have any disadvantages, because you're using the native APIs 1:1. Whatever is available on iOS or Android is also available through Xamarin. And whenever Apple for example ships a new version of iOS, Xamarin will ship the update for that within a few days, so you don't have to wait to be able to use newly introduced features by Apple.
Xamarin uses a technique called Ahead of Time Compiling on iOS, so everything you write in C# is compiled into the native iOS stuff before it is deployed to your device. That means there is no difference in what is executed between a "native" Objectice-C application and a Xamarin application (except some small overhead which isn't noteworthy from my experiences).
On Android Just in Time compilation is used as just with any other "native" Android app, too.
That all means you have all the exact same APIs and possibilities you would otherwise have, if you would go with Objective-C or Java. You even use the same objects for building your UI with the exact same types and names (sometimes slightly optimized ;)). So if you want a tab bar navigation for your app - you use a UITabBarController for that. See iOS vs. Xamarin.
After multiple years on my way with Xamarin I only one disadvantage:
Possible memory leaks. Their whole samples out there are a bunch of crap regarding essential basics of preventing memory leaks. If you are working with "expensive resources" like media files within your application, you should take care from day one. I had to get rid of all that problems when an app of mine had already been growing to up to 35 different (complex) dialogs. That took me almost two months or in other words thousands of bucks. They provide some documentation about it, but the tooling is poor at this end. And errors are likely to appear and very hard to be found (example).
But all in all it was one of my best decisions to go with Xamarin.
I have been coding with Xamarin for a while now. Its been great so far. Any problems I've had I figured it out because c# is my native language. The Xamarin site has many examples and API references for many features on all platforms.
Performance - You get native performance from using Xamarin. No questions asked. I have been using it to create audio, video and photo recording features for a new app i'm working on. Xamarin processes the c# code into native byte code for all platforms. Thats how this is achieved.
Look - The look of your app will be native. You literally have to use the Android xml format to make your user interface and the same Goes for IOS. You will still style your elements the same way you did on each platform. All Xamarin does is link a view to an event for you.
Api - The beauty of Xamarin is in the API. They ported the whole Android and IOS namespace to c#. Take a look at their Documentation.
Expensive - My only problem with Xamarin is that it is expensive. If you check their pricing it is outrageous. But you get what you pay for. A premium product that is backed by support.
C# - Sharp is a great language that has loads of support. The new async/await gets ride of the whole thread management issue. Json processing is super easy on the platform. I have uploaded several classes on Github that can be used for many apps.
If you are from a java background, brushing up on your c# skills will be a breeze.
The rdio app was created with Xamarin. Download it on Android and IOS and test its performance and enjoy its native look.
Best of Luck
There is much much more internet content, help, and support for native. That alone helps me make my choice. If you are really good at Xamerin, maybe 70% of the code you write will be usable by both apps, you still have to custom tailor things for each app.
But again, the support for native is so vast, that if you run into a proble, so has someone else.
With xamerin, well, good luck.
When I say app I mean iOS/Android
Related
This may or may not be a very straightforward question. I've very recently decided to create a number of applications with the android platform in mind, and as such installed Dot42, since C# is the language I'm most proficient in.
I noticed that Visual Studio cannot browse to the definitions for Dot42 or for the dot42 Android sdk. This pretty much means that I can make buttons and do calculations, but cannot do things as complicated as making sounds, playing media, streaming... you get the picture.
Is there a comprehensive definition standard for Android SDK? In particular I'm looking for methods to access components, most of all the media output handle.
If this is the type of question that is frowned upon, I do apologise. Let me know and I'll get rid.
The entire Android API is available. See:
http://docs.dot42.com/Reference/Index
I want to make a project for the summer where I want to create an Android app. Now my question is for those who have used Xamarin before to create Android apps:
Is it better to create Android apps with Java than in C# with Xamarin?
Are there any restrictions with usin Xamarin for Android app development?
I.e. are there some things that I can do in Java but not in Xamarin?
And last, what do you think about Xamarin for a pretty new programmer?
You specifically asked to:
create an android app
If that is your only requirement, and you have no previous experience in C# development, you should stick to developing the application using JAVA and Android SDKs. After all, it is free of charge.
However,
Why do you want to limit yourself to Android platforms?
If there is a chance that you might want to expand to other platforms in the future, you should IMHO start preparing for it right now, and create a cross-platform application.
C# is a powerful language, Xamarin products are mature and of high quality and Xamarin community is big enough for wide support.
There are no restrictions that I know of, and everything that you can do with native Java you can also achieve with Xamarin.Android. Also, in case you will ever find any restriction, you can always include Native Java Code inside your application.
The only thing to mind is the price, which is probably high for a beginner developer.
An additional feature which is in C# but is omitted in Java is LINQ which gives significant assistance to data handing and sorting.
The main factor to consider is as Liel has already said your preference of programming Language, Java or C#, go with which you are more comfortable with. The only hesitation which I would mention when referring someone to Xamarin as opposed to Java is that their is significantly tutorials out their.
This in my view though should become less of an issue in time. The main source which I use when I am learning is AppDev and Pluralsight Training DVDs and have found them to be essential in learning.
It is possible to simply refer to Java sources the only manipulation sometimes needed is to capitalize the first character setContentView() => SetContentView() in C#, and then using Intelisence to find the correct syntax Resource instead of R in Java.
Good luck with whatever you choose,
James
I'm pretty excitet about all the new stuff coming up in Windows 8, but at the same time a bit worried about how and if I can continue use the code and custom components I have already built up using .NET and C# during my time as a Windows dev. I've got some general mixed questions about this. Hope you don't mind I'm putting them together in one post:
Will Windows 8 Store be for both metro-style apps and regular WPF-desktop apps? Including pushing updates and making apps available for company employees?
Will the new App Contract-thingy also be available for WPF-apps? And is AppContract based on WCF-services with perhaps UDP-discovery on the network? Can I make my own contracts between my own apps using the App Contract framework?
I'm not particularly worried about if WPF will be ditched or not. I can live without it. The thing that worries me is if I still can write presentation and business-layer code in C# and use it as a backend for my apps, no matter what UI-framework I'll be using, HTML, Silverlight, WPF or what have you. If I'm still able to write logic in C# and present it using X UI-framework, I'm a happy developer. I've heard I can access the .NET-framework from JavaScript. But what about custom assemblies?
It has been announced that non-Metro apps can appear in the store but the store will just link to the publisher's website - not actually manage the sale/install/DRM/etc stuff.
What's been announced so far is that the contracts are only for Metro apps but I'd be shocked if this doesn't change. It would be crazy for Microsoft not to allow desktop apps to, for example, add commands to the Settings charm, support PlayTo or printing through the Devices charm, or act as Share sources. We'll have to wait and see where they draw the line on what desktop apps can/can't do.
Sharing code between Metro and non-Metro apps is going to be very difficult. A lot of the core concepts and conventions are the same but even basic stuff like file I/O rely on a totally new API. There aren't a ton of interesting things you can do with in code that will work on both sides of the fence. Best bet would be to define interfaces for your business layer stuff and then use dependecy injection to dynamically select desktop vs. winrt implementations at runtime
Store: there is no final information but as far as I understood it, it's for metro style applications only
The app contracts are a metro thing. I know a code snippet that documents usage from desktop apps (eg http://www.heise.de/developer/artikel/WinRT-in-klassischen-NET-Anwendungen-nutzen-1366039.html (sorry, German)), but I do not know if it will have support from Microsoft
WinRT compiles libraries to WinRT components. You might be able to reuse code and compile them to a component as long as you're not using a namespace that isn't available for WinRT
This question is heavy on guessing as there is no official beta available. And even then we can't be absolutely sure...
I'm already a Junior asp.net/c# developer and I know that java is pretty similar to C#.
I've considered using two methods:
the Java toolkit (which is the native language of the BB's OS so I
thought it would be more powerful)
the Visual studio (asp.net) toolkit (which is the language and the
platform I already know and practiced
before)
so which one of those are the best approach?
what are the advantages/disadvantages for every approach?
do you suggest other solutions for developing a blackberry version of my asp.net website?
I'm facing the same choice, and from what I see, it doesn't matter. You're developing web pages with additional API's interfaces that allow the WebKit browser to take advantage of the Blackberry API's.
It doesn't look like WebWorks applications run either Java OR .NET code. Instead, WebWorks apps are made up of HTML, css, and javascript.
However, if you're planning on doing standard Blackberry apps, you'll want to go with Java. This will also help to prepare you for developing on the Android platform. Java isn't going away any time soon, and with the rise in popularity of the Android platform, I think that the demand for Java development is going to be on the rise, compared to .NET. (I say this as someone who LOVES .NET and does NOT want to re-learn Java, but is doing so to ensure that I'll be able to compete in the job market.)
Greeting,
I'm a C# programmer guy. I'm planning to start developing app for iphone but I'm not sure if I should use C# under MonoTouch or just use the native language for iphone OS Objective C.
Is there a different to program for iphone app using C# or Objective C?
Is there limitation using C# to program app for iphone or it can do as much as Objective C can do to develop iphone app?
MonoTouch wraps most but not all of the iPhone SDK. So, yes there are things you can't do (yet), but they're relatively few and far between.
Many .Net folks find that they are more productive (at least initially) using MonoTouch, since they can leverage their existing skills. On the other hand, there's nothing like working in the native language of the land, it just takes a little longer. You will have to learn some Objective-C since most documentation out there in the world uses it (and/or C-level CoreFoundation APIs). Objective-C's dynamic nature will feel foreign at first, but you may find it quite liberating once you grok it fully. Having used many languages in my career, I find Objective-C (and the Cocoa APIs) one of the most pleasant development experiences out there.
Here's a Monotouch developer's answer rather than some guess work from people skim reading blogs.
Have you bought the Monotouch license? If not then clearly objective-C would be preferred. If you have bought a license then it makes sense to develop the app in Monotouch because:
The domain and business logic can easily be ported for a Windows Mobile 7 app later this year
The same is also the case for Monodroid which is coming soon, and the API could easily be ported to Java too.
Controllers, Views and the whole Monotouch system bar static void main can be very easily converted to objective-C. The names are all identical but in Pascal case.
As far as apps being accepted - so far Apple have let Monotouch apps through. I'm not saying they won't suddenly say "NO! THOU SHALL USE OBJECTIVE-C" but for them to ban an SO iPhone client on a high profile site like Stackoverflow would be bad PR.
Apple use apps in their demos which break their own SDK (Tap Tap Revolution being one), and 1 in 10 of the appstore best selling games use a health portion of none-objective-C.
Monotouch is a direct mapping to Cocoa and UIKit. You need to have a mac to use the compiler and IDE. As far as I'm aware Flash had no such restrictions and its UI was a lot less strict in terms of forcing the common "widget" set like UINavigationController, UITabViewController, UIAlertView and so on.
Here's my take: if you have absolutely never seen Obj-C code in your life, it'll take a bit of a time to get used to it. Put it together with the fact that the SDK is totally different and you'll have to learn every single new method, and it'll probably take at least a couple of months for you to become an average obj-c developer if you study hard.
Instead, use MonoTouch and learn the entire SDK using C#. In a couple weeks, you'll feel right at home with all the classes, Interface Builder, etc. You'll be able to develop the app in the same way you would with Obj-C, but in C#. The demo version allows you to use everything, for free.
THEN you decide what to do. Depending on how the whole issue with Apple goes, you may decide to just continue using MonoTouch, or you may decide to learn Obj-C, and basically use all the knowledge you have already gained about the SDK, which will make the transition much easier.
There is some debate over whether Apple will allow this. On the face of it, it seems not:
In the new version of the iPhone
Developer Program License Agreement
released by Apple today (and which
developers must agree to before
downloading the 4.0 SDK beta), section
3.3.1 now reads:
3.3.1 — Applications may only use Documented APIs in the manner
prescribed by Apple and must not use
or call any private APIs. Applications
must be originally written in
Objective-C, C, C++, or JavaScript as
executed by the iPhone OS WebKit
engine, and only code written in C,
C++, and Objective-C may compile and
directly link against the Documented
APIs (e.g., Applications that link to
Documented APIs through an
intermediary translation or
compatibility layer or tool are
prohibited).
From monotouch forums