In application there is menu in menu user can choose one of them. All required data from server. Where should I make an request and store data?
So far I made request inside fragment, but I do not want to make request per activity/fragment.
Is the good idea to make request inside main activity (of course using other thread <>). And then keep data in static list in this activity? Or is there better way to store this data?
This is a very vague question, the answer can vary by a lot based on the precise requirements.
For example if its just a boolean returned by server, sure you can save as static boolean, if the list returned is small, sure save it as static, as long as you are comfortable with loosing the data when the app is killed.
If not you need to save the data somewhere, depending on the size, type there are multiple options you can use please read http://developer.android.com/training/basics/data-storage/index.html
If you ment using Volley as a Singleton class read more in the following link.
Related
On example we have an app that tracks Taxi drivers, a taxi driver log in into application and pick an order to drive for given customer.
In this case we have an Order class that represents a lot of data, it's very important to have access to this object from anywhere while still being able to modify it.
From now we can:
pass it by putting extra data to an intent, but it's not something
that makes code readable, in some cases it won't be a solution
deserialize the object into json and store it into cache, we still
need to constantly update this value which is a headache when more
complex objects are in game, one mistake and god knows when the
mismatch happens
store it into class that extends Application, this
is approach I am testing right now, but I am having doubts about this
as when app crashes / android will release app resources randomly, I am in need to restore given object state using
black magic with cache anyway
This is a problem that I believe is shared across many applications, like Spotify's current playing track, etc.
Are there other approaches?
Try using a sqlite database. In this case, you can access your data anywhere from your app if you create a robust GetOrders API method yourself.
Here is a tutorial of creating a database.
In this case, you will never lose any data if app exits or crashes. Also, it really makes no difference compared with caching your data in memory.
Hello Dear Developers,
I am working on a project which uses Flickr API, I parsed the data and took the necessary values from JSONArray and JSONObject, however the URL does not provide all the necessary information about the user (the user who shared the photo on Flickr ) for this reason I decided to use flickr.people.getInfo but in this situation, how can I handle response JSON, I mean if I parse this URL, I have to change RecyclerView Adapter, ViewHolder, but it is not sufficient way of handling multiple different API calls.
I hope, the explanation is clear, if it is not pleasing make comment then I will provide answers to your specific questions.
If I understood correctly you should make two calls, then merge responses together and show result into UI.
You can handle this with callbacks or RxJava observables.
The main idea is to create a single class - model that will contain all data you need to present on your UI. Then make the first network call and parse the response into this object. Pass this object to the next network call and update it with the corresponding user data. And only after these two calls are done and you collected all needed data you can insert the model into RecyclerView.
Hope it helps.
I'm developing an app that downloads ParseObject's data from server and populate a ListView in Fragment with it.
I read about downloading data by Service and after it's done (some kind of listener?) it would update Fragment and be accessible until user leaves the app (which is fine by me).
On the other hand - I can just store it in Bundle and retrieve it every time I get back to that Fragment, but then I'd need implement Serializable which in this case can be cumbersome: like here
Fragments are held by DrawerLayout so it's really irritating now to see loading bar everytime You change to that Fragment and I'm looking for a solution to change that to improve UX.
What do You suggest? Which approach would be better in that situation? Maybe there are things that I should be aware of before attempting to use any of these?
I think it depends on how often the data is changed on the server.
If only daily/weekly the solution must differ compared to if the data is changed every mins/hours.
If the data is kind of static then you can download it only once, and save it to SharedPreferences, or to a seperate local file or DB.
If it changes kinda often, I'd suggest to use bundles or in memory objects, so when the user reenters the app the data should be downloaded again.
The solution i'd use would be to simply convert the entire list of data to JSON, and then save it in SharedPreferences. This allows for easy reuse of the data when the user goes back to that fragment.
As you aren't saving the data across app close/reopen, a local database is not needed.
I'm building an Android app, which should:
show some data, loaded from a server in the Internet.
At the moment I have a local SQliteDB used in my app where the data is stored, which should be displayed. I use this, because I want to be able to show the data, even if there is temporarily no internet connection available.
Next step I will work on inserting data in the local SQliteDB from a internet server. I thought about doing it this way:
When app starts, check if internet is available. If yes, connect to a webservice (including username and password). The webservice should deliver the necessary data via json object to the app and I will update the local SQlite DB.
My questions:
Is this a good idea?
Are there any better ways to do this?
The data can be viewed (and edited) by a Zend Website, too.
Thanks in advance.
Best regards
Daniel
The way you put it seems optimal. Maybe you should set a flag or alert which is time or date related..in case the app starts too many times without internet.
>> For updates to your mobile app, you should consider the priority/urgency of having the same data on the server and your app.
> For the better ways to do it, you can opt the way which suits your requirement better.
To fetch the data in one thread and render it in another,
1. Write custom Asynctasks:
http://developer.android.com/reference/android/os/AsyncTask.html
AsyncTask Android example
OR
2. Use something like AsyncHttpClient: http://loopj.com/android-async-http/
where you get onSuccess and onFailure methods to work with the response.
The option 2. is better if you just want to fetch data without doing anything else, and work on it, or save it. For the same, you need to parse the response first.
To parse your data:
As your response is JSON format, you may be better off using Gson to map data and with custom model classes. Eg.:
Gson gson = new Gson();
ModelClass modelClass= new ModelClass();
modelClass= gson.fromJson(responseContent,ModelClass.class);
//where responseContent is your jsonString
Log.i("Web service response", ""+modelClass.toString());
More on: https://code.google.com/p/google-gson/
For Naming discrepancies(according to the variables in webservice), can use annotations like
#SerializedName.
Use a for each loop to verify/browse/access the data that would be populated in/as objects/fields of your model class:
Check these for doubts:
http://docs.oracle.com/javase/1.5.0/docs/guide/language/foreach.html
How does the Java 'for each' loop work?
Now about saving your data:
>> It depends a lot on what the data from server is and how much data do you want to store.
In Android Storage Options:
http://developer.android.com/guide/topics/data/data-storage.html
a. There's Shared Preferences:
These are good for saving/storing data which would be relatively small in size and could be overwritten and fetched frequently. Eg. username, current user's details, password
http://developer.android.com/reference/android/content/SharedPreferences.html
How to use SharedPreferences in Android to store, fetch and edit values
b. Maintaining a database is good for the larger chunk needed in your app.
You can store, update or over-write the data according to your need. There can be multiple tables or more data could be stored in various fields.
http://developer.android.com/reference/android/database/sqlite/SQLiteDatabase.html
http://www.vogella.com/tutorials/AndroidSQLite/article.html
While you use Gson, you also have the option of populating the objects of model class and then storing that response in a String(maybe in SharedPreferences, depending on length/size) using gsonToJson method. I have used that, cheeky but effective.
You need to consider other stuff too, pertaining to UI and memory optimization, ListViews or layouts etc depending on your app and its control flow.
You could start a thread and get new data on loading the app. If you decide this path we had nice results with JSON using the Volley Project.
You can see a walk through here http://www.javacodegeeks.com/2013/06/android-volley-library-example.html
and get the code here
https://android.googlesource.com/platform/frameworks/volley/
Try using this library:-
https://github.com/Abhishekpalodath/FetchServerUtil-Android.git.
You can also load real-time data from the server by using this.
I'm thinking about where to store the connection data to the server. This could include a URL and port, maybe more.
I thought the best for this would be to create something like a file in /assets called "config.properties". However, while doing research I did find out this is not the most popular way. But my impression is that it's bad practice to save data like this hardcoded in a static class. And also the "preferences" are more made for configurations the user can change, or for information gathered during runtime (like the user's login data or a login token).
Is there a common way how to do it? In the best case with something like a "configuration"-file?
It depends on where do you wanna use these values. If it's only used in a single class taking care of your connections you could simply have all this as class attributes.