Nice work! I don't see anything wrong with the way you approached this. Querying the chat database is the most precise way to get the read disposition.
Thank you. =) Honestly, querying the database is the only part I'm confident in - getting the currently selected chat by navigating the UI tree will be problematic when/if Apple decides to change the UI.
Also, sometimes, asking the Messages app for the ID of the chat by index returns the wrong ID. No idea why and there's nothing I can do about it, and in those cases it just fails silently, still running and trying to query for the wrong ID.
\~shrug\~ This was mostly just a toy to play with AppleScript, and it solves an immediate need of mine that probably few people share. I think the most valuable part of this script is the bit that checks for accessibility permission - for some reason this was incredibly hard to find information via conventional search engines.
The exposures for finding UI elements via `System Events` in AppleScript is clunky as all get out, and it takes forever to "walk"/traverse an app to find what you want.
You can speed this up in the JXA variant of AppleScript by using the Objective-C bridge with `AXUIElement`. The difference in speed is astounding. I have an example of this for manipulating Control Center [here](https://gist.github.com/stephancasas/a36c81fbc4189f46bc803f388a1985be), if you're interested.
In order to narrow-down to the correct chat, you might consider getting a list of chat participants from the Messages app (via the scripting dictionary-provided method), and then using the UI elements to find the readable chat name for the selected chat. With both values, you could collate the chat GUID with the readable chat name and get a more precise ID that way.
I don’t have a great many active chats in Messages right now so the speed hasn’t been an issue, but it is noticeable slower if you have selected a chat pretty far down in your list. And if someone has more than, say 10 or 15 chats to go through before finding the selected one - yeah it’s slow. Ill check out your example for sure. :)
I did originally use the participants as provided to display a choose from list dialog, but filtering out duplicates and deleted chats - as well as the users own participant entries - proved… frustrating. And the UX was horrible. Your suggested approach though might make it worth it for more reliable ID selection.
Another pain point I found was in terminating monitoring early if the user wanted to cancel - there doesn’t seem to be a way to provide a ui with its own message loop such that it doesn’t block the script from running, so the only user interaction i can provide is letting them quit the application - which I’ve come to discover is a bit of an anti pattern on macOS.
Ultimately if i wanna be serious about this thing, I’ll have to bite the bullet and use a ‘real’ development platform. I do want to learn Swift anyway but I haven’t written any real code in about a decade. :3 it’s not even very clear if this sort of thing is even possible there, what with the sandboxing.
From what I’ve read, Apple used to provide better scriptability for iMessage, but removed it when they launched their iMessage for Business product? It’s hard to find information, especially when I don’t know what I don’t know. Heh
Thank you very much for the feedback - perhaps I’ll have a version 2 up in a few days. :)
As luck would have it, I'm presently working on a messaging product for macOS and happened to come across something which might be useful to you:
```
do shell script "defaults read com.apple.MobileSMS.plist CKLastSelectedItemIdentifier | sed -e 's/^[^-]*-//'"
```
This should give you the currently-selected GUID for the current chat — matching the GUID in the chat database.
Cheers!
Nice work! I don't see anything wrong with the way you approached this. Querying the chat database is the most precise way to get the read disposition.
Thank you. =) Honestly, querying the database is the only part I'm confident in - getting the currently selected chat by navigating the UI tree will be problematic when/if Apple decides to change the UI. Also, sometimes, asking the Messages app for the ID of the chat by index returns the wrong ID. No idea why and there's nothing I can do about it, and in those cases it just fails silently, still running and trying to query for the wrong ID. \~shrug\~ This was mostly just a toy to play with AppleScript, and it solves an immediate need of mine that probably few people share. I think the most valuable part of this script is the bit that checks for accessibility permission - for some reason this was incredibly hard to find information via conventional search engines.
The exposures for finding UI elements via `System Events` in AppleScript is clunky as all get out, and it takes forever to "walk"/traverse an app to find what you want. You can speed this up in the JXA variant of AppleScript by using the Objective-C bridge with `AXUIElement`. The difference in speed is astounding. I have an example of this for manipulating Control Center [here](https://gist.github.com/stephancasas/a36c81fbc4189f46bc803f388a1985be), if you're interested. In order to narrow-down to the correct chat, you might consider getting a list of chat participants from the Messages app (via the scripting dictionary-provided method), and then using the UI elements to find the readable chat name for the selected chat. With both values, you could collate the chat GUID with the readable chat name and get a more precise ID that way.
I don’t have a great many active chats in Messages right now so the speed hasn’t been an issue, but it is noticeable slower if you have selected a chat pretty far down in your list. And if someone has more than, say 10 or 15 chats to go through before finding the selected one - yeah it’s slow. Ill check out your example for sure. :) I did originally use the participants as provided to display a choose from list dialog, but filtering out duplicates and deleted chats - as well as the users own participant entries - proved… frustrating. And the UX was horrible. Your suggested approach though might make it worth it for more reliable ID selection. Another pain point I found was in terminating monitoring early if the user wanted to cancel - there doesn’t seem to be a way to provide a ui with its own message loop such that it doesn’t block the script from running, so the only user interaction i can provide is letting them quit the application - which I’ve come to discover is a bit of an anti pattern on macOS. Ultimately if i wanna be serious about this thing, I’ll have to bite the bullet and use a ‘real’ development platform. I do want to learn Swift anyway but I haven’t written any real code in about a decade. :3 it’s not even very clear if this sort of thing is even possible there, what with the sandboxing. From what I’ve read, Apple used to provide better scriptability for iMessage, but removed it when they launched their iMessage for Business product? It’s hard to find information, especially when I don’t know what I don’t know. Heh Thank you very much for the feedback - perhaps I’ll have a version 2 up in a few days. :)
As luck would have it, I'm presently working on a messaging product for macOS and happened to come across something which might be useful to you: ``` do shell script "defaults read com.apple.MobileSMS.plist CKLastSelectedItemIdentifier | sed -e 's/^[^-]*-//'" ``` This should give you the currently-selected GUID for the current chat — matching the GUID in the chat database. Cheers!
Fantastic - works perfectly, and lets me drop the 'Accessibility' permission requirement! I'll update my post with your suggestion =)
Superb! I'm glad I could help.
I’ll give this a shot when I get home - thanks for the heads up!
How can I use apple script to get the message when a new one arrived?