Deprecate loading.json and use preload instead

[gliechtenstein]

Changes

1. Get rid of the loading.json approach to loading screen because it was introducing too many unexpected bugs
2. Instead introduce much more flexible preload attribute to href.
3. Works for tabs as well

Now href has gained an additional attribute named preload, which is basically a JSON object that represents the loading screen's body (effectively the $jason.body of the loading screen). Here's an example:

{
  "type': "label",
  "text": "Next",
  "href": {
    "url": "...",
    "preload": {
      "layers": [{
        "type": "label",
        "text": "Loading..."
      }]
    }
  }
}

Benefits

1. Flexible: This means you can customize the loading screen per view, which makes it much more flexible than the previous loading.json approach which only had a single loading view available for the entire view.
2. Less buggy: The real reason why I decided to deprecate loading.json was because it was too buggy, since it was effectively loading the view twice, along with all the event attachments and everything. Now it's much cleaner since all you're doing is passing the preload view as an attribute and it renders immediately without loading the view twice.
3. No need for embedded file: Previously you had to use a local file://loading.json to customize loading screens. Now it's inline and you no longer need a file for this. Which means you can switch the loading screen even after shipping the app, just like rest of Jasonette.

Examples

• Instagram view: https://jasonbase.com/things/E1bD
• Simple transition demo: https://jasonbase.com/things/zMkx

[darenr]

with preload now being inlined what's the reason for the old style file:// reference in settings.plist?

<key>preload</key>
<string>file://preload.json</string>

[gliechtenstein]

That's for the very first view that the app launches with.

The very first view by definition doesn't have another view that can preload for them, so that's why it's needed. If you get rid of that field it will just launch with a blank screen, which is also fine.

[cpg]

This was confusing to me as well. Maybe the key should be different? say, firstlaunch or something?

I added a launch image to my app before this was in the works, but this would work in iOS as well as Android, making it easier to manage.

[darenr]

Thanks - I think I get it now, you define the preload before the preload happens, all except the first preload. Is there any convenient way of referring to the original built-in (preload.json) for those that just want to use the one that the app is compiled with or is that maybe the default when transitioning views?

[gliechtenstein]

1. I understand how the naming can be confusing, so have changed the "preload" attribute at settings to "launch".

2. The filename itself is still file://preload.json since you can use it for any view through mixins. For example:

   {
     "href": {
       "url": "..",
       "preload": {
         "@": "file://preload.json"
       }
     }
   }

3. As of latest on the develop branch, the file://preload.json is set ONLY for the launch screen, and for rest of the views you need to set preload attributes yourself manually.

4. I've done some testing with the preload feature, the only times it's good to use the preload attribute are:

   • when the next view has a completely different color scheme than the current view
   • when the next view does a dynamic network fetch (aside from the initial JASON load)

5. Otherwise it's better NOT to use the preload, especially if you just need to load the JSON once and don't do any dynamic rendering on $load via $network.requests, templates and $render. Looks like the preload screen itself adds a bit of a delay. Most views without a dynamic fetch/rendering load almost instantly WITHOUT a preload screen.