This object is in archive! 

Addon/API for Dashboard to display custom data

Falco shared this question 5 years ago

Let's they you want to have cool things on your dashboard which are not supported by locus. There would be 2 solutions:

- Add an overlay and check if somebody did close the dashboard by check UI content

- New dashboard components which are updateable over API

Why do I request it?

Well, I like my elevation change calculation ( so much that I want to keep it because the amount of customization on your own pressure value analytic software can never be implemented in locus without losing some features of it.

And now I would like to include the calculation result into my dashboard.

For me it's easy to do this as a overlay because I do only need to support my own dashboard. This is my todo list for this solution

  • place an overlay on top of the locus elevation
  • close the overlay if I use my hardware button dashboard toogle
  • close the overlay if you touch it in case that I close the dashboard without my hardware button
  • listen for elevation changes from locus to add them as offset to my own elevation change overlay value because it is to expensive to calculate it every time:sensordata line offset is to complicated becase there is more then one sensor output all files untill offset is reached is not an option because skipping 300.000 lines is still an expensive IO operation
  • full recalculation of the overlay every 2 hours because difference between my advance calculation and the basic locus altitude calculation isn't that much after 1 hour.

I do just ask about this because I want to know if an API support of Dashboard updates would be usefull for 2018. Because if this will not be implemented this year, I will create the overlay solution.

Replies (4)


A second topic is this one:

I still have 1 Problem with reading data from locus: I do have problems to get locus elevation calculation result values into tasker to use them as offset for my full calculation which is triggered every 2 hours.

  • UI element readout does not work because dashboard elements doesn't have parseable informationen like tab headers, the are rendered directly and you can't get any text out of them. I guess there is no easy way to change this?
  • I guess I can't receive Locus PeriodicUpdates with tasker becase it need a intend filter in Manifest? Tasker Limitations: Tasker can only receive intents which are sent to broadcast receiver components, not to activities or services. some intent senders require that a corresponding intent filter is specified statically (i.e. in an Android Manifest). Those intents cannot be received. intents which are broadcast with a specification of a particular package component to receive it cannot be received.
  • I don't want to write an app for getting locus data because then I need to handle all the events and IO operations by my self instead of using tasker. And I can't integrate an app in tasker, at lest not an app which need to be running all the time, there would require some weird filesystem interface between an broadcast receiver app and tasker :(
  • I don't like the periodeUpdater for this task anyway because If I don't want to receive everytime the whole dataset of everthing if I just need "mElePositiveHeight". And I don't know how the intends work in android, if there are just memory references or if this receive is a huge things with lot of memory copy operations. I can't imaging a lightwight architecture for this instent things but maybe I am wrong and it doesn't matter who much things are go through this.

Are there some other ideas? In worst case I have to think about a solution for getting the latest lines of sensor data without reading 300.000 lines of sensordata


I found a solution based on Locus API, I could create an app which translate the locus intent to a much smaller tasker intent. I do only worry about application terminates by power management because this perodicUpdates handler would be without UI.

Does the api already handle wakelooks to keep my app alive? Or is there any known solution for a good handling? After this Huawai storry I don't know which is the correct way to tell android that my app should not get terminated.


Ok, this second topic is answered, I will create an app between tasker and locus for data access only. All UI, Filesystem and Event things are handled by tasker. I like tasker because you could modify everything without implementing configuration UIs. My app won't do anything else except transforming locus api results to tasker calls.

I dicide this beause I found more cool things in the api like "INTENT_ITEM_TRACK_TOOLS" and I figured out how advanced your API code is. You did already implement the whole foreignt app database handling to access locus app content to get large amount of data instead of putting everything into the intent. I like this.

At first I thought that this api was just an wrapper for all your intent actions.

Which means only the main question is open: UI overlay vs set dashboard field intent.


I maybe need this "overlay vs a new set dashboard field intent" for another workarround: because this field is maybe not importend enoght. I guess we could solve alot of non importand dashboard requests with dashboard addon fields.


Not able to help with this, but I would surely use your solution if you get it done. Good luck!


The app would be mainly a project for autumn. That's why I ask about planings for late 2018.


Good day Falco,

I did no every imagined such specific requirement :).

  • yes, UI elements in the dashboard are drawn completely different compared to rest of common app UI, no way to change it simply
  • PeriodicUpdates ... I think you are now skilled with this system, so there is known method to you with the direct request for these data
  • About "wakelocks" ... API definitely does not help here. It is on your own app to keep alive. Best and most probably only way is to have running foreground service with active notification. In case of Huawei it is also a different story. They are killing applications that use GPS, which won't be your case.

API itself is partially wrapper, but offer also many features that are not possible over simple Intent>Intent communication. You already found it. Because it was made during maybe 5-6 years, it is little inconsistent and missing huge amount of documentation, sorry for that. I just rather write code and docs/wiki :).


Anyway, back to the original idea. This whole story is because you want to get improved altitude values in the app. I still fight with some stupid Huawei/GPS/License troubles and had not yet free evening time to read more carefully your post about the improved filter. Option to insert custom dashboard values is interesting, but definitely not possible during this year. Anyway, I believe that altitude system in app has a lot of space for improvement, so best should be to optimize the existing algorithm in the app from my point of view.

Otherwise, hope I gave you all the necessary answers for your interesting experiment. Feel free to ask if something won't be clear.

Replies have been locked on this page!