[TIMOB-4341] 2nd instance of application run from a separate process causes NullPointerException
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | Low |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2019-11-20T23:14:34.000+0000 |
Affected Version/s | Release 1.7.0 |
Fix Version/s | n/a |
Components | Android |
Labels | tbs-1.9.0 |
Reporter | Jeff English |
Assignee | Unknown |
Created | 2011-06-07T07:28:44.000+0000 |
Updated | 2019-11-20T23:14:34.000+0000 |
Description
The latest version of the Urban Airship SDK supports a new notification handling process, whereby the PushService can be configured to run in a separate process. When it is configured in that manner it creates a 2nd instance of the application which in turn results in the OnCreate method of TiApplication being called a 2nd time. The result is a NullPointerException occurring somewhere in that method.
The workaround for now is to configure the PushService to run within the current application process, but UA recommends running it in a separate process to conserve memory.
The following excerpt is from the Urban Airship documentation on how to resolve this issue:
Process Management
It is possible to run the push service either in your application process or as a separate stand-alone process. We recommend that most applications run it in a separate process. The primary benefit to this approach is that it allows the service to run with a relatively small memory footprint even if your application is resource intensive. In a low memory situation the OS can kill a backgrounded application's main process without disrupting the service.
To run the service in a separate process, simply add the "android:process" attribute to the service element and provide a name for the process. If the name starts with a colon, the process will be private to your application:
Note that when the service runs in a separate process it will create a separate instance of the application when the service is started. This means that your application's onCreate() method will be called again in another context. For most applications this is not an issue, but if the onCreate method invokes any code that should only be called once (such as analytics code that changes state outside of the application) you will want to ensure that it only runs in one of the processes. The following sample illustrates a method for determining which process your application is running within:
public class MyApplication extends Application {
public void onCreate() {
// the main process for this application is named for the package
// if this is the default process, run some special code
if (isProcess(context.getPackageName()) {
//run default process operations here
}
}
private boolean isProcess(String processName) {
Context context = getApplicationContext();
ActivityManager actMgr = (ActivityManager)context.getSystemService(Context.ACTIVITY_SERVICE);
List appList = actMgr.getRunningAppProcesses();
for (RunningAppProcessInfo info : appList) {
if (info.pid == android.os.Process.myPid() && processName.equals(info.processName)) {
return true;
}
}
return false;
}
}
The [service-in-a-separate-process suggestion by UrbanAirship](http://urbanairship.com/docs/android-client-push.html#advanced-setup) requires some fairly major architectural changes and considerations which we're deferring for consideration in 1.9. A few points: * It creates a second instance of the Titanium application but doesn't run through the root activity, thus no titanium javascript code has an opportunity to run. Because of that, there's no opportunity to call
takeOff
via JS. * In that second instance, our Java UrbanAirship module instance wouldn't be instantiated yet either, as the instantiation occurs viabootModules
, which gets invoked only when a KrollContext is created (which only happens via our normal startup via the root activity). * The UA notification callback (a JS function) is meanwhile hanging around in the first application instance's UrbanAirship module instance. So it anyway can't be called via the second instance.With the fix for TIMOB-4991 and MOD-157, this issue should be resolved. Initial testing of the fix for MOD-157 with a hand-coded fix for TIMOB-4991 shows that running UA in a separate process works. Awaiting official fix for TIMOB-4991 to do final validation.
Should have been closed per dev comments. Closing.