I am doing some investigation into developing a iOS App, Android App as well as a bootstrap website. This is really at the early stages of the project and I have been out of software development for a number of years so I am a little rusty, so please forgive me for my questions.
To connect to an external database and/or external C# code from an App, I presume you need to use a webservice? Is this the only way to do this?
What format is required? JSON?
From a bootstrap website, how would I go about doing the same thing? Via a AJAX call to a webservice?
Do most Apps use the internal storage/database for storing data? (I know that's a very general question, I am just trying to get a feel for things)
Thanks for your help.
You will need a web service. Theoretically you can connect to the databases directly with android and iOS, but that's less secure, and making changes is difficult. For example, if you ever want to rename a column in your database, you would break your existing apps. However, if you use a webservice, you can update the webservice to report the column under it's old name.
You can use whatever format you want, but I would strongly recommend JSON. There are lots of powerful, fast parsers out there to handle serializing and deserializing JSON strings out there, and some networking clients that will even handle the translation automatically for you.
You would indeed use an AJAX call.
Yes, that is very general, but most apps will. It really varies what kind of data you need to persist. If you're just looking to cache a feed until the next launch you may use a simple file storage (in iOS you can use a NSKeyedArchiver to quickly build objects into a file format and NSKeyedUnarchiver to build objects from a file), or if you need more complex data relationships you would use a SQLite database on the device. On iOS you should use Core Data to manage the SQLite store for you.
You are correct. To get data from an external database you will need to make a webservice call To a script that returns the data you wish to use.
You can get the data back in JSON or XML format. I prefer JSON as I think it is easier and simpler.
AJAX would be a good way to make calls for your data.
Its a good idea to make a mix of both. You can use and webserver to store all your data but if the user is in an area that they can't use data then it would render your app useless. Normally I keep all the data I need on a server then download and store it in the apps DB for that user. You can then make a request to the server at intervals to see if there is any new data to be downloaded. I would suggest doing a similar thing for the bootstrap site.
Related
We developing an app that will store data locally on phone, on server and share it between users. The access to store and retrieve data will be approximately 20 times a day for each user, it will consist mostly of strings. The app will be cross platform Android/iOS. So before beginning developing DB what you suggest Json vs SQlite or use HTTP Methods: GET, POST.
What are advantages and disadvantages of each, and what do you suggest.
I do not agree that sql is slow. It's not like these devices are using spinning disks. In my app, i've implemented a RESTful API that passes JSON data back. This is easy because on iOS, json can be easily converted to the iOS Native NSDictionary object.
I recommend storing data using sqlite or Core Data because you'll be happy for it later on if you need to query the data. That's what databases are used for, storing and retrieving data easily.
As an alternative, you can also consider building the SQLite database on the server, and actually downloading that file to the devices. This has it's benefits because you won't need to do the actual sqlite processing on device.
I recommend staying away from XML, not because it's bad, but because passing JSON data back has become standard, and a lot of large companies are moving away from XML formats because of the processing power required.
In designing your RESTful API, it's always good practice to use the already available HTTP request methods. Use GET to retrieve data, POST to create new data, PUT to update data and DELETE to remove data. Once you have a beautifully designed REST api, all things things should just fall into place and you'll have an app that's maintainable and scalable on the client and on the server side.
This question really depends on your own area of expertise. If you have good understanding of JSON, then use that. XML is another great way via SOAP (or REST) to distribute data to your platforms, Server -> Device -> Server. My own experience is that JSON with GZIP is small and fast and there exists lots of parsers that is fast. XML has the downside that it gets big quickly but is often easier to maintain over time since the syntax is set in the "namespace" of your XML. SQLite is slow, since its disk based and should only be used for persistent storage of data. Access it as little as possible during runtime. My suggestion: JSON+GZIP, REST-api on server/device, store as much as possible in memory on devices, SQLite for persistent storage on devices and lastly MySQL on server for persistent storage (free, fast enough if done correctly with views and methods).
But as said, this is all up to the implementation.
I want to create a database so both my website and mobile app could draw info from there.
I know how to execute queries with a website, but I have little to none experience with mobile applications.
I heard I can't just use any form of database(mysql, mongodb) because they are not compatible or something.
so how do I create my database so it will be compatible with android iOS and PC.
A few guidelines to get me started would be great :)
Sounds like you need to build an API to handle interaction between your mobile applications and your database, in much the same way your website communicates with your database. The primary difference will be that you will be returning JSON/XML to your apps, rather than displaying HTML to a user.
I thoroughly recommend JSON over XML as it is not as verbose and data usage will drop dramatically. However, if you're data structures are quite detailed / complex, go with XML.
To get started with building an API I'll recommend Slim PHP. You'll probably want some form of ORM also, for which I highly recommend idiorm/paris
The documentation for both of these frameworks is great, so have a dig around.
You can create a database with MySQL and draw info from your site with mysql queries. As for your mobile app, you can use some php pages and JSON Parser to draw data from the database. See example
As you say android doesn't support external databases such as MySQL. The easiest thing to do would be to create a MySQL Database that your website and android app can access.
The website would access the MySQL database as normal but the android app instead posts data such as variables to a PHP script, the PHP script can then get the retrieved data and perform the mysql queryies and json_encode the output and print the encoded data. The android app would then receive the outputted json format and the android app can then decode the json and process the data accordingly.
http://www.helloandroid.com/tutorials/connecting-mysql-database has some tutorials on how this can be done
You need to use Service - Oriented Architecture.
You may use REST API methodology for creating interfaces.
See this example
www.hassanpur.com/blog/2010/09/android-development-implementing-a-simple-client-server-model/
I am new to Android Application Development and a new member at stackoverflow. I am currently trying to design a recipe application. I have decided upon the features of the app and the scope it will cover. The scope is very vast for me in terms of covering all the recipes from all over the world. I am to deal with a lot of data in this process.
I am currently trying to figure a good and efficient way of handling the data in my app. So far, as per what I have read in different forums, I believe that I have two options in terms of a database choice : 1) SQLite 2) Database on remote server (MySql/Postgre)
Following are some of the thoughts that have been going on in my mind when it comes to taking a decision between the two :
1) SQLite : This could be a good option but would be slow as it would need to access the file system. I could eliminate the slowness by performing DB data fetch tasks in the AsyncTask. But then there could be a limitation of the storage on different phones. Also I believe using SQLite would be easier as compared to using a remote DB.
2) Remote Database : The issue that I can see here is the slowness with multiple DB requests coming at the same time. Can I use threads here in some way to queue multiple requests and handle them one by one ? Is there an efficient way to do this.
Also I have one more question in terms of the formatting of my data once I pull it out from the above DB's. Is there a way I could preserve the formatting of my data ?
I would be more than thankful if someone could share their knowledgeable and expert comments on the above scenario. Also this is not a homework for me and I am not looking for any ready made code solutions. I am just looking for hints/suggestions that would help me clear my thoughts and help me take a decision. I have been looking for this for sometime now but was not able to find concrete information. I hope I will get some good advice here from the experienced people who might have encountered similar situation.
Thanks for reading this long post.
What about combining both approaches?
A local SQLite database that has the least recently used receipes so you don't need network all the time. Network is way slower than accessing the filesystem.
Some remote database accessed via some HTTP interface where you can read / write the whole database. And if you want users to be able to add receipes for other users to see you'll need an external database anyways.
SQLite : This could be a good option but would be slow as it would need to access the file system.
Accessing a local database is pretty fast, 5ms or so if it's just a simple read only query on a small database.
But then there could be a limitation of the storage on different phones
Depends on your definition of huge database. It is okay if it is only 2MB which would be enough to store lots of text-only receipes.
Also I believe using SQLite would be easier as compared to using a remote DB.
Yes, Android has a nice built-in SQLite API but no remote database API. And you don't need to setup a database server & interface.
The issue that I can see here is the slowness with multiple DB requests coming at the same time.
A decent database server can handle thousands of requests. Depends on your server hardware & software. https://dba.stackexchange.com/ should have more info on that. Required performance depends on how much users you have / expect.
I'd suggest a simple REST interface to your database since it's pretty lightweight but does not expose your database directly to the web. There are tons of tutorials and books about creating such interfaces to databases. There are even hosted database services like nextDb that do most of the work for you.
Is there a way I could preserve the formatting of my data ?
You could store HTML formatted data in your database and display it in a WebView or a TextView (via Html#fromHtml()) - both can display formatted text.
Databases don't care what type of text you store, for transfer over the internets you may need to encode the text so it does not interfere with the transport formatting (XML, JSON, ...).
A simple way is to integrate Parse into your app. They have a nice framework that easily integrates into iOS and Android. Their plan is freemium, so you'll be able to use up to 1 million API request for no charge, and then its 7 cents for every request after that.
You'll have 1gb to store all your data sets / images, etc.
I don't use parse for everything, but I HIGHLY recommended it for large data schemes because they do all the scaling for you. Check out the API, I think it would be worth your time.
I just started to work on a few of my own projects, and I'm using Parse again. I have to say it's improved a lot over the last 6-8 months. Especially with the Twitter and Facebook integration.
The key issue here is the size of the data - any significant database of recipes would be too large to store on the phone imho,thus you seem stuck with the remote database solution.
As opposed to trying access the remote database from android I suggest you use a a go between web application that will process requests from the application and return JSON objects that you need.
It totally depends on your software requirements. If you need to deal with a small amount of data then you may choose SQLite, but for a huge amount to data better use a remote DB.
SQLite: It works fine with little amount of data & I experienced it response time is good.
Remote DB: I think you may use small server side app to submit the data to your client app. It will solve/reduce your thread related issues/complexities.
I'm writing an Android app that I want to use in conjunction with a band website I've developed. The website uses a SQL database to hold information such as blogs, band member information, tour dates, etc.
What data access method would make the most sense to use? I've looked at Andriod dev on tekpub and JSON data access is incredibly easy, however would it make sense to parse the database into JSON just for Android access?
Is there a good way to hit the SQL database as is? Any advice, tutorial links, or examples would be great.
It's a standard to use JSON or XML to transfer data from a server to an android client.
Giving direct access to the SQL from the devices would be a bad idea as it would
expose a large security hole
make your data base schema more difficult to change (too many clients would rely directly on its structure)
just not work in most cases as database driver are not meant to be used this way, they often use a stable channel to communicate with the database server.
I'm in the process of developing an Android application that will need to connect to a central database. Users should be able to access records and add records to the database through the application. The data itself will be fairly simple with each record being made up of a number of text fields.
The database will be developed specifically for the application and only needs to be accessed through the application. Initial reading seems to indicate that a web service should be written to parse data into xml format, for use by the app.
Seen as the database is being developed from scratch, specifically for this purpose, I would like to make sure I am heading in the right direction. I have very little experience with databases and would really just like a pointer on where to start reading. Any suggestions on the format the database should take would be greatly recieved too.
Thank you
You seem to have the idea down, if it were me, I would recomend using JSON instead of XML for the Webservice, they work in very similar ways, but JSON is a lot smaller and will make the application noticeably (as in it will make a diference for the user) faster. This is specially true if you are sending large amounts of data.
Take a look at this:
GSon
If your familiar with other aspects of Java, you could make the implementation entirely server side by means of JSPs. You could access the database via the phone's browser or any other browser. If you implemented a DAO factory on the server, this would enable you to switch databases from say Oracle, to MySQL etc by means of a properties file.