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.
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 have been searching around and have found several examples of ways to connect to Cloud Storage from Android clients but these methods are quite old now. This is generally using a p12 file and newer examples show .json files to hold settings.
I have looked at this... https://cloud.google.com/storage/docs/json_api/v1/json-api-java-samples and it sais "Note: This client library is separate from the Google Cloud Storage client library, another option for interfacing with the the JSON API using Java." giving multiple options!
So my question is.. What is the correct way to implement the client (Android) side of Cloud Storage?
The Cloud Storage JSON API Client Library for Java is an older, auto-generated client that is used as the underpinnings for the newer, under-development Google Cloud Java Client for Storage. The latter is part of the google-cloud project, and aims to reduce the amount of boilerplate code needed to interact with the service. If you have a pointer to your Android sample that needs updating, we can take a look.
Another option for mobile development is to use Firebase Storage, which ultimately writes into Google Cloud Storage. Firebase is all about mobile and untrusted clients, and provides additional security rules that allow you to provide access to users that do not have a Google account.
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.
I'm building my first app which uses an external database for storing data..
And I'm struggling with the following question:
How to connect with my database: use the Amazon DynamoDB sdk for Android or create a restful api based on NodeJS on my own server, which passes the data to DynamoDB?
I'm very new to this and when I look over the internet I see amazon suggesting to use the SDK.
The only problem is, if I want to change the data structure in the feature, what kind of problems will my users experience with the current versions of the app? And is it safe to save my Amazon keys inside the app (cause people may be able to decompile the app)?
On the other hand, I do have to pay for the extra server which handles the connections between my app and DynamoDB. So... is it worth it?
So I'm quite struggling with this.... What do you guys think?
I would go for direct access from your mobile application to DynamoDB.
This would allow you to scale your application much easier : you do not need to maintain, operate, secure a middle layer, AWS does that for you. You will also save on the cost of running your couple of NodeJS servers, load balancers etc ...
You should not store access keys / secret keys in your application but rather use AWS Cognito Identity service to dynamically receive access keys and secret keys for your user session. These keys will be limited in scope to whatever permission you define for your Cognito users and limited in time (default is 15 min)
Cognito works with backend identity providers to authenticate your users (Facebook, Google, Amazon, openID connect or your own backend) and can also work with unauthenticated users.
More about Cognito : http://aws.amazon.com/cognito/
More about Cognito ID for Android Mobile Applications :http://docs.aws.amazon.com/mobile/sdkforandroid/developerguide/cognito-auth.html
I'm not sure that the accepted answer is complete because it does not acknowledge use cases, and it does not address the question asked of "what if I want to change the data structure." Well, if you have outdated clients, and change the data structure of the documents in your nosql database, then those clients will not be able to access it. I don't believe DynamoDB offers a middleware platform to support this kind of old-to-new model adaptation. You'll have to force an update to your clients.
In fact, there are many operations beyond user-based permissions (which Cognito does do well) like this that you might need middleware for. Perhaps you want sorting logic to occur at request-time, and not maintain a copy of that sorting logic in every client application.
The question of "is it worth it" probably depends on the complexity of your application and your users' relationship with the data (ie. if the presentation layer basically just wrapped data -- then directly access DynamoDB. If you your presentation layer is not just wrapped data, then you should probably use custom middleware). In truth, I stumbled upon this question while running my own cost-benefit analysis, and am not sure which approach I will take. Another major factor of mine is that I might choose to switch database solutions in the future.. this will be more challenging to update on every client, if my clients are directly accessing the DB.
The one certain conclusion I've reached is that you should use middleware somewhere in your system, such that you can decouple your database vendor from either the client logic or the server logic as much as possible, eg. in a mobile app:
writeToDatabase(Data data){writeToDynamo(data);}
To achieve this, AWS suggests using Amazon Api Gateway as a proxy for AWS services, and even has premade configurations for Amazon API Gateway to behave as AWS service proxy.
My Android project currently requires an authentication of some sort (mobile phone number / facebook / gmail... I haven't decided yet), frequent read/write operations from the server's db (not a big amount of data, and no images/videos), push notifications and in the future, possibly complex queries on the data stored.
I started reading about Parse and Google cloud (in google, specifically about mobile backend starter).
I can't seem to find a comparison between the two. I've read that both have relatively easy implementations, but except for the platforms (I'm using Android, so both work for me), I can't find a place that says "Parse is better at ... and Google cloud is better at ...".
So my questions are:
Can anyone please give a recommendation / reference?
Does one of the above platforms at all fit my project? (I am familiar with AWS, and would like to avoid it so I will not need to worry about stability and scalability)
Shameless plug: I'm a developer at kii.com
You can also take a look at Kii Cloud MbaaS
Among its features:
User management, including authentication using Facebook credentials.
Data management that never locks you into any schemas.
File storage and cloud backup for your app.
Push notifications so you can push messages to your users or to your
app itself with updated instructions for functionality.
Geolocation so you can offer location-based services.
Server extension to define your own business logic without managing
servers.
Android, iOS, html5 and unity support