The chrome web store support 3 different app types: extensions, hosted apps, and packaged apps. Extensions are for apps that have minimal UI and primarily extend the functionality of Chrome. Packaged apps can run in a tab, can access the Chrome API, and run in the background. Hosted apps run in a tab and require an internet connection to load the page from the host.
But what kind of apps does the G-Suite marketplace support? I noticed that apps installed in the marketplace should up differently (i.e. they show up the nav bar launcher when logged in to Google Apps, not in a Chrome tab) so does that mean there are a different app type? And when Chrome removes support for it's hosted and packaged apps does that also affect the same types of apps in the G-Suite marketplace?
Since your question is more about G-Suite apps but it is worth to know little about other things in chrome store as well.
1. Chrome Extensions:
Chrome extensions are tiny applicatons with minimal ui. You can access all the chrome APIs that you need to create an extension. Take a look at the manifest file or jump over to top section to start learning.
Examples: add blockers and save bookmark extensions
2. Chrome Hosted Apps/ Packaged Apps:
These are Standalone apps with full UI. If you want to give users more interaction or if your app is more complicated with multiple views or it does not interact with user visited web pages then you can choose to create a chrome app otherwise go with extension. You can access all the chrome APIs that you need in your application. One thing to note about hosted Apps, they can't access chrome APIs since they hosted on other servers rather than local to user browser. Here is the manifest file or jump over to top section to start learning.
Examples for Packaged Apps: Rest Clients, Hosted Apps: Messenger apps
If you look extension manifest file and apps manifest file they look identical except you explicitly need to specify it as an app.
So what are chrome APIs: In general you want to access users top most visited websites, there you go you have chrome.history API. You need to specify the permissions in your manifest file before you use them.
Before you choose what you want to create take a look at here. It is just a decision logic which explains which fits for you.
https://developer.chrome.com/webstore/choosing
3. G-Suite Apps:
Google suite Apps are little add-ons to automate the tasks of Google's 11 Cloud Apps. Those apps are Google Docs, Calendar, Drive, Gmail, Translate, Maps etc.Quick intro here.
Since they directly included into google apps so that they can be accessed whenever you use those apps with any browser. You are going to use Javascript (known as App Script here but not much difference) and bunch of google APIs to build your g-suite apps.
Note: They are specifically designed for Google products.
Here are some of your questions:
what kind of apps does the G-Suite marketplace support?
G-Suite apps currently supports product management and education related apps.
I noticed that apps show up the nav bar launcher when logged in to Google Apps, not in a Chrome tab?
Since they are built for google cloud apps they live right inside the apps. You can access them from menu bar. A good example would be a spell checker for docs.
When Chrome removes support for it's hosted and packaged apps does that also affect the same types of apps in the G-Suite marketplace?
As of now, Chrome said they will remove support for in browser chrome apps after mid 2017. But they never told anything about chrome extensions and Google suite apps. So they are safe and Google suite apps are pretty new.
Related
Firebase Analytics can cover web apps and mobile apps, but is not supported for analytics inside Chrome Web Store. Chrome Platform Analytics seems to be purpose-made for packaged extensions, but I guess won't work for web or mobile components. And then there's good old Google Analytics... hmmm...
In general, it better to create a separate analytics property/tag for each separate medium?
If so, is the data shared across properties?
My Chrome extension has a web component. Should I use one standard Google Analytics tag across both the extension package and web instead of Chrome Platform Analytics? Or would I use Chrome Platform Analytics plus a separate property for the web pages? (note: web used for registration, logging in/out, settings, dashboard)
I intend to create the same extension for other browser platforms. Would I use a different Google Analytics property/tag or the same one across all extensions?
Mobile apps are not yet developed. Should I use Firebase Analytics for these, or what?
Thanks for your input!
I have reading about the new Azure offerings and trying to figure out what is what. The documentation I have been finding all over seems to have more information about the frameworks that are not valid anymore like this one here. Most of what they talk about at 4.8, 5.23, 12.13 into the video are no longer valid.
So far what I understand is that Mobile Services was offered in the past. That will soon be discontinued and App Services will take over. App Services are the top level services that contain Api Apps, Mobile Apps and Web Apps. Is this correct?
I am confused as to why we have Api Apps and Mobile Apps. Don't they do the same thing? And now that we have Web Apps in addition, are they only limited to UI related applications? The only simple thing to understand and one that has no similar other offering is the Logic app. This seems to be something that can only be done on the Azure portal. Visual Studio has no project template for it. Is there something that needs to be installed for creating logic apps in my visual studio only?
Also, in Visual Studio 2015 what is the difference between the Asp.Net Web Application project template under the WEB node and the CLOUD node? They both seem to be holding the same templates within.
Why do we have Azure Mobile App and Azure Mobile Service right under the Cloud node like here below..
..and also after selecting Asp.Net Web Application
On the face of it, both look the same. Are there any subtle differences that one needs to know about?
Also, why are all these options also not available for Asp.Net 5 templates? With all the changes happening is it a good idea to put apps developed under the latest versions to production?
Thanks for any pointers.
Azure Mobile Apps are the next version of Azure Mobile Services. Azure Mobile Services has been deprecated, and you can't provision it on new subscriptions. Mobile Apps has a lot more features over Mobile Services. To learn more, see I use Mobile Services, how does App Service help?.
Mobile Apps, Web Apps, and API Apps are all essentially the same thing, they just have some extra features for building particular solutions. You publish each of them to an App Service Plan, which is the actual underlying VM that hosts your service.
Once you've provisioned one of these app types, you can publish a Web API to it, regardless of what app type it is. For instance, you can publish your API to a Web App or Mobile App. Once you've picked a particular app type, you aren't locked in, you will just see a slightly different UI in the Azure Portal.
Mobile Apps also have a Mobile Server SDK for Node.js or .NET. The .NET server SDK is an extension of ASP.NET Web API. It doesn't yet support ASP.NET 5, mainly because there is a dependency on the OData library, which doesn't yet support ASP.NET 5. However, Mobile Apps is under active development and will support ASP.NET 5. Unfortunately, we don't have a timeline to share, mainly because not all the dependencies are complete.
For Mobile Apps in particular, you get the features of client SDKs that support authentication, offline sync, and push notifications. The easiest way to learn about the offering is to follow the quickstart guide: Create a Windows app on App Service.
You can learn all about the SDK and try them out, even without an Azure Account. Here's documentation about the .NET server SDK: Work with the .NET backend server SDK for Azure Mobile Apps.
API apps have a few extra features like creating a metadata endpoint for you automatically, which you can then use to generate client library using Visual Studio.
Currently, only Web Apps and Mobile Apps have a demo experience available at Try App Service, but you can see the API experience if you use a Microsoft Account to sign in, and then manage the app in the Azure Portal. You will see all of the API app and Mobile App options in the portal.
Note that Web and Worker roles are part of Cloud Services, and are a totally separate service. To learn about the difference between these, see Azure App Service, Virtual Machines, Service Fabric, and Cloud Services comparison.
I just describe what is the difference between Azure App Service, Mobile Apps and Api Apps, hope it helps:
Web and Mobile Apps o Mobile Apps offer a mobile application development platform with a rich set of capabilities. Based on Azure Mobile Services, Mobile Apps provide developers with a comprehensive set of client SDKs including Windows, iOS and Android as well as multi-platform environments such as Xamarin and Cordova. With Mobile Apps, you can easily send push notifications to your app, add login, and store data in the cloud with offline sync to any mobile client.
With API Apps, you can select from a rich library of existing on-premises and cloud APIs as well as contribute their own APIs easily for public or private use by Logic, Web, and Mobile apps in Azure App Service.
Azure app service, is a solution for creating web and mobile apps, is a cloud services that unifies everything you need to quickly and easily create enterprise apps that run on any platform or any device.
Azure app service is composed of: Web Apps, Logic Apps, Mobile Apps and API Apps
There is no longer API Apps in Azure, there is now only Web Apps.
I want to create a Windows Phone mobile app that receive inputs, send the inputs to an exe running continuously on Windows Azure to process and send outputs back to the mobile app. I have the knowledge to create a WP apps but little experience in Azure ,though I have access to it, so I don't know which service to use and how to use it. Please help
Technically, you could run an .exe in a web role on Azure but there might be a better, and easier, way to architect your solution.
Consider using Azure Mobile Services and, as WiteCastle says, re-architect your exe into a custom web API. Here are some examples of RESTful Web API projects from Microsoft's ASP.NET site.
Here are some useful resources to get you started:
Learn how to build secure mobile apps for the enterprise: view
webinar
Learn how to build consumer mobile apps that scale: view webinar
Choosing the best backend for your mobile app: view webinar
Alternatively...
If you're more comfortable with a web based back-end, why not try a product like appery.io, which allows you to create and connect up your app all via a 100% browser based IDE.
I have a WebAPI back-end for a mobile, and want to host it in Azure.
I am having a hard time figuring out the real differences between AMS and Websites.
All the articles I read about the subject talks about changes and benefits in general, and I want to understand specifically which new features AMS provides, and the benefits of hosting in AMS.
Authentication
In AMS I see the "IDENTITY" tab in azure portal. From what I understand, those 3rd party configs allow me to authenticate my users easily with google,FB etc. But this is just making the process more convenient and configurable via UI. In Websites, I can achieve the same functionality pretty easily using code from ASPNet.Identity and OWIN libraris.
Push Notifications
Again looking at AMS in the "PUSH" tab, I can see two mechanisms. The Notification Hub and 3rd party section.
The Notification Hub is nothing special to AMS, and I can get the exact same functionality when hosting in Websites.
The 3rd party section allows me to configure credentials to push services from Apple and Google (APNS,GCM...) and together with libraries in AMS namespace I can easily write code to communicate with those services.
But When hosting in Websites, in my back-end I can use open source libraries. For example, Moon-APNS to talk to APNS.
Scale
As far as I understand, both Websites and AMS allows the same scale functionality (One calls it Units and the other Instances).
Are there any big differences I missed?
Are any of the claims I made are incorrect?
It would be great if anyone could shed some light on the matter, specifically addressing all the 3 issues (Auth,Push,Scale).
That's a question I often get when I present Mobile Services at user group events.
For a .NET developer, there's nothing really special about Mobile Services since everything it offers, you can do it with a Website.
Mobile Services really shines for non .NET developers since you can have a complete mobile backend by writing scripts running on Node and Mobile Services abstract all the database and REST complexity.
I will likely get downvoted since I'll express a personal opinion but anyways: I see no obvious reasons for using Mobile Services if you're coding a .NET backend.
I think you are exactly the target customer for Azure Mobile Apps. You will get all of the power of having your own Azure Website (now rebranded as Azure Web App), with the additional convenience and client libraries of Mobile Services.
One feature of the client library that you may not have noticed is the cross-platform offline data sync capability. That's usually hard to build on your own, and we have an implementation that's conceptually consistent across all client platforms. (Plus, if you use Xamarin, you can share code between your client implementations.)
To be clear: Azure Mobile Services is NOT deprecated, and will not be until long after GA (general availability) of Azure Mobile Apps. Azure Mobile Apps is currently in preview.
The other big benefit of Mobile Services that you haven't mentioned is the client libraries for Android, iOS, Xamarin, and Cordova. If you already have a REST client library in your app and don't need to worry about multiple client platforms, then Azure Web Sites sound like a good way for you to go.
AMS by itself is built on top of Azure Websites. So you can actually implement everything in an Azure website that is available in AMS.
However, the good thing about AMS is that it allows you to quickly build the backend for a mobile app with CRUD operations, authentication/authorization and also provides client side libraries for different type of clients e.g., HTML, C#, etc. so we don't have to manually make the HTTP calls.
If you have need to implement the above functionality in Web API, it is quite an effort. Isn't it?
I want to use some of the APIs provided by Firefox OS. But many APIs are accessible only for privileged and certified apps. Firefox OS documentation suggests (as far as i understood) that "the apps which are deployed in marketplace are privileged apps". But how can i deploy an incomplete app to the marketplace without even testing the functionality of those APIs? Is there any other way to access those APIs? Thanks in advance
You can test your app using the FirefoxOS Simulator:
https://developer.mozilla.org/en-US/docs/Tools/Firefox_OS_Simulator
Depending on the APIs you're testing the simulator can help. Some aren't available due to hardware not being available on a desktop device.
Also, if you are developing a "hosted app", you have access to APIs which use web permissions. If you need more than that you would need to create a "packaged app" with type=privileged and specify which permissions you want access to in your manifest. This is described here: https://marketplace.firefox.com/developers/docs/packaged
The app permissions table will tell you if the APIs you want required hosted, packaged, or certified (only available shipped on device).