I was brainstorming how I should handle this. This is how the application is going to work:
User enters multiple pieces of data into app
App stores data into SQLite database
User hits SYNC button and app will pass all new/updated/deleted info to site PHP and update MYSQL.
I was thinking I can do a loop where it sends (and receive) one row at a time to mysql or I can use a string builder to build a XML, and pass (and receive) the XML string to PHP to process. The xml will have tag data specifying if the element is to be added, deleted or updated.
I figure the XML is a better option, but I'm coming here for opinions how I should push multiple rows to be added/deleted or updated to my MYSQL because I feel there's probably a more efficient/easier way of doing this.
Thanks!
--UPDATE--
Here's some helpful links I found of JSONArrays for those seeking similar information as I am about Android SQLite to PHP MYSQL.
Nice tutorial about JSONArrays in PHP: http://webhole.net/2009/08/31/how-to-read-json-data-with-php/
Another tutorial about JSONArrays in Java: http://www.androidcompetencycenter.com/2009/10/json-parsing-in-android/
Ah, opinions. Painful things though: everyone has one and everyone thinks their opinion is better than the next persons'.
I've implemented a system that is pretty much identical: I used JSON for it though. There is no intrinsic issue with using XML: whatever translation layer you are comfortable with is probably fine. JSON was (for me) a bit more compact than XML, required less code on both sides (json_decode is your friend) and seemed to me to be an easier row to hoe than using XML. However PHP's simplexml would probably work fine as well.
If you're doing this from scratch you might want to look at one of the systems with automatic data syncing like Mobile Couchbase (see http://www.couchbase.com/products-and-services/mobile-couchbase): would require a fair bit more tooling and a bigger server/client resource footprint but might get you there faster.
Related
as part of a university project, i have to build an android app that will contain informations about diseases, the diseases will be listed in a list (alphabetic order), when clicked on a disease you'll be directed to another layout that contains informations about the disease chosen (including text and images).
i'm new to this and i don't know how to approach this app..and for the text should i build a database or directly input the text inside the app or something like that .if you know a tutorial or something that would help please share
Ps: there is almost 60 Diseases and each disease will have a subitems (causes, treatment, clinical signs .)
thanks
First of all, the comments are right. Please be more precise in your question. Ask what specific problem occured, if possible provide code samples, errors and research state. https://stackoverflow.com/questions/how-to-ask
UI Design (List)
there is almost 60 Diseases and each disease will have a subitems
Therefore I would suggest an ExpandableListView.
Check out this code sample: https://www.journaldev.com/9942/android-expandablelistview-example-tutorial
Afterwards if the user clicks on an item, you open another Activity with details
Data Storage
should i build a database or directly input the text inside the app or
something like that
Static approach
As you can think of, putting data directly into views makes it difficult to maintain, but is faster implemented and less difficult.
Implemenation: I would suggest putting the data into res/raw as a .json file. In your code, build a JSONObject out of it and pass it to the ListViewAdapter.
Dynamic approach
You need Internet permission, a webserver and a remote database from where you can query the data.
Implementation: If you have a hosted webserver you probably have PHP and MySQL databases. Create a table, fill it with data and build an API in PHP where you provide the data from the database. If you have a VPS or dedicated server you can use MongoDB which works with JSON out of the box.
My guess
For an university project, use static. Otherwise dynamic of course.
Hope this helps
Many times my client ask me whether they will deliver data via XML feed or JSON strings. I usually say:
XML if you already have a feed and do not have a web developer who will create script for generating JSON strings
JSON if you do not have any feed and need to create any from the scratch
What do you say? Do you think that delivering data via XML feeds is obsolete and that XML is over-complicated and too heavy?
Should I advise all clients (for the sake of the future) to move onto JSON way of delivering data?
EDIT
From another discussion https://stackoverflow.com/questions/2636245/choosing-between-json-and-xml I can see that JSON is advised for web services, which is the most used case scenario in my clients. It seems that I was advising them properly.
What is they want to pass news articles onto a mobile device - shall I advise XML of JSON?
What about post&get cases when I need to post some data and the to get the response which will be displayed on user's mobile device - XML or JSON?
If the consumers are browsers or mobile devices, I would recommend JSON.
Faster
Lighter
Native parsing support
If the consumers are other programs, I would recommend XML
Can be validated easily
Code generators available to make programming easy and is less error-prone
JSON - if you have a choice :) Google GSON is a serious help there.
We Use JSON: If we want to serialize a data structure that’s not too text-heavy and all you want is for the receiver to get the same data structure with minimal effort
We use XML:If we want to provide general-purpose data that the receiver might want to do unforeseen weird and crazy things with, or if you want to be really paranoid and picky about i18n, or if what you’re sending is more like a document than a struct, or if the order of the data matters, or if the data is potentially long-lived.
This discussed topic might help you .
I agree with all the other recommendations for JSON, but for me the main reason for going with JSON is it's far easier to process on the server especially if you are using a language that supports the JSON structure natively (e.g NodeJS or Python).
I would not say XML is obsolete though. The one obvious case where XML wins is readability. As a programmer I would say JSON is just as readable but I've worked with a lot of people (mainly web designer types) who prefer the look and feel of XML, probably because they are already intimately familiar with HTML.
I agree with your assessment really. Json is easier (for a human) to read, more intuitive and lightweight. XML is better if you have lots of existing XML solutions/interfaces that you're plugging in to. I see XML as the established, mature heavyweight of structured documents, but you don't always need an established, mature heavyweight. It all depends on the use case.
I have an Android app that needs to work offline and requires a lot of static data.
Currently I'm using a JSON file in the /res/raw and loading it with the Jackson parser into my POJO scheme. It works really well since I have an external program that will be generating this data and once in a while when there is a change I'll just publish new version to the Market so I don't have to deal with running an update server and so on.
However, right now my JSON file is about 2.5MB with limited dataset for testing, in the end it'll be about 5-10MB.
The issue is that it already takes about 3-5 seconds to parse the file and this needs to be done every time the application is restarted.
So, what are my options here? I could put the data to a sqlite database, but that would require rewriting the external application and changing the data structure quite a bit. But then I could only query the things I need at the moment and not loading the entire thing at once.
Is there some easier/better way? Also, is there a good way to publish the app with the sqlite database? All the articles I've found talk about creating the database for user data at first startup, but this is not user data and I need it to be deployed from the Market.
JSON feels like the wrong approach for this - it's a good way to encode data to transfer, but that's pretty much it.
It'd be nice to have a bit more info on what exactly your app does, but I'm struggling to imagine a use-case where having several MB of POJOs in memory is an efficient solution. I think it'd be much better to use SQLite, and this is why:
I could put the data to a sqlite database, but that would require rewriting the external application and changing the data structure quite a bit.
You can still use your other program's JSON output, but instead of loading everything into POJOs with Jackson, you could populate the database on first app launch. This way, the app boot time is negligible if the dataset is unchanged.
If you still want to work with POJOs in the rest of your app, it'd be trivial to write a query that retrieved data from the database, and created objects in the same manner as Jackson.
But then I could only query the things I need at the moment and not loading the entire thing at once.
What're you doing that requires access to all the data at once? Searching or ordering a set of objects is always going to be slower than a SQL query to achieve the same thing.
Also, is there a good way to publish the app with the sqlite database?
You can definitely ship your app with a database, though I've not done so personally. This is a relevant question:
By Default load some data into our database sqlite
Hope that's of some help.
There's an excellent API called JExcel (just google it) that works with .xls spreadsheets. If you're not going to be doing any selecting and just loading data from a source, I like to use JExcel because it's more manageable from a desktop and produces easier-to-read code.
Not sure of any performance differences, however. Just throwing in my 2 cents :p
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.