multipart request
abhitheawesomecoder opened this issue · comments
support for multipart request
For what? For REST?
Multipart is not supported because...well to be honest I never thought a multipart would be necessary in an offline scenario. If the user is uploading a file, they already have that file on their device. That's not to say that theoretically this is impossible. Brick is just a thick wrapper around the native http library, so you could simply change your request headers using a RequestTransfomer to the right mime type and that could work.
Multipart is not mentioned in the documentation because it's not supported. If you have specific suggestions on where to improve the documentation, I'm open to hearing them. This package tries to accomplish a lot, and it's difficult to provide clear explanations that solve low-level problems (like this one) while also explaining high-level concepts (like when you'd want to use Brick) without being completely overwhelming.
I tried to follow all the steps mentioned in quick start and run the example_rest on android but I am getting blank(white) screen and get request for customerList.data is returning null. (I am running the server and on browser customers endpoint is returning customers).
Here you can check the code :
https://github.com/abhitheawesomecoder/offline_first_example
flutter: null
flutter: [Instance of 'Customer']
Can you make an http.get('http://10.0.2.2:8080/customers') request on your Android device? Android can be difficult with localhost. You may also need to try 0.0.0.0 or watch the adb logcat stream to ensure your device is connecting to your localhost service.
Yes it worked but not with the server.dart. I ran another server with express/nodejs with same endpoint and response and it worked.
I have one more doubt. If I make upsert and the request failed due to no internet connection. Will there be further automatic request later (when internet is available)?
If not then how can I check the failed request?
(I am sure the upsert data will be cached in sqflite.)
@abhitheawesomecoder Correct, the request replay if the code response it in reattemptForStatusCodes. You can edit it in your Repository
/// If the response returned from the client is one of these error codes, the request
/// **will not** be removed from the queue. For example, if the result of a request produces a
/// 404 status code response (such as in a Tunnel not found exception), the request will
/// be reattempted.
///
/// Defaults to `[404, 501, 502, 503, 504]`.
final List<int> reattemptForStatusCodes;
@abhitheawesomecoder @hortigado is correct. There is a way to tweak what failed error codes are stored in the retry cache. You can read more on the cache here and about the offline architecture here.