locked
What technologies to use for multi-platform app RRS feed

  • Question

  • I need to design an android and iOS app that at some point will need to be ported to a web page format. With this in mind I would like to ask what you guys think should be the right choice when it comes to the selection of tools that should be used. The project will be developed by a single developer, so code re-usability is a strong point here.

    I have a long term experience with .NET platform from ASP do Xamarin, however I was not able to follow the latest updates of the platform for the last 2 years. With this in mind my first idea was to use Xamarin.Forms as a base for the app, and then Blazor for the web page while sharing the view models between the projects. Everything done in a MVVM architecture.

    1- But then the question that comes to my mind is if there is some way to share as well the view part? After doing some research I saw that there is a possibility to define views in Xamarin.Forms, using Razor syntax. Does that mean that writing an Xamarin.Forms app with views defined in HTML, I can just recompile the resources with Blazor, and have a web page? Of course only in mobile mode, but still executed in navigator. The only work that would need to be done is to create a view representations that would suit the normal full size navigators?

    2- Another question that comes to my mind is the fact of implementing everything in MVVM architecture, is there any solution that would help me to separate views and logic (like MVVMCross), and as well be compatible with both Xamarin.Forms and Blazor? Is the support of bindings the same in HTML as in XAML?

    3- As well I would like to have some opinions about implementing the Backend of the app, I'm familiar with the ASP.NET Web API 2 but I saw that there are some products created for .NET environment like the Azure App Service which seems like a bundle created specifically for this purpose.

    I would be glad to know your opinion about this questions.

    Thanks,

    Tuesday, April 28, 2020 10:59 AM

Answers

  • I disagree with this. The concept of a viewmodel (or simply model, depending upon your pattern) is Ok but trying to use a VM from, say, WPF in a web app probably won't work. There are several issues with trying to do this that come to my mind. The concept of it being possible is true but the reality of it making sense, not so much.

    1. Desktop apps have the advantage of keeping things in memory and therefore using your language of choice. Web stuff is in javascript so models have to consist of either primitive types or types that are themselves models otherwise the JS side won't work. If you fail to follow this then you will get errors when the server tries to send the data to the browser, when you try to serialize the data to a web-friendly format like JSON or you'll get funny looking data on the client. Blazor plays games with serialization so it is hard to tell what it can and cannot serialize right now. In the web world models need to be DTOs. Whereas on desktop apps VMs tend to be more full featured (because you can). 

    2) VMs in a desktop app can be created and managed by the app itself. If you're using DI then this is easy to do. In the web world DI doesn't work as well for models. While you can certainly do it the behavior may be inconsistent because models from requests tend to be created and initialized by the binder. This generally won't connect to DI because, again, models are DTOs. So in a desktop app a VM may expose methods that rely on services but in the web world the models would tend to be DTOs so they are passed to a domain/app service to do the heavy lifting.

    3) VMs, and models, should be set up to support the exact needs of the view they are tied to. In the few cases I've seen people try to apply the OOP reuse process on a model it didn't end well (even in the same web app). The sole purpose of a model in the web world is to get data from the server into the view. The same purpose exists with a VM on the desktop but (at least for WPF) it is convenient to include services. 

    Irrelevant I cannot think of anything beyond the simplest of UIs where the UI for the web would be the same UI for a desktop. There are going to be differences. In a modern app the only thing we might send to the browser (hence the model) is an ID or something that then allows the client to call back to the server via an API and fetch the data it wants. We'll likely do this for each component in our app. Blazor wouldn't quite follow the same rules but behind the scenes it is doing something similar. In a desktop app though I'm loading the data into the VM and then going to use it as needed. There is no benefit in "sending an ID and then calling an API" because I'm already in the same process.

    Personally I think the UIs for the desktop and web are going to be dramatically different such that this whole "reuse a VM" discussion isn't going to matter. I also don't think there is going to be any savings in trying to reuse a VM. If reusing a VM is going to save a lot of time then, at least in the web world, we'd say your model is wrong. Models are literally getting data from point A to point B. It takes no code to do that so reuse is not meaningful. Models are not OOP things. However VMs, again at least in WPF, seem to be OOP for whatever reason. 

    I stand by my original recommendation that if you really want a web app then build a web app. It works on all the platforms. If you later decide you need a richer client for mobiles then write one that relies on the APIs your web app is already hosting. Less code in the mobile app, less code to write, less code to maintain. Win win in my book.


    Michael Taylor http://www.michaeltaylorp3.net

    • Marked as answer by Joshin95 Wednesday, April 29, 2020 10:04 PM
    Tuesday, April 28, 2020 9:46 PM

