I am trying to decide on what data storage methods to implement. Here is the situation. Whatever method I choose, it is going to be updated once week (can I update a SQLite db without putting out an update in the market?). The user cannot add or remove items from this ListActivity, they can only pick the ones they want. This data method should be able to remember the selected items during any given week. Let me know what method you would use and why. Thanks so much in advance.
A webservice would allow you to update the data whenever you want without having to push updates to the market. And updating your app in the market doesn't guarantee that users will apply the update. Ofcourse the downside here is that your users would need to be connected to the internet while using the app.
Moving your database to remote server will give you freedom to manipulate data without actual application being updated, thus no need to update on the market. If it is a matter of access to internet, you can still use this practice, just more work has to be done (adding Broadcasters that will listen to connectivity than update the local database with global one on your server, or something similar).
If you want to update the data on the device once a week, then you will need to use the local SQLite database and interact with a web service that provides the updates. You will not need to go through the market to do this. However, if you need to update the structure of the database (add, remove, or change columns or tables for example), then you will need to update your app on the market.
I highly recommend watching the Google IO 2010 talk Developing Android REST client applications. The speaker is the author original author of the Twitter app for Android, and talks about the design patterns and best practices that he uses.
Related
if the application receives its data from remote server then we should save our data in the local database and have our UI load data from the local database for better UX right? Our UI should not load data from servers directly it will result in bad UX. Now my question is I am developing an e-commerce application and it’s data is very dynamic it can change anytime. The product can go out of stock, it’s price and the discount amount can change etc. So how to keep up with it. If I refresh local database every time user opens application then what will be the benefit of the local database. If any of you had faced the similar situation or worked on any e-commerce applications then please me suggest me better ways. Any help would be appreciated. I do not know if this is a right platform to ask this questions.
There are some solutions. You can use push notifications using Parse, for instance, when your MySQL changes. Or you can use JobManager to enqueue custom synchronization tasks. I recommend you to see this video and check out the video project: https://github.com/yigit/dev-summit-architecture-demo
This reflects your problem very good and it is a very nice solution and, the most important, it is developed by a Google employee.
I hope it helps you!
So the app is for a Parrot Rescue. It will contain profiles for each of the birds that we currently have for adoption. So a picture of the bird, and then basic info about the bird. It needs to be regularly updated as the birds are adopted out and new ones come in. What route should I go? My main concern is that I want it to be relatively easy to update so that some of the less technically inclined could use it, as I won't always be available to help them.
Instead of loading a new version of the application every time, you should implement a database on a parrot information server. Then the application (the client) will ask the server to receive parrot information.
Just implement a mySQL database and a PHP page that returns the information in JSON format. Then through the application you will make a request to the server using the volley library or okHTTP and enter the information into a list.
As there are also pictures, use the glide library to download the images.
Also remember to upload small images to the server.
This way the app is always up to date
The easiest way is to update the app on the play store with the newest db, and let auto-update update the app with the new db.
Next easiest is to have a nightly (or whatever frequency) service download a new db and replace the old one from your servers
If you want it to be as easy as possible to update for everyone I would recommend a little app that has two main activities. One for displaying the entries of the database (and maybe also giving the ability to delete the entry) and another with a template to fill with all information and the image.
Then like Raffaele D'Arco explained use a little server. You could also delay the updates to be in a 5 minute routine or the like so that you put as little stress as possible on the server.
There are multiple good ways to update the interface without updating the app constantly.
Use a database which the app will download after a fixed amount of time which will be located on the server.
Secondly, if you have a website you can convert the web pages to XML or JSON or something like that and can update the app UI as per the data downloaded from the website.
I would recommend the second option as it is quite easy than the first one...
I am working on an android fitness app and I want to get the hang of using ContentProviders. I was thinking about using the myfitnesspal api to get a list of exercises, but the api is private and my request has not been addressed yet. Then I considered scraping exercises from a website--but I am a little concerned about the reliability of this approach (if the site goes down, app won't keep working).
What is the best way to go about this? Is it "safe" to get information from a website (rather than an api) with a ContentProvider?
Correct me If I am wrong. You want user to acces your data even if there is not web API active. So my thought for it would be
Download all the data from web API and store it in database
create an node to check if data has been updated in the API if updated download new data in background and update the database else show same data from database
Benefits
User don't need to download data all the time they use app and their volume of internet would be saved
User don't need to see blank page if there's not any data
If im wrong, i would really like to know.. but the answer is simple: a ContentProvider allows only the connection to a database in your cellphone. You can't use a ContentProvider to get data from the internet. What you're trying to do is achievable with a WebService, which is an application running on a determined domain on the Internet and allows you to call some pre-defined methods linked to URLs of this same domain (but i imagine you know about that, right?).
I am currently developing an application that provides some temporary static, but often changing data.
You can think of it like a telephone book. Most of the entries might never change, but there might be cases where people change their telephone number or move in/out. The dataset isnt large but has to be available at any time.
My first thought was to implement a clientside-SQLDatabase which queries a backend in certain intervals asking for updates (stored in another database on the backend server). If there was an update since the last query, the updated data will be send over and stored in the local sqldatabase.
Now I stumbled over this interesting looking database model Couchbase. Altough I dont see through it completly by now, if I got it, I can use it to keep the client-side database in sync with the servers database. Is this a usecase for couchbase or should I go with another strategy?
Thanks in advance!
That's a perfect use case for Couchbase. You'll want to check out Couchbase Lite (https://github.com/couchbase/couchbase-lite-android) and the Sync Gateway (http://docs.couchbase.com/sync-gateway/).
I'm developing an Android app as a "proof of concept" for our company. If they like it and think it's worth investing, then we'll move on to bigger things. I'm trying to figure out the best/most practical approach for this.....the basics of the app will connect to our DB and display information regarding a specific customer. For now, let's say we will only pull data from 3-4 tables (but there could be 10+ in the future). If the app doesn't have an internet connection then it should use the local DB. What is the best approach for this? Here's what I was thinking and would like some input/suggestions if possible:
1.) app runs checks internet connection. If exists, check db version (how, through a web service?)..if server db is newer, get latest data. If no internet, use local db.
2.) app parses data and displays it.
If this is correct, then there could be no modifications to the web service that would add fields to a result without changing the app as well. Is there a way for an app to parse fields regardless of how many fields there are?
I've read and walked through the tutorial on google with databases and such (Notepad tutorial) but it seems like the column names are all hard-coded in the parsing class, which I was hoping to avoid.
Sorry if this is confusing but I know I need my app to use a local db to read data, I also know that the app must get data from the server when it can (via onCreate or a refresh button) and copy it locally....Copying it locally is the part I'm having trouble understanding I guess....is there no way of saying "go out and get this result and display it", knowing that those results could mean 5 fields the first time or 1 the next.
Any help/guidance is greatly appreciated!
You probably want to use a SQLLite DB to store your data locally, a ContentProvider to provide CRUD access to the db, and a SyncAdapter to sync with your server when possible. The Sync Adapter also writes to the DB via the ContentProvider. See the SampleSyncAdapter sample in the SDK for an example of how this works. You will be implementing your own ContentProvider, but the sample just uses Android's supplied Contacts ContentProvider.
http://developer.android.com/resources/samples/SampleSyncAdapter/index.html