running multiple sessions in android - android

I am learning Android and I have written some simple apps which work. The apps individually are quite simple. But I want to execute these as asynchronous functions in the background without using intervention at regular intervals. For example, this is the sequence of methods I want to execute every 15 minutes:
Check for internet connectivity
Try to access www.google.com and return success or failure
Try to access a bad URL so you get a failure
Send SMS in background check for success or failure
Send gmail in background check for success or failure
Send yahoo mail in background check for success or failure
I can create a method for each of the items. The question is how do I execute each of these one after another and get the result to log? Then repeat the whole process. Do I need to sleep() between each of these activity?
I can do this in iOS Swift using NSURLSession.
Appreciate your help and guidance on this.

Related

Why in Google App Engine Always 11 secs of Latency coming only for the first requests?

I am deploying my Nodejs sample app to Google App Engine Flexible env and when I am using google app engine URL which is in the form appspot.com to hit my API, it is taking around 11 secs to send response from my mobile data, but other APIs are sending response in milisecs.
Also, the time delay is only happening when I am opening my android app and sending request to the server after that all requests are taking normal time, and again delay is coming when I again open the app and send request to the server.
Edit - I found that
This can be a caused when your application is still booting up or warming up instances to serve the request and can be called as loading latency. To avoid such scenarios you can implement health check handler like readiness check so that your application will only receive traffic when its ready
That's why I checked in my Logs that readiness check is performed sometimes around 1 sec
and sometimes around 200 ms
Can anyone please tell me is there anything wrong in warming up my instances because I don't think cold boot time is causing this problem.
Edit 2
I have also tried to set min_num_instances: 2 so that once loaded atleast my 2 instances will again not get boot up, but the thing is delay is again same.
Edit 3
runtime: nodejs
#vm: true
env: flex
automatic_scaling:
min_num_instances: 2
max_num_instances: 3
Edit 4
I am noticing a strange behaviour that when I am using this app Packet Capture to capture traffic, then all https requests (if I am not enabling SSL Proxying) and all Http requests are executing in milisecs whereas without using this app all Http/Https requests are taking 11-16 secs of delay.
I don't know how but is there any certificate kind of issue here?
Edit 5
Below I have attached Network Profiler where delay is coming 15 secs
Please Help
Depends on which App Engine you are using and how you setup the scaling, there's always a loading time if you don't have a ready instance to serve a request. But if you have readiness check to ensure your instance is ready (and not cold started for the request), then there shouldn't be a problem.
Can you find a loading request or any corresponding slow request in your logs? If not, then it's likely an issue with the app. If possible, instead of calling this API on your app, do it from two apps (one is already open, one is not). So you make calls from both apps and if you notice that the one that's already open is getting a response faster than the other one, that means that's a problem with the app itself. App Engine can't determine whether or not your app is pre-opened so any difference would be client side.
=== Additional information ===
In the your logs, there's no delay at all. The request enter Google and was processed within a few milliseconds. I am sure there's something application-side. Maybe your app is constructing the request URL (first request) from some other source that results in the delay? App Engine has no knowledge of whether or not your app is opened or not or whether it's sending a first request after being opened, it cannot act differently based on it. As long as your App Engine instance is ready and available, it will treat your request the same way regardless of whether or not it's your first request after the app is opened.
The issue is resolved now, it was happening because of network service provider which is Bharti Airtel, their DNS lookup was taking the time to resolve the hostname. After explicitly using alternative DNS like Google 8.8.8.8 the issue got completely resolved. Maybe it's a compatibility issue of Airtel with Google Cloud.
Last time I checked I remember having to put a warmup request handler so that Google would know that the instance is up and running and can be used to answer calls. Keep in mind that code has to be EXACTLY under the endpoint you specify in the handler under the yaml file. (Wouldn't be the first time someone forgets that)
Here are the docs https://cloud.google.com/appengine/docs/standard/python/configuring-warmup-requests this is python specific, but you can also check other languages like Go, Java, and such in the docs.
If the problem is client dependant (each time a new clients spawns and makes a call it gets the latency) then it is most likely, either a problem with the client app itself or with initialization, registration or DNS resolution.
You could also try to reproduce the requests with CURL or similar, and see if also with those you see the mentioned delay.

Keep getting messages, Socket

I have a scenario which I need to resolve. Currently I'm able to connect to an embedded system through socket connection, via android device.
I was able to use asynctask to send xml commands and receive them back, update UI with the results. But on the last step I need to use a command which will start the system to work, and I will keep getting messages from the system. it will be sent variously and the time can be different (we are talking about few 200-500 ms).
So my question is:
Asynctask wouldn't work. Because the 'work' varies more than 100ms and I'm not sure when the messages will be send, So I can't use async and show dialog for unknown time.
I have read that intent-service or service can do this work, but I'm not sure yet if it will be a good solution.
What would be a good solution for receiving these messages and for updating the UI?

Proper error handling when sending an XMPP push notification using go-gcm?

I'm using https://github.com/google/go-gcm to send push notifications from our Go backend to Android devices. Recently, these push notifications started failing because the call to SendXmpp() was returning with the following error:
write tcp <IP>:<port>-><IP>:<port>: write: connection timed out
Restarting the Go process that called SendXmpp() makes this error go away, and push notifications start working again. But of course, restarting the Go process isn't ideal. Is there something I can do explicitly to handle this kind of error? For instance, should I close the current XmppClient and retry sending the message, so that the retry instantiates a new XmppClient and opens a new connection?
I would recommend using or implementing a (exponential) backoff. There are a number of options on GitHub here; https://github.com/search?utf8=%E2%9C%93&q=go+backoff though that's surely not a comprehensive list and it's not terribly difficult to implement.
The basic idea is you pass the function you'd like to call in to the back off function which calls it until it hits a max failures limit or it succeeds. Between each failure the amount of time waited is increased. If you're hammering a server, causing it to return errors, a method like this will typically solve your problems and make your application more reliable.
Additionally, I'd recommending looking for one that has an abort feature. This can be implemented fairly easily in Go by passing a channel into the backoff function (with the function you want to call). Then if your app needs to stop you can signal on the abort channel so that the back off isn't sitting there with like a 300 second wait.
Even if this doesn't resolve your specific problem it will generally have a positive effect on your apps reliability and 3rd party API's you interact with (don't want to DOS your partners).

How to design an app which executes tests on webpage in background, and let the user use his phone normally?

I am currently trying to design a particular application and I don't really know how. The app has to run like this.
What I have to do :
The user launches the application. This action starts something independent of the UI (a Service currently), which has to request a remote server to get test scenario, execute the tests and send results to the same server, even if the UI of the application is not on the screen.
Second constraint : the user chooses, at the beginning, the time between two requests of scenario from the server.
Example : The user starts the app, chooses "do one request of test scenario every 5 min" and after, he can do what ever he wants on his phone. And the app, every 5 min, send a request to get test scenario (not one, but a various number, 50 for example), do the test scenario, and send the results to the server ; and then, wait for the next request.
During this, I think a notification icon in the status bar could be a good thing to access to the UI of the app. With that, when the user feels that the app has done enough tests, he can access to the UI and stop the app.
What I have already done :
I create an Activity which creates a Service. I also set an alarm with AlarmManager, received with an AlarmReceiver which calls the Service every X min/seconds/... and starts in the Service a request to the server to get the scenario (the http request is done in an AsyncTask). The service puts a notification in the status bar in its onCreate() method. I also managed to parse JSON, send HttpRequest and just technical things like that.
What my problems are :
I find that the Service stops itself at the end of the onStartCommand(). It finishes the method and then go to onDestroy() (where I don't put stopSelf()), but is the Service really closed ? If yes, how could I managed to have it "up" during all the duration of the application ?
The notification in the status bar just appeared and disappeared with the rythme given by the AlarmManager. How could I "stabilize" it ?
If you have already designed an app like that (a mail app, I think, is a good example, which request the mail server every X minutes to check new mail, and send a notification), how can I reach my goal ? To reuse the mail app example : is the service which checks the new mail on the server is always running ?
I really don't know how to design this king of app, so any help is welcome.
Sorry for my bad English. If you want precisions, code of the Service, the Activity, just ask.
Regards
Looks like your Service is running on the UI thread. You should create a new thread inside your Service, where all networking operations will work. So, there is no need in AlarmManager - just wait X milliseconds inside your Thread.
P.S. If you don't know how to create new thread:
new Thread(new Runnable(){
public void run(){
//your code here
}
}).start();
but I highly recommend you to read about multithreading first.

Notification of Activity from AsyncTask

Within an AsyncTask, I am making a REST call to retrieve data. Within that AsyncTask, I may encounter an exception which I would like to package up (the HTTP code) and inform the Activity, which based on the HTTP response code (Timeout, Unauthorized, etc), would display different messages to the user.
What would be the best way to bubble that information up to the Activity for processing?
I have looked at a number of different Android mechanisms such as Notification, Handler, etc but I can't seem to determine a good architectural pattern for this situation.
If the error causes a halt in the users workflow, then you need to obtrusively interrupt using a dialog alert and then direct the user to the fix. If the error does not stop the user, then interrupt unobtrusively using a toast or notification.

Categories

Resources