I am developing an application that is required to retreive information from an XML file stored on a server.
I have written a parser class, using SAX, that reads in the data and pops it into an object which I can then access as required.
How would I go about querying the data, for instance searching for particular values and then only reading in the relevant elements. Server side, I can easily write an XQuery in order to return the required elements, however I am unsure how to do this from my application.
Is it possible to execute querys server side and then parse the resulting XML file?
I'm a little lost. If anyone can point me in the right direction, I'd be very grateful!
If you are developing on Android 2.2 or later, you can take advantage of the javax.xml.xpath's functionality (introduced in API level 8).
If you are developing on Android 2.1 or earlier, the server side filter (as you suggested: xquery or xpath) would be the best, otherwise you should hard-filter your xml data, or wrap all of it into java Objects in a List<?>, and filter that list. Both ways are quite resource-eating.
In my opinion, if handling huge amount of data at once, but displaying just a small part of it, the server side filtering is better (even though it needs multiple http requests: on changing data sets this is unevitable anyway).
Related
I'm new to GAE, but have worked on Android for a while now. I'd like to write some code that basically parses xml files and stores it on a database at the backend. Then send part of this data based on a query to the front-end android app.
The android app in turn will store the data in the local database. Here, if possible, I would like to reuse code from the GAE and the Android app. So, my questions are:
what are the choices for databases on GAE?
which methodology to use to promote code reuse with backend and frontend?
is there any xml parser which can also be reused?
Thanks,
Rajath
in GAE basically you have two non exclusive choiches: The Google Cloud SQL and the Datastore.
Which is better and which to use it depends on your application. The SQL server is a classical mySQL base database while the Datastore is based on a different non-relational structure and you should take some time to get familiar with it.
Generally speaking you can reuse code being in both cases Java, however there are many cases in which you interface with different services (ex. a local android sql service rather than the google datastore) therefore in this cases you have to adapt your classes. I can suggest in these cases to reuse concepts rather than code, let me explain: imagine you have to manage images. you take a picture in android and you have to associate to it some informations, for this purpose you can define a custom data model (let say a class AppImage). AppImage will contains only data and basic methods. Then you can for example create a class that manages AppImages (ImagesManager) (implementing upload, local storage and so on). In the serverside tyou will have a similar structure with that can differ for the persistency technologies. Therefore you can again create a similar object AppImage and also a class that manages them (ImagesManager). What will be different in the code will be the API calls to store info and in these cases you have no choiche and you have to write custom code, however the high level structure remains the same and this may help when things start getting complex.
The comment above worth also for the xml parsing problem. (What libraries are there for processing XML on Google App Engine/Java Servlet)
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 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.
I am a php/mysql developer learning android. I am creating an android app that receives info from my php app to create list views of different products which will open a web view of that product's detail.
Currently my php cms web application outputs xml lists for an iphone app.... (also, separately outputs html). I have full control of the php app so if there is a better way to output the data for the android app please let me know.
I have created code that reads the xml from the web and creates the list view. The list can be refreshed daily, so the data does not need to be read from the online xml every time the app starts.
So I was thinking to store the data retrieved locally to improve my apps responsiveness. there may be up to 500 product descriptions to be stored at any given time in up to 30 different xml lists. I am starting development with one xml list with about 30 products.
For best performance should i store the product info in a sqlLite db or should i store the actual xml file in the cache/db or some other method like application cache.
I also was think to create the update of the data as a service, would this be a good idea?
The most efficient way to store data is RAM. But if you want to cache it, then the most efficient way is Database.
I recommend you store your data in sqlite android database.
You could also consider zipping you xml for faster network transfer and unzipping through java.util.zip package classes. You could even consider a simpler format for transmitting data, less verbose than xml, using a datainput/outputstream.
(I do that in of my apps and it works great)
Here are some details on data input / output stream method :
imagine a proprietary protocol for your data, only what you need. No tags, no attributes, just raw values in order.
on the client side, get an input stream on your data using URL.getContent() and cast it in input stream.
on the client side still, build a data input stream encapsulating your socket input stream and read data in order. Use readInt, readDouble, readUTF, and so on.
on the client side, from php, you need to find a way to save your data in a format that is compatible with the data format expected by the client. I can't tell much about PHP, I only program using java.
The advantage of this technique is that you save bandwith as there is only data and no verbose decoration due to xml. You should read about java specs to understand how double, int, strings are written in data output stream. But it can be hard using two languages to get the data right.
If php can't save format in a suitable way, use xml, it will be much simpler. First try with just plain xml, then give a try using a zip or tarball or xml file.
But all this is about speed gain during network connection.
The second part of what you have to do is to store each row of your list in a SQL table. Then you can retrieve it pretty fast using a CursorAdapter for your list view (it breaks the charming MVC model but it is quite fast !).
Sorry about this, but it became too long to write as a comment. This is not intended to be an answer to your question, because in my opinion Stéphane answered very well. The best solution is indeed to store the data in an sqlite database. Then you need to create the class to be used as a connection between the data, the database and the app. I don't want to take credit for what is said here already (I, too, voted it up).
I'm concerned with the other suggestion (use of low level raw streams for data manipulation, the list steps on that answer). I strongly recommend you to avoid creating your own proprietary protocol. It goes like this:
I need to exchange data.
I don't want to deal with the hassle of integrating external APIs into my code.
I know I can write two 5 minute routines to read and write the data back and forth.
Therefore, I just created my own proprietary format for exchanging data!
It makes me cry whenever I need to deal with unknown, obscure and arbitrary sequence of data blobs. It's always good to remember why we should not use unknown formats:
Reinventing the wheel is counter-productive. It seems not, but on the middle term it is. You can adapt your project to other mediums (server-side, other platforms) easily.
Using off-the-shelf components help you scale your code later.
Whenever you need to adapt your solution to other technologies and mediums, you'll work faster. Otherwise, you would probably end up with ad hoc code solutions that are not (easily) extensible and interoperable.
Using off the shelf components enables you to leverage advances in that particular technology. That's particularly important when you are using Android APIs, as they are frequently optimized for performance later down the road (See Android's Designing for Performance). Rolling your own standards may result in a performance penalty.
Unless you document your protocol, it's extremely easy to forget the protocol you created yourself. Just give it enough time and it will happen: you'll need to relearn/remember. If you document, then you are just wasting the computational time of your brain.
You think you don't need to scale your work, but chances are you will most of the time.
When you do, you will wish you had learned how to easily and seamlessly integrate well known formats.
The learning curve is needed anyway. In my experience, when you learn, you actually integrate well known formats faster than imagining your own way of doing things.
Finally, trust your data to geniuses that take their lives into creating cohesive and intelligent standards. They know it better!
Finally, if the purpose is to avoid the typical verbosity of XML, for whatever reasons, you have several options. Right now I can think of CSV, but I'm no expert in data storage, so if you're not confortable with it, I'm sure you can find good alternatives with plenty of ready to use APIs.
Good luck!
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.