I would like to know if we can pass a database table as http response object to android application? I am using a serverside mysql database and I can pass a string to the client side right now. So I concatenated each column with a special character in server side and extracted it in client side to transfer a single row. But in case of table it is not possible, as the table may have huge amount of data. Do any one know how to fix this issue?
Generally speaking, you will use some kind of serialization to exchange data between your Android application and your server.
The two most used serialization formats are XML and JSON -- I generally prefer JSON, but it's a matter of personal choice, I suppose.
You should be able to find JSON libraries in several languages, including the one you are using on your server, and JAVA (for the android-side).
What you want to do isn't possible. You need to design your system so that the whole table isn't needed in the Android application. Instead, you can send a message with the number of rows found and perhaps their ids. Then, you would make individual http requests to retrieve the contents of each row on a when needed basis.
Related
Implementing and managing remote or cloud databases in Android Applications is new to me. I am currently making an app that would take in thousands of "entries" to a form, think of it as an attendance app. Right now I've decided to use JSON as my database type and Parse as my BaaS. I need some tips on my decision.
I don't actually see JSON suitable for this because it is a "text" file that can easily be modified or if I somehow accidentally append an extra bracket it would render the whole database corrupt whereas SQL use queries like INSERT which I think is more secure. I just picked JSON because it works well with Parse. Do you think this is a good idea?
Another is what if the JSON file will accumulate tens of thousands of entries, how do you manage this huge database? Do you split it into several files (eg. every 1k entries make another JSON file) or is it enough to just dump all the data in that one JSON database file?
When using BaaS do you just sync the data in that server or do you also make backups of some sort (I don't really know how to put this)?
Thanks in advance!
JSON is not a database, but a data interchange format. You can have a database that uses JSON for communication, for internal representation, etc. but that does not make JSON a database in itself.
Parse itself manages the organization of the data. You communicate using JSON but don't have to care about how it's stored, updated, etc. internally.
So in your app, you should use SQLite for storing such amounts of information, or, depending on the app, just send it to the Parse server and execute the queries against it. You can see how it's done in the Parse Android documentation.
Read Update 1 for a beter question description. Sorry about that.
I'm trying to figure out how to build a Android App and Web App that syncs there data.
I know that I should make an REST API for the MySQL database to sync with the Android App.
I have made a App before that syncs data but only for retrieval (SELECT queries) on the android side.
I now want to make a Android App / Web App that should create/update items on both platforms and syncs so both have the new/updated items. The app should also work offline.
I'm used to creating id's for most database tables as key with autoincrement. Now that I'll have 2 databases i'm not sure how to create those unique IDs. Or should I ditch those id's and use a combination of columns as primary key (with a timestamp or something).
Hope it makes sence, english is not my native language.
UPDATE 1
Narowing the question:
So i have a MySQL database with an PHP API. The API will be used by the Web App and Android App.
Question is how to handle offline data creation in de android App. If you rely on a id with autoincrement of the MySQL Database.
Example: When creating a person how to get an id for that person (If the MySQL database handles ID creation)
Thanks in advance,
Otto Vanluchene
What you're asking is a very broad question and there's a lot of options, but this is how I do it.
HOW TO HANDLE NATIVE SIDE REST CALLS:
First of all I use an HTTP library to handle my GET/POST REST API calls. It handles the callbacks and can be super helpful.
This is the one I usually use:
LoopJ's Async HTTP Callback Library
This will handle GET and POST requests with a lot of cool features such as custom timeouts, JSON format, onSuccess() and onFailure() methods, etc. There's a lot of working examples of this library too. I've used it in all my apps and haven't had any problems yet!
DATABASE SETUP:
Your going to want to create a MySQL database to store all your data. You may want to read up on common DB practices.
API SETUP
I write all my APIs in PHP, but that's just my preference. The APIs you write here will be used in your web AND mobile apps to keep things consistent. Assuming you use GET, you can just pass an argument (which I usually call "callback") that will determine what chunk of information the API will return.
For example:
http://www.ottosite.com/otto_api.php?callback=get_users
So in your PHP code, you'll have it checking if callback=get_users, and if it does, it will query the database for all the users, format the json string, then simply echo it.
This may return something like:
{"status":"success","users":["user1","user2","user3"]}
So this is obviously a JSON formatted response, then in your app, when you call that API, you just parse the response into a JSONObject (JSONArray for users) and then grab whatever data you need from it.
Hopefully this helps.
I'm trying to create a REST API to interact with a MySQL database. I want to use this API to access the database from an Android or iOS device without (obviously) exposing the database directly through the application. But I'm having problems wrapping my head around a key aspect about REST and the implementation of an API designed on its principles.
I understand the concepts of REST from the theory stand point. What I've been struggling for days trying to grasp is how a REST URI maps to something located on a database server.
If I make a GET request to a server for a resource with a given URI, say http://www.example.com/resource, internally, where does this go to on the server? The way I understand it, is that it goes to the root directory, then to the "resource" directory. From there it returns all the files within that "resource" directory. I'm simply confused because the resource is located on the database server and not the server where the API is being called from. Does the resource path/hierarchy represent actual directories on the server or is it an abstraction of the resource? If the latter, then what do I do with that abstracted resource name to make it map to a table or row in a database? It's been frustrating not being able to find concrete implementation examples of this where I can easily understand how this URI path works internally.
You can use a framework to do a lot of the work for you, but what happens under the hood is no magic. In some way, the URIs map to some database tables. They don't refer to a certain directory structure, but try to explain a hierarchical relationship between the resources.
For example, let's say that we're modelling a university. The elements in the database are stored in one of two tables, either Faculties or Courses. The Faculties table consists of rows describing the Faculty of Law, Faculty of Medicine and so on. It has a unique faculty_id column and then columns to describe whatever we need. The Courses table has a unique course_id column and a foreign key faculty_id column, to tell which faculty the course belongs to.
A RESTful way of designing this API might be
/faculties to get a list of all faculties, retrieved with SELECT * FROM Faculties
/faculties/2 to get the information about a certain faculty, retrieved with SELECT * FROM Faculties WHERE faculty_id=2
/faculties/2/courses to get all the courses belonging to a certain faculty, retrieved with SELECT * FROM Courses WHERE faculty_id=2
/faculties/2/courses/15 to retrieve a certain course, if it indeed belongs to faculty 2, retrieved with SELECT * FROM Courses WHERE faculty_id=2 AND course_id=15
The exact implementation of this depends on the programming language (and possibly framework) that you choose, but at some point you need to make choices about how you should be able to query the database. This is not obvious. You need to plan it carefully for it to make sense!
The result from the database will of course have to be encoded in some way, typically XML or JSON (but other representations are just as fine, although maybe not as common).
Apart from this, you should also make sure to implement the four verbs correctly so that they match the SQL commands (GET=SELECT, POST=INSERT, PUT=UPDATE, DELETE=DELETE), handle encoding negotiation correctly, return proper HTTP response codes and all the other things that are expected of a RESTful API.
As a final piece of advice: If you do this neatly, it'll become so much easier for you to design your mobile apps. I really can't stress this enough. For example, if you on a POST request return the full entry as it now looks in the database, you can immediately store it on the phone with the correct ID, and you can use the same code for rendering the content as you would if it had been downloaded using a GET request. Also, you won't trick the user by updating prematurely, before you know whether that request was successful (mobile phones lose connection a lot).
EDIT: To answer your question in the comments: Creating an API can be seen as a form of art, and should probably not involve any coding in the design stage. The API should be meaningful and not rely on a particular implementation (i.e. a different database choice shouldn't affect your API). Your next task will be to create ties between the human-readable structure of the API and your database (regardless of whether it's relational or something else). So yes, you will need to do some translation, but I don't see how the query string would help you. The typical structure is api.my.website/collection/element/collection/element. Queries can be used for filtering. You could for example write example.com/resource?since=2012-06-01 to retrieve a subset of the elements from your 'resource' collection, but the meaning of this particular query is to retrieve something you couldn't express with an unique ID.
The way I understand it, you think that incoming requests must always go to separate files based on the way PHP and HTTP servers work. This is not the case. You can configure your web server to route every request to a single PHP file and then parse $_SERVER['REQUEST_URI']. Depending on your choice of HTTP server your mileage might vary, but this is essentially what you want to do.
By googling I found a list of frameworks for PHP but I don't know any of them. There are others, though, and I also recently heard someone mention Apify, although I can't tell you much about that either. PHP is probably one more the more common choices for implementing an API. cURL, however, is a library/tool that's only designed to connect to other websites, as far as I know. You can certainly use the command line version of it to debug your API, but I don't think you'll have much use for it on the server side.
I think you should start with what framework you want to built the REST application from. Rails, RestEasy for java, Codeigniter, all have the basis for good REST routing capabilities.
This includes abstracting URL's from the underlining resource either from database or even business processes. They accomplish this using URL mapping, or creating a Facade for abstractions.
Generally REST does not really differ from tradational GET/PUT/POST with query parameters. Infact Apache URL rewrites usually are used to support REST style routing. I recommend you should pick up one of the frameworks and study how they implement this functions. Rails i thing has significant strength among other frameworks.
The title almost says it all.
I'm building an Android App to collect data on sites. The data is stored in a sqlite database on the unit.
I'd like to transmit them to a web server over wifi.
The data is to be stored in sql form and analysed on the web server, then graphed on a web page.
I though about making a csv and send it to a php page that would parse it and write it to the server sql database.
I saw alson json, but must read more about it.
What are the best options to have the data transfered with integrity ?
Thanks a lot
I would recommend using JSON for a couple reasons:
It is human readable.
There are nice libraries for JSON-Object Mapping, such as Jackson or GSON.
There are JSONObject/JSONArray classes that are a part of Android that are easy to use.
As an additional option you can use Google's protocol buffers. With protobuf you have to include an additional library and write your data in a specific message format, but you gain an automatically generated library with getter/setter methods and the data is sent in binary form. All you have to do on either end is send/receive the number of bytes of the message and then write/read the message itself; the library takes care of populating all of your instance variables.
Of course this depends on what language you are using on the server, as you have to use a protobuf library there as well; but it would appear that there are many different language bindings, including for PHP.
So my Android app uses a SQLite database. I need to "replicate" two or more tables with a central server. The remote server will merge the data from remote client devices (my app), along with a few extra fields to make each record unique, since multiple client devices will be participating.
This must be a common need for developers using SQL replication so I'm hoping someone can point me to an existing (turn-key) solution.
If not, I would like to consider methods that doesn't require me to code a lot of specifics about the table schema. Perhaps I could just specify the table and specify the server and that's it. I guess I could even sqlite dump to file then pass the file?
Thoughts?
Thanks!
Do you only need to send data to the central server (replication as you say), or do you also need to receive data from that server (synchronization)? If you only need to send data and bandwidth/data usage is not a constraint, then you can create a CSV or TSV file with the data you need, optionally compress it and send it to the server, and implement all merging logic in the server. Even if it's not table-specific, you need to determine what to do in case you already have identical or very similar data (overwrite, ignore, error?).
I would advise against just sending raw sqlite data, since that would create an unnecessary dependency with sqlite on the server. Creating a TSV file isn't hard.
I don't think there are any turn-key solutions for what you need, though there are many libraries and frameworks to help you implement it server-side.