Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 months ago.
Improve this question
I was working in existing application in which it has more than 5 api calls in the viewmodel through retrofit. When fetching api call it has showing loader to main screen and block user untill we get data from response. Some are dependent to each other but some are not i.e. Login session dependent on customer data etc. All response are huge in data so may be it taking time to load. I read the review from play store, its frustrations for user and giving bad reviews. This project is growing day by day. I know you guys asked why this api calls in single screen and reason behind this is the application is healthcare. We make a survey from customer and they want there results in homepage. I already read the doc and everything is up to according to doc. I don't want spoonfed, but I need guidance for you guys. Many thanks
I had a similar case where I had multiple api calls and it was so difficult to handle the ui state and dealing with loading and failure.
We can separate those api calls, there is calls that depends from each other so they can't be in parallel and there is calls that can be in parallel.
I made a loading state for each call and I separate the loading UI ( I used skeleton loader ), So each part of the UI is able to have a loading by itself not a loading state for the whole screen ( loading for the user picture, loading for posts, loading for categories... ).
And then I'm able to handle the success of each call alone, so if call 1 succeeded I will set the content related to call 1 and the other parts of the UI will remain on loading state waiting for their content, so each part of the screen is related to the calls responsible for returning the content of that part.
So no need to keep the loading state for the entire screen until all the calls finished.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I am building an Android app which uses activity and fragments and rest calls and a local database. Does anybody know where REST calls is ideal to be placed. I am more interested for fragments but would also like to know about activities as well. I also have a local SLQLite database and I have a method for getting the data. Because a database operation is long running is that similar to a REST call?
Thank you
You SHOULD NOT place long-running operations or any model logic on classes that can be destroyed by configuration changes (rotations, screen changes, phone states), these classes are designed to render the UI to the user.
You should instead use:
ViewModel (for shorter tasks, will only survive as long as the app does) and use a background thread.
https://developer.android.com/topic/libraries/architecture/viewmodel?gclid=Cj0KCQjw09HzBRDrARIsAG60GP-qiuPnYKryrX2YYZI39988xMfqTx4s6fuk5xfKtvuPZ-XQ98DxpgEaAphmEALw_wcB
Services (Recommended, can survive despite your app not being active), make sure to check out the documentation first and some examples.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I am already aware of the advantanges of retrofit and have used it in many scenerios. For a particular application , I need to call only 1 login API which will do authentication.
I am not sure if the advantages of retrofit are worth it for only one API. or is it a overhead and I should Http for sake of simplicity
If it is just a single request, then I'd say go with the simplest/lightest approach. But these things tend to evolve with time, therefore you are likely to find yourself in a position of adding another one, then another one...
Remember - networking mechanism is not an architectural decision. In fact, your application should not care what networking mechanism is being used - it should depend on a general interface that you define. You could start with implementing this interface using the simplest approach, and add a more complex implementation in case your networking requirements evolve. You could also implement several approaches and benchmark them...
So, whatever approach you choose, I recommend not to "pollute" your business logic with networking logic, but hide it behind interface. This way even if you make the wrong decision now, it will be a matter of few hours to fix it later.
For a single API call http is fine. As you know using library with your application is going to occupy user phone space when they install your application on their device. so for a single call, you are good to go with async task.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Need Suggestions.
I was discussing the design of an android app. Should we create a login activity to let a user login to the app or should we redirect the user to a browser and let him login over there and then on successful login redirect him back to the app and may be a next activity.
So I want to know that what are the benefits and consequences of doing it the either way.
You can do it either way, but like most apps do, I would suggest a login activity instead of browser redirect.
Browser redirect is just an overkill, for the user, as well as for the developer.
First of all, even if you use the in-app webview which doesn't make the user open the browser, it still means that the whole HTML will be loaded, which would take time and also consume data.
It's generally more user friendly if you use a Login activity. This ensures that:
The user doesn't have to wait for the page to load. The whole page is in memory. You can take the data required to login from the user in the activity itself.
You do not have to write code to handle the redirect. I know it isn't much of a challenge, but still, why complicate matters?
You can make any service calls you need in the activity itself, display appropriate error or success messages in a customised beautiful way like you want (which is the point of an app), and can start following a theme for the rest of the app, which makes the user comfortable with the app.
Best of luck!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have an interesting issues and wanted some input from someone with a similar experience.
I have an Android app that makes a REST call (e.g. accepts an open order). App sends out the request and runs into connectivity issues, meanwhile server gets the request, changes order state and sends back a response (e.g. HTTP 200). But, the app, missing its network connection, does not receive the response and gets an timeout exception. If I try to accept the order again, I get response that it is already taken (in this case by me).
The question would be - what should be the best approach to such situation.
For now, the requirements are to run a loop if I get a timeout exception (in some scenarios it's a loop including another web call to check whether this order did not appear in my "CurrentOrders"). I don't like this design and was wondering what would be better. Maybe the web call could return 200 (success) if the same client tries to accept the same order twice or more? Or how would some of you handle such situation?
I'm not quite clear about the semantic of your "accept" action.
What does it actually do?
On the one hand it seems it updates the order state. It should be then idempotent since further updates should not change anything.
On the other hand you have some kind of external state (order is taken). This can't be done through REST, you have to use some kind of unique id to resolve the conflict. Look at this question for more info.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
in a part of my app, I need to start an Activity immediately, I mean it should immediately comes up and fills the screen but no matter if it takes some seconds to load the view and widgets(and it has no I/O operations). is there any specific thing in Android for such purpose?
for example base on this article:
On iOS, the system displays the launch image instantly when the user starts your application and until the app is fully ready to use.
that is about launch time, however. but I want to gain something like that.
I know I should optimize the onCreate method and avoid time-consuming operations in the UI thread but I'm searching for another specific way of staring an Activity immediately.
Sounds like the flow of code is causing you a problem. I would suggest putting nothing in the onCreate(). And the layout that has all of your elements set them all to gone. That way when the activity starts, you're given a blank black screen. Then turn all of your layout to visible via code and any of your start up task that were originally in the onCreate() can now be launched. You can use a tree observer to determine when the layout has filled the screen to fire something, like a method call or async task for example, to finish all of your loading.