For a single screen, I have to show data which is not available from a single webservice call. I have to call three independent different webservices to get all the data to show in the screen. If I call three at a time, there is chance of getting false in poor connection and if I call one by one, then it will take long time and give poor experience to user. How to deal with this problem so that it gives best user experience and lowest chance of failure in internet connection.
I think this post would be off on UX Stack Exchange
Anyway, if your asking for something technical though, what we used before is implement a connection speed utility class (ConnectivityUtil) and provides a method hasFastConnection. See sample implementation here.
So when it detects a slow connection, we show a Toast saying something like "Your connection is a little bit wonky!" or any other. This would switch the blame to the user's connection rather than your app being slow.
We also increased our timeouts for this and if you have access to the backend, enable GZip compression and handle it appropriately on the client.
Related
I was going through the android docs for Efficient Network Access. I got the data prefetching part as well as the batch transfer approach, basic crux behind both of them being
Don't keep the network radio in active state all the time. let it go to stand by state at regular intervals
However, proceeding to the next section, Reduce Connections, I am still not clear with some of the statements. They are:
Reusing connections also allows the network to more intelligently react to congestion and related network data issues
and
it would be more efficient to make a single request for every news article to be returned in a single request / response than to make multiple queries for several news categories
and
A useful compromise is not to close the connection immediately, but to still close it before the inherent timeout expires
Can someone please explain these statements in detail?
What is a correct approach to deal with Internet connection unavailability (that is common on mobile devices)?
Maybe it's a big question (or maybe not), however I didn't find any Codename One tutorial / article / video or API to deal with an unstable Internet connection (that is the normality on mobile) without errors or unexpected behaviors. I've found an app (Protonmail) that has a functionality that I would like to replicate in my apps. Please look at the following two screenshot: the first one is taken when the Internet connection is available, the second one when it's not available.
I noted that the ToastBar appears not only when Internet is explicitly disabled, but every time that the server is not reachable. When the "No connectivity detected" message is shown, the app pauses the Internet activity, so no errors are generated (and the messages written by the user are not lost). When the app server returns to be reachable, the ToastBar disappears automatically (without pressing the "RETRY" button).
What is a correct way to implement a similar functionality in Codename One, in a way that is as most as possible independent from the specific app? Is it possible to suspend the Internet activity of a Codename One app and then restore it?
I'm imagining something like this:
the app tries to do a simple request (like a ping) to a server every few seconds, implementing the performBackgroundFetch method;
if there is no response in a fixed time (i.e. three seconds), the Internet activity is suspended and the ToastBar is shown;
if there is response, the Internet activity is restored, the paused or failed downloads are restarted and the ToastBar disappears;
ideally all of this should works also with a BrowserComponent.
You can detect a networking error in the NetworkManager class by using:
NetworkManager.getInstance().addErrorListener(e -> {
// prevents the error from propagating into the ConnectionRequest class
e.consume();
ToastBar.showMessage("Connectivity error, retry?", FontImage.MATERIAL_ERROR,
ee -> ee.getConnectionRequest().retry());
});
As explained here: https://www.codenameone.com/manual/files-storage-networking.html
The toast bar code just prompts in a similar way and offers a retry on the connection request. Notice that this is the generic global approach.
This will not work for things like browser component which connects on its own without "us". In there you will need to handle errors in the JavaScript side.
I have been reading a lot about network operations with android and how to do it properly. The documentation suggests using Volley and it abstracts the process making the network request:
http://developer.android.com/training/volley/simple.html
As I use Retrofit in my app I thought that the best practice was to use Loaders as they behave well on orientation change, but I found this:
http://www.androiddesignpatterns.com/2012/08/implementing-loaders.html
"Using a Loader to perform network requests isn't great practice, because (1) it means that your application will be hard on the battery (having to poll for new data from the network repeatedly each time you start the Activity, (2) there is no way to observer the network for content changes without polling it repeatedly, and (3) your application won't work offline."
(1) isn't particularly true because you can just resume the loader on activity creation. I don't think I fully understand point (2) and point (3) isn't a concern for me as there is no way for my app to work properly offline.
However, this caught my eye, again, from the same link.
"So my answer is to forget about using the Loader/AsyncTask combination entirely and to stick with a Service. The Service can poll the network for data every once and a while and insert new data into a ContentProvider. You can then use a CursorLoader to load data from the ContentProvider without it needing to know anything about where the data coming from."
Has anyone used this approach of using a Service to poll the network and populate a ContentProvider? I don't think it will work properly with my app as it uses a RESTful API that is constantly requested. I don't think it will be particular effective, but I might be missing something here.
Sorry for the long question. It is not a question exactly, but I wish to create a discussion around the topic.
I'm currently developing an mobile application and rest service. The mobile application executes lots of calls to the service even if no update is required and data didn't changed. In order to remove this overhead of rest calls I'm planning to implement GCM (Google Cloud Messaging).
My strategy would be the following:
Load all required data on application startup. When data change was recognized on server side a push notification will be sent via GCM to affected devices to make partial refreshes of data (via specific rest calls). Advantages of this would be less overhead at service side, because there are no unnecessary rest calls and a more fluid user experience in my opinion. Disadvantage is that the app is dependent on GCM Messages and that they arrive in time.
I'm unsure if this is the right strategy for this. Could someone maybe point me in the right direction and tell me if this is a good practice?
We could use more information before answering details...
I'm unsure if this is the right strategy for this. Could someone maybe point me in the right direction and tell me if this is a good practise?
I will consider for the sake of giving an overall answer that:
A - User is not always with the application "online", neither has network, not even a desire to have updated info at all times.
B - User is eletronicaly litterate enough to understand difficulties with the program.
With those in mind, then what would be a good approach is:
Poll relevant data, store them locally. At this stage, one would consider the relevant informations that user would have and store them, with a date flag.
Once a flag goes "old" (below your threshold), re-query that data.
Operations follow 2 directives... When observing a data, check its state, show the user if its recent or not, and if its not, poll it. If it is, if the user selects operations on it (POST mostly), re query the data.
This way, you have no static overhead, if users dont have the app on foreground. Also, should they use your "always online app", they understand that network is a necessity.
I have developed android apps, and have a web server application which serves REST style JSON, to the apps.
My apps are strongly dependent on that web services but as traffic gets higher, users' complaint started, as force close problems. I am not sure but maybe my server (AWS small instance) may not answer all requests correctly or in time.
I am planning to retry the web request when a problem on getting json response arise instead giving the error/net-connection alert.
I guess there are many developers who integrates apps with web services, so what is the good practice on handling network problems?
Or is the frequency of such network problems acceptable?
I take about 10-20 problem per day.
I have about 200.000+ web requests per day, for a AWS small instance (1.7 RAM), dedicated to server Tomcat. I analyze the logs there is no clue, no error log. Also the errors are spreaded.
You need to start with analyzing the problem, and determine the root cause or root causes of your issues. You always need to take into account that
a network connection might drop
a users switches from 3G / WiFi
the android devices "thinks" it's connected while in fact it's not
Also, be very sceptical when using the Android ConnectivityManager / NetworkInfo. Only trust it when it states that it is not connected. If it is connected, check it yourself (as sometimes, user is on a hotspot and the only connectivity he has is with a login page).
The application needs to handle all these scenarios properly. The way it's presented to the user depends on the use-case (do you want the user to be informed of the error, do you silently ignore it and just retry, ....)
In terms of retrying webservice connections, there are several ways to implement this :
exponential backoff
periodic rescheduling
event-driven triggering
retry-after moratorium intervals
You need to start by putting sufficient logging both on the client (Android) and on the server (AWS) so that you can analyze the issues and draw the proper conclusions.
I think the answer to your problem lies in the design of your android app.
You need to take into consideration the worst case scenario and redesign your application to take that into account and recover. Dealing with the chaos monkey - jeff atwood.
Personally I never allow an android app to be in a state where it needs to force close. For any or all network connection I assume that the connection is down, lossy, not all data can be retreived and (finally) up and working correctly.
That way my app will degenerate gracefully. If it needs web access it'll make an attempt in a background thread allowing the user to continue using the app, it will cache previous requests and will retry until it gets a connection or gives a nice toast to the end user.