Does anyone have experience with Xamarin trying to use allready existing .NET code? Especially Form.Elements - or do they have to be redesigned for java(Android)?
My second question is, whether it is possible to build an Xamarin-Library to use system.Forms elements?
No, you can't use Windows Forms code in Xamarin.
The idea of Xamarin is that it uses the UI framework which is native to the OS you're writing for - so that isn't portable - but you can share the business logic which will be common to all of your implementations.
So long as you have a clear delineation between UI and business logic, you can create a portable class library containing the business logic and share that very easily between any "normal" .NET environment and Xamarin.iOS / Xamarin.Android. (There may be other platform-specific parts too, such as local storage - again, it's a matter of isolating that and abstracting it where appropriate, so that your business logic may be able to say "Get me storage record X" and it will use whatever storage provider you've plugged in.)
Related
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 need to make a desktop app which is pretty complex and handles a particular
domain. The domain has entities at the back end. I want the UI of this desktop app to be portable
to different frameworks such as Java(Eclipse RCP Plugin) and .NET(Visual Studio Plugin). So
1.)can I write the domain layer using C++ and interface with Java using JNI for Java
2.)use same C++ layer as point 1.) for interfacing with .NET (C++/CLI) as plugin for VStudio
What are the architectural considerations, pitfalls, future issues one will face if one
relies on a portable C++ layer interfaced with higher level APIs like Java and C# for a rich
client desktop application
For example one of the issue I will face is that I cannot debug and step into Native code from Java.
Are there many such items?
Should I just rewrite my domain layer using .NET and Java for each type of environment rather than keeping it portable as C++ layer?
Why isn't such an approach adopted by the industry?
What are the practical issues one faces when one has a JNI layer in between the View and Domain Layer?
Interfacing with domain models in another language / on another platform is really painful and my main architectural advice would be to avoid going there.
If you want a portable desktop app, I think you are better off writing it end-to-end in Java (or perhaps another JVM language like Scala or Clojure if you are one of the people who thinks that Java itself is a bit old-fashioned).
Rationale:
You'll only need to write the GUI layer once as Java will give you access to all the environments you need. You can run Java desktop apps pretty much everywhere that has a JVM, without recompiling. You just need to take a little care to avoid hard-coding platform specific features (e.g obvious stuff like don't assume "\" as a file separator, you need to use the portable File/pathSeparator instead).
This avoids the complexities of having to do a lot of cross-language interfacing. This is inherently a hard problem, since the languages have different object format and method calling semantics.
Java has a great open source library ecosystem with respect to portable code.
You can make pretty decent portable UIs in Java for most purposes (using Swing or SWT), and this is probably better in the long run than developing a custom UI layer for each target platform.
If you are smart, you can architect the app so that the GUI interacts with the back end domain objects through a clean and simple API. If you do this, then it will be easier to add new GUI options in the future (for example a web-based front end).
Writing the app end-to-end in .Net is also clearly feasible and might even be a bit easier on the GUI side given how good Microsoft's GUI-building tools are, but has the big disadvantage that you're now effectively locked into Windows, so your portability and platform flexibility goes out of the window. In addition (though this will depend on your domain) I think the Java ecosystem has the overall edge in terms of library ecosystem and tool support (with things like Maven).
When you want a cross language data model, a common pattern is to use a DSL to describe the domain model and generate the code from that. e.g. proto buffers. That way you can have native C++, Java, C# etc code for a common domain model.
One of the pitfalls of using a C++ library from Java is it doesn't feel like a Java library. You have to do all sorts of unnatural things to use it and you end up adding a layer to make it more Java friendly. I imagine its the same for C#
For example one of the issue I will face is that I cannot debug and step into Native code from Java. Are there many such items?
Netbeans supports Java + Native code debugging and you can step into native code from Java and debug both.
Should I just rewrite my domain layer using .NET and Java for each type of environment rather than keeping it portable as C++ layer?
I would have said yes, but that is me. For you it could make sense to leave in C++. There are pluses and minuses both ways.
Why isn't such an approach adopted by the industry?
Developing in Java and C# (and other virtual machine languages) is often seen as more productive and easier to find people who can support it.
What are the practical issues one faces when one has a JNI layer in between the View and Domain Layer?
You have to mirror the domain model, as you cannot just import it. i.e. all the data model you expose needs to be translated. This requires creating Java versions of the exposed model and well as translation code. (Another good reason to have all of it generated)
Can you please provide me with some tips/guidelines when architecting, designing and implementing a .net framework application, with the requirements given below:
It will be an analytical tool which will retrieve data from files, sql databases and may be cubes. So data layer should be able to handle that. The middleware should be totally independent of the other layers so probably need an IoC container (which one would you recommend)
It will be deployed on the local intranet
The front layer might be WPF application or Silverlight in future (for now, I am concentrating on Silverlight but the point is that it will change)
It should be easy to customise and improve it in the future without changing much of the code as the framework will be deployed for many clients
I need a way to store the configuration information, which will be picked up by the application on application load events to set its feel and look.
I have two months to implement it and looking for as many tips as possible.
SoC for a start
break your application into several assemblies that use IoC (interfaces + implementations):
application model assembly - all other assemblies will reference this one because these classes will be used for inter-communication - they will mostly be just POCOs
presentation assembly - references app model and business services - this one is either WPF or Silverlight in any case use MVVM to make your testing life easier
business services assembly - references app model and data repositories assembly
data repositories - these define repositories that actually get data from the stores
Then I'd create three additional ones:
file data providers
database providers
cube providers
Data repositories would reference all three and use them to provide necessary data.
If configuration becomes very complex with a lot of functionality then you should put it in a separate assembly as well and reference it by business services assembly.
Which MVVM library to use
Since you mentioned time I suppose you'll have hard time catching your deadline. When using MVVM (which I suggested to use) I also suggest you don't use a full blown PRISM (a.k.a. Composite Application Guidance from P&P) but rather go with MVVM Light Toolkit. It will take you less time to get on the bandwagon.
Code generation
In places where appropriate I suggest you use T4 to its full potential. I use it to import stored procedure calls to avoid using magic strings when calling stored procedures (and using their parameters). Check my blog post about it as well.
DAL technology/library
Don't write your own data access code using things like SqlConnection/SqlConnection functionality. There're many data access layer libraries/technologies today that you can use and not reinvent the wheel. If you know nHibernate, then use that. If you know EF, then use that. If you know anything else, use that. Anything that will provide/generate as much code for you as possible that is already tested and debugged.
So it all boils down to:
DRY + YAGNI
a.k.a. Don't repeat yourself and You ain't gonna need it = don't over-engineer you code.
Agile developers are supposed to be lazy
They should develop just as much as it's needed and no more! TDD implicitly provides this process by the red => green => refactor steps.
I would recommend using MVVM and Test Driven Development. The MVVM will give you good separation between the front and middleware, and the TDD will help control the chaos that comes with any nontrivial app development.
Have a look at the Composite Application Guidance from Microsoft's Patterns and Practices group, it may not match what you are doing exactly but will give you some good ideas.
From an architectural standpoint, I highly recommend taking a look at the Microsoft Application Architecture Guide. Since you are already using the Microsoft technology stack, I would consider using Microsoft Unity for IoC. You indicated that your presentation layer might use WPF or Silverlight, so take a look at using Windows Communication Foundation, as you will be somewhat constrained in Silverlight when it comes to communication with your data layer.
What is the simplest way of converting my .NET C# windows forms app to a silverlight app?
Thanks!
You will need to re-write all GUI completely.
If you used any pattern separating business logic and data model from its presentation (MVC, MVP) it will be easier to port user interaction. If you used any database access layers or framework, they can most certainly be reused in Silverlight project. However, if your application logic is defined in form event handlers and data access is performed from within them, chances are high that you'll have to write a new application.
Also note that you can't use third-party libraries compiled for standard .NET Framework in Silverlight. You'll either need to recompile them, provided that you have the sources, or look for a specific Silverlight version of the binaries.
Standard .NET Framework libraries can easily be accessed, however there are some exceptions to the rule. For example, obviously, there is not System.Windows.Forms in Silverlight subset of .NET Framework.
To give you a better answer, I need more details: what kind of application are you considering to port, what libraries does it use, whether business logic is separated from presentation logic, etc.
Regarding the UI there is a Windows Forms to XAML Converter that may help a bit.
This might seem like a ridiculous question since I'm quite inexperienced in .NET.
Is it possible to build components in C#, using .NET, which can be reused in ASP.NET. For example if one would like to port an application onto the web.
If possible, how portable are they? I.e. can GUI be reused in some extent? Is there an intermediate format to use as base or is it required to use C# components as binaries?
Thanks.
Edit:
Thanks for your input! I'm quite familiar with the design aspects of this problem, i.e. how to model components for reuse. However you made me realize that the question really is about - To what extent is .NET reusable between ASP and Windows? Can one say that certain packages of .NET components are independent of environment and some are platform specific?
Absolutely - a .NET class can be used in any kind of .NET application. However, it kind of depends on what part of the application you're talking about.
Generally, Windows Forms user interfaces are NOT reusable as ASP.NET user interfaces, because the design constraints are so different (i.e. web browsers only support a small number of controls, often use flow (not grid) layout, etc. Similarly, the events are different (a web form button isn't the same as a windows form button, etc.).
What you can reuse easily, though, if you do things correctly, is the business logic. Design your classes so that they don't internally know anything about whether it's a windows form or a web form (or a console application, or web service, etc.). That is, the classes should be pure implementations of your business logic. Then you can use those classes in any context you want to.
The short answer to your question is yes - simply separate out the code you want to share between the two views into a interface-independent class, preferably in a separate assembly, and include that assembly.
The long answer is more complicated - the ability to do this will vary between application and application. You'll be able to separate out less code for UI intensive applications that don't do much behind the scenes (such as, say, some sort of graphics game), than you will for a very simple UI application that does a lot behind the scenes (say, a UI that consists of a single button that then kicks off a complex data manipulation process).
In the end - .NET provides the ability for you to do this. Your actual ability to do this will be very dependent on your own design abilities and your particular requirements. There's a lot of writing available on this subject - I suggest starting by taking a look at Design Patterns (though the original book writes examples in C++, I believe that someone has done a book with examples in C#. I cannot, however, speak to the quality of it.)
I've never done it before, but i guess you can place the common code on a separated class. UI will need to be duplicated as windows forms and asp.net have completely difference programming approaches.