Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integration with tasker #18

Closed
GoogleCodeExporter opened this issue Mar 20, 2015 · 10 comments
Closed

Integration with tasker #18

GoogleCodeExporter opened this issue Mar 20, 2015 · 10 comments

Comments

@GoogleCodeExporter
Copy link
Collaborator

Integration with tasker is very easy - we just need to make our intents 
'public' and some instructions that should probably go onto the wiki.

Regarding making the intents "public" - in the attached patch, along with 
exposing .GTalkSMS.TOGGLE and .GTalkSMS.SEND, I renamed ACTION to CONNECT as 
this more accurately describes what it does. I figured that if we are going to 
start documenting these intents, we might as well make them as reasonable as 
possible :)

Once this patch is in place, the following instructions would be valid:

= GTalkSMS public actions =

There are 3 Android 'actions' which GTalkSMS handles.  Any application on the 
system can send these actions and have GTalkSMS perform a corresponding 
command.  For example, the 'Tasker' application can be used to send these 
actions in response to many different things happening on the phone.

== Public Actions ==

.GTalkSMS.CONNECT: Connects or disconnects the xmpp connection.  By default, 
the request is considered a connection request, but an extra called 
'disconnect' set to 'true' will cause it to be considered a disconnection 
request.  If xmpp is already in the requested state, no action is taken.

.GTalkSMS.TOGGLE: Toggles the current connection state (ie, disconnects if 
currently connected, and connects if disconnected.)  If GTalkSMS is in a 
'waiting' state (ie, with a yellow icon), it will become disconnected.

.GTalkSMS.SEND: Sends a message over xmpp - the message itself must be in an 
extra called 'message'.  No action is taken if xmpp is disconnected - if you 
want to force connection first, just send a .GTalkSMS.CONNECT action before the 
send action.

= Working with Tasker =

You can send commands to GTalkSMS by using a Tasker 'Action Intent' - when 
Tasker presents its list of Actions, select "Misc Action", then "Action 
Intent".  Note the following:

* When tasker prompts for the 'Action', enter one of the strings above - eg, 
'.GTalkSMS.SEND' - without the quotes but *with* the leading period/dot.

* The Category should remain at its default of "None", and the optional Data 
field should be left blank.

* One of the Extra fields should be used if the action requires an 'extra'.  
You enter a string in the format 'name:value' - eg, 'message:hello' could be 
used for a .GTalkSMS.SEND action.  The second Extra field can be left blank as 
no GTalkSMS action require multiple extras.

* The Target field must be changed to 'Service'.


Original issue reported on code.google.com by skippy.hammond@gmail.com on 31 Dec 2010 at 5:14

Attachments:

@GoogleCodeExporter
Copy link
Collaborator Author

Note to self: also register these intents at openintents.org 

Original comment by skippy.hammond@gmail.com on 2 Jan 2011 at 12:30

@GoogleCodeExporter
Copy link
Collaborator Author

Change checked in, wiki page added.

Original comment by skippy.hammond@gmail.com on 3 Jan 2011 at 12:19

  • Changed state: Fixed
  • Added labels: Type-Enhancement
  • Removed labels: Type-Defect

@GoogleCodeExporter
Copy link
Collaborator Author

oops - this hasn't been checked in yet.

florent: ISTM that these intent action strings really should be fully-qualified 
(ie, with leading com.googlecode.gtalksms), especially if we want to register 
them at openintents.org.  What I don't quite understand is why they are *not* 
currently - the leading "." in strings in the manifest should magically get 
that prefix appended.

Regardless, would you like me to re-submit this patch so that it uses 
fully-qualified intent names everywhere (and at the same time, change the 
string literals to a public static strings on the service (ie, 
MainService.ACTION_SHOW instead of the literal...)?

Original comment by skippy.hammond@gmail.com on 3 Jan 2011 at 1:26

  • Changed state: Started

@GoogleCodeExporter
Copy link
Collaborator Author

Sorry I didn't see your patch.
I changing package path each time I'm making a donate version. It's the only 
way to deploy 2 versions of the application. Eclipse project add automatically 
the full path.

Original comment by Florent....@gmail.com on 3 Jan 2011 at 1:30

@GoogleCodeExporter
Copy link
Collaborator Author

> Eclipse project add automatically the full path.

I don't quite understand this.  In my testing, I had Tasker use the action 
string ".GTalkSMS.SEND", and all of our code checks only for that string (and 
works).  But if eclipse is adding the package name to the intents in the 
manifest, I'd expect that to *not* work - that Tasker would have needed to use 
the fully-qualified name to find the service to send the intent to (and in that 
case, our code would have ignored it - it assumes no leading prefix).  Do you 
have any idea why that would be the case?  (Note that I only told tasker the 
intent name and that it was targeted at a service - I didn't tell it the 
package or service name to receive it)

Original comment by skippy.hammond@gmail.com on 3 Jan 2011 at 1:41

@GoogleCodeExporter
Copy link
Collaborator Author

Fixed in 1.6

Original comment by Florent....@gmail.com on 4 Jan 2011 at 10:22

  • Changed state: Fixed

@GoogleCodeExporter
Copy link
Collaborator Author

Holy shit this is awesome. I just realized I hadn't bought the donate version 
yet. Will gladly do so, unless you have a way for me to drop you a fiver 
separate from the market, or if you'll differentiate the donate version on 
features at some point.

Keep up the great work, both! My mind is already spinning at what I can do with 
some of this stuff... absolutely great!

Original comment by chriscar...@gmail.com on 6 Jan 2011 at 10:34

@GoogleCodeExporter
Copy link
Collaborator Author

Issue 63 has been merged into this issue.

Original comment by fschm...@gmail.com on 27 Jan 2011 at 6:42

@GoogleCodeExporter
Copy link
Collaborator Author

Issue 35 has been merged into this issue.

Original comment by fschm...@gmail.com on 27 Jan 2011 at 6:42

@GoogleCodeExporter
Copy link
Collaborator Author

Original comment by fschm...@gmail.com on 25 Aug 2011 at 7:51

  • Changed state: Deployed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant