I'm looking for guidance on the optimal REST/Json method to use for our production app. The scenario is app <-> web service <-> server (lighttpd or nginx) <-> our program <-> sql database. The data traffic between Android and server per call is pretty small. There is no significant CRUD on the client.
I've seen the Google IO 2010 presentation (http://www.google.com/url?sa=D&q=http://dl.google.com/googleio/2010/android-developing-RESTful-android-apps.pdf) with the 3 proposed patterns (Service API, ContentProvider API, ContentProvider API and a SyncAdapter). Have briefly looked at the iosched 2010/11 app though haven't worked out which of the 3 methods (if any) it implements.
We want to offer our app users a seamless experience by managing state to support various types of interruption or failure. How can we determine what is the optimal REST method for our need? Are the Google suggestions overkill?
Thanks in advance!
The correct answer depends on how much data and what operations we are talking about.
You wrote: "There is no significant CRUD on the client." If you are only using the "R" from "CRUD" (=read data from somewhere), AND if your app doesn't really depend on it, AND you are not synchronizing content frequently, you may even get away with fetching it form inside your Activities.
However you may want to explore the Service API from the get-go anyway. Like that Google presentation said, your Activity can be shut down at any time, so if makes sense to put your REST methods somewhere where they have a better chance of completing.
Please consider the future needs of your app, its use cases, and then look at the available options.
Related
I'm developing an Android app (using MVVM) and I'm trying to implement Room DB caching for one of my models fetched from a REST API through Retrofit.
My question is: Is it correct to have my caching/fetching logic in the Repository as well as the network connectivity checks (using ConnectivityManager) to dictate whether to fetch data from the network or a Room DB cache? I'm asking since ConnectivityManager requires Activity-level Context to be instantiated and having it passed all the way down to the Repository doesn't sound correct to me in MVVM terms (and I'm not sure if it could work since I want to use ApplicationContext to instantiate it and I haven't seen people doing it like that).
I also don't want to try making a request to test connectivity because that'd ruin the entire purpose of using the Room DB as a Single Source of Truth for all my data and would be a rather useless request.
The only other way I might implement such connection checks and handle all the possibilities is through the NetworkBoundResource unofficial code excerpt from Google but I'm wondering if anyone else has a better solution. I'm also planning to save the last fetch time from the API as a property in my Repository (and update it after each API call) but I'm afraid that could lead to some tight coupling and overall shaky architecture. If anyone has a solution to how I might go about that, it'd be very helpful.
I'd be willing to experiment a bit but I don't think I can get in that headspace without mucking everything up.
Thanks in advance!
I have read countless posts regarding the use of JDBC with Android. Everybody suggests to take the path of using PHP scripts and using HTTP clients within the Android code.
It would be great to just get a clear indication as to why the JDBC is not advised.
JDBC access directly from a web client, be it browser or web phone, implies that the database port is exposed on the public internet. That's not a safe place for any data to be.
I think a better approach is to put one or more servlets between clients and the database. Let the servlet(s) handle security, validation, binding, deciding which services to invoke to fulfill the use case, marshaling the response, and routing to the next page depending on the outcome.
This design lets you put the intermediate layer on the internet and keep your data safe behind a firewall.
It's called Model-2 MVC. It's been the standard idiom for Java web development for more than ten years.
You'll get a lot more use out of your code if you have a clean separation of the presentation of data from how it's produced. UIs come and go, but services and data linger. Think in terms of services first and you'll do better.
i was trying to build an app which takes the data from server database and use it in android app ( in may case for reading the gprs coordinates available on database).
after a lot of search, i came across RESTfull services for implementing this. but there is a simpler way also, that is accessing the server database directly from android app by using a driver (jtds) and running mysql on server side.
i am actually confused which one to use. Why restful service which is highly platform independent and have a wide range or directly accessing the mysql database from server. which is most extensively used and why? giving below examples of both scenarios.
through restful service - http://avilyne.com/?p=105 and directly by accessing sql server database- http://amitku.wordpress.com/2011/08/03/how-to-connect-and-access-sql-database-server-from-android-app/
please let me know which is better and mostly used and why?
I would strongly encourage using the REST approach, and although there are many reasons, two or three come immediately to mind:
1.) Security. By using a REST approach, any data on the server side can only be accessed by server-side code, which can provide a protective layer between the data and the outside world.
2.) Scalability. A direct connection, such as the example at your link, hooks into a particular instance of a database. If that database already has a large number of connections, there will be performance issues or worse.
3.) Server side flexibility. If the underlying database structure or technology needs to change, a REST approach will allow for that. All the client side cares about is posting or requesting to a server that will respond via REST protocol.
I would think that a REST approach is much more widely used than a direct client-server approach.
I have profiles in my mobile app and in web project. We are currently thinking about how can we synchronize them. The point is, if person add something to mobile profile - we can just send a bundle of ids to webserver and server will add them as well. The same with removing items. But what is if person will removes in mobile profile without constant connection, then removes something inside his profile in webserver`s profile? And after that we have to synchronize it somehow.
I understand that solution of such issue has to be already found, but unfortunately I didn`t find anything helpful yet.
I'd recommend watching Virgil Dobjanschi's Google I/0 2010 talk on designing RESTful client applications: here. It's about an hour long, but very informative and helpful.
Some key points to note are:
Use a SQLite database to act as a cache between your application and the webserver, so changes can be saved even there is no connection, then sent/received once you gain connection again.
Use a Service to handle REST calls, as it won't be restricted by a single Activity's lifecycle. This way your server requests can still be executed and properly handled if a user or the Android OS kills your Activity, a phone call pushes your application off the screen, etc. I'm using an Intent Service, as it handles threading for you.
You also need to determine which syncing relationship is most suitable for your application. What I mean by that is "Which database should overwrite the other: The SQLite or the webserver?". So when there are differences between the two, which data should be deemed "correct"? This is commonly referred to as master-slave.
To all,
If you watch the Google IO session on building Android REST apps they are suggesting in all three design patterns to use Content Providers regardless if you need to share data or not.
If you look at the Content Provider class doc at http://developer.android.com/reference/android/content/ContentProvider.html they say you only need to use a content provider if you plan on sharing your data with other applications.
My application does NOT need to share any data with other applications so is using a Content provider overkill? And if so why does the Google IO REST video imply that it should be used in all scenarios?
-= Update =-
Talks are here https://dl.google.com/googleio/2010/android-developing-RESTful-android-apps.pdf.
There's no real right or wrong answer to this question but I'm strongly in the use a content provider camp for the reasons below.
You get a well-defined, easy-to-use CRUD interface for your data. Once you've written a Contract and your Provider methods, it's just a couple of lines to start retrieving data. When you come to work on the project later, or you hire another developer, you'll be up to speed in minutes.
Lots of classes in the Android framework are designed to work with content providers. In particular, CursorLoaders are brilliant, and you'll have to do a fair amount of work to emulate their functionality on your own. Good luck with managing the cursor lifecycle within an activity, in addition to writing all of your own data retrieval code and asynchronous tasks. There are various nuances and things to take care of. This will take a while.
Updating or inserting rows often? It's pretty easy to notify ListViews and other Cursor consumers of changes via the ContentProvider. If you're not using a ContentProvider, you'll have to write your own Observers and manage it yourself.
Want to integrate the Quick Search Box, or apply some powerful filtering to a ListView? Again, it's simple if you're using Cursors and ContentProviders, and a whole load of work if you're not.
If, in future, you decide to open up your data to other apps, you'll end up writing a ContentProvider anyway. Remember, you can still use ContentProviders without allowing other apps to modify your data.
I could (and may) expand on this post further but hopefully you get the idea. Google use providers in great apps like iosched for a reason.
In my experience, implementing a Content Provider can be a lot more work then simply working with a database directly. One of the reasons Google could say that an application should use a content provider could be because they believe in expansion. An app that implements a Content Provider would have an easy time expanding its data to other apps.
Because it is a REST talk, another reason could be because Google is starting to focus on a lot of cloud storage ideas. If you can implement a Content Provider, you can change your data retrieval functionality while still keeping a lot of your existing code. A Content Provider generally separates the data retrieval functionality from the actual data, leaving it much more flexible. If you wanted to switch your data to the cloud, it would be much easier having implemented a Content Provider within your application.
In my opinion though, most applications don't need to query the large amounts of data that make cloud storage desirable. It depends on the application, but I think you'll be OK avoiding a content provider if your data is meant to be kept in-house.