Help/Feature request: Access to device clock / enhanced timer

[Rob_Schoemaker]

hi Thunkable / Thunkers

Does anyone know if there are any plans to create a block that allows access to the time on the device?

I need to keep track of the time that a match has been running and the time needs to be displayed on screen in realtime. I know people suggested a workaround using a webapi call to timezonedb. While that works if time is needed occasionally, it is not workable for me to keep time of the match.

Here is what I did so far:

• when match starts, look up unix time in timezone db (=seconds since 1 jan 1970)
• store starttime
• set elapsed time to 0
• start timer with 1 sec interval, and when timer fires, increase elapsed time by 1
• etc

As long as the user stays on this screen, this works fine. But when a user leaves the screen (duh), or if app goes to the background or if screen locks, the timer does not fire anymore (which makes sense). So if this happens, the time goes out of sync. (as to be expected)

so, to work around this, i do the following:

• in screen open event, get time from timezonedb again
• get stored starttime
• calculate elapsed time by subtracting starttime from current time
• setup timer again, and increase elapsed time by 1 every time timer fires.

This works fine if a user navigates within the app and opens the stopwatch screen again.

HOWEVER: the open event does not fire when the app returns to foreground from background or when the device was locked and the user unlocks the device.

I found a dirty workaround for that, but I don’t find it really satisfying: although the timer component does not fire when the app is in the background, it does interrnally keep track of time. This means that for example if you set a timer with a 10 second interval, and the app goes to the background for more than 10 seconds, the timer will fire immediately if the app goes to the foreground again.

I used thin for the following workaround: I set a second timer with an interval of 15 secs (this is arbitrary). And every time that timer fires, I perform the same actions as in the open screen block. This way, if the app goes to the background and returns to the forground, at least the time is synced every 15 seconds.

It works, but is a dirty solution that involves a lot of api calls to timezonedb, so I am not happy with this solution.

So here comes my featurerequest:
please make the hardware clock available, because in that case the only action needed to keep the elapsed time is to subtract starttime from current time (no webapi calls).
Alternatively, i would also be helped if the elapsed time for a timer would be accessible. In that case you could just set a timer and see how many milliseconds are elapsed since the timer started.

Hope it is possble to include one. of these features in one of the next releases.

Thanks!
Regards Rob

PS If you also need this kind of functionality, please leave a comment/reply to this post, so that the Thunkable team knows that more people need this. Hopefully it will get a higher priority then …

[actech]

Hi,

You told us about a curious decision, but I would not timezonedb through and through WebViewer and Firebase: in Javascript get the time and store it in Firebase and then instantly get it in the application in block listener data.

[Rob_Schoemaker]

Hi,

Thanks for trying to help! Appreciate it. However, I don’t really understand what you mean by ‘curious decision’?

With respect to using webviever/javascript and firebase: I like the idea, but unfortunately I don’t think that will solve my problem. When I use your suggestion, I would need to make even more calls over the internet (instead of calling timezonedb once, I would need to call firebase 2 times: one for the write and one for the read). Also, if multiple users use the app, I would have to create a separate key in firebase for each user to avoid that the time info of one user interferes with the time info of another user.
It also doesnt solve the problem that I don’t know when the app comes back from the background and/or when the user unlocks his/her device. So I still would have to do all these dirty tricks to detect when I need to refresh the time.

Your post triggered me to think a bit more about Javascript, and I see another option, and that is to do the whole stopwatch in Javascript, so load the javascript page at the moment the stopwatch shouls start, and then do all the processing and displaying of the time in the webviewer. Probably that will work, but then I have a new problem, and that is that I dont have enough control over the webviewer (e.g. I would need to have a transparent background so that the stopwatch integrates nicely with my design of the app, and so far I did not find any way to do that). But anyway, I will look into that.

Still, I hope that Thunkable can provide a clock-block soon. I think it should not be too complicated to build (just get the time from the system and return it as a ‘value’ in the block). So I have my fingers crossed that something like that will be available soon.

The app I am building is for the soccer club of my son, and the season starts at the beginning of september, so I hope that something is available by then

Regards and thanks again!
Rob

[Rob_Schoemaker]

