I followed the tutorial at Amazon DynamoDB to make my android app write the data to DynamoDB. It works great. But, after reading the thread Using Amazon RDS with android application I realize I need to have REST API between my Android Application and DynamoDB.
Where is the documentation for REST api (and gateway api); is there any working example using such api, that would help me build REST API in AWS that can accept requests coming from Android apps
In a classical approach, you would have a dedicated API server, that exposes calls using REST (or whatever) to the clients (Android apps in your case). This API server can be in any programming language, .Net in our case. The API server typically contains an API facade that the client can call, a service layer that is called from the API facade and contains business logic and then a Data Access Layer that actually makes the calls to DynamoDB or whatever DB System you have behind. This is reasonably clean, as you can have several API facades, e.g. for a backend system, for integration systems, etc. The actualy business logic, if any, should be in the service layer.
In terms of infrastructure, we run our API server on AWS Elastic Beanstalk, which greatly simplifies deployment. You need to be able to handle various API versions, so that an older Android app which uses different API calls will still work after you have updated the API.
Having said that, for simpler projects with very little actual business logic this may be overkill. Amazon offers the API Gateway that allows you to expose logic to clients and you will be able to access DynamoDB or whatever behind it. I suggest that you experiment with the HTTP Endpoint walkthroughs to see how it works. Once you have it running, the advantage is, that you don't need a dedicated server for your API calls, but can handle everything using the Gateway and you pay only per request, so it scales nicely.
Once you know the technical approach, it makes sense to first define the interface (the API) between your clients and the server; so you can also create stub methods and work independently between the Android and Server logic.
Related
I am not clear with architecture of using Firebase for Android apps. Can you make everything from client side without using Cloud Functions, since it is possible to access database with functions in java. Is it used only for security purposes to restrict client from making problems?
Most functionality can indeed be performed directly from the client-side app, using the Firebase SDK for your application platform. And whenever this is possible, I highly recommend implementing it this way.
But certain types of functionality don't lend themselves well for performing directly from the client. They typically fall into these main categories:
The operation requires privileged information. For example if you want to send push notifications to your app users, you will need to specify the FCM server key. As its name implies, this key should only be used on a server you control, or in an otherwise trusted environment, such as Cloud Functions. This same reason also applies to things like interacting with payment gateways, and many APIs in the Google Cloud Platform that require server-side API keys.
The code of the operation itself is a privileged operation. For example you'll often find this in games, where you want to validate that the user isn't cheating. If you put this code in your app itself, a malicious user can see it and use it to circumvent your detection. By moving the code into Cloud Functions, the users of the app can't see the code anymore.
The code requires more "power" (CPU, network, memory, disk space, battery) than you can rely on being available on your user's devices. Since Cloud Functions run in Google data centers, they are always connected to mains power, they have a reliable CPU, a great network, and configurable memory/RAM disk space.
Another advantage is that Cloud Functions are the same for users on any platform that you target. Say you have a complex algorithm that you want the users on Android, iOS, and Web to use. If you implement the algorithm in Cloud Functions you only have to implement it once, and then call it from each platform, instead of having to implement the algorithm for each one.
I also recommend that you check out the list of use-cases in the Cloud Functions for Firebase documentation.
I'm going to implement a Web API to be consumed by mobile devices (android, iOS) and web applications. From what I understand about Web API, it should be client-agnostic, so no matter which client consumes it: a mobile app, a web application, a console application, etc.
My concern comes when a mobile developer suggested me to design all the API methods according the mobile app views. For example, in one view I need to display information about a user and its products, I think I need to create 2 methods:
/users/231
/users/231/products/1453
But according the mobile developer I need to create only one method that returns all the view data in only one call:
views/initialviews/params
His main argument is that we need to reduce calls to server. But the disadvantage I see, is that if at some point the screens/views change, we'll need to change the API, also other clients could implement different views structures.
Is it a good practice to provide API methods per view , only one call that returns all the data required in that view?
or
is it better to handle atomic/single responsability methods in API to be consumed by clients no matter how many calls clients do to the server?
Please, guide me a little about this, and tell me if the multiple calls affect performance or have disadvantages.
I think no matter how many calls client do, if the response from server is milliseconds. So client works with a composition of calls.
Any article or more references is welcomed too.
Thank you in advance.
Perhaps you could implement Batch-Requests? Facebook also uses this approach.
Web Api Batching
How to avoid 26 Requests in your API
Introducing batch support in Web API and Web API OData
Its driving me nuts,somebody pls help me out here.This google cloud stuff is confusing me.I m little bit off here,something is missing in my understanding.I want to use cloud storage.Now I have a default Android Studio Project which has an android client,an app engine backend,consisting of entity,endpoint,library for client etc and A WEB CLIENT.While going through the google cloud storage doc, I found the following-
Google APIs Client Libraries
Google Cloud Storage Client Library
Google Cloud Storage API
Google Cloud Storage JSON API Client Library for Java
I m still not sure what each one does actually.I dont know how to implement cloud storage in my android client.
If I use cloud storage why do I need app engine backend app? I dont need API for my backend,right? I can directly consume my bucket using Google Cloud Storage JSON API as we do using Volley. Am I missing something here?
Is there any "hello world" tutorial on how to use cloud storage from android client/app or can anyone help ?
If you're 100% sure that you don't need any back-end logic, and never, ever will, see Using Google Cloud Storage JSON api in android for direct Android <-> Google Cloud Storage operations.
Usually, in the course of a successful app's lifetime, some logic on the back-end is eventually required (e.g to deal with different versions of clients -- not all update in the same nanosecond:-), so it's normally more prudent and future-proof to have the front-end go to an App Engine back-end that can apply whatever logic is required besides providing access to Cloud Storage.
At version 0.1 the amount of logic required may be very small (though usually at least some kind of authentication) but if the application is successful likely new versions will be required and the back-end will be able to evolve to deal with that.
Then in a comment you ask:
As far as I have understood the appengine, if I need to store data in
NoSQL datastore, then I can make a backend with endpoint support which
will in turn consume my Restful API.
A more common arrangement is to have the back-end supply a restful API for the front-end to consume; and, that's what Cloud Endpoints can do for you (though you could design and implement that restful API in many other different ways, if you'd rather).
I mean, can I/should I consume the cloud storage rest API from within
my backend endpoint, which itself is used to call my own rest API?
One robust architecture is based on separation of concerns. Let the front-end running on Android concern itself essentially with the "human interface" part of your overall application -- presenting data clearly and usefully, interacting with the user.
The front-end can delegate just about every other concern to the back-end, including both storage and most aspects of app-specific logic concerned with what to store where, whether to allow access (of what kind -- read/write or read/only) to certain data depending on authentication of the user, and so on.
This delegation can take advantage of Cloud Endpoints, or, you could choose to design and implement it differently (e.g producing and consuming the app's REST API via different frameworks).
Why do I need backend logic to deal with different versions of
clients?
You'll need that, for example, if and when a new version of the client wants to store and retrieve more data than older versions did -- for example, in some future version you may decide it can be useful to add GPS location data, or optionally multiple photos or an audio snippet, etc, etc, which were not used in previous versions. (It's hard to be specific of course without any idea as to what your app is all about, but in general there's always something that you didn't do in early versions and want to add to some future one:-).
In such cases, the back-end needs to know what bits and pieces of data, exactly, to expect from the client, and conversely which ones to serve back to the client -- and those crucial aspects will then depend on the client's version; and without back-end logic to mediate, smooth seamless transition between old and new clients won't be feasible, particularly during the transitional period when some clients have upgraded to the newer version but others are still stuck on the old one.
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.
I have a set of computations that I am currently running on the Android. I want to move these computations from Android to a cloud (possibly google c2dm architecture or any other free service) but I dont have enough knowledge on how to use the c2dm. I will be sending a list of strings to the cloud, do lots of computations on the cloud and then return the rearranged list of strings to android.
Can anybody help me with this (as to how to connect the cloud with an android app)?
Thanks
Anks
You could use HTTP POST-GET requests to communicate with server, send and receive JSON/xml data.
EDIT that's almost enough to leverage client-server communication in your app.
http://developer.android.com/reference/java/net/HttpURLConnection.html
http://www.ibm.com/developerworks/opensource/library/x-android/
http://www.ibm.com/developerworks/xml/library/x-andbene1/
I am unsure what you mean by "google cloud".
One way to achieve this would be to use Google App Engine. It allows you to run server applications developed in Java/Python on Google's infrastructure.
What this means is that you can develop the server side yourself, and therefore implement any protocol you like to communicate with clients, that is, create your own web service.
As Mighter mentioned you could perform raw HTTP requests. However, there are a number of existing protocols for remote procedure call: SOAP, XML-RPC, etc..
I personally tend to like JSON-based protocols. It's easy to make your own implementation for that type of protocol, but you may be interested by this JSON-RPC library for Android, as an example.
Also check this other question: How to call a SOAP web service on Android
Once you'll have your web service ready, whether using SOAP, JSON-RPC or else, then you should be able to create a client, and expose the remote service calls through Java classes. If well designed, it could 1. feel as if you were calling methods on a local object, and 2. allow you to swap with a local implementation in case the network is unavailable.
I think it depends of how heavy your computations are, or how much computation power do you need. you can try to write a simple app engine server which handles post requests and return a JSON format answer. in case your computations are complex i would use google compute engine and install my custom stack.
in both cases you would need to write a server side to handle your data. if you use google app engine you can write it in java, python, php or go. if you use compute engine you can basically write it in any language that you can run on linux.
hope it helped!