BangleApps repo changes (apps.json removal?)

Hi!

This seems to have been a bit of a sore point, but I know a few people have complained about having to edit the large apps.json file to add their app, and instead wanted a single metadata.json file inside their app's folder that contained all the info about their app.

There was some discussion on https://github.com/espruino/BangleApps/issues/46 and https://github.com/espruino/BangleApps/issues/1020 with the reasoning either way.

I've been a bit on the fence about this as it increases complexity, but adamschmalhofer on GitHub has come up with quite a neat solution with: https://github.com/espruino/BangleApps/pull/1221

Basically it uses jekyll (which GitHub pages uses behind the scenes) to ensure that any time the app loader is published on GitHub Pages, apps.json is automatically created from the separate files.

So...

• You'll no longer have to mess around with apps.json. Every file you need to change will be in the apps/yourapp folder.
  
• If you're hosting with GitHub pages there's no change, everything 'just works'
  
• If you're hosting locally or with some other web server, you'll have to run a script before you publish changes - either via jekyll or I'll add a python/bash script to do it do you don't have to install Ruby/etc in order to use it.
  
  

What does everyone think about this? I'm inclined to do it, but it is a step away from the complete simplicity of the current app loader.

I would definitely welcome such a change!

I think separating like this is a good thing.
Although it is something you only need to learn once, I initially overlooked the existence of apps.json, assuming the apps were completely self contained.

or I'll add a python/bash script to do it do you don't have to install Ruby/etc in order to use it.

I think this additional script is an important aspect - needing to install Ruby etc. would have probably swayed me the other way on this. I assume there is a good reason (it would be pretty wasteful) for not doing the concatenation of apps.json client-side.

This would be a great feature to have, because often there are always conflicts in apps.json when I try to merge my fork and the master branch.

I'm all for it, now that the GitHub pages thing keeps working for newcomers.

Much tidier, less merge conflicts, plus we get an excuse to play with new and exiting ways to make apps.json automagically update in other scenarios ;-)

+1 for the idea, I also think it's a good solution.

One thing to notice, I don't know how many of you do the same, but I've changed my apps.json to only show the apps that I've changed on my github, so it's easier to understand, move around, etc.

On local file, it's easy: just edit the apps.json, but on github, how would that be done? Removing the metadata from everything else? Maybe some kind of whitelist config I can push?

I would love to have all files belonging to an app inside its own folder.
I think it will also make it easier to fetch the upstream on a repository with added apps.

Ok, great! For once we're all in agreement!

I assume there is a good reason (it would be pretty wasteful) for not doing the concatenation of apps.json client-side.

Yes, there's some discussion in those issues, but right now the app loader can start displaying apps after loading ~10 files. Client side it'd end up having to load 300+.

I've changed my apps.json to only show the apps that I've changed on my github, so it's easier to understand, move around, etc.

That's a good point! It'll need documenting, but this is still totally fine. There'll be some 'magic code' inside apps.json, but if you want just the apps you're interested in, you just pull that out and put in the contents of each metadata.json file you care about.

Gets my vote as long as the splitting up is done by a script and we all dont have to convert our own apps etc.

Getting rid of the merge clash will be a good thing. Also will it make the App Loader more robust as one bad metadata.json wont break the whole App Loader - you will just get a ? on the bad app ?

ad 1: I did the splitting (semi-automatically) and it will be in the merge, so you won't have to do the converting.

ad 2: Sadly no. But the bin/sanitycheck.js will give an error message pointing to which metadata.json is broken.

Hi Gordon,

this is a great idea! I already thought about this, too, but did not come up with a suggestion as I also saw the problem of the apps.json file creation. github magic and shell script would be perfect.

I also host my own app loader with the small subset of apps I actively work on. Currently, I've stripped down apps.json manually and solve merge conflicts on rebasing my own app loader branch manually.

I think that the use case "local app loader with app subset" is quite common. May I suggest to add a "restrictedapplist.json" (or whatever name it gets) in the main app loader directory. If it does not exist, the apps.json builder behaves exactly as proposed and includes the metadata of all apps into the apps.json. If however, restricedapplist.json exists and contains a ['list','of','app','ids'], only those apps are added to apps.json. This would allow to have that restrictedapplist in pesonal app loaders, it would not create merge conflicts (as the official loader of course does not have it) and make continuous integration of the official app loader into personal copies a charm.

One could even think about moving the restrictedapplist.json evaluation alternatively into the loader code. It could work like this (pseudo-code):

getAppsJson() {
  if apps.json exists
    load it
  else if restricedapplist.json exists
    load it
    apps.json={}
    for each app in restrictedapplist.json
      load app's metadata
      apps.json['appid']=app's metadata
  else
    bail out

Small development-only app loader could leave out the apps.json creation altogether this way. Loader with more traffic would create it by script or jekyll and had no performance loss. I must admit that my time and my Javascript skills are too restricted so that I have not tried to implement this myself so far.

Best regards,
Dirk
(who just created parts of the footage about a Bangle.js GPS video)

One could even think about moving the restrictedapplist.json evaluation alternatively into the loader code

That's a nice idea. I'll leave that for someone else, but we have a (semi-custom) loader.js file.

Perhaps index.js could check for the existence of Const.ONLY_APPS = ["launch","boot","foo","bar"] and could then ignore apps.json and load manually. Sounds like a really neat solution

Just FYI it's all merged in now! The development version of the app loader is using it! https://espruino.github.io/BangleApps/

Thank you very much for your enormous effort!

Wow! Great!

In https://github.com/espruino/BangleApps/pull/1323 I added an easy way for using a restricted apps.json. It still requires changing the apps.json-template. So you still need to ensure that it doesn't get commed. Merge errors should be less of a problem as upstream won't be changing apps.json often, anymore.

works well, seemless in fact.

Hi guys, I recently edited some metadata.jsons to fix some version numbers and add screenshots to some of the apps. When I was finished I checked my own fork of the app loader, but the app list was corrupted probably due to some typo. Is there any way to see where the error came from because it would be hard to check all the metadata.jsons I edited. I don't see any errors in the developer tools on chrome.

If you've got the fork running locally you can run npm test and it'll check everything for you.

OR if you submit a PR you'll get a travis check done on the PR (a green tick or red cross) and if you click through on that it'll tell you exactly what the issue was

ok, Thanks!