I have a site that's done using ASP.NET MVC and jQuery. Is it possible to modify my existing project without too much of rework so that it can be used in phonegap to create iphone/android apps?
Here's an approach: move your logic to an MVC WebAPI (or other REST/webservice) project, then convert the MVC site into a simple html/javascript/css/image site (Mobile site). Then refactor your Mobile site to use Ajax/JS to query the WebAPI/Rest services you created. Once you've separated your code this way, you can then package the Mobile site with Phonegap. I'm not sure how much work that will be for you or your project. If you're using a lot of Html Helpers or Razor markup in your views it may be too involved.
The core point of my suggestion here is to separate your mobile UI layer and the backend processing layer so you can only package the Html5/UI/Javascript layer with Phonegap and leave the backend processing on your web server. I don't think I need to explain this, but obviously the app packaged with Phonegap is not going to have the MVC/.Net framework available on the mobile device to render views or execute controllers, etc. By migrating your UI to be simple Html5 and Javascript you can use Ajax/Jquery/Javascript calls against your backend, which you will probably want to host in ASP.Net MVC WebAPI.
Edit: Guess there was some confusion about my suggestion. I'm not saying this is the only way to do go, but this is what I'm familiar with as it's how our team builds our desktop/web + mobile + phonegap + mvc4 + webapi + kendoui application. This pattern works well for us so maybe it'll work for you too, or at least give you some ideas on how to structure your solution. Good luck!
I'm not sure but you need a server to compile the ASP.NET right? so I don't think that will work for you. I think you need to work with AJAX to do your ASP.NET work and separate your ASP.NET code and your HTML-jQuery because Phonegap wants a index.html file. You can store your ASP.NET files at a server tough
The answer to your question really depends on the type of site you are trying to convert. Are you just trying to put a native framework around HTML and get your app into an app store?
If it is is mostly or entirely informational in nature and you have simply used MVC to build brochure-ware type pages then it should be fairly easy to move. This assumes that there is little to no logic other than page to page navigation.
If your site instead pushes a lot of data around that relies on a back-end server you will need to re-architect it to store data locally or pre-fetch it via a manifest. Next you will need to implement a strategy that allows you to push your local data back to the server.
Does you app need to run in a disconnected state?
Phonegap is one of the options if you want to target multiple mobile platforms & may be most widely used. Since you are using jQuery, jQueryMobile will be a least learning-curve path to use. Effort is mostly on the front-end UI and will depend on how many screens you want to design to provide a sub-set or the full set of functionality you already have on the web UI. Most likely you will have to redesign your screens using the jquery-mobile UI widgets documented here. It is also a good way to show it to your customer the initial screen design with navigation.
jquery mobile is great for learning and designing , but it's slow in the web browser control that phone gap runs in .
you'll need a more lightweight framework for this .
you can use an inappbrowser control to show your site in case it's responsive , but you wont have the device camera and contacts and so ...
take a look at : http://docs.phonegap.com/en/3.0.0/cordova_inappbrowser_inappbrowser.md.html#InAppBrowser
Related
What is the architecture difference between working with razor vs blazor?
Documentation suggest that I have to write an Web Api when using blazor - is it still possible to pass model objects like in traditional razor ?
0 Video with visual explanation
I decided to make a video, since several questions about Blazor were asked (also on other forums) and this format seems much better for me to visualize the differences - instead of reding my (longer) explanation. The video contains a bit improved version, compared to my first post (the text post is also updated) It's one of my first videos in this format, so any feedback is welcome. If you prefer to read a classic text without much visualization, you'll find it's content in the following sections. Of course without the demos, which I made to lighten the content up, but the basic information content is the same.
1. What is a traditional multi-page site or application?
First you need to have a basic understanding how traditional websites/apps works: For every call/request, you send a request to the server and the server responds with the complete HTML of the entire page. This can be dynamically generated like with ASP.NET Core MVC and Razor templates or Razor Pages or even some other technique like PHP, Java, Python and so on. Let's say you have a list of articles showing a preview.
To illustrate this, let's say you have a list of articles (for example blog posts) showing a preview. When the user clicks on read all, you usually have two ways to realize this in traditional web apps:
Load a page like /view-article?id=123 where the above happens again: Loading the entire HTML DOM of the article page
Using JavaScript to make an Ajax-Request, which loads the desired content from an API like /api/get-article?id=123 and manipulate the DOM to display it at the desired position
Without JavaScript, traditional sites are not interactive. This means: After the page is loaded and rendered, nothing happens any more – except the user load another page (with the entire DOM) by clicking on a link – for that reason, it’s called „multi-page“ application.
You'll propably prefer the second approach, cause it's faster and saves ressources: Instead of rendering the entire page again (where only a part of it has changed), you stay on that page and just load the new information you need (the article content in this example). Especially on large pages with many ressources to load and render, the JavaScript approach feels much faster to the user.
If you like traditional pages to be interactive, you need JavaScript. For example you can add an ajax call to some API that displays some data when the user clicks a button, without having to reload the entire page.
In short we can say, that most of the work happens here on the server side.
2. Where is the difference to single-page applications (SPA)?
SPAs have just a single page, in terms of a full rendered html page. If you navigate there like by clicking on article, they load a JavaScript application. It handles everything interactive there. If the user clicks on an article, there is NO complete HTML document fetched from the server! Instead, it only fetches the parts who are changed, in this case the article. Everything else (e.g. navigation bar, footer, widgets etc) will remain - in opposite th multi-page apps, where this may be reloaded if no js/ajax is used.
You often have modulary components there and two-way data binding. This means, a variable is linked to some HTML element. When the variable changes, the element automatically displays the new value. In traditional apps, you'd have to create event handlers manually to handle this. It can be seen as continued development of a single page application with vanilla JavaScript, where you need more manual work to archive things like data-binding.
For the user, a SPA normally is much faster than navigating through pages on multi-page apps.
In short we can say, that most of the work happens here on the client side in the browser of the user. The server just serves static stuff (html, js, css) and provides APIs for e.g. fetching entries from the DB or save them.
3. What has Blazor to do with that?
A Blazor app actually is a SPA. But the main difference to other frameworks is, that Blazor lets you control both the client and server side with C# code. To show that benefit, let's look at other SPA frameworks like Angular: You can build an Angular SPA with ASP.NET Core. In this case, you write your client side in Angular with TypeScript. If you need to access data, it will make API calls to the ASP.NET Core server, which is C#. It will be similar with other frameworks like React, but here with JavaScript instead of TypeScript.
This make it hard to share code between those two: If you have an article model, it needs to be defined in C# on the server and in TypeScript on the client as well. With Blazor you just define it once in C# and re-use it on both sites. In other words: You just write C# without having to care about JavaScript*
*That’s the basic idea behind Blazor: Use C# everywhere, without the need for JavaScript as second technology. But it’s worth mentioning that you need to work with Blazor components to accomplish this. If you need some library not being ported to Blazor yet, you still have to handle a bit of JS. However, there are still benefits like the data binding. Using it on an entire plain JS stack would be some work, so I’d recommend to start with an UI library that offers Blazor components.
3.1 Blazor WebAssembly and Blazor Server
Now you know the basics and you need to decide between two flavours:
Blazor WebAssembly
As the name suggests, it basically uses WebAssembly to run your C# browser directly in the browser. It requires a relatively recent Browser and is not yet supported on all platforms/browsers. Also major engines like Chromium or Safari doesn't support all standardized features yet.
Let's say you have a button with C# code as handler like this:
<button class="btn btn-primary" #onclick="IncrementCount">Click me</button>
IncrementCount is a C# method. The code got transfered to the client and would be executed in the browser. Imagine it as .NET Core runtime inside the browser, like Silverlight BUT without any external plugins. There is no need to even have ASP.NET Core on the server-side! It can be served from any webserver, as long as you don't need things like DBs from the server side. This makes the app larger (and slower, at least on the first load).
The example Visual Studio template has a size of more than 17 Megabyte! With compression this can be reduced to 7 Megabyte – still a lot for a hello world application. By publishing the application in release mode, this goes down to about 7 MB and 2.4 MB with gzip.
At least subsequent requests are faster. Those DLL files are stored in the browser cache, which avoids further requests.
But it can be used offline (at least the main logic without API calls). For that reason, it's sometimes called real SPA – it’s compareable to Angular, React and other client-side frameworks.
Because of the WebAssembly-Usage, Debugging can be harder here, currently it just support Chromium based browsers.
Don’t know WebAssembly? It’s a relatively new, open standard that generates bytecode to improve loading and execution time to realize more powerfull web-applications – independent of the language. You’re not forced to use specific languages like JavaScript: Since Bytecode is generated, also other languages like C++ or Rust can be used.
In a nutshell, WebAssembly can be seen as next generation JavaScript for feature-rich webapps, where Blazor WebAssembly is the C# implementation. Because of the browser runtime, there are some APIs which can’t be used here. For example sockets or I/O access, like File.Open or File.Write.
Blazor Server
The app runs on the server and just transfers the output (like the result of a click event, that increases some counter in another HTML element) to the browser using SignalR Websockets. This makes the app smaller and faster, but requires more ressources on the server-side cause you have a SignalR connection and it's virtual DOM also on your server - making it harder to scale in large setups.
On the other side, this reduces the requirements on the clients: They don't need to support WASM, so it could run on older browsers or browsers with restricted WASM support as well as low-end devices. But since every action ends in a SignalR call, the app won't work offline - if this is a requirement, choose Blazor WebAssembly over Blazor Server.
What to choose?
It depends on your needs, as pointed out above. For example, if you need offline support, Blazor server wouldn't be a good choice. If you're unsure I'd prefer Blazor Server and only really worry about this if you're planning to deploy a very large application.
Imho, Blazor server is currently smoother and more flexible. Blazor Server also got stable before WebAssembly. This recommendation may changes in the future, when WebAssembly has developed further and got more widely supported.
But in this case, you can migrate later!
Both Blazor WebAssembly and Server use Razor components. This means: You can change between both, without re-writing your entire code. Some migration work is only required for things like data-calls outside the browser when migrating from Blazor Server to Blazor WebAssembly. The reason is, that Blazor WASM runs entirely in the browser, so you need a server part like an ASP.NET Core API projekt to handle them.
Further information
I recommend the Introduction to ASP.NET Core Blazor in the official documentation. Also the other chapter describing a lot of information about the platform and offers tutorials. They go deepter in detail to topics like data binding or event-handling to just name a few, and illustrating them with examples. I tried to kept it shorter here for a basic overview.
See also: Blazor WebAssembly 3.2.0 and ASP.NET Core 5
I come from using ASP.NET MVC/Web API and now I am starting to use Angular but I am not clear on the proper way to mix them.
Once I am using Angular does the MVC sever side concepts still provide any value ? Or should I strictly be using Web API purely to get data for the angular HTTP calls ?
Any tips you have for a ASP.NET MVC guy transitioning to Angular would be helpful
Pure Web API
I used to be pretty hardcore with ASP.NET MVC but since I've met Angular I do not see one reason why I would use any server side content generation framework. Pure Angular/REST(WebApi) gives a richer and smoother result. It's much faster and allows you to build websites that come quite close to desktop applications, without any funky hacks.
Angular does have a little learning curve, but once your team has mastered it, you'll build much better websites in less time. Mainly this has to do with the fact that you don't have all these state(less) issues anymore.
For example imagine a wizard form with any traditional server side framework. Each page needs to be validated and submitted separately. Maybe the content of the page is dependent on values from a previous page. Maybe the user pressed the back button and is re-submitting an previous form. Where do we store the state of the client? All these complications do not exist when using Angular and REST.
So ... come over to the dark side ... we've got cookies.
Similar question
AngularJS is more associated with the single page application paradigm, and as such, doesn't benefit much from server-side technologies that render markup. There is no technical reason that precludes you using them together, but in a practical sense, why would you?
An SPA retrieves the assets it needs (JS, CSS, and HTML views) and runs on its own, communicating back to services to send or retrieve data. So, a server-side technology is still necessary for providing those services (as well as other means such as authentication and the likes), but the rendering parts are largely irrelevant and not particularly useful because it's a duplication of efforts, except MVC does it on the server side and Angular does it on the client. If you're using Angular, you want it on the client for best results. You can make Angular post HTML forms and retrieve partial views from MVC actions, but you'd be missing out on the best and easiest features of Angular and making your life harder.
MVC is pretty flexible and you could use it to service calls from an SPA application. However, WebAPI is more finely tuned and a bit easier to use for such services.
I've written a number of AngularJS applications, including a couple that migrated from pre-existing WebForms and MVC applications, and the ASP.NET aspect evolves towards a platform for delivering the AngularJS app as the actual client, and for hosting the application layer the client communicates to via REST (using WebAPI). MVC is a fine framework, but it usually finds itself without a job in these sorts of applications.
The ASP.NET application becomes another layer to the infrastructure, where its responsibilities are limited to:
Host the dependency container.
Wire the business logic implementations into the container.
Set up asset bundles for JS and CSS.
Host WebAPI services.
Enforce security, perform logging and diagnostics.
Interfacing with application caches for performance.
Another great thing about an SPA is it can increase bandwidth of your team. One group can blast out the services while the other lays in the client app. Since you can easily stub or mock REST services, you could have a fully working client app on mock services and swap out for the real ones when they're done.
You do have to invest up front on Angular, but it pays off big. Since you are already familiar with MVC, you have a leg-up on some of the core concepts.
It depends on the project you are working on.
If angularJS is something new for you I would rather pick a small low risk/pressure project to get started and ensure you learn how to do things in the right way (I have seen many projects using Angularjs wrong because of pressure, deadlines... lack of time to learn it in a proper way, e.g. using JQuery or accesing the DOM inside the controllers, etc...).
If the project is a green field one, and you have got some experience on AngularJS, it makes sense to abandon ASP.net MVC and in the server side go for pure REST/WebAPI.
If it's an existing project, you can pick up a complex subset of functionality and build that page as a separate angularJS app (e.g. your app is composed of a big bunch of standard simple / medium complexity Razor based pages but you need and advanced editor / page, that could be the target piece to build with AngularJS).
You can use Angular framework for front end development i.e to construct views. It provides you a robust architecture and once you learn you will find it's advantages over Asp.net MVC's razor view engine. To fetch data you have to use WebAPIs and now ASP.Net MVC project support both WebAPI and MVC controllers out of the box. You can refer below link start with Angular and ASP.Net MVC application development.
http://hive.rinoy.in/angular4-and-asp-net-mvc-hybrid-application/
There are two frameworks currently available for developing UI components for angular applications. I have used both these frameworks in one of the angular projects that I worked.
Material
https://material.angular.io/
PrimeNG
https://www.primefaces.org/primeng/#/
Is there much point to using angular js on top of asp.net mvc since they're kind of both doing the same thing? What are the advantages to using angular over asp.net mvc + jquery? What kind of scenario would you pick angular in? If you do pick angular in a microsoft environment, what would you run on the server side? Would it be something like Web API? Or is there still benefit of using traditional asp.net mvc?
This question is a bit subjective, however here was our reasoning.
Let the client handle rendering of pages, free up resources on the server.
Leverage built in caching of cache servers since we are just dealing with <html/> content.
Since the pages are cached the only traffic back and forth is json payloads.
We have been using NancyFx, but WebAPI or Service Stack would work just fine.
We wanted to build a responsive single page application and AngularJs fit the bill for testability as full feature rich framework.
AngularJs forces you into a pattern that we needed for JavaScript, in the past our jQuery heavy applications turned into functional spaghetti (That was our fault but being guided by Angular helped out a lot).
As with all frameworks pick the one that suites your needs
On my site http://www.reviewstoshare.com, I am using AngularJS along with ASP.NET MVC. The main reason I did not go all the way with AngularJS was that SEO is not easily achieved with AngularJS.
Keep in mind that my site was already built using ASP.MVC + Jquery for in page interaction as needed.
On the other hand there is still some "Ajaxy" nature to the site like comments, voting, flagging etc. Not too different than Stackoverflow itself. Before AngularJS it was a mess of Jquery plugins and functions within $(document).ready() callback, not to mention the JS code was not testable much.
In the end, I went with both.
If you fancy using Java Script framework then Angular JS rocks.
SEO could be the issue. You need to have deeper understanding of DOM and Java Script as compared to other famous JS Frameworks.
I ve developed a Proof of Concept - using Angular JS with Require JS using ASP.net MVC
You can have a look at it at the below given link
http://angualrjsrequirejsaspmvc.blogspot.com/2013/08/angular-js-with-require-js-front-end.html
I'm creating a PoC of an ASP.NET MVC 4 mobile application (tablets) for field operators that needs to support offline capabilities. It's a relatively simple data entry application with a WebAPI backend that will use a SQL database as persistent storage.
This is the first time I'll be implementing offline support, so I'm a bit unsure of which is the best way to design this. Right now I can think of two ways, and not sure which one is better or more correct.
What I want is that whenever there is internet connectivity, the information is retrieved from the server. If the connection is lost, I want the latest information to be cached/served and available to display to the user.
Based on a few tests that I've made, the way the HTML5 offline support appears to work is that as soon as any of the Views is loaded, the browser will check the manifest and cache the version of each page at that moment of time. If my understanding is correct, that means that if the user adds new entries after the browser downloaded the manifest files, then those records would not show in the offline version.
One way I can think to work around that is to change the manifest version (since I'm generating it dynamically) every time it is served, but i feel that would defeat the purpose..or at least be incredibly inefficient bandwidth-wise.
The only other alternative that I can think of is not using regular MVC (not passing the records/db information as the model property or a ViewBag property) to display the records, but just retrieve the json for the page information needed and save in local storage. Then, generate the view using a template or javascript based on the information in localstorage. That would work either online or offline, wouldn't it?
I'm not sure if I'm approaching this the wrong way. Would building an SPA or a simple HTML/javascript application be more appropiate? Maybe using a JS framework? At this point I have some ability to determine what technology or framework we'd use.
Any guidance is greatly appreciated.
Based on a few tests that I've made, the way the HTML5 offline support appears to work is that as soon as any of the Views is loaded, the browser will check the manifest and cache the version of each page at that moment of time. If my understanding is correct, that means that if the user adds new entries after the browser downloaded the manifest files, then those records would not show in the offline version.
This is why you shouldn't use server side rendering. When the server mixes data with formatting before sending to the browser it means that the browser can't tell the difference between the two. HTML5 and Javascript are perfectly capable of handling templating on their own so why not let them?
Write your MVC application as nothing but a series of controller methods. Do not use "views" per-say. Instead use straight HTML files that use javascript to make AJAX requests to the server for data. Populate the HTML view with the data and you're golden. Then you can cache the HTML files because they're static and you can save the data separately for offline mode.
Adding to the accepted answer, there's a thorough post in this matter titled:
Build an HTML5 Offline Application with Application Cache, Web Storage and ASP.NET MVC.
The guy explains everything using a sample/complete app and do a great job explaining each and every point.
Besides that, if you really want to get the crème de la crème from modern web dev with offline capabilities, I'd suggest you take the 2 parts course by extraordinaire/star developer John Papa. It uses the SPA = Single Page Application UI paradigm.
The course is available at Pluralsight:
Building Apps with Angular and Breeze - Part 1
Building Apps with Angular and Breeze - Part 2
Enjoy as much as I'm enjoying it. Make sure you check this keyword/feature in the course: WIP = Work In Progress.
If you're interested, here's is a repo where I keep the updated course's code:
https://github.com/leniel/SPACodeCamper
Is there any reason that MVC isn't equally useful for desktop apps as for web apps?
What would be required to make an ASP.NET MVC directory tree implementable as a desktop app?
Prism
I've always thought of the term MVC as the same as a n-layer application - so correct me if I'm wrong here folks.
When i develope, I always(unless other instructed) use the following model/structure, also in applications:
GUI(Web, Winform, whatever) ->
Business logic ->
Data layer ->
And also with an underlying "Model"
... Which is a sort of MVC - So yes, it is usefull for desktop apps also. The main advantage with this, is that you can develope web, win and mobile(++) applications based on the same code.
Another thing that could be done, is to create the data/businesslayers as web-services...
I think this aproach would qualify as SOA.
EDIT:
As a note, the four levels of applications are created as seperate projects - and then used as adding reference to either the project, or the DLL, or from the GAC(or wherever you like.....) :) Thus, the need for a directory structure is not needed.
Hmmm... well, your view can be rendered as anything... HTML, XML, etc. So, why not XAML? I wonder if you can get your WPF or Silverlight app to work in the MVC framework this way... that is, not requiring a web server to run.
There is nothing stopping you from using the MVC pattern in a desktop app. In fact, it has been used on the desktop since before there was a web.
See Wikipedia for some examples
MVC just stands for "Model View Controller" which describes the way that concerns are separated from each other using the MVC pattern.
As far as using ASP.NET MVC on the desktop, there are a few problems. For one thing, it relies on HTTP requests and responses. You would need a server layer as part of your application architecture to listen for requests and send responses. Second, ASP.NET MVC views are really just simple HTML text files meant to be interpreted by a web browswer. So, you would need an HTML rendering component as a GUI front-end. You would likely want a CSS rendering engine and a JavaScript interpreter as well.
Basically, all you would be doing is running a dedicated browser as the front-end and a local web server as the back end.
There is really not much need since there are many great MVC frameworks already. There are also closely related patterns like MVP (Model View Presenter) and MVVM (Model-View-View Model). For example, many WPF (Windows Presentation Framework) apps are MVVM.