I have an app that has a Service that offloads photos that people are taking to the server.
Specifically, users are sent to the device's native camera to take a photo and then the photo is returned via intent to the app from which they "approve" it.
This act of approval saves it out to the file system and the Service comes along every x seconds, notices files awaiting offload and offloads them.
This all works fine.
However... in situations where there is bad connectivity but enough for the HTTP handshake, the app finds itself in a state where even though the offload is happening in a Service, at the point where the user is coming *back to my app from the photo taking (and Android is delivering the 4-8mb photo back to my approval Activity, my app hangs - sometimes long enough to provoke the "do you want to kill or wait" prompt. Eventually (if you wait) it does succeed in making its way back to the app.
I've verified that this is Network related because when the connectivity is strong (or when the app is in airplane mode - so the upload just fails instantly) everything works perfectly smoothly. The *only time this happens is when the offloader in the Service is hampered by a hinky connection.
So, my question is - what can I do about this? Is there some way I can isolate the Service to not have a larger effect on the app? Is my solution to write a partner app that sits on the device and just looks to offload the files (would that even solve the problem?).
HERE is the report I'm getting when the WAIT/KILL prompt is offered to the user. I'm not sure what to make of it.
The answer turned out to be that Services are actually running on the main Display thread (I was mislead by the fact that when you make an HTTP call in a Service you don't have to run it in a separate thread manually).
http://gmariotti.blogspot.com/2013/03/antipattern-freezing-ui-with-service.html
Related
I have a strong Android background but I have recently developed a PWA that can be installed to a users device. I have noticed that when the app starts for the first time, the splash screen shows and then the app displays it's first page which is great. Now, if the app has been backgrounded for a while and I relaunch the app, it sometimes appears to display a white screen for a few seconds then the app kind of flickers and some aspects of the page reload, creating a jarring experience.
I am familiar with how lifecycles work in Android, saveInstanceState and all that jazz, but what is actually happening here with a PWA is backgrounded? I am unable to debug what is happening because it takes a long time to reproduce and the debugger needs to be attached before launching the app.
Are there any documents describing exactly what is happening with the lifecycle of an installed PWA and how to gracefully restore it when it has been backgrounded or background-killed?
You may look into this documentation. "Progressive Web Apps have to be fast, and installable, which means that they work online, offline, and on intermittent, slow connections. To achieve this, we need to cache our app shell using service worker, so that it's always available quickly and reliably." A service worker has a lifecycle that is completely separate from your web page. Based from this article, a service worker lifecycle usually has three stages:
The install stage, during which it is common to cache assets like stylesheets, client-side JavaScript, and so on.
When the install stage was successful, the activation step happens, during which any obsolete caches are deleted.
Then, the service worker is idle until it needs to deal with a request from the client code.
You may read the article for more information. Hope this helps!
I was wondering if it is possible ( it should actually) to run a piece of code every couple of minutes even if the user is using the app. The basic Idea behind this is that the User will take the smart phone with my app loaded in the field and start collecting data, while he is collecting data or playing with other options of the app the phone catches the 3g/wifi zone it will start syncing the data to the server. I keep pushing notifications to the devices from my web service using Google Cloud messaging (GCM) and when it reaches the phone it means the phone is now connected to the internet I run that piece of code which do the sync for me. Would it stop the current activity of the app or I would say do the user will be able to keep collecting data and the sync is also running on the background?. any idea of this type of scenario?
thanks guys.
Anything that communicates with a server is by nature asynchronous in ActionScript (and you can't make it synchronous). So just do what you'd normally do to communicate with the server. Other processing, such as loops over a large collection or drawing a lot of objects, can make the application unresponsive.
Yes it is possible using AsyncTask. And your application will not stop while AsyncTask is running in background.
I have having problems with a WSDL/SOAP service call in an app I have built in flash builder for mobile. I have connected to the service using flash builders built in data/services functionality.
For the most part, the service call works perfectly but once in a while it will cause the app to crash - on my android device it completely locks up (spinning animation stops) and then Android informs me that the app is not responding and asks if I want to close it.
The crash appears to occur quite frequently but not with any pattern. One time it happened on my third attempt, another time it took approximately 30, a couple of times I could not get it to happen and most times it occurs somewhere in between.
It appears that the crash happens after a service call is made but before any response is received. Neither the success or the fault listeners are ever fired. I am very confident that I am sending exactly the same variables to the service every time.
I have used web service calls in other apps without trouble so I have to assume there is something in this particular build that is causing problems but I can't seem to find anything.
Any thoughts on possible causes, things to test or even a solution would be hugely appreciated.
Thank you,
Jamie
Your question lacks essential details, so now I can suggest you to setup Charles proxy and monitor you requests trough it.
If you send too many requests simultaneously, you shall not be confident in fault/result events as air runtime has limitations (in any case, it is a good practice to handle request timeout).
Is there a known / common pattern of how a mobile application should behave from the point it is launched (more the case of fast launch from suspended mode) until the point a connection with the server is establish and ready?
I'll try to explain, when the app comes from suspended mode, the UI is quickly shown, but for the connection it usually takes a bit more time to re-connect with the server.
Even more, a lot of time the app needs to re-login with the server so it will take some more time.
My question is, how responsive should the app be at that time?
Of course blocking the all UI is a bad idea, but should I for example block the buttons that trigger some network activity until the login phase is finished?
I have the EXACT same issue with my App. A secure app that has to ping a server for login credentials after a programmer defined time-out or the user choosing to exit. I've found it to be better, from my very limited experience, to show a simple progress dialog that informs the user the App is connecting to the server for secure logon. My UI isn't blocked completely. The progress bar spins because the login process is always in an AsyncTask(Asynchronous Task). I hope this applies to you in some ways. I choose to make the dialog completely Modal so all other buttons beneath it aren't active. I also inflate my dialog to completely fill the screen to stop anyone who might have just picked up another person's phone from seeing sensitive data on the screen.
You should do the server connection thing on other thread or use GCD.
In that way the main thread will be responsive and it will act accordingly on establishing connection with server.
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.