[Withdrawn] SDL 0319 - Add a notification and restore function for unexpected exception/error
Closed this issue · 14 comments
Hello SDL community,
The review of "SDL 0319 - Add a notification and restore function for unexpected exception/error" begins now and runs through September 8, 2020. The proposal is available here:
Reviews are an important part of the SDL evolution process. All reviews should be sent to the associated Github issue at:
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of SDL. When writing your review, here are some questions you might want to answer in your review:
- Is the problem being addressed significant enough to warrant a change to SDL?
- Does this proposal fit well with the feel and direction of SDL?
- If you have used competitors with a similar feature, how do you feel that this proposal compares to those?
- How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Please state explicitly whether you believe that the proposal should be accepted into SDL.
More information about the SDL evolution process is available at
https://github.com/smartdevicelink/sdl_evolution/blob/master/process.md
Thank you,
Theresa Lech
Program Manager - Livio
theresa@livio.io
1. The motivation states:
"As a result, the function is insufficient, such as not being able to return to the state before the error occurred after restarting the app."
This is also untrue. The register app interface already has the ability to restore much of the UI state through the resume hash mechanism.
Additional notes based on the proposed solution:
2. In 1.a. You note that the iOS library should send an RPC when the app is killed. This isn't possible because apps receive no background time when they are killed.
3. In 1.b. You note the app library needs to do several things in the case of an app crash. But this is not possible, because the app crashed.
4. The entire section (2) doesn't have nearly enough information.
a. The app library needs to send an Alert to core on startup, but the language and localizations are not defined.
b. There seem to need to be buttons on the Alert but those are not defined.
c. Nothing is stated about what to do if the app cannot send an Alert.
d. Nothing is stated about when in the startup process with the managers this alert should be sent.
e. There is no definition of the technical details behind what will be stored, how it will be stored, or how it will be restored.
f. You only talk about "restored templates" but there is a lot of other restoration information that is far more important, such as choice set, menu, and other VR information. You provide no details on if this will be restored. Additionally, you don't talk about the existing restore mechanisms at all.
g. You don't talk at all about how the app will receive information about the restore.
In short there is no discussion of the existing restore mechanism, and there is no discussion about how an app is supposed to send crash or kill information when it has crashed or been killed and is therefore no longer able to send any information. I think that this issue is prohibitive for implementation, and the fact that there is no discussion of the existing restore mechanism at minimum means that the proposal needs to be heavily reworked at a minimum.
@joeljfischer -san,
1.
Certainly, in the chapter of OnAppRegistered on the HMI documentation, we confirmed the sequence of "App Register with Resume" is written. Therefore, we think the system can resume.
However, this sequence is written only case that an app terminated normally case. We did not find the documentation of abnormal case. Could you please teach me where to refer?
7.
We did not know what you said.
Have the specification of the behavior of menu been changed?
What documentation should we refer?
Could you please teach us where to refer?
1. I see nothing in any documentation that states that resuming wouldn't work if the app didn't resume normally. Core sends a new resume hash whenever the app updates data, and the app can send the resume hash on a new connection, therefore I see no discussion of how an app terminates changing how resuming works.
7. There is no number 7 in my comments, so I don't know what you're referring to.
@joeljfischer -san,
We talk about it internally. By the way, What is the "Background time" meaning? Is the app in a background state?
3.
Since it is addressed after re-launch, we think there is no problem.
the "AppExitAbnormal()" is shown the re-launch for terminating for abnormal.
4a.
Since to terminate only app but the connection between mobile and HU is kept, we think the data such as language and localizations are maintained.
4b.
We recognize the alert template has the button.
Is it correct?
4d.
The figure 2 shows the SDL Core confirms whether the template information is saved, and if the data is exist, the SDL Core sends the Alert RPC to HMI.
4e.
Since to terminate only app but the connection between mobile and HU is kept, we think the basic data except template information are maintained.
4g.
As wirrten the figure2, the information for restoration is provided to app via restFinishNotify witten the end of sequence.
7.
I'm sorry.
No.7 is my mistake. Do not need to any response.
@joeljfischer -san,
4c.
Since the app occurs the re-launch, we do not assume not to be able to send the Alert.
Is there any case not to be able to send the Alert during the normal?
If yes, what is the system do?
Basically, we think the behavior is same as it.
4f.
The app library sends the RPC UnregisterAppInterface to the SDL Core, and the SDL Core sends the RPC OnAppUnregistered to the HMI.
However, the system is not relaunch, and also the mobile does not chaged.
In this case, we think the registration data such as VR information is remained.
2. By background time I mean that time that iOS allows an app to continue to execute code when the app is no longer on screen. When the app is killed, it is allowed to execute one synchronous method, but isn't allowed to execute any additional operations such as would be necessary to send an RPC.
3. Hello, I googled the term AppExitAbnormal() and found nothing. Could you please add detailed steps and code for exactly how this feature is proposed to work?
4.a. I'm sorry, but this doesn't make sense and I think you missed the point. When an app is terminated, there is no connection between Core and the app / app library / device anymore. Additionally, since according to this proposal the app library needs to send an alert, this proposal needs to include the text in all supported languages.
4.b. There is no "alert template". If you mean the default alert, that can be different between OEMs. Additionally, there seems to be multiple buttons and actions need to be taken when the user selects those potential buttons. Therefore, you need to define those buttons, their text (in all supported languages), and what the buttons should do when selected.
4.c. If the app is in the BACKGROUND, if another app has presented an Alert or other on-screen RPC, etc. There are many situations in which this may not be possible.
4.d. Your comment doesn't address the question. The app library sends the Alert to Core, which forwards it to the HMI. The diagram doesn't address when in the manager startup process this Alert should be sent.
4.e. I'm sorry, but that is not specific enough. Please enumerate exactly what data will be stored, and technical details about how it will be stored, and technical details how it will be restored.
4.f. I'm sorry, but this doesn't answer any of my questions here.
4.g. I see that now. You need to provide how that API works, where it is located, etc.
The Steering Committee voted to keep this proposal in review, to allow time for discussion to continue on the review issue.
@joeljfischer -san,
Thank you for your comment.
We understood about the "Background time".
When we confirmed internally, this process is addressed before termination of the app.
Therefore, it is necessary to add the notification process.
I'm very sorry.
The meaning of AppExitAbnormal did not have the re-launch.
It means the trigger to occur the abnormal.
4a.
In the Figure 2, since it starts from AppRestart, we assume that the app will send the Alert after the app is connected with the SDL Core by RegisterAppInterface. Therefore, we recognize that the SDL Core has the app information excepted the last template infomation.
If is it necessary, we will modify to add the sequence of RegisterAppInterface.
4b.
Since we thought the SDL system has the template of Alert, we recognized to need the consideration about it. By the way, regarding to the template, the SDL system did not have an Alert templete from beginning? Or the SDL system deleted it from the middle?
4c.
Thank you for your comment.
We assumed that the premise is to become the app to FULL status.
We may need to consider the app's behavior if the app is Background.
4d.
The sequence does not shown the behavior of manager.
We will confirm internally, and if possible, we can add the information.
4e & 4f.
In the Figure 2, since it starts from AppRestart, we assume that the app will send the Alert after the app is connected with the SDL Core by RegisterAppInterface. Therefore, we recognize that the SDL Core has the app information excepted the last template information.
1. I'm still waiting for this to be addressed. This proposal seems to be entirely unnecessary to me. I would recommend that you use the existing restore mechanisms and withdraw this proposal.
2. I'm sorry, but I believe that you don't understand. The iOS app is entirely incapable of sending the data that you are stating it can send. Therefore, you must either change your solution or remove this process from this proposal. But since this is the entire proposal, I believe you either need to rewrite your proposal entirely to explain how this is to happen or withdraw it.
3. Okay, then I don't see how your previous comment is relevant to answer this objection.
4a. Okay, but that contradicts what you said in the last comment. That still leaves the original objection that you need to provide all localizations for this content in the proposal.
4b. As far as I'm aware, there has never been such a thing as an "Alert template." There is an alert modal through the Alert RPC, but that is different from an "Alert Template," whatever that might mean. The original point stands and you need to define these buttons and all localizations.
4e. How. You cannot simply assert that it does. In what form? How is it saved? In what format? What is the flowchart? How is it restored? How is the data communicated? This is clearly different than the existing restore mechanisms, so you have to give a full technical breakdown of all of this information.
4e/f. I think you're confusing language. In the proposal you state this will restore "template" information, but now you say it's other information. In the proposal you state that the app will take care of restoring information, but above you say that Core / HMI will restore this information. I think this proposal is becoming far too confused to follow. I would recommend that you withdraw this proposal, take this feedback, and if necessary (though I think the current SDL systems adequately handle your problem), submit an entirely new proposal that addresses these fatal flaws to this proposal.
@joeljfischer -san,
What does the existing restore mechanisms show?
If there is such as a document that has been decided as an SDL, please let us know the reference.
After confirmation of the documentation, we will make a decision whether this proposal is valuable or not. Therefore, please give us the documentation.
4a.
Is the last comment "If is it necessary, we will modify to add the sequence of RegisterAppInterface."?
Since the RegisterAppInterface is the process required the app registeration and it is well-known fact, so we just think it was not necessary to describe it.
We will modify to add the RegisterAppInterface.
If our understanding is wrong, could you please teach us the contradiction?
4b.
I'm very sorry.
The Alert is not template, it is RPC.
However, the Alert RPC has the parameter of softbutton.
So, we think that the Alert RPC can display the buttons.
The Steering Committee voted to keep this proposal in review, to allow time for discussion to continue on the review issue. It was noted that the author needs to provide a response for items 2, 3, 4e and 4f.
1. Here is the overview documentation, and here is a previous proposal that is not yet implemented to integrate resumption with the screen manager system. Given that this feature already exists, it is our suggestion to reject this proposal.
@joeljfischer -san,
2, 3, 4e and 4f.
We are very sorry for delay our response.
We continue to consider this matter internally.
We will reply to you as soon as the consideration is completed.
This proposal has been withdrawn per the author's request.