Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-4341] 2nd instance of application run from a separate process causes NullPointerException

GitHub Issuen/a
TypeBug
PriorityLow
StatusClosed
ResolutionFixed
Resolution Date2019-11-20T23:14:34.000+0000
Affected Version/sRelease 1.7.0
Fix Version/sn/a
ComponentsAndroid
Labelstbs-1.9.0
ReporterJeff English
AssigneeUnknown
Created2011-06-07T07:28:44.000+0000
Updated2019-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; } }

Comments

  1. Bill Dawson 2011-06-23

    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 via bootModules, 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.
  2. Jeff English 2011-08-15

    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.
  3. Alan Hutton 2019-11-20

    Should have been closed per dev comments. Closing.

JSON Source