Here, Google is talking about "web apps". Is a "web app" just an Android app that is connected to the web? Android app you need internet access for?
"Web app" is simply a broad term that can be used to refer to any web based/hosted site or service that involves a significant amount of user interaction, user generated content, or provides a "rich" user experience or a service API for third-parties to integrate with. A web app interface will "run" inside of a web browser, while typically all of the state handling and business logic will be handled by a backing server.
Google App Engine exists to provide a platform for implementing the "backing server" component of a web app (as well as basic hosting for the static resources needed by the app).
The concept of a web app really has nothing to do directly with Android apps. However, an Android app may (and many Android apps commonly do) communicate with a web app to provide various features or services within the app (think weather, Facebook integration, etc.). And in certain cases it is possible to implement a "quick and dirty" Android app by simply pointing a WebView at an existing web app's URL. In such a case that Android app's WebView becomes the "browser" that the web app's UI runs in.
Web app traditionally means a browser-based UI.
Google Web Apps was introduced in 2008, before the rise of the iPhone and Android. I would say those are a later addition to the definition.
If the client is using HTTP as its communication protocol with back-end services, I would call it a "web app", regardless of what the client hardware is.
Related
I have a Vue web app that makes use of device functionality such as camera, microphone, geolocation, and more. I want to convert this to a Cordova hybrid app that is simply used to request the required hardware permissions, as well as user login/signup functionality. This would all be local "native" code hosted by the phone's binary itself. After hardware permissions are granted, and the login/signup information is posted to my server, and validated, the user is then redirected through the web view to the web app hosted externally on my server.
Assuming the web app itself meets the Apple/Android mobile application design requirements, would I have any problems having this approved on the App/Play store?
As per Apple's App Store Review Guidelines:
4.2 Minimum Functionality
"Your app should include features, content, and UI that elevate it beyond a repackaged website."
The web application from a WebView does look and feel like a native application (android/iOS-like animations, functionality). But it is also essentially just a "repackaged website", as it's not inherently different from the application accessed from a browser, aside from being rendered in a mobile view.
The information I've read online about this has been pretty hit or miss, and seems to be pretty dependent on a case-by-case basis.
I want to ask about the security of web application.
I'm developing on web site for an inventory management system by web service.
And wrapping as android application with the webview.
But my client ask the website can be opened in android application only.
I think it is possible with agent header when web server response to request.
But it just a makeshift.
So is there any way to check the website is opened in browser not authorized application?
I used spring boot for web server.
This is not possible. Once you expose an endpoint publicly, you can always try to connect to it with whatever software supporting the protocol (or an analyzer which will reverse-engineer the protocol).
This said, you can make it difficult by obfuscation.
One solution is to use information provided by the client (browser in your case). This is usually the agent header (as you mention) but can also be some fingerprinting. You could for instance detect the size of the screen and make some decisions from there on.
Another solution is to use some secrets (better call them "secrets") to show the backend application (or API) that some specific code is calling. I can imagine that you could bundle the HTML/JS/CSS code in your application, together with a key so only the application owners will be able to send a recognizable traffic (recognized by the backednd).
All of this is more or less difficult to crack but with some layers you will get rid of at least some population which would like to access the site via other means than an app.
I need a way to communicate and control from my app, every other app in a mobile android device.
Is there any communication protocol like SOAP (Web Services) for installed android apps?
I have found a way to open from my app, other apps but I can not control them to send and receive data.
Is there a way to do this?
Thank you
I need a way to communicate and control from my app, every other app in a mobile android device.
That is not generally possible. Few apps expose any sort of API that third-party apps can use to "communicate and control", outside of making a launcher activity available.
Is there any communication protocol like SOAP (Web Services) for installed android apps?
An app can choose to allow third-party apps:
start one of the app's activities, or
start or bind to one of the app's services, or
work with one of the app's ContentProviders, or
send broadcasts to the app
All of these (activities, services, providers, receivers) represent Android components. Those components that are exported can be invoked by third-party apps, through IPC, subject to any security conditions the app may put in place (e.g., third-party app must hold a certain permission).
Whether an app does any of this, and to what extent that it does, is up to the author of the app. This is no different than with Web services -- you, the client, cannot force a Web site to magically sprout a SOAP Web service. Similarly, you, the client, cannot force an app to magically sprout one of these IPC mechanisms.
I have a web based service (running for years) that works with google apis.
Now I would like to create an android and iphone ui (using xamarin) that uses my web services which in turn talks to google apis.
Given that I don't talk directly to google apis from the phone, do I need to use a web browser control to let the user login, or can I authenticate my server and establish a session natively on the phone?
I'm afraid I need to use a browser window, and I don't think it's user friendly to have to login to a google account in a browser window on the phone.
(I want to keep the logic on the server, so that the phone apps and the web ui uses the exact same code for it's calculations.)
EDIT: It seems Cross-client identity is what I'm looking for.
It can be done natively. See this video https://www.youtube.com/watch?v=9wAx39s10yw which explains all of the procedure using cross-platform authentication.
I'm going to build application for web (asp.net mvc) and mobile (iOS and Android). And all three of them must communicate (share data, user authorization etc.) . What is best way to this ? Using asp.net web api or azure mobile services ?
EDIT
I was also wondering what was best practice for scenario like this: I have data base and business logic in one project which needs to communicate whit web and mobile using service. So which technology is best to develop this service Azure or web api or smth. else ?
Your question is very general.
ASP.NET Web API is just a framework to build RESTful web services which you can host everywhere. It does not help you with your task to "communicate (share data, user authorization etc.)".
Azure Mobile Services is an Azure hosted PaaS that actually provides everything you need and even more. It also provides you with ready-to-go RESTful web services that you might implement using ASP.NET Web API as well, but in addition to that it also provides support for federated identities, data sharing etc.
So, I would say since you seem to be somewhat new to this area, you should try Mobile Service, for they are very well documented and there is plenty of nice tutorials suitable for beginners, here is my favorite one.
You can also download a project template for Android and iOS after you have set up your own mobile service and just extend it. This is really a great help for beginners and hobby developers.
UPDATE:
Let's approach your question with some fictional scenarios for different solutions offered by Azure:
Azure Mobile Services cover the scenarios where you have multiple (mobile) devices running occasionally connected applications that need to synchronize their content through the cloud.
AMS provides you with the possibility to implement the custom processing logic for data requests and updates; it hides the burden of implementing and hosting a web service.
About 90% of the logic is set or written directly in the management portal, the rest is just the client logic.
The main purpose of this service is data sync (this is the core functionality), all other services (authentication, logging, scheduler) are just auxiliary.
The language used for development is JavaScript, the whole development is similar to server-side development using frameworks like Node.js.
Azure Web Sites is the way to host your code within IIS, that usually would be a web page, but nothing hinders you on hosting your web services (Web API based or even full-fledged WCF) here as well. Azure Web Sites are easy to deploy and this is a rather cheap solution for hosting web services, provided you allow other IIS applications (from other users) to run here as well (shared instance), but you can also prioritize your application by going for a reserved IIS instance (and pay more). Sure, you can reuse most (virtually all) of your existing business logic here (unless you need something exotic like interop or shell access that can't be hosted in IIS natively). The disadvantage of this solution is that your logic will run within the context of your web service and for long running processing this might be a non-optimal solution.
Azure Cloud Services allow you to defer the processing of logic rules and to decouple the logic from the service input. In this scenario you can have two kinds of roles, typically called web role and worker role. Web role provides endpoints for your services and queues the requests, the worker roles reads the queue and does processing. This allows you to fine tune your load balancing and capacity planning, increasing the number of parallel instances with web roles and worker roles.