Flutter – question about architecture, providers and fetching data from server

Question

I am a rather fresh Flutter programmer so please excuse any flaws in the questions below…

I am struggling with a structural/ architecture dilemma. Here is the background: App rationale:

• my app allows its users to check little jobs available in their area and if they find time and are in a proper location to execute the job for a remuneration,
• the app uses standard REST API (not Firebase) so that the server cannot be relied on sending status change notifications to trigger re-fetching of data,
• the critical elements are (1) up-to date list of jobs for a given address - other user may have already taken on a job in an address (timed refresh of list e.g. every 5 mins), and (2) the app needs to keep track of the user’s location and accordingly ask the server for jobs if the user relocates by more than 2km in less than the refresh time,

The challenge:

• I guess that on the basic level the app should have the following providers: (1) auth – providing the authToken, (2) geolocation – regularly checking user’s location, (3) jobList - for particular location (fetches high level job descriptions and addresses(, (4) jobDetails – fetches exact instructions for carrying a particular job,
• as you can see: (2) geolocation and (3) jobList – need to refresh programmatically (at interval or on some change of geolocation), while (1) auth, (4) jobDetails are triggered by the user.

The Big Question ;) is … what is the proper architecture for the above type of app? More specifically:

• should I use services for connecting to the server API and these would in turn be used by the providers?
• how to ensure programmatic refetch of jobList on timer and relocation event from geolocation?
• how to continually listen to location changes to detect a relocation but not overwhelming the app with processing?
• should I store the (quickly outdating) jobLIst data just in its object class or should I use settings provider or a local db or maybe there is an easy way of storing the latest JSON response not to have to build the settings provider or db mapping?
• in all my call to Auth api I need to provide the deviceId - how to make it available accross the app - this is pretty static but is needed in authentication so should checking it be a part of the auth provider?

If you could comment on the above or suggest a source of relevant examples I would be really grateful.

Thanks and cheers!

Answer 1

Here are my thoughts:

• how to continually listen to location changes to detect a relocation but not overwhelming the app with processing?

You can rely on third party to do this for you. Such as: geolocator. With this, you can specify the amount of distance the user must have moved before the package notifies you of the change in user location.

• should I store the (quickly outdating) jobLIst data just in its object class or ...

Since it is likely for a job listing app to use this data often and in various places, I would prefer to use db. It would be helpful in the long run too, if you plan to have some sort of analytics done on the mobile end or to gather any insights.

• in all my call to Auth api I need to provide the deviceId - how to make it available accross the app ...

When you app is initialized, you could fetch the deviceID and store it in shared_preferences. Then in auth api, you could just retrieve it before making the API call.

• should I use services for connecting to the server API and these would in turn be used by the providers?

As for geo location, geolocator can update you about the change in location and you could make an API call based on that.

However, if you plan to have a timer based approach to refresh your job listing, then you must realize that your users are likely to face issues arising from your inconsistent data. If you have plans to tackle it, then this implementation here might help. But I strongly feel that server supporting push notifications or maybe a web socket approach would be ideal here.