Community maintained API's?

that sounds interesting. And we could pre-install that add-on I assume?

You mean as an add-on or as a classic web-app too ?
This would allow people to create new clock app, and that’s a really good point.
So we might keep the alarm app as a classic one, and not a part of chrome.

I think the idea is to create a web app with timer, countdown and alarms, but the actuall alarm handling is handed to an add-on. The app then is able to register an alarm in the add-on.

I don’t really understand what’s the point if you’re right. It’s like creating a new alarm API.

That sound like a advantage to me, because we reuse the things from Webextension to our missed features and preventing the implement new WebAPIs now in the transition of project.

If you mean in the build or by default, we can do that in the build process.

That sound like a good way to restore the webapp “clock” from the disable_app folder.

So, maybe we can found a way to expose the webextensions apis to the new webapps and use this for enrich the features for the new webapps. What do you think? @benfrancis or maybe we consult this to the platform team?, one of them is @lissyx, Right?

We can’t create an alarm API since there is no standart for that and we can’t change gecko, but like everyone else we can extend it with add-ons.
We need the posibility to set alarms, so we have to choices. Either we hack around in our own gecko fork which we always need to update with mozillas master and which probably will break again and again because they don’t bother about our changes. Or we create an independend add-on which interfaces with gecko through a clearly defined API which won’t break unexpectedly and Mozilla will inform us if they are going to remove, change or add an API.

Note that there is another way to introduce many APIs without making them (too) proprietary, “simply” by embedding a web server on the phone and using REST/WebSocket/WebPush/WebRTC APIs, depending on the case. I’m not clear about the complexity of this web server, but I hope that it is limited. Also, I hope that this can be made a bit more portable than WebExtensions, although I’m not clear about the specifics yet.

For instance, couldn’t mozAlarm be implemented as an (offline) WebPush? Or would this require some more platform support?

but REST services can’t be installed from third parties on the device. I’d prefer the add-on approach.

That’s not my point.

What I meant is that embedding an add-on that is used for alarm feature have the same default of creating a new API - every app need to be adapted for B2G OS.
I don’t understand what @benfrancis means about this add-on. Why can’t the webapps use this feature, and not a special add-on created for that ?
I don’t understand the advantages.

As far as I know there is no web standard way to create an alarm clock.

A few possible options:

  1. Propose a new web standard Alarm API built on Service Workers which the clock web app can access.
  2. Make an alarm feature part of the system chrome, e.g. in settings. (Figure out a way to re-use the Web Extensions alarms API, possibly by implementing the feature as a settings add-on.)
  3. Figure out a way to create a local alarms web service (e.g. using push notifications as David suggested).

The problem is we can’t keep the old API. There are no privileged apps anymore and we can’t make the API publicly available to every website. So we need a solution which lives outside of Gecko.

Is there any security issue with an alarm API ?
If no, I see no reason to avoid exposing it to every webapp.

That’s a game changer ^^
Can you explain what was your idea with the integration of this feature in an add-on ? I didn’t understood.

This could block the possibility to install another alarm app, right ?
I yes, it would be a big loose for the users in term of customization.

@benfrancis I’m trying to get the clock app working again, but I need some help. Should I file a bug? Is a general bug for fixing the app ok, or should I seperate it into single problems?

A meta-bug might be useful IMHO, as I guess you will run into more than 1 issue.

Hi guys! I was (and I am) very busy these days so I haven’t been working on the app this week but I have hosted it on GitHub:
You can try it online here too:
There is still to much work to do, but It looks nice :slightly_smiling:

About how to build the Alarms System, maybe for now using Web Extensions could be the best way.

@TitanNano I will be happy to try to fix apps with you. Unfortunately my computer died and I think I need to wait two weeks to have my new computer to work again.

@joancipria Your work is great but I am a little puzzled. Why not working on the original app from B2G repo? Removing the calls to the specifics API should correct the app.

[quote=“stargayte, post:36, topic:8298”]
I will be happy to try to fix apps with you
[/quote]Me too.[quote=“stargayte, post:36, topic:8298”]
Why not working on the original app from B2G repo? Removing the calls to the specifics API should correct the app.
[/quote]I think this is the best way.

@stargayte @pochy thats great! I will file some bugs and post them here so can subscribe to them.

1 Like

Maybe we can open a topic for the clock app ? This one starts to be long, and it’s not only related to clock app(s).

So it seems that you are working on 2 different apps guys, I’m not sure it’s very efficient right now. Having a second one, with a new design/feature, can be cool and add more choice for the users, but right now the priority might be to focus on 1 app, make it working, and after work on alternatives.
As the system clock app proved that it was working correctly, IMHO it seems to be the easier choice right now, and we can focus more on the alarm API issue.
And when it will be working, @joancipria you might work on your app, with for instance a new design or more feature - depending of what’s your wishes here.

What do you think about it ?