All replies

  • For iOS and Android you're going to be using Xamarin unless you are building a web app in which case the user will simply use their browser and the platform won't matter.

    1) You cannot share UI components across frameworks. You will be building separate UIs for the Xamarin and web app. You can share everything on the back end provided you limit your back end library to what is supported on all platforms. Multiple UIs is one of the reasons for using MVVM so this shouldn't cause any issues. However VMs are generally tightly tied to the UI so most likely they are sitting in your UI project already. These wouldn't be shared because: a) web apps don't use MVVM, b) web app models cannot be used like VMs in other apps, and c) the UIs are going to be different so you're going to need different data anyway. Questions related to Xamarin should be posted in their forums. This forum is only for C#-specific questions.

    2) Web apps do not use MVVM, they use MVC. Similar but different patterns. There is no easy way to get MVVM in a web app and it wouldn't make sense anyway. If you have properly separated out your app then it won't matter. V is clearly tied to the UI and will be different. VM is also tightly tied to the UI along with functionality. Web apps have M but no functionality (because it won't survive the client leap) so you're building those per view anyway. The only thing that is left is the underlying infrastructure. Don't try to reuse anything related to the UI. There is zero benefit and you'll just make it harder on yourself. No HTML does not support the binding of XAML. Most binding logic will be handled on client side. You could use Blazor but it is still experimental and requires calls back to the server to update everything. Unlike a XAML app that keeps everything in memory a Blazor app is going to have to constantly reload data which is inefficient. Your UI for XAML is going to be feature rich and one user-based. Web apps are going to be multi-user and must be fast without reloading lots of data. They are stateless after all.

    3) You are mixing things here. Don't worry about Azure at this point. It is a hosting environment and has nothing to do with Web API (directly). Azure can host APIs (in app services) and web apps (in app services) but that is only if you need it. You can also just host yourself. You don't probably have the experience yet to worry about the added complexity of Azure. Questions related to building web apps and the use of Azure should be posted in the ASP.NET forums. A web API is simply a service that allows the front end client to call into the back end server to get data. It is heavily used in client side frameworks like Angular or React. I don't see that it would add any value in a Blazor app but I've never tried.

    Personally it sounds like you're planning too far ahead. Assume that you will not be able to reuse any code from iOS/Android to the web. Also assume there won't be a web app. Just build your iOS/Android app. Once you're ready to move onto a web app (if ever) then see what existing logic can be reused. Refactor that into reusable code that you can use on both sides. This is how software is development today. Trying to figure it all out up front will take longer and ultimately probably not solve your problem anyway (because you don't know what that problem is yet).

    However if you're really thinking web app future I'd personally start there.  A web app can run on any platform so once the app is done you have iOS/Android done. Then if you find that you need a more feature-rich app then you can build a custom mobile app for those platforms. At that point you can get into code reuse. Furthermore since you will have already built out the infrastructure (including APIs) to support your web app the mobile platform can rely on those as well which means you don't need to share code as much as you're sharing the API. This is how we build modern apps. For example VS doesn't have any logic in it to retrieve stuff from Azure DevOps or Git. It does have an extension that calls the APIs that these web services expose. Hence once the APIs are done you can use them from anywhere. This cuts down on the code that has to be maintained.


    Michael Taylor http://www.michaeltaylorp3.net

    Tuesday, April 28, 2020 1:59 PM
  • MVVM is popular with JavaScript plugins, like React.Js, Angular.JS and others.

    https://geekflare.com/best-javascript-frameworks/

    I have not worked with Blazor. But from what I understand,  Blazor is a substitute for JavaScript in Web programs on the client-side that can use the MVVM pattern 

    IMO, you can use WebAPI, Entity Framework, the DAO pattern and DTO pattern. The client will need to know about the DTO(s).

    https://docs.microsoft.com/en-us/aspnet/web-api/overview/data/using-web-api-with-entity-framework/part-5

    https://www.codeproject.com/Articles/1050468/Data-Transfer-Object-Design-Pattern-in-Csharp

    https://javarevisited.blogspot.com/2013/01/data-access-object-dao-design-pattern-java-tutorial-example.html

    Tuesday, April 28, 2020 7:10 PM
  • Thank you for putting effort into this post. You pointed out very interesting facts. The web apps are really interesting and after some research I see how it can solve some of my issues.

    However I dont think I agree with the blazor part. As far as I understood is made exactly for the purpose of sharing as much .NET code as possible, including the logic behind each View. Even if a webpage is a combination of several "mobile" views, there is no problem with just reusing its ViewModels in the Controller part of the Web View. The dreams about defining mobile views in HTML and CSS was a perfect scenario, that I think would be very cool to implement in some future.

    Yes I totally agree that the Azure area is my weakest point, and your answer clarified the confusion in my head.

    Tuesday, April 28, 2020 8:58 PM
  • Thank you for the answer.

    I have the same understanding about Blazor, that's why I see it as a candidate for my project, just for the efficiency purpouse.

    About DAO and DTO patterns, I think I will have to do the same for the mobile app part so it will be totally reusable AFAIK.

    Tuesday, April 28, 2020 9:00 PM
  • A viewmodel is an object that is strong typed to a view. As long as the view is bindable  to  view controls, ,then you should no problems with a view no matter if it's Web, desktop or mobile view. 
    Tuesday, April 28, 2020 9:22 PM
  • I have the same understanding about Blazor, that's why I see it as a candidate for my project, just for the efficiency purpouse.

    MVVM is just a UI design pattern. One can use MVC or MVP with Blazor I suspect.

    About DAO and DTO patterns, I think I will have to do the same for the mobile app part so it will be totally reusable AFAIK.

    Why wouldn't the mobile app use DAO behind the WebAPI, like the Web program?


    • Edited by DA924x Wednesday, April 29, 2020 1:12 AM
    Tuesday, April 28, 2020 9:29 PM
  • I disagree with this. The concept of a viewmodel (or simply model, depending upon your pattern) is Ok but trying to use a VM from, say, WPF in a web app probably won't work. There are several issues with trying to do this that come to my mind. The concept of it being possible is true but the reality of it making sense, not so much.

    1. Desktop apps have the advantage of keeping things in memory and therefore using your language of choice. Web stuff is in javascript so models have to consist of either primitive types or types that are themselves models otherwise the JS side won't work. If you fail to follow this then you will get errors when the server tries to send the data to the browser, when you try to serialize the data to a web-friendly format like JSON or you'll get funny looking data on the client. Blazor plays games with serialization so it is hard to tell what it can and cannot serialize right now. In the web world models need to be DTOs. Whereas on desktop apps VMs tend to be more full featured (because you can). 

    2) VMs in a desktop app can be created and managed by the app itself. If you're using DI then this is easy to do. In the web world DI doesn't work as well for models. While you can certainly do it the behavior may be inconsistent because models from requests tend to be created and initialized by the binder. This generally won't connect to DI because, again, models are DTOs. So in a desktop app a VM may expose methods that rely on services but in the web world the models would tend to be DTOs so they are passed to a domain/app service to do the heavy lifting.

    3) VMs, and models, should be set up to support the exact needs of the view they are tied to. In the few cases I've seen people try to apply the OOP reuse process on a model it didn't end well (even in the same web app). The sole purpose of a model in the web world is to get data from the server into the view. The same purpose exists with a VM on the desktop but (at least for WPF) it is convenient to include services. 

    Irrelevant I cannot think of anything beyond the simplest of UIs where the UI for the web would be the same UI for a desktop. There are going to be differences. In a modern app the only thing we might send to the browser (hence the model) is an ID or something that then allows the client to call back to the server via an API and fetch the data it wants. We'll likely do this for each component in our app. Blazor wouldn't quite follow the same rules but behind the scenes it is doing something similar. In a desktop app though I'm loading the data into the VM and then going to use it as needed. There is no benefit in "sending an ID and then calling an API" because I'm already in the same process.

    Personally I think the UIs for the desktop and web are going to be dramatically different such that this whole "reuse a VM" discussion isn't going to matter. I also don't think there is going to be any savings in trying to reuse a VM. If reusing a VM is going to save a lot of time then, at least in the web world, we'd say your model is wrong. Models are literally getting data from point A to point B. It takes no code to do that so reuse is not meaningful. Models are not OOP things. However VMs, again at least in WPF, seem to be OOP for whatever reason. 

    I stand by my original recommendation that if you really want a web app then build a web app. It works on all the platforms. If you later decide you need a richer client for mobiles then write one that relies on the APIs your web app is already hosting. Less code in the mobile app, less code to write, less code to maintain. Win win in my book.


    Michael Taylor http://www.michaeltaylorp3.net

    • Marked as answer by Joshin95 Wednesday, April 29, 2020 10:04 PM
    Tuesday, April 28, 2020 9:46 PM
  • you explanation makes sense, and I guess starting to do the app will be the best choice, and then to try to share as much stuff as possible on the way. Thank you for your time!

    Wednesday, April 29, 2020 10:05 PM