Just for your information, the app that I am building is for the soccer club of my son. It can be used to keep the live score of all the teams that are playing, one (or more) of the parents of players in a team have an account and can login to the app to change the score, keep the time, etc of their team. All the other parents/friends/family/anyone who is interested etc can download the app and see how their team is doing (live). Also the idea is to have a website that collects the status of all the teams, so that a live overview of how all teams are doing can be shown on TV screens in the clubhouse.
In the future, I also want to extend the app with functionality to keep statistics of all the players, like how many minutes they have played, cards, goals, etc.
So you can imagine that ‘time’ is quite important for this app. It doesn’t have to be accurate to the millisecond, but at least the minutes should be accurate… The idea is that the parent that is keeping the score presses a button when the first half starts, when the first half ends, etc. The timestamps of these events are kept in firebase, and are used to update the time on the screen of all users that are using the app. (for this it is really important to have access to the local clock, because otherwise all these devices are making calls to timezonedb or firebase (if I use your solution) all the time. If I have access to the local clock, I only need to update the start/end times via firebase, and all handling of the clock can be done locally on the devices of the users)

To give you a flavour of how things will look:

The main screen that anyone can see:

The main screen for users that are logged in and where the score can be kept (if a user presses the score he/she will go to a screen to enter a goal, if the user presses the time he/she will go to a screen to start/stop the stopwatch, if the user presses the temperature the weather conditions will be updated, the buttons at the bottom are for entering events like changing a player, a card, etc. Also it is possible to share an overview of the match via whatsapp/mail etc using the share button):

I still need to add a part with a list of events (like in the first screen), but I’m postponing that for the moment because I hope there will be an enhanced listviewer before the app should go live (september) (I would like to have the option here to remove or edit events and for that a listviewer would be more convenient than the label-tricks I did on the first screen)

The screen to setup a new match:

The sub-screen to start/stop the stopwatch (for parents that are logged in):

And there is a number of other screens (like setting up a team (=players, positions, etc), setting up a match (duration, location (as you can see, the app will automatically update the weather using openweathermap based on the location of the match), opponent, home/away, etc), entering events (like card for player x, goal by player y, change of players, etc), but I think you will get the idea ;-).

For now this app is only for the club of my son, but if it works as I think, I will also make a more generic version that can be used by any club that is interested (in fact, I already built in the functionality to do so, but for now I just force the app to use the club of my son)

So again, I really hope that we will have some clock component soon. (and also a better listview would really be handy, because now I use all kinds of tricks to display the scrollable view with the events on the first screen ;-). And using workarounds is not handy as I just found out: I use the trick shared on this forum for newlines (place a \n in a firebase db, and read that value when the app starts and store locally. In the next screens I use the stored \n to build the label that is shown on the first screen. This used to work fine, but in the latest build of my app, the \n characters are replaced by commas (,) - strange since I did not change anything in that screen, so probably something in the Thunkable backend changed, breaking my workaround . And also a ‘segmented’ button would be handy, the button in the setup screen to select Home/Away (“Thuis/Uit”) took a lot of manual work with rows/blocks…)

Thanks again for your help, and happy Thunking!

Regards Rob

BTW: Red/White/Black are the colors of the club (and yellow for their training shirts)

[actech]

Thank you very much, Rob, for discussing our question and a detailed description your interesting application!

You are right, the native component of the clock and other components will save us from many difficulties and create workarounds.

As far as I understand, you use the Firebase component in your application and every user must log in to get the necessary information in real time. Then you can make a field on the basis of the unique user ID for the time stamp. Firebase works much faster than web-services (and timezonedb) and two calls instead of one should not be embarrassing.

“because otherwise all these devices are making calls to timezonedb or firebase”. No, the work of timezonedb and firebase differs in principle. Timezonedb really works on requests, which happens slowly, and firebase uses the event model and the update client data occurs when an event occurs, and not with persistent requests to the web server.

I do not know when a clock component can be implemented. Now I see in the documentation the announcement of the component Alert dialog.

Regards Alex

[Rob_Schoemaker]

Thanks Alex for the clarification of the difference between firebase and timezonedb! I will definitely try to implement that. I will keep you posted on how that works out.
Just a question (in case you know?): how do I instruct the webviewer component to get the time again? If I supply a new url (even if it is the same as previously called), will it execute the javascript again? Or will it assume that the page didn’t change and dont do anything?

Thanks!

