The MMS lost story
-
@lduboeuf said in The MMS lost story:
if possible, i would suggest having the same prefix for all error status, x-ubports-nuntium-mms-error-...
ok, will fix & notice you (hopefully today).
not present is ok for me, don't see what is your question.
if there is no expire information from operator, can we expect the message never expires, or expires after some default time (eg. 7days)?
[Edit]: Did some tries with debian control, so even by setting the PATH to /usr/lib/go-1.13/bin in rules (export PATH := /usr/lib/go-1.13/bin:$(PATH) ), i had no success, it didn't find go files ( but no more "no such files or directory" ), though. But i'm really a noob in that debian packaging thing.
I'm also virgin in the debian packaging thing. For me it is read internet + trial/error cycles for now. Will experiment. But our approach (with the path) could be a good one. If the
go installcommand runs, but didn't find go files, the setting GOROOT and/or GOPATH may help. Will try (also can you
). If we can't solve it today, tomorrow I will comment out the incriminating code (it's just some testing thing), to be able to compile at least.
Edit: The moment I posted this, you edited your comment wit solution to the packaging problem. Thank you. (I've read the same bug on launchpad, but you were quicker by implementing
) -
if there is no expire information from operator, can we expect the message never expires, or expires after some default time (eg. 7days)?
Yes, lets say 7 days
I'm also virgin in the debian packaging thing. For me it is read internet + trial/error cycles for now. Will experiment. But our approach (with the path) could be a good one. If the
go installcommand runs, but didn't find go files, the setting GOROOT and/or GOPATH may help. Will try (also can you ). If we can't solve it today, tomorrow I will comment out the incriminating code (it's just some testing thing), to be able to compile at least.Yes, see above, i've edited my comment and finally got it built...
-
@lduboeuf I've pushed commits to set default expiry time (7days), unify download error code and changes you suggested to be able to build a dep package (thank you again). I've updated the previous post to reflect current state.
-
@jezek said in The MMS lost story:
@lduboeuf I've pushed commits to set default expiry time (7days),
sorry, need confirmation, but i see 15 days seems the default duration
unify download error code
also maybe @UniSuperBox @Flohack or someone from core teams can have a look on them
and changes you suggested to be able to build a dep package (thank you again).
glad it helped , thanks also for keeping that alive
-
@jezek Is there anything still to be done in backend side ?
-
@lduboeuf said in The MMS lost story:
@jezek Is there anything still to be done in backend side ?
Yes, I have a bunch TODOs in nuntium (and other apps along the way to messaging-app), but the error message part will stay the same. Yesterday I trimmed some TODOs (loccaly, not pushed yet) and looked at what has to be done and how it affects the current error message format (and error codes) and I've come to conclusion, that it will be not affected (unless you want to change something).
Why do you ask?
-
@jezek ok,nice. Was just asking if i need to do the UI part now
BTW we don't need to have all errors message handling at first.
And if you see there is too much work remaining, we can cut some parts to be able to deliver a solution quicker.This is so awesome that we can redownload afterward without asking the user
-
@lduboeuf said in The MMS lost story:
@jezek ok,nice. Was just asking if i need to do the UI part now
Yes, you can start (if you want).
BTW we don't need to have all errors message handling at first.
That, I leave for you, sir.
And if you see there is too much work remaining, we can cut some parts to be able to deliver a solution quicker.
I have a plan to move some TODOs to github issue tracker to speed up release, but some need to be done (in my opinion).
This is so awesome that we can redownload afterward without asking the user
Yes, that is awesome. And in my opinion it should be switchable (on/off). Eg.: I have a prepaid card and I wouldn't like it if it would automatically download some MMS and use some credit.
-
Failed MMS redownload progress report:
This week nuntium PR only got these updates:
- Some forgoten and obsolete TODO comments got deleted
- MNotificationInd.Expiry type and decoding got some rewrites and more tests
- Expired incoming undownloaded messages handling (deleting from storage & notifying telepathy-ofono of deletion) upon nuntium start (resp. modem initialization)
I will continue to solve my own TODOs in the stack, see you next week.
-
@jezek So on my side, did some tweaks for the UI part.
Now message when cellular-data is off is displayed like that:
For other cases, no changes
I wonder if we can simplify on telephony service for the notification part the message to "New MMS message received" instead of the "Oops...." and let user discover any errors within the messaging app. It will be easier to manage has we will not have to parse the msg, and check for different cases there.
One thing more, but will need to add some logic, in history service, can we take the received date (timestamp) from the previous message before deletion so that the MMS will not appear at the bottom of the list but as a replacement of the error message ?
-
Hello.
Just a little sidebar: can you tell me if MMS currently works for Android 9 devices in RC 8 or dev ?
Specifically for me, MMS don't work in RC 8 for Volla (cellular data ok, internet ok, sms ok, APN mms configured). -
@domubpkm idk, isn't that related ?: https://github.com/ubports/ubuntu-touch/issues/1657
Please move that question to support or issues on ubuntu touch or Volla directly ?
-
@lduboeuf ok. Maybe.
I signaled and asked.
Thank you -
@lduboeuf said in The MMS lost story:
So on my side, did some tweaks for the UI part...
Thanks, will test.
I wonder if we can simplify on telephony service for the notification part the message to "New MMS message received" instead of the "Oops...." and let user discover any errors within the messaging app. It will be easier to manage has we will not have to parse the msg, and check for different cases there.
That's a nice idea, I'm not against. I will change the text.
One thing more, but will need to add some logic, in history service, can we take the received date (timestamp) from the previous message before deletion so that the MMS will not appear at the bottom of the list but as a replacement of the error message ?
Nice idea too, will implement.
