I am developing an App for Firefox OS. The App is just my own website with some added functionality. What will be preferred to add new functionality to mobile website and make it Hosted Firefox OS App or creating a new packaged App?
Definitely go with the Hosted App in this case with emphasis on offline first. You already have a website so the domain name for your website can already be used to represent the mobile web app version of your site. There are tons of advantages for going the hosted web app route. I'll try to list some of them on that are on top of my head. By using a hosted web app you gain:
Faster and easier review process when submitting to any marketplace
Improve discovery (think SEO)
Ease of updating your App and delivering new content
Owning the domain representing the identity behind your content
You can share the very same code on many platforms
Much more that I can not think of right now ...
As a rule of thumb, if you can get away by doing a hosted app, I would always recommend it over the alternatives. Packaged and Privileged apps are essentially stop gaps until mobile web matures enough to supports all the APIs you would need. Hosted apps already support many APIs and if that is enough for your use case then you are set. Another way to look at it is that hosted apps are essentially the purest form of mobile web apps -- they are the closest thing to web applications that are accessible from mobile devices.
Make sure to do some research about responsive design and offline first.
Good luck with your Firefox and mobile web adventure!
Related
Can I use one azure mobile app as a backend to support for mobile app and website?
I need it to support push notification and authentication as well as CRUD operation. Should I use API app or Mobile app or something else?
An Azure Mobile App is just a regular ExpressJS app with the Azure Mobile Apps SDK implemented. Here is a good example of a combined web + mobile:
https://github.com/adrianhall/azure-mobile-apps-html-quickstart
The 'public' directory contains the static website, complete with JS and CSS files. The app.js is your app (note the serve-static module usage to serve up the static content).
Now that Mobile App, Web App, and API App are under one roof so to speak you have several options.
They are all part of App Services.
The easiest way to think about App Services is in terms of a VM that hosts multiple web apps in isolation.
You create an App Service that is like a VM and then you create multiple apps that run in that VM.
You could create a Mobile App and a completely separate Web App that share a common database for instance.
You pay for the App Service instance, not each app, so it's really up to you how you want to divide up the functionality.
Now before someone cries foul on my VM analogy, I said it was the easiest way to visualize it, not the most accurate.
What you really get is a "Virtual Virtual-Machine" that could be one or many VMs. You see it as one logical thing in terms of management, deployment, etc. but it could really be multiple VMs. It can scale up or down based on your configured options (eg 1 VM always, scale up to 5 VMs if CPU or Memory exceed thresholds you set, etc.).
I am in the process of building a Web based client for a Server application which is running as a Windows Service. The server application currently has a Windows Form based Client Application written in C# and the idea is to obsolete it and provide a new Web based Client Application. The Server application will be exposing REST based APIs and the Client Application would be using the REST APIs to communicate with the Server Application. (Currently the Server App exposes SOAP based endpoints which are consumed by the Windows Form Based App)
The Browser based client application would be written using Angular JS. The Client Application would be used by at max 10 concurrent users. The App is targeted for system administrators and would be used inside the enterprise environment.
Another requirement is to integrate Active Directory Authentication for the Client Application. So given the performance requirement and authentication requirements, I am wondering whether I should use IIS for hosting the Web Application. Or should I just use the existing Server to self host the web pages.
If at all I go with Self Hosting option, would Katana Self host be a good option? Or should i use WCF Rest kit to serve the pages?
What are the performance implications of using a Self Hosted mechanism for hosing the Web Application compared to IIS?
Any suggestion would be greatly appreciated.
WCF REST Starter kit is still in second preview 2 version from 2009 so I'd be pushed to recommend using it.
The question of IIS or self host depends, do you need the features that IIS has out of the box like logging, restart after failure, etc?
My suggestion would be to use ASP.NET Web API (or Nancy, which is an excellent choice too) but keep your hosting layer separate from your application layer so you have the flexibility to decide how you host your service later on.
The second suggestion is performance test early on, pick a hosting mechanism and measure how the service copes under load - you may find out that you're worrying about something that you don't need to.
I have created an Azure Web App today and it has a Mobile section in the Settings which contains Push notification, Mobile Authentication, etc. You can even download the source code for a mobile client app. I know that this used to be part of Mobile App (Mobile Service). I have created an Azure Mobile App to compare with Web App and they look the same in terms of Settings and Tools. Even the Icon is the same.
My question is what is what is the difference between Azure Web App and Azure Mobile App?
Like you, I couldn't get my head around the difference between the different types of App Service apps (Web Apps / Mobile Apps / API Apps). Judging by the fact that no one has really answered your question, it looks like we weren't the only ones.
It made no sense to me that Web Apps, Mobile Apps and API apps were distinct things: surely the whole point is that you should be able to expose an API that serves your web site, your mobile apps, any other kind of client, making use of whichever features you need for your use case?
And, lo and behold, buried deep in the Azure docs:
The only difference between the three app types (API, web, mobile) is the name and icon used for them in the Azure portal.
Yep: they're exactly the same.
In old days of Azure, they had 2 offerings - Azure Websites and Azure Mobile services. Some time ago, both of them got rolled into something called Azure App Service which also included two more kinds of apps - API Apps and Logic Apps.
To answer your question specifically, Azure Web App is new name for Azure Websites that you can use to build websites in multiple languages where as Azure Mobile App is the new name for Azure Mobile Service that provides backend infrastructure for mobile applications (or in other words, Azure Mobile App is Mobile Backend-as-a-Service [MBaaS] offering from Azure).
Mobile Service is the "classic" version and is only available in the classic portal. Mobile Apps is part of App Service is only available in the preview portal.
App Service includes Web Apps, Mobile Apps, API Apps and Logic Apps is deployed as one unit. Using the classic way, you would have to create and pay let's say for a Web App and a Mobile Service so you can save money using the App Service. You also get a larger selection of VMs.
Not all Mobile Services features have been migrated yet to Mobile Apps. If you use a Node.js backend, there's no nice UI built-in in the new portal to manage your JS code.
Note that Microsoft has not announced that it will deprecate Mobile Services.
I have found some subtle, but key, differences. Assuming a C# backend, the Mobile App Service controllers will inherit from TableController - which provides out-of-the-box CRUD operations on a table, compared to the Web Api 2 style ApiController (which you can still use in a Mobile App Service). Any less confused now?
Sorry for the late reply. They all are really the same thing. If you look in Azure Resource Explorer (available in the application menu of your app or resources.azure.com) you will see the indication of how we display a different icon for it - "kind": "mobileapp", for Mobile Apps for example. We leverage the different kinds to provide different quick-starts. You can certainly create an Azure Web App and load Azure Web App code to it to get the Mobile Functionality.
I can't find answer for this simple question: What kind of application can I deploy to Windows Azure?
Can I upload only ASP .NET apps or can I upload:
Windows Forms Applicaton
Windows Presentation Foundation Application (WPF)
Other?
Here's a summary of the sorts of applications you can host on Azure:
Platform as a service
Azure Websites
Most existing / new Microsoft-stack (IIS-hosted) web applications (ASP.Net MVC, Web API, Web Forms, etc.)
A bunch of existing / new web applications written in other popular languages (Java, PHP, Node.js or Python)
Azure Cloud Services
Newer Microsoft-stack (IIS-hosted) web applications similar to above, but with some additional functionality / overheads (this answer will give you a good comparison of the two)
New web (IIS-hosted) applications designed to take advantage of Azure hosting (for example separating front-end and back-end concerns using web and worker roles, again covered in the linked answer)
Infrastructure as a Service (VMs)
Anything that you might host in a VM in another data centre / on another cloud service provider--usually legacy web applications / services, or those where the owner avoid tying their application code to a particular vendor by building on top of their PaaS
You'll notice that these are all basically webby, which excludes the likes of WinForms, WPF apps, and any other applications that are designed to run for users on their local machines. To directly answer your question:
ASP.Net applications--yes, you can host these on Azure
WinForms applications--no, you can't host these on Azure
WPF applications--no, you can't host these on Azure
Other applications--if they're web-based and fall within the broad descriptions above, then there's a decent chance you'll be able to host them on Azure, but it really depends on the nature of the application
Windows Forms and WPF applications typically comprise of a rich client application as well as dependencies on backend services and databases. Windows Azure provides a great host for the backend services and databases - and you can learn more about this here - especially in the compute section. There is also a lot more you can do - so just take a look at the other links for more information.
Enjoy!
Jason
I'm fooling around with a WebAPI application I've developed in two solutions: one solution is the WebAPI / serverside solution with db access using SQL server, the other is a durandalJS client application. I have the WebAPI bits hosted in an Azure Website right now, but I'm not sure where to put the client solution.
Should I throw it in its own website and just have it make requests within azure across to the other website? I want to avoid putting them in the same solution because I would eventually like to practice load balancing the front-ends when I have more dough to play with.
Idea of cloud like Azure is pay as you go. If you do not have the volume currently to load-balance, why create two websites and pay for them both regardless of the usage? You can have just one web site and host both the web application and web API. In the future, if you want to separate out API piece and load balance web app, you can do that when you have the volume. For this approach to work, structure the solution like this. The Web API piece will be just an assembly which you can reference in the Web application itself and host it in the same web site as the web application. In future, if you want to separate out, create a new empty ASP.NET Web application and host the Web API referencing your Web API core assembly.