BTW: This will be challenging for other reasons (see my other post on number of screens in a tab navigator): when I had all of my screens in a single tab navigator, registering a listener for firebase worked fine. However, apparently there is a limit to the number of screens that can be loaded in a single tab navigator, so I thought I found a workaround by nesting tab navigators. However, that doesn’t seem to work as I hoped, because listeners I create in the screens in the second navigator just don’t seem to work, and I also have issues navigating to other screens. So a lot of challenges ahead, to be continued…

(Well at least the Tunkable team is getting some feedback on the issues we run into. It will only make the product better )

[actech]

Now I’ll try to remember how I solved this issue.

[actech]

I used a timer.

https://x.thunkable.com/projects/5b30d1e77a2e150ebc9b084f/project/properties/designer/

[Rob_Schoemaker]

Thanks, I will look into that tonight (I’m at work at the moment, so cannot really look into it now). Thanks again!

[actech]

I found another way to work with the date and time. Perhaps this may be useful to you.

In AirTable, you can use the “Create time” command to create a date and time field. When adding a new record to the table, the date and time of its creation will be automatically added in this field. After that, it can be obtained from the table to perform an operation.

[Rob_Schoemaker]

Great, I will look at that as well! Thanks again!
Another option that I will investigate is to create a function in firebase, that updates the elapsed time in firebase directly. Then the users would be able to just get the elapsed time from firebase (and also, if I limit the ‘resolution’ to one minute, maybe by adding a listener I can update the time display that way)
Anyway, lots of options to explore (which is fun in itself), but access to the clock on the device would still be the most convenient option

[Rob_Schoemaker]

Thinking about what you just said, I think this might also be an option:
Now I am using firebase to keep track of the events in a match. If I change that to Airtable, I can immediately add a timestamp to each event as well. I can then use firebase to set a trigger (just changing one field, so that the clients know that airtable is updated) and the clients then download a fresh copy of the events.
Still doesnt solve the issue of displaying time on the screen, but this way at least the times of the events will be ok

[Rob_Schoemaker]

Question for Thunkable staff: is access to the clock a block that is on your planning? (trying to figure out if I should spend time on finding a workaround or that I can postpone a bit and hope for a clock component in the coming 2 months (I understand that you can/will not give any guarantees, but it would be nice to know if I should spend my time on this or if I can better focus on other functionalities for now :-P)

[Ghica]

Why don’t you store the start time in the TinyDB?
You can retrieve the value at the Clock.Timer event and use it with the Clock.Now method to calculate the duration. In the TinyDB you store the start time in milliseconds, at initialization, either like this:

or a value that you receive from a FirebaseDB.
Then at the clock.Timer you could do this:

(This is for App Inventor, but it should work the same for Thunkable).
Cheers, Ghica.

[actech]

There is no Clock component in Thunkable X yet.

[Ghica]

I see. I should look at it soon. Cheers, Ghica.

[Rob_Schoemaker]

Thanks Ghica for trying to help. But like actech already mentioned, the problem is that there is no clock component in ThunkableX (that is why I need to workaround this using all the weird/complex stuff with timezonedb and timers, etc).
Hope the Thunkable team adds a clock component soon …

[Rob_Schoemaker]

@ Thunkable staff: can anybody please give an indication if there is a clock component on the planning anytime soon?

Unfortunately I had to put the development of my app on hold, because I cannot find a reliable way to implement the “stopwatch” functionality for my app. And without a display of how long the current game is running / how much time is left, the app is really useless. So I am really hoping there will be some kind of clock component soon.

@ Other Thunkers, I already got some great suggestions from @actech and @Ghica, but unfortunately I cannot really use them in my app. So if anybody has another suggestion to keep time of the match and update the stopwatch “in real time”, that is reliable, please let me know. Any help is greatly appreciated !!!

[paulmw]

We’re figuring out the best way create the clock component. There is actually a prototype already built, but we aren’t completely happy with it, and are trying to make sure that it’s the best solution for the future.

Sorry for the delay.

[derence.walk]

Hello @paulmw and/or @thunkable team,

First of all, thank you for making this cool product. It’s so great!

Quick question- just wondering if there’s an update regarding the clock component?

Thanks to the community, I think I’ve found a work around using a timezone api; however, I’d much prefer to use a built in clock component so my app could work offline.

If a clock component is coming to thunkable soonish (next month or so), I’ll hold off on publishing this app. If not, I’ll go ahead with the timezone API workaround.

Thanks!