White screen/Load time: App launch takes > 30 seconds

Capacitor
1

I am currently facing an issue specifically on Android with Capacitor: The initial loading time of the app is over 30 seconds long. A white screen is shown for a long time, before the app is loaded.

I do not use any splash screen and the issue does not occur on iOS either.

I took the following screenshot of chrome:/inspect: https://abload.de/img/load_time_capg2jxc.jpeg

So, after navigationStart() and fetchStart() nothing happens for like 30 seconds.

Do you have any idea?

Thank you!

2

Small addendum.

Removed the whole JavaScript from the index.html

Still loads enormously long.

Meanwhile, I also removed the /android directory and started with a fresh npx add android. Same issue as before.

I suppose it is not related to the server, since the web app loads perfectly fine on Chrome or Safari.

Used plugins:

[info] Found 7 Capacitor plugins for android:
@capacitor/app@1.1.1
@capacitor/filesystem@1.1.0
@capacitor/geolocation@1.3.1
@capacitor/haptics@1.1.4
@capacitor/local-notifications@1.1.0
@capacitor/share@1.1.2
@capacitor/toast@1.0.8
[info] Found 2 Cordova plugins for android:
cordova-plugin-file@6.0.2
cordova-plugin-file-opener2@3.0.5

3

Possible bug, and possible workaround!

4

Hey just seeing this.

Capacitor doesn’t really recommend that you use remote hosting for your app

5

… and introduces huge problems with API calls, authentication and external libraries (cookies) when using the local build. That’s the problem.

6

Care to explain more? Using local builds have been very successful for basically everyone, and anything that stands out is likely a small config fix.

for external libraries that use cookies…remote vs local wouldn’t affect that. Besides, cookies are also not useful as ios/chrome will likely block third-party cookies.

7

Thank you! I am currently facing the issue that “Cookies” are generally not set on a local build version. Both in terms of the API, as well as any libraries.

I have CORS set up and can also send requests to the backend and get the correct responses.

Cookies are simply not stored in the WebView. The “Remote version” works without problems in this regard. Although, of course, WebView is also used.

It also doesn’t matter if I use Axios or community-http. After all, external libraries usually use Axios or Fetch. That means that this must also work for the local build version.

I have tested several things and nothing seems to be working.

MainActivity.java

public class MainActivity extends BridgeActivity {
  @Override
  public void onPause() {
    super.onPause();
    CookieManager.getInstance().flush();
  }

  @Override
  public void onPostCreate(@Nullable Bundle savedInstanceState, @Nullable PersistableBundle persistentState) {
    super.onPostCreate(savedInstanceState, persistentState);
    WebView webView = getBridge().getWebView();
    WebSettings settings = webView.getSettings();
    webView.setBackgroundColor(Color.parseColor("#919191"));
    /*
     * webView.clearCache(true);
     * webView.clearFormData();
     * webView.clearHistory();
     * webView.clearSslPreferences();
     */
    settings.setJavaScriptEnabled(true);
    settings.setAllowContentAccess(true);
    settings.setDomStorageEnabled(true);

  }

}

server.js

const cors = require('cors');

const allowedOrigins = [
    'capacitor://localhost',
    'ionic://localhost',
    'localhost',
    'http://localhost',
    'https://localhost',
    'http://localhost:8080',
    'http://localhost:8100',
];

const corsOptions = {
    origin: (origin, callback) => {
        if (allowedOrigins.includes(origin) || !origin) {
            callback(null, true);
        } else {
            callback(new Error('Origin not allowed by CORS'));
        }
    },
    credentials: true
};

app.options('*', cors(corsOptions));
app.use(cors(corsOptions));
8

I am facing the same issue in android however its work fine in iOS.

10

The cookie problem has to do with cross-domain requests. It isn’t worth fighting it, we’ve tried.

For session ids, we put it in the url as a query parameter. All other storage goes either in localStorage or sessionStorage (or secure storage using a plugin).

1 Like
11

@aparajita Thank you.

But with built in methods this problem could be possibly solved, for example Angular Http Client. I read the following article about this.

However, when you intend to have also a website beside your apps, you would of course go for something like Axios. These requestes will not work, also from my experience so far.

In my view, this is a design flaw in Capacitor.

You can only use Capacitor if you only want to provide apps, and accordingly align the HTTP infrastructure only to them. Or you write the requests all twice, which is a lot of work and also error-prone.

The only solution for having “Website & App”, like you would nowadays usually want to have, is to point to a server. However, this is not recommended in the documentation, and obviously does not work too stable.

12

Edit: The Cookie problem is not solved with the mentioned article above.

13

Could be fixed with 4.1:

14

If you want a website and app to point to a server, you should be building a PWA for mobile. The whole point of Capacitor is to build a hybrid mobile app that runs on and is served from the device, thus feeling like a native app, while of course still allowing you to access remote API servers.

15

Nevertheless, the access to API servers is not that helpful considering that many libraries also require Cookies to be set, beside the most crucial “Authentication”. This is currently not possible with a local build, but only in the “PWA” mode when pointing to a server, which serves the whole app.

16

True enough. Hopefully they will finally implement a working http plugin on iOS.

20

With a new release now?