Here is one design/ best practices question..
I'm new to android development, and basically new to web/mobile solutions.
So, my question is - what are best practices when organizing structure of android application that get data from the remote server?
Should request to server go into one class that does communication with server (get and post requests), or should I look at my requests as data source, meaning that every data class manages it for itself?
or should I have more levels of abstraction - one level for acquiring data, other for model that uses some interfaces without knowing from what source data come from?
I'm curious how experienced android developers approach to these design issues...
Virgil Dobjanschi presentation is a good resource as pointed earlier, which basically tells you to run your requests from a background service so the activity does not get destroyed and to store your data in the database as early as possible.
For more technical details, the way I am doing it is to divide the app into three components:
1- Library to encapsulate the handling of the HTTP request and response (with ApacheHTTP), which can handle simple request/response and advanced features that might involve cookies (can be necessary for login) and modifying the HTTP header.
2- Marshal/Unmarsha layer, where I parse the server data (e.g. XML or JSON) and convert it to objects (i.e. models) that the rest of my app will deal with.
3- Persistence layer.
As per Dobjanschi's presentation, I usually make data requests run in a service not in a thread worker inside the activity.
Use one of the 3 models presented at this Google I/O talk. It provides you suggestions that will help you out on the whole process of definition of your app architecture. It'll also prevent you from making common mistakes beginners use to make:
http://www.youtube.com/watch?v=xHXn3Kg2IQE
This post will also help you out:
Need sample Android REST Client project which implements Virgil Dobjanschi REST implementation pattern
Related
first post.
I am building an android app and the backend (remote server) im using ktor with exposed and hitting a postgresql data base. I am just unsure upon getting my results back from queries how I should attempt to send those back to my user app on android. What would be the right way. To have the user app install exposed library and just send the query results ? format all the results to a json string and blast that? Just dont know what would be ideal.
I haven't really attempted anything yet because I was looking for a "best practices" idea.
Hi and welcome to Stackoverflow.
There is no one "best practice" way to send the data from the server to the client. Noramlly it depends on your use case. However, one common way that I would suggest you use is to create RESTful-API.
This means:
Requests and Responses to/from the server will be serialized to JSON.
Confirm to HTTP verbs semantics (use GET to read data, PUT to update, etc).
Use status code for error handling
Follow the REST API guidelines for best practices (API versioning, end point names, pagination, etc)
To read more about REST API guidelines, this page is useful.
For Ktor, this will mean having a serializer, and then defining your routes. This guide is useful for Ktor.
Although this is not the only way, but it will provide you with enough experience to explore others APIs (Custom API, RPC, SOAP, etc).
Im developing an app that have alot of web requests. Such as download or upload files , REST requests and etc.
I want to save all of this functions in a class like a helper and only just import the class and call functions that i need them in my activities.
something like a custom library for web requests i mean.
Is there any Design pattern for this?
(I hope i explain my idea well)
Consider using these libraries:
Robospice - for asynchronous network calls
Retrofit - for REST calls
OkHttp - good HTTP/SPDY client
Picasso - for image loading and caching
Jackson - to work with JSON
You can use custom IntentService class to hanle all networking there, starting this service from UI and passing apropriate ACTION to perform.
And of course i would suggest you watch this video from Google I/O 2010 and use REST Pattern A described there in EVERY network app you make.
You could use the Chain of Responsibility pattern for building up requests and then executing them. See some details here.
Of course, using just this one pattern would not be enough. It should be used in conjunction with an Observer, Factory, Proxy and maybe some others. Just start developing with SOLID in mind.
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'm looking for some best practice concepts as far as transferring data between a mobile device (Android right now, but concepts apply pretty much to the rest as well). I currently have a WCF service set up with a working JSON endpoint. I'm starting to modify the existing service methods with the appropriate WebGet/Invokes, etc to make it RESTful. The service implements the request/response pattern so that all communication between a client and the service are wrapped in a complex MessageRequest and MessageResponse object.
What is the best way to have a mobile application successfully utilize this pattern? There are only two solutions I can come up with, each with their own pros and cons:
Create all the data transfer objects in the client project, and then create a JSON/DTO mapper (GSON might work well here). Use the client-side objects to handle all client data management until a server request is necessary, go DTO-to-JSON, and send the request to the server. The upside here strikes me is that it makes client-side data management easier because it parallels the service domain. The downside is that these have this has the potential to breakdown the more complex an object becomes.
Ignore the DTOs client side and just do everything straight from the JSON. The upside here is that it removes the overhead associated with the larger objects and the required mapping. The downside here is that this strikes me as being very brittle - any changes to the returning object need to be handled deep in the code, rather than just making the change to the client side DTO and mapper.
Is there a better way to accomplish this data exchange? Or are these the only real ways to handle it? How do you manage data transfer in your mobile applications?
I have a very similar WCF setup as you do, and I ended up creating very lightweight data objects client side. These manage pulling apart a JSONObject representing themselves and create any sub-objects they need, but aside from that are simple classes mostly used to group data together and contain no business logic. We haven't yet needed to do any client side caching, but these objects would be a great place to put in SQLite code to persist themselves out.
It has worked great so far, and we were even able to port the client-side Android code to another project running regular Java just by including org.json.
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.