Usually it is recommended to have two projects for both wp7 and wp8 platforms. Wp7 project contains .cs and .xaml files, and WP8 project contains links to that files.
I think that there is no reason to compile non-platform specific business logic code twice, since it can be referenced to WP8 project.
I'm thinking about following solution structure:
Business logic dll compiled for wp7 (not a PCL)
UI comliled for wp8
UI comliled for wp7
Such application can be compiled and I can deploy it to device/emulator.
The question is: will this app pass certification in Windows phone store? Or it is necessary to recompile shared dll?
UPD:
My crazy idea was born after this steps:
Create new WP7 app (WindowsPhoneApplication1)
Create class library targeted to WP7 (WindowsPhoneClassLibrary1) Use it in WindowsPhoneApplication1
Use Upgrade to WP8 menu. WindowsPhoneApplication1 will be updated to WP8, but the referenced project will be still targeted to WP7!
Such app can be deployed to WP8 devices.
Unless you use a Portable Class Library, you'll need to have separate project files, and compile separately for WP7 and WP8.
Thanks to Claus,
I made some research, and it looks like the answer is - you can use such solution.
I didn't find related information in documentation, but here is a proof from one of MSFT tech. evangelists from Netherlands: link to blogpost
The basic idea is to move all our code that can be used from both our existing Windows Phone 7 app as well as the Windows Phone 8 build, which we will add soon, to a Common project in the solution. The bad thing about this approach is that we have to create the Common project as a Windows Phone 7 class library, which will be used in our Windows Phone 8 build. I haven’t really noticed any negative impact of this decision in my existing apps, but note that you will be referencing a Windows Phone 7 library in your Windows Phone 8 build.
So it is a possible, but not the best solution.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I am currently reading up on Xamarin and have stumbled upon a topic that confuses me. My intent is, to develop an iOS app as the target of my project. However, due to other circumstances, I can only test on an Android Phone right now and first in the last part of the development on an iPhone. Therefore, the app would have to be initially developed and tested for Android and then later on - through Xamarin - deployed as an iOS app.
In Visual Studio with Xamarin installed, there is a choice of using native app development such as Xamarin.iOS, Xamarin.Droid and Xamarin Windows app. As far as I was told by some more experienced programmers, it does not matter which of those three apps/platforms one would choose for the initial development as it is always possible - again through Xamarin - to deploy to whatever platform is required in the end.
Now there is also a fourth app solution in the project menu, called "cross-platform" and this confuses me. As I understand, this is a general app choice virtually fulfilling the same purpose as the native apps, mentioned in the previous paragraph - deployment to whatever platform is desired at the end of the project.
Unless I have misunderstood something here, what exactly would be the difference or idea of having a so called "cross-platform app" as a fourth choice if it can basically do the same as the native apps?
In Xamarin there is two approaches:
Traditional Approach where you share application business logic and you write UI specifically for each platform using Xamarin.Android or Xamarion.iOS APIs to target ~70% of code share.
Xamarin.Forms which is a library on top of the specific APIs (Xamarin.Android and Xamarin.iOS) to help share UI as well to target ~90% of code share.
With Xamarin you generate a native app and keep in made the quote:
Everything you can do in native with Java, Objective-c or swift you
should be able to do with Xamarin.
Xamarin does not magically make an app, you write for Android, run on iOS. At least not without creating an iOS app and all the UI etc. that goes along for that.
With Xamarin you create native applications, just written in C# instead of Java or Objective-C or Swift.
So why choose Xamarin? It enables you to share a lot of code. Depending on how you structure your code, there are some apps that achieve more than 90% shared code or more. However, that differs a lot from app to app, and differs whether you are using Xamarin.Forms or not.
You might be referring to Xamarin.Forms in your question and the project types that come with it. Xamarin.Forms is UI framework that runs on top of Xamarin.Android, Xamarin.iOS and UWP. However, note this is only a UI framework and it can potentially meet all of your needs.
However, Xamarin.Forms does not magically make a Android application run on iOS. The UI you write using Xamarin.Forms, has a huge potential to run and look fine on iOS too. However, it still runs in an iOS project and not the Android project. This would be the case for any other platform you are going to target.
Xamarin.Forms is an abstraction on top of those individual platforms to help you write your UI once and potentially run everywhere, among other features such as navigation and a service locator.
The project types you are referring to in the Cross-Platform section in Visual Studio, is just different ways of creating Xamarin.Forms apps. This can be in a Portable Class Library (PCL), which creates an assembly targeting the common subset of .NET capabilities of the chosen targets. Along the PCL there will be a application project for each supported platform.
The other type is creating a Xamarin.Forms App using a Shared Project type, which is different from a PCL. How? A Shared Project should be though off as a glorified file linking project. Eh what? Look at it as the files in the Shared Project are copied and compiled in the Application project itself when you build the project. So you can write platform specific code in that Shared Project. It does, however, not generate an assembly you can share with your friends just like the PCL does.
That was a lot of Xamarin.Forms talk. However, Xamarin.Forms is not the only way you can create a Xamarin app. Xamarin provides 1:1 exposure of the native API. Meaning, just like on iOS you create storyboards, ViewControllers, utilizing UIKit for Views etc. You can do exactly the same in a Xamarin.iOS project. The same goes for Xamarin.Android, where you will be able to create Widgets, Activities etc, simply in a Xamarin.Android project. Both of these yield a native App. However, in this case the UI is not abstracted, and gives you much more power to customize your App, without having to work against Xamarin.Forms.
Which one should you pick? That is up to you to figure out. Both approaches, yield fully native Apps with native UI. It just depends on whether you want more or less abstraction.
I've found a few examples, as I in a Xamarin.Native use a Windows UWP. But that would mean that I a Xamarin.Nativ in a Windows UWP Convert.
I would like convert a finished Windows UWP application to the target Android or iOS. Is that generally supported or needs my UWP application rebuild again with Xamarin?
Links:
Adding a Universal Windows Platform (UWP) App
Getting Started with Xamarin.Forms 2.0’s Windows 10 Preview
Unfortunately asfar as I know there is no converter that allows to convert UWP app to Android app straight forward.
There are few ways to make the whole process a lot much more easier (so you can create your Android app faster).
If you wrote your UWP application and separated common code that can be used in the other applications you can also use it in Xamarin.Android app - the best way is to have PCL with the common code.
It is also important which type of Xamarin app you would like to create:
1) Xamarin Forms - common UI for each app: Windows, Android and iOS.
There is one shared code that can be used by them. Remember that Xamarin Forms apps are generally speaking the best for displaying the data and they are limited with reference to platform specific functionality.
Please see below to read more:
https://docs.xamarin.com/guides/cross-platform/application_fundamentals/building_cross_platform_applications/sharing_code_options/
2) Xamarin.Platfrom (so Xamarin.Android and Xamarin.iOS):
Here you can create native UI foreach of the project (Windows, Android and iOS) and access specific platform functionality.
With reference to the code - you can put common code in one PCL and have access to it from each project.
Please see this site - here you can find different Xamarin options to create cross-platfrom apps:
https://developer.xamarin.com/
Firstly, if you want a shared code, using Portable class library, you can use the same code for all the platforms including WPF, Android and iOS. First of all what you can do is convert the codes that is used again and again in the PCL (Portable Class Lirary). Once you get used to PCL, you can easily work on any platform you want.
As the Android, iOS are different from windows, a lot of .net framework functionality is not supported in PCL. Although, once you create the basics in PCL, you can integrate the class library in android as well as iOS.
I know, there is an issue with System.AppDomain.CurrentDomain.GetAssemblies() in the Portable Class Libraries. To overcome it, I have decided to extract the list of assemblies in the target application and send it to my PCL as custom objects.
This was easy when using single-platform applications (pure WinForms, pure WP 8 application, etc.). However, I cannot find any suitable replacement for the method in Windows 10 Universal apps (and the documentation for both PCLs and Win 10 Universal Apps is pretty bad, so far). The reason, why PCLs are not able to get a list of assemblies is simply because the library does not know of all the assemblies, until it is built and packed into DLL. However, that cannot be said of the Universal App, since it should run the same system (Windows 10) -> therefore, it should be the same program on both PC and Phone -> therefore, the application should know of all its assemblies already before compiling.
So, does there exist a suitable replacement for this method, or some workaround how to get all the assemblies inside the app?
EDIT: I have found this workaround, which loops through all .dll and .exe files... however, that seems extremely unreliable. Is there a cleaner/better way?
I have a Windows 8.1 C# project for windows store ready.
I want to make a copy of it for Windows Phone 8.
Is there any good and easy way to do this?
I use Visual Studio Ultimate (2012 and 2013).
There's no simple/automatic way to do it, but the code will be mostly compatible. The UI will probably need to be adjusted significantly.
If you target Windows Phone 8.1 WinRT you will find more of the code will work (Windows Phone 8.0 does not support WinRT, which is what Windows Store 8.1 apps use).
A possibly better way would be to create a new Universal Windows 8.1 WinRT project and copy your existing project code in, placing as much as possible in the shared project (or in class libraries), then create a new UI for the phone version (you can keep most of the actual code behind in the shared project - see my blog post here: http://grogansoft.com/blog/?p=760 - to minimise duplication. Note that this must target WP8.1, not 8.0.
If you absolutely must target WP8.0 then you may have no better option than to just copy in the code and adjust it where necessary. This will be relatively easy for a simple app, but relatively messy for a complex app that happens to use APIs that don't match up.
Well, they are different platforms, so you'll still have to adjust your code for that, but maybe converting your portable code to a portable class library will help you:
http://msdn.microsoft.com/en-us/library/vstudio/gg597391(v=vs.110).aspx
I am creating universal app, but I want to use parts of older app, wroten in Silverlight 8.1. Is there option how to make cooperate these four projects:
MyProject.Windows (Windows 8.1)
MyProject.WindowsPhone 8.1 (Windows Phone 8.1)
MyProject.Shared
MyProject.OldSilverlightCodes(Windows Phone Silverlight 8.1)
I want to avoid migrating Silverlight code to Runtime line-by-line, it is just too complex to my skills. Is possible connect them any way, maybe via some converter class?
No, you cannot include a Silverlight project in a Windows Runtime project, and there aren't any automated converters.
In general, the best way to share .Net code across multiple targets is to use a Portable Class Library. Depending on what code you have in the Silverlight project it may be straightforward to extract the shared code to a PCL and then use the same PCL in both projects.
--Rob