Search code examples
jdeveloperoracle12coracle-maf

Remove White screen in Oracle MAF applications


I am using springboard in my application and have multiple task flows. So, whenever i switch from one feature to another feature a white screen flicker screen comes on task flow change among feature.This screen is also coming in MAF examples as well given by oracle.I want to remove that white screen coming for a short while on first time load of task flow feature.Please reply me that how can i achieve it.

jdeveloper version : 12.1.3

maf : 2.2.2


Solution

  • Anand, we (I'm an Oracle employee) recently received a similar question internal to Oracle from Oracle Support on behalf of a customer. Presumably that customer was you and you already have an answer. Let us know otherwise.

    Post edit in response to Anand's follow up answer.

    No worries, here’s the details of the issue you’re seeing. I’ll attempt to describe why it's happening, and how you can potentially change your app to reduce this problem.  While the description is long, it isn't actually that difficult to make these changes, it just takes a lot of words to explain!

    In addition, I recommend you DO NOT make these changes permanent without a FULL ROUND OF REGRESSION TESTING.  These changes will fundamentally change how your app is composed, so I can't guarantee it won’t break some of your logic.  In order for you to make these changes and have confidence that nothing breaks, you also need to undertake a FULL ROUND OF REGRESSION TESTING before you make the changes, then compare it to the results of the post-change regression test, so you can differentiate from existing issues and new issues introduced by these changes.

    So let's take a step back and describe why the issue occurs.

    Firstly, as you’ve noted the issues happens the first time the application opens, and the first time you open a feature with an associated task flow. If you have a springboard with many features, as you skip between the features and they each start for the first time you will see this white flash for each (only the first time, not on each subsequent reopening). It also slightly delays the navigation to that task flow depending on the speed of your device.

    Second, this issue will be much more noticeable on slower devices or in the Android emulator without HAXM as it is associated with a performance bottleneck. As MAF runs faster on iOS it’s hard to see this problem at all, and on modern Android devices in turn it's hard to see as it is too quick.  As example on my older 1.5Ghz 2nd-gen 2013 Nexus 7 tablet I can see the white flash, most modern Android phones have a 2Ghz+ processor and I’ve not really noticed this problem any more. In turn as a developer you will see the flash more often as you will be continuously killing & redeploying the app which results in a restart of the app and the flash appearing the first time the app & each feature are opened/restarted again. (real users will see this much less often as they tend to stick to a couple features in most apps, and leave the app running in the background so the features are already initialized)

    So why does the flash occur, and the associated delay in navigation?

    When a feature is first called, MAF initializes a number of things in the background, including a classloader per feature.  That initialization for whatever reason is costly in terms of performance, and during the processing can result in the UI being cleared which results in the white screen. I coin this effect the “white screen flash”.

    Once a feature has been initialized, the speed underwhich it renders is much faster and you're unlikely to see the flash as everything is now safely initialized. In other words the problem is only noticeable for the first time a feature is rendered. If you re-open the feature, it will be too quick to see as the classloader is already loaded.

    As we now know what is causing the problem, what can we do to avoid this assuming Oracle won’t fix or optimize the issue? (and in fairness the MAF development team did optimize MAF heavily in the 2.2 release).

    Ultimately the solution is to reduce the number of features in your application, and ultimately (if possible) reduce this to just 1 feature so when the app starts you get the white flash once, but not again. But that begs the question, when MAF pushes you towards using features invoked by the springboard, how do you do this? Can we really reduce all the features?

    If you think about your MAF application, you will typically have 1 feature for the springboard, then lots of other features for various useful parts of your app. Let’s call that the “springboard” feature (singular), and the “logic” features (plural).

    The solution is therefore to:

    1) move everything from your existing logic features (but the springboard feature), that is all the AMX pages, and other components such as managed bean in your task flows into 1 new single logic feature. For each of the preexisting logic features now embedded in that single new logic feature, create a wildcard navigation for each so they can be accessed and give each a name. eg. goFirstFeature, goSomeOtherNameFeature etc

    2) for the current springboard feature it will stay, but we need to change how it works.

    Typically customers create a springboard feature with a listview to navigate to their features (rather than use the autogenerated springboard).  As our goal is to eliminate the logic features and replace them with the new single logic feature, the original springboard won’t work as it’s designed to call the other original individual business features (rather than our new super single logic feature).

    Instead what we need to do is hardcode the ListView with ListItems to call each individual (logical) feature in our new single logic feature using the wildcards.  Something like the following:

    <amx:commandButton text="Go First Feature" id="cb1" actionListener="#{viewScope.myBean.goFirstFeature}"/> 
    <amx:commandButton text="Go Second Feature" id="cb2" actionListener="#{viewScope.myBean.goSecondFeature}"/> 
    

    This is backed by a bean with the following code:

    public class MyBean { 
    
        private void doFeatureNavigation( 
          String featureId, String navigationFlowCase) { 
            AdfmfContainerUtilities.hideSpringboard(); 
            AdfmfContainerUtilities.invokeContainerJavaScriptFunction(featureId, 
                "adf.mf.api.amx.doNavigation",  new Object[] { navigationFlowCase }); 
        } 
    
        public void goFirstFeature(ActionEvent actionEvent) { 
            doFeatureNavigation("package.name.of.new.single.logic.feature", "goFirstFeature"); 
        } 
    
        public void goSecondFeature (ActionEvent actionEvent) { 
            doFeatureNavigation("package.name.of.new.single.logic.feature", "goSecondFeature"); 
        } 
    } 
    

    Note how the code hides the springboard, then in context of the single business feature navigates to one of the wild card navigation rules you setup earlier in the new single logic feature.

    3) if any of your existing logic features have AMX pages with command controls that navigate to any other logic features, you will need to change the code to call the wildcards:

    <amx:commandButton id="cb5" action="goFirstRequest"/> 
    

    So it feels like a lot of explanation, but it really is 3 steps. Having done this then satisfactorily tested the app, you can start eliminating the redundant original logic features + task flows. Do not delete any AMX pages, pageDefs or beans, just delete the redundant features and task flows.

    I’ve made a lot of assumptions along the way here in proposing the solution as I haven’t seen your app. But I hope this will give you a flavor of what the solution is.

    And also you really need to think about is this a big problem and should you really undertake the solution. Personally with the latest optimized versions of MAF on Android, and faster Android devices I’ve not seen this problem for some time. Basically the white-flash is so quick that it’s just no longer a noticeable problem. In turn as real mobile users keep the app running in the background, they see this problem once, and won’t see it for sometime again until they kill the app and restart. So you need to think about are you fixing a problem that may not be seen by the majority of your customers.