Currently i have an application where an activity calls a service which sends a file to a server. This is working fine..However, i was wondering does anybody know what happens if the internet connection is interrupted. Will the service run again when the connection comes back...Or is there something i need to implement to do this? If so how and what etc? thanks
The service will not run again when the connection comes back unless you add logic to do so. I'd recommend using a success flag to determine if a file was uploaded correctly, and if it wasn't due to an error (such as an interrupt), then you start the upload over again.
Perhaps alerting the user that a file upload has failed would be the best route to take, that way he/she can decide if its worth another try. This would also help keep your app from spiraling out of control while endlessly uploading a file to a server (although you could add a variable like maxNumberOfTries to avoid this).
Related
I'm trying to figure out if it is plusible to make an app constantly look for any kind of internet connection so once it finds any it makes a comparison of its local database with the one in the cloud and upload anything that is not in the cloud.
I was thinking about a code that triggers every time the phone connects to the internet but my research turned to be inconclusive and I'm running out of time.
You wouldn't do it that way. There's methods of being notified when an internet connection is made in Android, but you really wouldn't even do that. Instead you'd use WorkManager to schedule a job that requires internet, and let it launch the job at an appropriate time for you. See https://developer.android.com/topic/libraries/architecture/workmanager
I Have implemented the node js rest API. That being use in my android app with the help of Retrofit. Now. If my app is in production and then somehow my main server will be crash. So, in that case I have a backup server that will work same as the main server do.
So, How can I set an alternate base URL in retrofit android? So, If the main URL does not work then call all API from that alternate URL. Is there any build-it functionality?
Or most welcome for suggestions, Any other alternative ways to implement this.
I have another suggestion for you.
A NodeJS server should not stop for no reason. Most of the time, it's because of a 500 Error that have not been catched and stop the server. So, at first, make sure that every js command that may cause error is inside try/catch block.
Then, I suggest using of PM2 package
This is the best option to run on a production server.
It has several advantages:
It's easy to setup and run.
PM2 will automatically restart your application if it crashes.
PM2 will keep a log of your unhandled exceptions - in this case, in a
file at /home/safeuser/.pm2/logs/app-err.log.
With one command, PM2 can ensure that any applications it manages
restart when the server reboots. Basically meaning your node
application will start as a service.
ref: https://pm2.keymetrics.io/docs/usage/quick-start/
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
I am in the process of making an application. I currently have a database and a method that uploads pictures (along with data corresponding with the picture/s, stored in the database) using a PHP script on the server. Neither the purpose nor the database's schema are important. I haven't really done anything like this before but have looked into it a bit. Basically the user will take a picture with the app. The picture and its data will upload if there is a network connection, but won't if there is no connection (duh). I want to have the pending images upload once a connection exists.
To do this...My current plans are to use a BroadcastReceiver to detect when the user is connected to a network then use a Service to upload the files. Is this the proper approach? How can I basically go about starting a service when connectivity exists if and only if there are pending uploads?
Your approach sounds reasonable to me in general.
You would register a broadcast receiver with your package, listening for android.net.conn.CONNECTIVITY_CHANGE.
If the activities also trigger your service, you may be able to properly handle every case with an IntentService alone, so you won't have to deal with the many questions around when to stop or start a service with a specific life cycle.
Hope this helps; you don't sound like a beginner so you'll be able to make ends meet.
I have a task which I need to run in the background in my Android app. It reads data over the network and populates a database. It can take several minutes to run.
Once it's started, it needs to complete successfully without interruption. (Otherwise I'll end up with a broken half-populated database.) I realise I can never guarantee it will always complete, but I want to make it as hard as possible for the system to kill off this task. For safety I guess I will have it populate a temporary database, and then only swap out the old database for the new one on successful completion of the import.
It's a modal operation; it does not make sense for the user to be interacting with the app while the import is in progress.
My first attempt is using an ASyncTask with a Progress dialog to achieve the modality, but this obviously breaks the "don't interrupt" requirement. I could work around the screen-rotation issue with ASyncTasks, but I don't think that goes far enough.
At the moment I'm not sure if this should be an ASyncTask, a Service, an IntentService, some combination of these, or something else entirely. Can you help me decide?
I'd run it as a service and additionally I'd also have a clean SQLite DB on my server populated with the data the clients are going to retrieve so I can generate a kind of signature. Have the clients check for the correct signature of the DB. If the signature is not matching the servers signature then reinitialize the database filling process.
This is just an idea tho. I have no idea whether it'd be possible with what you are trying to do or not.
You are better off with services in that case. The Android runtime will leave it alone working as long as enough memory is available. In the case it kills the service, you can save the state in a bundle, and the system will restart the process as soon as possible, so you can resume the process, if possible for your solution:
Android Fundamentals, Service Section
Then it is easy to communicate with the service, like showing the progress/ notifications etc, using a handle registry like proposes by Mark Bredy in his Android Service Prototype