You are reading a single comment by @Rarder44 and its replies. Click here to read the full conversation.
  • a premise:
    the message is long and I helped myself with google translate for some pieces, I hope there are no blunders!

    I was thinking more of an app that manages the receiption of the message, (saves in the storage, sets the additional parameters to the msg, etc.) and another that ONLY implements the show functions
    (showMessage, showMusic, showMap) which obviously are recalled if necessary by the first.

    Actually these days I was thinking about it, especially the optimization speech and two ideas came to mind that could be used (at least partially):
    1)

    to manage everything in events, it is not necessary to move all the code during the boot phase, but only the "pushMessage" function which at this point could be cleaned of all those references to the actions to be done (load message, turn on the screen, etc.) leave only the code that "understands" the type of message and launches the appropriate event.

    The message app, (or who will intercept the event) will not necessarily have to load everything in the boot, but something similar will suffice

    Bangle.on ("message", msg => {
    eval (require ("Storage"). read ("myMessage.app.js")) (msg);
    }
    (I don't know what the performances could be; I should do some tests.)

    so in the boot area only a few references will remain and each app will manage the events independently.
    (obviously the message app will also register for events like all other apps)

    we would only have to think about a question of "priority" and handling of the event, but I think that is the least of the problems.

    the advantage of this methodology is that multiple apps could register and handle the same event (for example an app that tracks a specific notification, along with the standard messsage app)

    2)
    if instead we want to keep the performances to the maximum, then we could:
    leave the Android / IOS app as it is
    structure the message app in a similar way:

    • message.core.js (containing all the message app logic, getMessages, buzz,...)
    • message.GUI.message.js (containing only the showMessage function)
    • message.GUI.map.js (containing only the showMusic function)
    • message.GUI.music.js (containing only the showMap function)

    When loading the app from the appstore, we can merge all these files to create a single file that works exactly like the actual message app.

    we could therefore think of a way to "choose" the GUI part that you want to install (such as customizing the app from the AppStore, or a separate app that does the same procedure during installation).

    I know it's a bit of an overkill but it should allow you to logically divide the "graphics" from the "code" without practically affecting performance (the message app would work exactly as it does now)
    I doubt however that this method could be a bit "tight" in some applications

About

Avatar for Rarder44 @Rarder44 started