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.
Related
If I open a web app using a web browser or a PWA by clicking the icon on my home screen, can that app still send HTTP requests while it's minimized?
I'm asking this because of say, for example, I want to check out a navigation app to navigate to somewhere but I still want the web app to update the user's location through HTTP requests while it's minimized.
Is it possible or does the app stop "working" while it's not in focus? Is it a service worker implementation needed?
You can achieve your task implementing a PWA. The Service Worker file will run in the background and keep running even when the user closes the app.
This is possible since the SW runs on a separate thread.
It is also possible to execute background sync, even though its support is quite limited:
You can let the service worker call the server to send the user's position if internet connection is available, otherwise this information can be stored in a local DB (eg. IndexedDB or Cloud Firestore) and then, once the users gets online again, the changes will be pushed to the server.
The nice thing by using Cloud Firestore is that the synchronisation is made out of the box for you. I wrote an article about the usage of Firestore with PWAs to overcome the limits of CACHE API. It is within a series of articles about PWAs, have a look st tit if you want to deepen the topic.
I started with a application where you can chat.
Now im in the position to start with the chat.
The problem I'm facing is that I don't want to use
resources from "outside". With outside I mean:
Firebase, Socket.io and so on.
I do simply rent a webspace. And I'm asking you now,
how is it possible to realize an live chat without
using extern services like firebase.
Is it possible with only using an Webspace?
What is required to make an live chat?
And there comes the second question:
How do I realize to stay connected to a server to check if there is a new message without using much battery or network ressources?
I'm not asking without hardly trying by my self.
Two days ago I started with the research of possibility, but I didn't found anything which would work I guess.
Thanks folks...
You need to connect to the Web Server using a Socket and keep that connection open to receive new messages with little delay (see for example http://srchea.com/build-a-real-time-application-using-html5-websockets) This keeps the phone active and uses much battery.
The very purpose of Firebase is to bundle this work for all services which need this type of communication (E-Mail, Push messages of newspapers, Chats) such that the phone only has to query one server. Therefore, I see no way for you to find another solution which uses little battery.
Is there anyway that I can read the data from the real time database of firebase and can save it while the app is not opened, I am using Firebase.getInstance.goOnline();
in the code whenever Network connectivity changes so that it listens the data.
I am able to write the data in the database if app is not in recents or is not opened but in the same way I am unable to read the data when app is not opened. Is there any possible way ? Or I am going for an wrong approach ?
I just wants that whenever network connection will be available it will download the updated data automatically. , so that later on I can see the updated data being offline.
Any help will be highly appreciated. Please.
Android makes no guarantees about whether or not your app process is running when it's not visible on screen. It could be killed in favor of other processes that are a higher priority for the user. So, in general it's not a good idea to assume that you can do networking any time you want.
Also, newer Android devices will go into doze mode to help save the user's battery. In that case, your app will definitely not be running.
If you want to ensure that your app process is running, you can schedule some time with JobScheduler or AlarmManager. Or you can ping your app from your server with Firebase Cloud Messaging.
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'm building a program which interfaces with a device which runs its own internal web server. I communicate with the device via a web API.
Basically what happens is that a GUI is presented to the user, where the user can make certain modifications to the device. These changes are communicated to the device, and results are returned through XML. The device needs to converse with the program in the background more or less continually (say every 15s or so) to update certain values to the user.
My structure that I'm envisioning is something like this:
UI - Main - Networking - XML Parser.
I'm looking for advice on how to manage these. I understand the UI thread should be separate to provide a smooth experience to users. I also understand that the networking should be at least an asynchronous task. I'm not so sure about how to handle their interaction, and make sure things are happening smoothly and effectively.
My idea is that Main will handle passing data around, telling the networker to send specific messages or changes, passing the returned XML to the parser, and then passing the parsed values to UI for handling.
I'm curious though for advice beyond that.
Have a look at creating a service that is created with your Activity. Without knowing the details of your plan, a Service looks like the optimal solution to perform all the heavy work.
UPDATE:
You could have the calls to web API run in a Service and, when needed, update the UI through an interface. You would have to instruct the Service to run on its own thread, so thread safety is an issue, but less trouble in the long run than using an AsyncTask.
Have a thought about using Google C2DM.
In your case,
Pros -> Less battery use, coordinated network traffic, Don't have to run a continues service and doesn't have the potential of being killed when the device runs out of resources.
Cons -> You have to post the results manually back to your internal server, and server should know which request the device is replying to. Communication is disconnected and may not be real-time. Requires a google account on the device and Google market.