Hi Andre,
With our clarification of the term ‘navigation application’ in mind (see my e-mail from earlier today in this thread), I think we are on the same page about these points. I’ve replied inline below, and will send out a new version (0.3.1) of the design shortly, which will hopefully clarify some of the ideas I refer to a little more.
On Tue, 2016-01-19 at 14:13 +0000, Barkowski Andre (CM-CI1/PRM1) wrote:
Andre: no, we still have a fundamental mismatch, the purposes are very different. I feel its hard to discuss all that via email, but lets try: With the referred APIs (point_of_interest) we hand over data _responsibility_ form one (source-app) to another (sink-app). The “navigation app” imports that data, from that point in time any further data management (duplicate handling, persistence storage, validity, usage in various embedded services like destination input, route calculation, etc) in in their internal (black box) responsibility. The mechanism is simple a point-to-point data pipe, deliver and forget. We do not flood the navigation app by providing to it all information available, only information which shall be handed over into their responsibility, so typically which shall influence their routing. We do _not_ import all mac-donalds data into the navi app. This stays in the mac-donalds app, it gets browsed within this app etc.
The points of interest API supports filtering the set or stream of PoIs which an application receives, so if the navigation UI needs to show a specific set of PoIs (fuel stations, for example), it can request from the PoI service to only receive those.
Please keep also in mind, that the navigation app itself is somehow special in regard to their output. Beside provides some UI to control its functions like all the other apps (e.g. media player), the “route guidance” information is very special. In addition to a black box build-in solution for the route guidance - like all the smartphone Smartphone solutions realizing today – (on prompt the guidance is only acoustic or an app-change transition to the navigation app appears) we will go a step forward for this driver related information. The guidance will be presented to the user independent of the current App in use in foreground. So you can “leave” the navi- app but the guidance shall continue. In fact we influence the internal design by requesting an agent to be provided by the app- developer to deliver these data. And that’s not only an acoustical prompt, its also data which gets finally a visual representation (turn icons, lane information, etc). In this approach via an SDK-API the rendering gets done by some system service. Its more like a “notification”/“dialog-box”/“status framework” stuff (please have a look to the running status framework and the relation to assist framework too). So the navigation App provides its data as output to some SDK-API. In fact part of this is the route list, which finally land in that guidance dialog. Lets call it assistance window – driver related information.
I see. The way I would recommend doing this in the design is to implement the guidance UI separately from the navigation UI. It could potentially be part of the same application bundle, or part of a different one, or even implemented as part of the system chrome.
The guidance UI would take data from the SDK points of interest API, and from the SDK navigation route guidance API (§7.6). This would allow it to render the route (from the guidance API), and points of interest along the way (from the PoI API).
The navigation UI (where the driver chooses their destination and plans the route) may retrieve points of interest from the SDK, or may choose not to if the developer thinks they will be distracting.
i.e. The SDK API you are suggesting for the data from the guidance UI is effectively the points of interest API plus the navigation route guidance API.
To this route list, other apps can directly add further data. This is _not_ forwarded to the navi-app, it does not modify the route list nor does it gets stored by the navi-app. The navi app don’t has any interest in getting and managing it. This data, gets provided by the source app to the rout–list and with that finally rendered to the user by some system service (assist window). On the other hand, other apps can consume this enriched route list again for their build-in functions and policies. Its all outside the navigation, the navi only provides the initial foundation.
That’s possible due to the split between the navigation UI and the guidance UI. The navigation UI can choose to not query for points of interest, or can heavily filter the PoI requests it makes. Conversely, the guidance UI can query for lots of PoIs.
If other applications want to display something similar to the guidance UI, they must make the same navigation route guidance API and PoI API queries as made by the guidance UI. This should be simple to do, and allows each application to further customise the points of interest they display.
Specifically, depending on the answers to the questions in that design about the relative bandwidth of the POI streams, this can be implemented by: • the navigation app queries POIs from a publish/subscribe POI service and displays them on the calculated route as appropriate; or • the navigation app sends the calculated route as a query to a POI query interface (§(Consumer-initiated pull via a stream)); or • the POI apps send their POIs to the navigation app which then chooses which ones to display on the calculated route (§(Provider- initiated push via a stream)). Andre: like said, we are not restricted to an App-App relation (even though we support this limited approach too), I am talking about a system service in-between. On the one hand this is handling all driver related notifications like guidance, but hazard sport warnings, speed limits etc, and the navigation App is only one out of many providing this data, on the other hand it’s the data responsibility, which does mean Points_of_interest API gets used to handover the responsibility and this will be done only for a very small subset (relevant for route calculation)
I think this is covered by my points above. If it becomes necessary to add a PoI service to cache points of interest queries between applications, I believe that can be done much later without affecting the PoI design significantly. There is no need to add one from a security point of view, which is the normal requirement for adding a service.
The other suggested data sharing models are also possible here, depending on the bandwidth needed. If it’s also about changing the behaviour of other applications to display data pertaining to the calculated route, then we will need another API for exposing that data, and it would be entirely unrelated to POI sharing. Andre: yes, that’s part of the scope.
Right. That API is the navigation route guidance API, and is at section 7.6 of the latest design.
- add UseCase: to add something into a route list (e.g.
restaurants
along the route from restaurant app) and this based on own
interest
of the user, specified in this app (e.g. via favorites) and under control of User by enabling this participation via settings.
Do you mean automatically? What is the user's participation in this use case: are they specifically interacting with a restaurant app and
ask
it to book them into a restaurant and add it as a navigation waypoint; or do they just want to see nearby restaurants highlighted on the
map
as they travel through an area? Andre: like said above, information from the route list will find
its
way to the route guidance (we sometime call this driver assistance
information).
So its not about reservation, its about information. A Restaurant
App
could provide recommendations for a rest stop, fitting to the driving
time
(e.g. a location area reached after 2 hours of drive), the day time (afternoon, evening, etc => coffee break, dinner, etc), the user preferences (Italian, vegetarian, etc) etc. In relation the use-case above “add UseCase: to share/subscribe (updated) route-information” The App subscribes for changes in route list, and provides new POIs inc ae the path has been changed.
I guess I am not quite clear about the user experience here. With this restaurant use case, are you expecting the restaurant app itself to provide the recommendations //as part of its interface//; or are you expecting it to export them as POIs which will be displayed //by the navigation app as part of its interface//? Andre: like explained above, please don’t see the Navi app as the final sink. It has a relation to a system service to expose its notification to the driver. <<...>> <<...>> <<...>> The “user interface” is part of a system chrome, we call it “assist window”. Its like a notification center, but for driver centric information. The navi-app provides data to it, but other apps too. For each product variant, we implement a UI customization for the look & feel of this “driver notification center”. Once the user tap on an object in that view, the related app gets launched. There can even be a second instance of that information exposed to the instrument cluster, but that happens behind the scene with some Interdomain communication. There can also be “POI data” w/o any active navigation (route guidance). In case there is no destination set (and with that no route list) apps can provide POIs surrounding the current geo position (e.g. hazard sport warnings, touristic info, etc). The user can define via system settings if an app is allowed to expose data to this center (like in a usual notification center)
I think this is covered by my points above.
Please add this to the right place – the right proposal - as take care that our design fits to it.
To be sure I understand you, you’re talking about ensuring that a task which is started by an application which is then sent to the background, is completed rather than (for example) being paused? Even while another application is in the foreground? Andre: My focus is less the completion in background, my focus is independence (or vice versa side-effects) caused by remote calls. It’s a kind of “multi-threading”, even w/o multi-user capabilities. But to skip the software terminology, think about having a user driven path (assume you start writing an email in email client) and an inter-app communication (user interrupts email writing, leaves the app, [email state in background is still in editing mode of the last mail], launches browser, jumps to a url and renders the page, and then he gets in mind to “share” that page with some friend, initiates sharing mechanism, selects via email, an editing view of email slides in with the given url embedded). This task shall _not_ irrevocable destroy the background mode of the email app, which is still in editing mode of new mail. The user can even switch to email, and continue writing it, because the new one is executed on behalf of browser. If the user switches back to browser, he gets the sharing screen on top, etc. Its typical iOS behavior, so you can reflect it quite easy.
I think that is the behaviour we are aiming for, although it depends to a certain extent on application developers implementing their applications to behave correctly when focus changes and another activation request comes in.
In an app centric solution we would like to enable freedom for Apps to present it accordant to its needs. So the App can define the size of the map widget, its position in the screen, it can add animated transitions to the whole widget (e.g. a backflip animation of the map, showing some preferences on the back side), and can also define the look & feel of Data added to the map (e.g. appearance animation of added POIs,
i.e.
own clutter actors).
OK, that’s all possible. What would not be easily possible is to allow the application to define how the map itself is rendered (for example, what colours are used for different grades of road), as libchamplain typically uses pre-rendered image tiles for its map, whose rendering we cannot affect. Andre: yes, the tiles are ok. I referred to freedom for data _added by the App_ That’s not the tiles, but additional icons, points, polygons, etc. Even for these we can prepare some fitting well to the overall look&feel, e.g. “blue pin falling from sky” for POIs, but an app my create on own clutter actor for its POIs and use them for the representation of its additional data.
Definitely all possible (and easy) with libchamplain.
In all three cases here, I think the POIs are coming from the same pool of sources. The differences arise in how long the sinks keep the POI data, how they process it, and which of the POIs they consider interesting. Am I following your thinking correctly? Andre: to be honest, I am thinking in another direction. Its driven by responsibility and data management. In regard to the first topic: There is stuff which gets embedded into libchamplain which stays completely in the App responsibility. Its for User Interaction, nothing else. It uses libchamplain APIs (clutter) to embed POIs. The user can interact with it and libchamplain informs the App about content selected which has been included by it. So nothing from a central POI service in that regard. In regard to the last topic: There is stuff which gets imported into some other App. Data responsibility gets forwarded. This is the “some App streams data into the navigation” via a pipe solution. Nothing central in between for the data flow, only for the control flow some SDK-API has been used.
My suggested design for implementing the guidance UI avoids the need for tunnelling points of interest, by keeping the points of interest API separate from the navigation route guidance API. If the two were combined (i.e. PoI data nearby to the route was provided as part of the navigation route guidance API), then we would potentially have problems with data ownership and freshness. Keeping the APIs separate means that each application which queries for points of interest gets up to date ones.
Finally the is the route list, where Apps can decide to embed data for the driver. I have explained above that stuff more in detail. Again a different thing to the 2 above. The validity of this data is only during runtime. The system service does not store the data persistently.
I don’t think there are any recommendations for any of the software we’ve discussed (the navigation UI, guidance UI, or other applications) to persistently store points of interest which have come from the PoI API. I would expect any application (or part of the system chrome) which uses PoI data to re-query it at appropriate intervals, and certainly every time the application starts up.
Philip