Experimenting with Mobile Chrome apps API: ( https://github.com/MobileChromeApps/mobile-chrome-apps )
What I'm trying to achieve is the registering of my chrome alarms without having to crudely start the apps' main activity as this causes a bad user experience.
The challenge:
I have specified a chome.alarm which gets successfully registered when I open the app ('cca run android ' for example). These alarms are specified in a background.js file, which is declared as a background script in the manifest.json file.
I wanted these to be registered automatically on boot, therefore I implemented a background service and thought I could simply call the app to register the alarms specified in the background.js file. However, the only way I can find thus far to achieve this, is via a call to launch the apps main activity via an Intent from within the background service as explained in more detail below.
On boot, my background service simply invokes:
//Launch main activity..
Intent LaunchIntent = getPackageManager().getLaunchIntentForPackage("com.company.appname");
startActivity(LaunchIntent);
The above launches the app into its main activity and the aforementioned chrome.alarms are registered as desired. Happy days! A massive downside to this, of course, is that no user wants the full blown main activity window to open on boot.
Please advise if there is a less clunky way to have the chrome.alarm specified in background.js registered at boot by a background thread. I do not wish to open the mainActivity of the app, yet this is currently the only way thus far I can see to get them to be registered. It is preferable not to register these alarms from within the Android SDK as I intend to stay as close to using web APIs and want to use background.js as the hook to do this keeping things in-line with chrome web apps as-well-as the android platform.
What I have done:
A cca (chrome mobile web app) app which registers a background service natively (I extend BackgroundService) as a plugin and register this to run at boot time. This is the only 'native android code' in order to load the app at boot-time.
Upon booting android, this background service then simply issues a startActivity(LaunchIntent) in order to open the app. In doing so, my chrome.alarm specified in my background.js file get registered successfully. If I don't do this, my chrome alarm specified in background.js do not get registered until I manually open the apps main activity. Therefore I use the backgroundService to open the apps main activity.
This is not at all ideal, I would simply like to somehow have my chrome.alarms registered without crudely having to launch the apps main activity window.
Is there a call which I can place in my BackgroundService to have only the chrome.alarms contained in my background.js file read and registered to fire?
Thank you for your time.
First, thanks for using Chrome Apps for Mobile! (Note: I work on the project)
Sorry that our current bootstrap is "crude" and "clunky", and we agree that it is. You can track this issue for progress on our effort to replace our current Background-scripts-embedded-in-main-Activity-webview strategy with a real background service and multiple window support. Basically you've summarized exactly our plan and existing limitations.
This work is actually scheduled for the near term, and will certainly be done before the end of the year.
As well as chrome.alarms, this feature is quite important for chrome.gcm and chrome.tcpServer (among other reasons).
Related
I am trying to create a flutter app that sends notification every time there is new entry in stream builder, it works fine when the app is on or opened but I want it to work and receive notification even when it is not opened , I have used workmanager to make the task work in background but it is not working ...the code for it can be found here code
Flutter apps by nature are supposed to run on a UI thread or foreground. The background tasks you are asking for are features disclosed by each individual platforms.
In case of Android, you can create a a Background Service to accomplish the tasks you need to perform when application is closed. The link to the bacground service is as follows: Creating a Background Service
In case of iOS, see this link for creating a background task. Other platform implementation will be as like above, so please have a look into each platform specific background process.
UPDATE:
Please have a look into the package Flutter Background Service. This package helps to deal with background tasks setup from flutter side even when app is closed.
NOTE:
Q: Why the service not started automatically?
A: Some android device manufacturers have a custom android os for example MIUI from Xiaomi. You have to deal with that policy.
Q: Service killed by system and not respawn?
A: Try to disable battery optimization for your app.
I'm adding to my App offline capabilities. Once the user clicks download button, the App is downloading some content to device (makes https calls and saves the result). The problem is that the download process is long (few minutes) and since the user is not interacting with the app, the app moves to the background and the download process fails. Coming from cordova world there is a simple plugin that allows running the app in the background. For Flutter, all the I found is the following medium article which looks pretty complicated solution to what I'm trying to achieve:
https://medium.com/flutter/executing-dart-in-the-background-with-flutter-plugins-and-geofencing-2b3e40a1a124.
Is there any method more simple to achieve what I need?
Hi I have looked for this question and can’t find it, so here goes...
My application starts with a sign in activity which logs the user in. Upon successful authentication, the initial launcher activity is replaced by a ‘content’ activity.
Everything works fine until I place the app in the background via the home button and start up some memory consuming applications.
Upon returning to my app, Android tries to recreate the activity on the top of the activity stack, however what I’d like is to have the signin activity be restarted instead.
The reason being that the user needs to be reauthenticated again due to inactivity in communicating with the server.
Is there a way of specifying this behavior in the Manifest.xml file or programmatically?
I’m aware of save/restore activity state, but in this case I want the app to restart with the signin activity, thus bypassing needless restore. (Since the user will have to be signed in again due to inactivity)
Thanks for the help!
UPDATE:The issue arises solely when my application process is killed by Android to reclaim memory to be used by other apps that are being loaded. The only aspect of my app that still exists at that point is the activity stack and its top entry is my MainActivity. This is because the activity stack is NOT inside the app process.
So Android is attempting to be nice to the user and it tries to restore the state of my MainActivity. However my ability to authenticate against my server is gone at that point because the user’s credentials have been wiped from memory together with anything that used memory.
Therefore instead of attempting to restore my MainActivity under these conditions, I’d like my app to start at the activity which is designated as the LAUNCHER activity in the Manifest.xml file. This activity implements the signin process which gets credentials from the user and sets up various singletons whih are not tied to any specific activity. NOTE: I don’t want to persist credentials or cookies for various reasons, so that is not an option.
I'm in the process of porting an app originally developed on iOS to Android. I'm trying to accomplish the following:
every time the app is started, call the start() method on a Manager class
every time the user leaves the app, call the stop() method on the same Manager class
every time the user comes back to the app (resuming from idle), call the start() method on the Manager class
The so-called Manager class handshakes with a server on the Internet and needs to do a variety of book-keeping activities every time the user the user enters and leaves the app.
Whereas iOS enables you to subclass the UIAppDelegate class and have code that runs when the app starts, ends, or resumes from idle, it seems Android doesn't have an equivalent approach. Instead, these are the options with Android:
1) Activity class: methods for every time an Activity (view) is created, stopped, or resumed
2) Application class: onStart and onDestroy for every time the app is started or killed
3) Service mechanism to create a background task that can be used to perform long-living operations in the background while the app is active or even while its not active
None of the above align real well with what I'm used to in iOS. Option 1 would require every Activity in the app's view hierarchy to have code that runs when the app starts/stops/resumes. Of the 3, I sense option 3 is more relevant. I'm just not entirely clear how I could start/stop a service in Android as the user starts/stops/resumes an app without regard to the specific activity they're on at the time.
I would appreciate input from Android developers or developers that work on both iOS and Android.
The so-called Manager class handshakes with a server on the Internet and needs to do a variety of book-keeping activities every time the user the user enters and leaves the app.
This might be a valid design pattern on iOS -- I have no idea. It is not a valid design pattern on Android. You don't "leave the app" on Android any more than you "leave the app" in a Web app. "Leave" is determined mostly as "you didn't come back in a while" in both Android and Web apps.
2) Application class: onStart and onDestroy for every time the app is started or killed
Note that the method is onTerminate(), not onDestroy(), and it actually never gets called. The Application object is created when the process is and lives until the process is terminated outright.
Its just not entirely clear how I could start/stop a service in Android as the user starts/stops/resumes an app without regard to the specific activity they're on at the time.
You might elect to use a service for doing the "handshaking" -- in fact, that's probably likely.
However, there is nothing built in for "leave the app". I would strongly encourage you to simply get rid of the concept entirely.
If not, you're welcome to rig up a service that is notified on each onPause() and onResume(), does the bookkeeping to see if there are any live activities, and if there hasn't been for X period of time, does your "leave the app" logic, then shuts down. You'd also trigger the "leave the app" logic in onDestroy(), if the service is shutting down at OS request vs. your own shutdown request. This is not 100% guaranteed to work -- users can force-stop your service and the OS can kill the process with impunity.
If you want to avoid duplicating code in all your Activities, why not have 1 subclass of Activity with the common code, and have the other Activities subclass that?
You can track activity lifetimes using a variety of mechanisms, including setting/clearing SharedPreferences in onPause/onResume, or use a singleton with reference counting.
Hope this helps,
Phil Lello
In the home page of my iphone app, there is a button added. When that button is clicked some other iphone app needs to be opened in a new viewcontroller (with out closing the parent app).There will be a back button on this view controller. When the back button is clicked, the new viewcontroller which is showing the another app needs to be closed and our parent app's home page needs to be shown.
Please give me some ideas on how to do this. I googled for this i didnt get any solutions.
Thanks,
Raja.
-- the following applies to iOS versions previous than 4.0 :)
Actually, there can be only one iPhone application running at once (with exceptions of Safari, Phone and some other system applications). The iPhone Human Interface Guidelines say so:
Only one iPhone application can run at a time, and third-party applications never run in the background. This means that when users switch to another application, answer the phone, or check their email, the application they were using quits.
However, if you only need to e.g. show a webpage, you can do it using UIWebView
Also, if you need to open another application, you should use URLs as pointed by Steve Harrison. This will, however, close your application. The recommended behavior in this case is to remember your application state and restore it when the application is run again, as Nithin writes.
According to apples documentation, they are not allowing any applications to be run in the background, except system generated ones. So you will be unable to do the thing you are going to implement. However, there is one thing that can make the same result.
You told that you are calling other application to run on a button click. Before initiating that application, save the current state of your application, may be using sqlite3 or core-data, and then open the other one. While returning back, load the pre-saved data from the database or wherever you have stored it. Every time you start the application, you check for the persisted data, if exists, load it or otherwise load your basic view
I don't think that you can run other iPhone apps within your own one. It doesn't make sense. You can open another iPhone app via a URL (see here and here), but this will close your app.
Like it has been stated: running two apps is not allowed by apple. You can however implement this apps features into you're app and have both get and save data to the same server...
Or like Nithin said: this functionality is available on JB iphones. Look into "backgrounder" for implementing one solution for normal users and one for thouse that has jailbroken.