Is it necessary to apply for both services if my app is not going to the App Gallery or Play Store?
I'm mainly developing this app for a college presentation so its not going to be released at all.
When an app is running, it verifies the permission and fingerprint certificate. Therefore, you need to apply for an app ID and enable related services to use the app, regardless of whether you want to release it on the App Store.
In order to use the majority of HMS Kits, it is necessary that the desired app services are enabled and properly configured on your Huawei Developer Account. This is the case regardless if you plan to release your app or not. Furthermore, this is the general process of most mobile development when you are linking your app to a mobile API backend.
Related
I am building an app that will have Native iOS, Android apps + a web app version. These will be the same thing, working with the same backend and the same data, they will have to share the roles and other app-related data so I don't think it will just 'work' to register it as native-app for the native apps and as a web-app for the web app as then I'll ahve 2 different applications with different ids and different roles.
What are we supposed to do in this situation?
Register an app for each platform anyway
Register just the web version and use it for both? or the Native one?
Is there some type of configuration to get this working in Azure that I'm missing out?
We encourage you use the same app registration for apps that are essentially the same but built for different platforms
The new "App registrations (Preview)" enables you to do that.
By reading more from the comments, emphasizing on the "same app" bit. Microsoft word is the same app, whether its the web version or the client versions of it on Windows, IOS and Android.
But if you have apps that are functionally different, then you should consider registering them separately. For example, front end client app and back-end WebAPI should be different app registrations
I'm building a mobile app and I intend to build its backend with Azure Mobile app backend, but according to this issue azure mobile app is obsolet, and I fell on Mobile app center recently, My question is should I build the back-end as a normal service and include push notifications using Mobile app center or should I use Azure Mobile Service, Please I need clarification on this.
I'm a PM in App Center team at Microsoft. We are doing user research right now to understand the evolving needs for these services and plan to build the next generation of Azure Mobile Apps as part of Visual Studio App Center. While we're working on the roadmap, we are fully committed to supporting Azure Mobile Apps including support for the latest OS releases, bug fixes, and documentation updates.
To answer your question, Push Notification service in App Center is in "Preview" right now which means that there could be changes in the service while we are working to make it production ready. We don't recommend to not use this service for your "production apps". You can use Azure Mobile Apps as it stands currently but there won't any new features added to it. Based on your needs, you can make a decision on what service would be best suited for application.
Hope this helps.
We are currently running Azure Mobile App backend + Xamarin app as client and it works fine. Soon, we will be creating new mobile backend.
However, it would seem that, according to this
https://github.com/Azure/azure-mobile-apps-net-server/issues/227
azure mobile apps is abandoned? Even Adrian Hall has moved to AWS? This begs the question, should I create mobile backend using WebApi 2 and deploy it as usual Azure Web App, use Azure Web App Mobile App?
Namechanging from Azure Mobile Service to Azure mobile app was confusing enough,there is also complete lack of up to date documentation for Azure mobile app SDK except from couple of examples.
I'm a PM in App Center team at Microsoft. I'd like to share our continued commitment to Azure Mobile Apps as our team own it. We are doing user research right now to understand the evolving needs for these services and plan to build the next generation of Azure Mobile Apps as part of Visual Studio App Center.
While we're working on the roadmap, we are fully committed to supporting Azure Mobile Apps including support for the latest OS releases, bug fixes, and documentation updates.
This is a similar pattern to what we are doing with HockeyApp and Xamarin Test Cloud. App Center is the next generation for those services and as we roll their functionality into App Center, we are re-imagining key developer workflows and adding new features, as well as integrating them into an end-to-end CI/CD solution that helps developers ship better apps faster.
I arrived here while looking for guidance on Xamarin.Forms offline sync feature in Azure Mobile Services.
Turns out Azure Mobile Services has been superseded by Azure App Service Mobile Apps. Fine, I'll look there for offline.
Turns out Azure App Service Mobile Apps has been superseded by Visual Studio App Centre. This supports auth, data and push so I went looking for offline again.
Turns out App Center Mobile backend as a service (MBaaS) offering is being discontinued so MS can focus on DevOps.
So in short if you want mobile backend service don't bother looking for MS to provide you a stable platform as a service, instead focus on building your own on their core products and hope they don't abandon those after a couple of years.
I hope these notes help sign-post the changes and demystify things a litte.
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.
We have built a simple mobile app that connects to ASP.net Web-API 2.
We would like to use Microsoft client SDK for it's offline sync support.
Now that Azure Mobile Apps support custom authentication we could actually take the leap.
I want to know out if the offline sync SDK absolutely requires us to use Azure Mobile App or Azure Mobile Services.
Microsoft documentation is full of how-to guides but does not explain what happens under the hood. The best I could understand, both are just OData rest API's and swagger for documentation.
Can the Azure Mobile Client SDK work with API server created on top of ordinary ASP Web-App, outside Azure?
What is it about the Azure Mobile App that makes the magic happen?
Vladmir,
On top of OData, in order to support features like soft delete, offline sync and others, the Azure Mobile Client SDK expects the server to implement a certain protocol. So although the answer to your question:
[does the] sync SDK absolutely requires us to use Azure Mobile App?
... is no, and in theory, you could implement your own API, but I would recommend against doing so, since (among other reasons) even if you manage to implement the expected conventions and behaviors, this will become a maintenance challenge down the road if you need to upgrade the client SDK to take advantage of bug fixes and/or new features.
The good news is that with the latest release of the Azure Mobile Apps server SDK, adding mobile capabilities to an existing ASP.NET Web API application is trivial, and you should be able to enable the scenarios you're looking for simply by adding the appropriate Table controllers. So you can just enhance your existing application and not have to develop and maintain the Azure Mobile Apps specific logic yourself.
About your last question, since both, the client and the server SDK are both open source and developed in the open, you can look at what what makes the magic happen here:
https://github.com/Azure/azure-mobile-apps-net-server
https://github.com/Azure/azure-mobile-apps-net-client
I hope this helps!
The answer for your first question: Yes the SDK can be used in any Server API you have since it will be your entry point to work with Azure Mobile Services.
The Azure Mobile app creates a mobile services instance which has push notifications and SQL tables to store all messages you would like to send with the capability to customize the message as needed. Also it creates a notifications hub instance under the hood to manage notifications for all mobile platforms. Azure mobile apps provide offline capabilities through native sync services between db on your devices and the server when connectivity is present.
Feel free to ask more questions to have a full understanding on How mobile apps works.
Hope this helps.