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:
- Propose a new web standard Alarm API built on Service Workers which the clock web app can access.
- 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.)
- 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: https://github.com/joancipria/b2g-clock
You can try it online here too: http://s610249639.mialojamiento.es/clock/
There is still to much work to do, but It looks nice 
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.
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 ?