I recently started using Kinvey as a backend for my Android app. The documentation doesn't have a lot of info about Collections. I want to know if it's possible to create Collections using the same concepts applied to MySQL tables for example:
A Collection called Users will hold a User ID, Username, User Email
And another Collection called Items corresponding to users -> Item ID, Item Name, User ID.
Has anyone successfully created Collections like this using Kinvey?
kinvey.com
I have also contacted their support team about this bu no reply yet.
I'm an engineer at Kinvey and can help you at this. Kinvey uses a NoSQL store on the back end, so the concepts are a little different than those of a relational database system like MySql, but in general the same thought process can apply. A Collection is similar to a table, although it is Schema-less. This means that attributes (columns in MySql terms) can be added dynamically as needed. You simply create the collection, and then start saving data objects to it. For more info on our Android library specifically, take a look at our Data Store User Guide.
Related
I am a novice android programmer, and I am developing my first android application. I'm trying to figure out if firebase is suitable for my needs.
My app looks like this:
users add the product to the database by filling in the product
fields
products are stored in the database as objects with simple fields (numbers and strings)
users search for a product in the database to compare its fields according to different criteria
users edit (update) product fields
users have their own accounts
My priority is the ease of use.
My question is:
Is Firebase suitable for my needs or is there a more suitable solution?
Do I understand correctly that I am interested in the Cloud Storage product?
users add the product to the database by filling in the product fields
Yes, you can achieve this using either Cloud Firestore or the Realtime Database. In both cases, you can add the data as a Map object or as a custom object of your choice.
products are stored in the database as objects with simple fields (numbers and strings)
Yes, you can achieve that. Here are Cloud Firestore supported data types, as well as Firebase Realtime Database data types.
users search for a product in the database to compare its fields according to different criteria.
None of the above databases supports native indexing or search for text fields, so you can use third-party libraries like Algolia or Elasticsearch.
users edit (update) product fields.
These are basic CRUD operations that are supported by both databases.
users have their own accounts
In this case, you should use Firebase Authentication, a service that works perfectly with both databases.
Is firebase suitable for my needs or is there a more suitable solution.
As I see in your requirements, yes, it suits your needs.
Do I understand correctly that I am interested in the Cloud Storage product?
For storing data (objects) you need to choose one of the above-mentioned databases, or why not even both, and for storing files, you should indeed use Cloud Storage for Firebase.
You could use firestore for this. Although full-text search won't work, you can use algoia/elastic to do full-text search.
I need to do a application that incorporates a database and I'm thinking about using the Firebase Realtime database.
Basically the application is an information app. It has different categories, Shops, Restaurants, Attractions, ect. I've almost completed the Udacity course on firebase and It can do what I need, I'm just not sure it's the most efficient.
They way they explain the database is structured is having a key so my key would either be Shop, Restaurant or Attraction. Below the Shop key there would be "Shop1","Shop2","Shop3", ect. Now this is where my problem comes in, inside shop1 I'm planning to have the shop name, longitude, latitude, description, and other details about the shop. Each time I want to add a new shop I'm going to have to add a child of the shop then under the new child I'm going to have to manually type the key and value.
This will get very time consuming and I was wondering if this is the correct way of adding data to the database ?
Thanks
Is Firebase the best way to store data for an information app?
This question is primarily opinion based, but since Firebase gives you so many choices under the hood, it is becoming a pretty decent service. Being scalable and the quick response of the database is a great option.
Read more about a good Database Schema here and about populating the database, you can write cloud functions and that would be a pretty advanced level of implementation.
May be your question is "What is the best way to store data for an information app in Firebase?"
In your case, it will be difficult to save sequential key without keeping track the number of shop.
I would rather suggest using push(shopModel). If you're using push, the key will be automatically generated and it's guaranteed to be unique and order by time inserted.
Sorry if this question is very basic but I started seeing no sql storages for an android app and I found App engine endpoints and servlets that as far as i understood, expose an api to do CRUD operations.
The thing that it is difficult to grasp for me is the format of the objects stored and it's efficiency. I read that by using libraries like objectify/gson the objects are stored in json.
Now, suppose I have a class Person that has an attribute Friends that is a list of Person. If two different persons share the same friend it will be stored in two different json objects, duplicating the information. Should I make a different class for the storage that keeps the id of the friends and then when loading a person find his/her friends from a hash map of Person? But that would imply requesting all the Persons to the Web service to construct that map even though I only want to find a Person without friends.
Another way would be to make the 'query' in the server side, return the friends objects of the person that is requested and put them in a hash map for future 'queries' of other Persons. In this way I would transfer less data each time but i would consume more times the webservice which can lead to exhaust the daily request limit quota.
Again sorry for the beginner question. I would appreciate any directions, patterns to solve this problem, in a nutshell how to efficiently -in the sense of space- store objects and efficiently retrieve them -in the sense of the amount of queries and data transfer from the web service- in a nosql database.
Indeed Google Cloud Endpoints will allow you to do CRUD operations through one or more API(s). But, as detailed in the documentation (https://cloud.google.com/appengine/docs/java/endpoints/) it allows you to do much more than that, e.g. "all of the services and features available in App Engine, such as Google Cloud Storage, Mail, Task Queues" etc.
You can use Objectify when the back end of your endpoints is Datastore. Objectify is the open-source API for Java which is recommended by Google. However, note that the data is not store as json but as Data objects that are called "Entities" which can have properties of different data types. See https://cloud.google.com/appengine/docs/java/datastore/entities for more info.
The approach to NoSQL database is very different from relational database when it comes to data modelling. You should not care about normalizing your data and storing the same data multiple times is quite a common approach.
In your case, if two persons share the same friend, you would save the friend information two times, in each person entity. In such a way, when you will query the list of friends for one person you just have to get the person entity through Objectify in your endpoint: it will include the list of friends and it will automatically be transformed to JSON when sent to the front-end.
I would suggest you try the Google examples (https://cloud.google.com/appengine/docs/java/endpoints/helloworld-java-maven) or even better follow the Udacity MOOC which will help you understanding the entire stack https://www.udacity.com/course/developing-scalable-apps-in-java--ud859
The tutorials from Romin Irani are also an excellent entry point to this technology https://rominirani.com/google-cloud-endpoints-tutorial-part-1-b571ad6c7cd2#.p4h8rmkt3 There are tutorials for Eclipse as well as Android Studio (I recommend using the second one).
I am coming from a Sencha Touch background into Android/ Java programming.
For a simple List based application (say a Note, that has a Note Title, Note Text, Note Author, Note Date Created, Note Comments),you could define a Note model with Title, Text, Author, Date Created and a Comments model, that has the Comments Text and Linked Note object/instance. (the basic way to make a database design)
You can then define a Data Store (a local database) that knows which endpoint to fetch the serialized Notes data from (essential a JSON array of Note objects, with embedded comments objects inside them), and define functions to draw out useful info out of the JSON array and put it into the Notes object
The View (the actual list display of notes) then accesses the Notes Stores and anytime the Store is changed the ListView is updated automatically.
Is there such an elegant mechanism in Android? I experimented with ORMLite (which is somewhat similar to stores), but is there a way to achieve this tight external endpoint -- local store -- list view binding in Android?
Out of the box, Android offers but one type of database, SQLite. While there are other storage options (file system, preferences, etc) it sounds like you def want a DB. Android has a nice write up for all storage options, and here's the SQLite section.
To bind that data with a ListView, you'll need to use a CursorAdapter. If you don't want to handle the view generation part, you can instead use the SimpleCursorAdapter. However they are more or less the same thing. As the name implies, these adapters work with Cursors. Cursors just expose the results of running a query on a database.
To achieve the automatic updates, you'll need to use a CursorLoader. Basically this guy handles querying for data on a background thread, then feed you the results on the UI thread. When there is a relevant change in the DB, it'll re-run the query and return you the latest data. Android has a nice write up explaining how to do this.
I currently have an Android app which uses 3 SQLite database tables and I want to store this data on the cloud in my Java-based GAE app. It will be used as backup and also, the user will be able to view it in their browser upon logging in. The user is entering data into the Android app so all the data in the 3 tables belongs to that user. Is there a recommended way of storing this type of user-specific data? Should I store user email with each entity in order to identify it or have a User entity as the parent and all the entities belonging to this user as the children? Are there any advantages of using a parent in this case?
It all depends on how many records you have for a single user, how frequently these records are updated, and how you access this data (what kind of queries you need, etc.) So there is no simple and definitive answer to your question.
Most likely, you will be fine with either approach unless you have thousands of records per user and they update them every few minutes, at which point you may run into some limitations.
Note that you don't need to include an email address to identify each record. Typically, you create a user entity first, and then you use an id of this user entity (a Long) to identify all other entities that are related to this user.
My two cents.Unlike Sqlite,Google App Engine is not a relational database so saving your SQlite data to GAE won't be a straightforward task.However, you could create an app on GAE where you use the useremail from ur app as the Entity key.You can then retrieve the user specific info based on this key.All(well,the most important thing)you need to do in this case is find a way to send that data from your app to GAE.