Status Update
Comments
ch...@mixmax.com <ch...@mixmax.com> #3
hey , Do I really have to do that ? . It is not hurting my application at all . I was just taking some clarity on to why it is occurring which you provided.
Just dont want to run into any problems in the future since we just freshly started working with Room KMP .
Please do let me know if I should attempt a solution like you have provided or if its fine the way it is .
tr...@gmail.com <tr...@gmail.com> #4
If you don't perceive the disk read as an issue during startup / database initialization then you don't have to do the workaround. I provided it in the mean time if it was hurting your app while we try to make a fix.
ry...@google.com <ry...@google.com>
ki...@iriscrm.com <ki...@iriscrm.com> #5
Great ! .acknowledged. Ty
ek...@google.com <ek...@google.com> #6
Project: platform/frameworks/support
Branch: androidx-main
Author: Daniel Santiago Rivera <
Link:
Lazily load SQLite's native library when a connection is opened.
Expand for full commit details
Lazily load SQLite's native library when a connection is opened.
Moving the load call into an inner object effectively makes it so that the library is loaded lazily when the object's class is loaded, i.e. when instantiated and accessed during the open call.
Bug: 363985585
Test: BundledSQLiteDriverTest.kt
Change-Id: I72fa01618169cb3225ea9d5d5e9f9ae59c6d4b09
Files:
- M
sqlite/integration-tests/driver-conformance-test/src/androidInstrumentedTest/kotlin/androidx/sqlite/driver/test/BundledSQLiteDriverTest.kt
- M
sqlite/sqlite-bundled/src/jvmAndroidMain/kotlin/androidx/sqlite/driver/bundled/BundledSQLiteDriver.jvmAndroid.kt
Hash: 4f69d19088dae47b6a7bcf454ea22f7e2da78e92
Date: Tue Jan 21 17:51:32 2025
ki...@iriscrm.com <ki...@iriscrm.com> #7
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.sqlite:sqlite-bundled:2.5.0-alpha13
androidx.sqlite:sqlite-bundled-android:2.5.0-alpha13
androidx.sqlite:sqlite-bundled-iosarm64:2.5.0-alpha13
androidx.sqlite:sqlite-bundled-iossimulatorarm64:2.5.0-alpha13
androidx.sqlite:sqlite-bundled-iosx64:2.5.0-alpha13
androidx.sqlite:sqlite-bundled-jvm:2.5.0-alpha13
androidx.sqlite:sqlite-bundled-linuxarm64:2.5.0-alpha13
androidx.sqlite:sqlite-bundled-linuxx64:2.5.0-alpha13
androidx.sqlite:sqlite-bundled-macosarm64:2.5.0-alpha13
androidx.sqlite:sqlite-bundled-macosx64:2.5.0-alpha13
ki...@iriscrm.com <ki...@iriscrm.com> #8
ki...@iriscrm.com <ki...@iriscrm.com> #9
Thanks
di...@gmail.com <di...@gmail.com> #10
Thank you in advance for your help!
We are having an issue with emails being rendered differently for recipients using Outlook as their email client. Our business provides a CRM to businesses and most of our clients, approximately 60%, use Outlook as their email service for sending B2B emails. The inability to render the emails properly for all clients because HTML is being stripped during the sending operation by the Gmail API is really hurting our business.
We applied for verification and are going through the process but we wouldn't need a restricted scope if we didn't need to use XOAUTH to send emails via SMTP instead of the Gmail API.
If I am missing something, please let me know. Please fix this as soon as possible, it is very important!
br...@mixmax.com <br...@mixmax.com> #11
di...@gmail.com <di...@gmail.com> #12
ko...@gmail.com <ko...@gmail.com> #13
Thanks,
br...@mixmax.com <br...@mixmax.com> #14
I tested sending a complex email with a custom DOCTYPE and HTML comments via the Gmail API. The email came through without any modifications by the Gmail API.
fe...@gmail.com <fe...@gmail.com> #15
br...@mixmax.com <br...@mixmax.com> #16
sp...@gmail.com <sp...@gmail.com> #17
I also notice the html tag I send <html lang="en" xmlns="
I also tried composing the email with Swiftmailer first, but the end result is the same after passing the message off to Google.
If a GSuite user is going to be forced to stop using SMTP/less secure apps soon, is it wrong to consider this API 'cleansing' of the HTML ridiculous? Is this not valid HTML in Google's eyes? It seems to be at Litmus, etc. and has been for years.
6 years since this thread started - worries me. Assuming the rumor is true, what happens once I'm forced to use the API instead of SMTP? Boring or broken email templates I guess? I want to use the API for the 25+ accounts that need to send mail. I've put 3 days into getting it working. I don't want to have to store passwords in a database which constantly need updating. I don't want to be less secure.
br...@mixmax.com <br...@mixmax.com> #18
ki...@iriscrm.com <ki...@iriscrm.com> #19
sp...@gmail.com <sp...@gmail.com> #20
I read there were 400M Outlook users in 2018. I don't know if these hacks are necessary with Office 365, but surely a few million of these users still use Outlook 2016 or older. What about the Outlook app on a phone? Sure, MS needs to get their act together when it comes to standards, but I guess Google just doesn't care since they don't bother to even discuss the issue any longer. Might be time to dump Google and go back to using email accounts on our own server.
It's been a pain as it is getting this far, only to hit a dead end.
la...@gmail.com <la...@gmail.com> #21
var bodyRaw = $"From:{from}\r\n";
bodyRaw += $"To:{to}\r\n";
bodyRaw += (!string.IsNullOrEmpty(cc))?$"Cc: {cc}\r\n":string.Empty;
bodyRaw += (!string.IsNullOrEmpty(bcc))?$"Bcc: {bcc}\r\n":string.Empty;
bodyRaw += $"Subject:{subject}\r\n";
bodyRaw += $"Date:{DateTime.Now.ToString()}\r\n";
bodyRaw += $"Content-Type:text/html; charset=UTF-8\r\n";
bodyRaw += $"Message - ID: {Guid.NewGuid()}\r\n\r\n";
bodyRaw += $"{body}";
var body64 = Base64UrlEncoder.Encode(bodyRaw);
Description
Retyped below:
Repro
Go to
Scroll down to "Try it!"
Log in with OAuth
For "userId" enter: me
For "raw" enter the result of the following node script:
generateMessage.js
var email = "From: 'me'\r\n" +
"To: bradvogel@outlook.com\r\n" +
"Subject: Test Doctype\r\n" +
"Content-Type: text/html; charset=utf-8\r\n" +
"\r\n" +
"<!doctype html>" +
"<html><body>test <!--[if !mso]>hidden from outlook<!--<![endif]--> </body></html>";
var base64 = new Buffer(email).toString('base64');
var websafeBase64 = base64.replace(/\//g, '_').replace(/\+/g, '-');
console.log(websafeBase64);
Actual result
When I view the raw message source from the email received at bradvogel@outlook.com, it comes through without the doctype or comments:
To: bradvogel@outlook.com
Subject: Test Doctype
Content-Type: multipart/alternative; boundary=089e0102fc52abed0a04ff355038
--089e0102fc52abed0a04ff355038
Content-Type: text/plain; charset=UTF-8
test
--089e0102fc52abed0a04ff355038
Content-Type: text/html; charset=UTF-8
<html><body>test </body></html>
--089e0102fc52abed0a04ff355038--
Expected result
Notice the doctype below:
To: bradvogel@outlook.com
Subject: Test Doctype
Content-Type: multipart/alternative; boundary=089e0102fc52abed0a04ff355038
--089e0102fc52abed0a04ff355038
Content-Type: text/plain; charset=UTF-8
test
--089e0102fc52abed0a04ff355038
Content-Type: text/html; charset=UTF-8
<!doctype html>
<html><body>test <!--[if !mso]>hidden from outlook<!--<![endif]--> </body></html>
--089e0102fc52abed0a04ff355038--
Notes
Sending the same message via SMTP preserves the entire message.
The doctype and comments are needed to format emails for Outlook and iOS Mail. The API appears to be taking my raw rfc822 message and converting it multipart/alternative with text and html representations, but with important content stripped out.
Does anyone know how to preserve doctype and comments in a message send through the Gmail Message Send api?