I'm fetching some data from an API and displaying it in a list. When that API update data, I want to reproduce a sound, how can I do that?
I tried to use Streams to implement that, but it wasn't successful.
Related
I have an api call that have list of images and text in json response, i want to store json in local and use it in the ui, The api should be called after every 12 hours and save data in cache or the internal storage.
Api call is in the listscreen that opens on a button click.
which one is more suitable. How can i call an api in certain screen even when the app is closed?
Which one is more prefereble to store response cache or using sharedprefrence?
I have used dio and retrofit as sub for the api call.
I tried using Cron and save data in sharedpref.
i tried using flutter cache manager but didnt fit well.
i tried using dio cache mnanager but it didnt work well with retrofit submodule with dio.
Please suggest solution for this.
I do not know how I can solve the following doubt, I have a GET request from my API and of course, I would like to save the parameters obtained in the application and not have to make every time I browse each activity a new GET request, as it would overload the server by the over-requests requested. What is the correct way to keep this temporary data while using the app?
My idea is that as soon as the application loads, an Activity SPLASH is shown and this same SPLASH, performs the API request and from here the data is kept. How should the implementation be done?
I am planning to use Firebase as my backend service for the mobile application. As part of the functionality, I need to get the data from external rest API which returns JSON data. I need to update the data periodically so that I can have updated information.
I have an option to call the rest API and update firebase on the mobile application however it is not the right approach. I prefer to keep this logic on the backend service.
Is there a way to use Firebase cloud function to periodically update firebase database from external Rest API?
#Ioki, I assume what you are trying to do is make a mobile app which gets updated data every time a user goes to the app but you want this to be on the backend. I haven't tried it but you might want to use Node js with their Firebase Admin SDK.
See the link: https://firebase.google.com/docs/admin/setup
Although I think it might make more sense to use the real-time database via the iOS/ Android SDK because automatic/ value event updates are basically the purpose of the real- time database. Good luck! :)
We are successfully sending data for new, changed, and removed events to Google Calendar from a Scala app using Spray HTTP. However, we are currently sending one event per request, and this becomes very inefficient when there are multiple events for the current user. In these cases we would like to send batched data, as described here:
https://developers.google.com/google-apps/calendar/batch
The documentation begins with:
A batch request is a single standard HTTP request containing multiple
Google Calendar API calls, using the multipart/mixed content type.
Within that main HTTP request, each of the parts contains a nested
HTTP request.
Since we are already using spray http we would like to use its support for multipart/mixed requests (spray.http.MultipartContent) but it isn't clear that this is possible since the parts must consist of one or more spray.http.BodyPart instances and there doesn't seem to be a way to turn a spray.http.HttpRequest into a BodyPart.
Has anyone successfully done this? We are also taking a look at the Google API Client for Java but would rather not go down that path if there is a more Scala-friendly way to do it.
I have been pondering about this for a while now and been unsuccessful in finding any information on the topic of subsequent api (ajax) requests.
Let's say we have list of users and one of them is updated. After updating the user, I would like to retrieve the entire, updated list of users.
My question regards two actions:
Update user
Retrieve all users
It is clear to me, that the React component initiates the view action to update the user resulting in an API request via the dispatcher. What isn't clear to me is where the second request to retrieve the users happens.
Looking at Facebook's Chat example...
Does it happen in the web API utils?
Does the store do this after it has been notified of the update?
Does the component do this after it has been notified of the change?
Currently I would do this in the API but I would like to know if there are any tested pattern for solving this problem.
You don't need two actions doing two XHR calls. You actually want just one action that results in two XHR calls. Beware of the tendency to think that you should cause a cascade of actions -- this is exactly the anti-pattern that Flux was created to avoid.
The side effect of updating the entire list of users should be something the UserStore is doing in response to the USER_UPDATED action.
The UserStore will update the user record. This can happen either optimistically or after the server call completes. The XHR call to update the user server-side can happen either within the updateUser() action creator or within the store. However, you will need to create actions for the success/error of that call, so that the store can respond appropriately.
The next step, again, can happen either optimistically or after you get the data back from the server. The store, in this case, would make a XHR call to retrieve the list of users to update all the relevant records it holds.
But like the last XHR, you will want to create two new actions based on success or error of this second XHR.
Creating new actions keeps your application very flexible and resilient. So that if any other store ever needs to know about the result of these XHRs, it will already be receiving that data.
I'd be remiss if I didn't mention that, if you have control over the server-side code, you should simply build an end point to update the user and return the new list of users -- this would make the client side code much simpler and the entire thing would be more efficient.