I'd like an easy interface to events around the phone being at rest (no accelerometer input).
For the rest state: I assume that most people have their phone by their beds at night. I have a locale rule that puts my phone into airplane mode during the hours I'm normally asleep. This is much more easily/accurately expressed as "phone at rest for 15m". Similarly, I'd like to sync news when I pick up the phone to leave in the morning (I don't always unlock the phone when I do) so it can sync over wifi.
I'd also like to monitor signal strength. I do so in Locale and shut down the 3g data connection if the signal strength is under 25%. This combined with the airplane mode at night and an undervolted kernel gets my (old, otherwise stock) Droid Incredible up to 3 days of battery life through normal use.
From my quick run with the app, what I find lacking isn't in the events, but in actions: currently, it mostly notifies you (or others) about events.
It'd be more useful if it could also interact with the phone settings (for example, silence the phone at certain locations, &c).
Currently, this could be worked around by having an event launch SL4A that would run another script doing it; but this forces you to maintain a separate script for the desired action, instead of doing it at the same place.
On a BlackBerry, when it is put in the charger, it goes into Bedside Mode, and the clock application is shown. The user can set up the profile to be used during this state (i.e. what notifications to allow, etc.). It can also be programmed to only enter bedside mode during certain hours.
I know it's not exactly what you're asking for, but it's something they've done for several years, and done quite well. I'm hoping they extend it, and keep it in BlackBerry 10.
For me the nicest variant of this idea was the TouchStone thign from Palm/HP/Web OS.
Inductive charger that triggered a configurable mode on your phone -> Drop the phone on a magnet, get a clock or whatever and the phone charges without searching the plug beneath the bed.
Just to clarify, BlackBerry does this sans a dock. It simply activates whenever being charged, whatever the source. However, it can and does distinguish between USB and dock. Just unsure if it actually uses it in the software, because I always use a dock nowadays.
IIRC keeping the accelerometer hot is a big battery suck. For this reason Tasker wouldn't let you use accelerometer input as a first-order input. You had to prefix it with some other, less expensive condition, like time of day ranges, wi-fi SSID visibility, etc.
And truly surprising that when you add faster components, bigger screens and many, many more functions, phones require additional battery power. At this point, my phone can make it from my wake up at 7am easily until 3am if I'm out late, and that's enough that I don't have to worry about it (though obviously I won't say no to battery improvements).
They likely did this on Android because it's the easiest platform to developer such a product. On iOS and WP, background apps are severely limited so it makes sense why Android is only platform that gets this.
There is no reason to say "likely," the article comes out and says that android was the easy platform:
"Shira Weinberg, the team’s Program Manager, explained that the less strict security model of the Android platform is well suited for deploying early stage technology previews."
I am not a mobile developer so when I read the statement I was not sure if it was an underhanded slap at andriod or a valid assessment of mobile platforms. Can anyone comment?
I think the security thing is BS. It's the ability to run arbitrary background services on Android versus strictly limited background tasks on other platforms that matters here.
_less strict_ does not mean insecure. iOS for example has very strict rules about when apps can run, how long they can run, and the resources they use. Everything is a tradeoff and in general Android leans in the direction of power and freedom.
Rules restricting the range of passwords that may be used in an arbitrary fashion can markedly decrease the search space for an attacker.
A strict rule count by itself is neither good nor bad. Well, arguably, it's bad, as it increases system complexity, side effects, loopholes, and trains users to thwart restrictions. Ideally you want a small number of sane rules (mostly based on role and access), tightly implemented, with strong auditability.
Going back to passwords: the simple check of denying the use of any known password (there are collections of millions now from various site compromises) would be an audit check, not strictly a rule, though it might result in a rule of "known passwords will be denied".
It's less a matter of security and more a matter of consistency. MS's/Apple's rules are geared towards ensuring apps don't affect battery consumption too wildly while in the background. Android has no such restriction, and any app you have installed can decrease your battery life significantly even if you do not open it.
The advantage of this, of course, is platform flexibility. The disadvantage is inconsistent app behavior (battery is drained by background apps).
Semantics. The strictness of a security model says little about the security of a security model, especially when comparing different security models. (And not all security is wrapped up in a security model either! I wouldn't trust an Android or iPhone conversation to remain private, fortunately there's PGP.)
That's assuming the security models being compared are strict about the things that matter.
For instance, I can be very strict about PDFs on your computer: no PDF allowed. If you have addressed the risks posed by other more vulnerable attack vectors, OK, then my rule reduces the uncertainty of less strict but more complicated rules that would address the vulnerabilities of PDF readers. Otherwise, for example if I'm allowing the auto-execution of apps on removable devices, my strict PDF rules don't increase security.
And might even decrease security in practice if people end up working around your strict rules via an even less secure path (e.g. sending around Word documents instead of PDF, perhaps).
I thought that stuff was well covered already, with the leader being Locale (iirc).
Did anyone try a couple of these and can provide a comparison? The article is light on details, the biggest difference that I noticed is the configuration via a website. Well, and the Facebook login downer.
The main difference is that you can write a JavaScript snippet that is pushed to your phone and executes.
The JavaScript can register on device triggers and you can control the logic to do whatever you like. You can code it to be very specific in contrast to other rule based platform which have to be broad to cover main scenarios.
You still have pre-coded recipes which you can choose and quickly configure and install, and one of the coolest things is that you can actual see the recipe's code and hack it to your own profit :)
Locale is no longer free though correct? I downloaded it in beta and tried some things but it was a little overwhelming, not sure if it has "simple" mastered.
This is really cool. Just set up a message to my wife when I leave work. "I'm heading home from work. Based on traffic data, it should take me XX minutes to travel XX miles". Took about 10 minutes to write thanks to some good examples in the documentation.
Looking forward to watching this evolve. Should be extremely powerful with the right set of triggers and hardware integration.
The biggest problem with Tasker/Locale is that they're missing all the verbs you want and have really tragic consequences for performance and battery life.
onX claims to offer verbs like 'when i'm in the car' or 'when i'm walking'; Tasker/Locale offer verbs like 'is there a wifi network named X nearby' or 'is bluetooth on'. I spent money on Locale to try and solve these kinds of problems on my Android phone and regretted it.
Are you familiar with the Android Account Manager? [1] You can let users log in to your app with pretty much one click of an existing account. Since virtually every android user already have a google account signed in on their phones. It seems that using a google account would be the most obvious route for ideal user experience (no need to type in a new account you haven't before).
That's funny, I'm the opposite. I'm generally unlikely to sign up for any site or service that makes me create and record yet another username/password combo.
It seems there's a discussion on your forum now. [1]
Unfortunately, to chime in on the discussion one needs to log in with Facebook, which might keep a good chunk of those 'Please support something else' voices out. I know you wrote (both here and in that entry) that you plan to support other authentication methods. The reason why I post this is just to point out the flaw of asking the subset that willingly gives out their FB details in the first place.
I use llama for Android, which is a free app where you can do these things. The drawback it has is that there you do not get to program your scenarios using javascript, you instead need to create them through a GUI on phone.
Can the browser/login be completely removed from the picture, so that you get to manage your own scenarios either online or at home computer and push some compiled file to the phone yourself?
This article is bizarre. Why is written in such a strange way? "your favorite Redmond techno-giant is sitting on a horse" What the fuck does that mean?
In some cases this might backfire horribly. Imagine some guy sets his phone up to send an SMS to his spouse when he is held up at work. Imagine he also lets the phone send his location, because he travels a lot at work. Result: "X will be late today, he is currently at [coordinates of his secretary's house]". Don't get me wrong, this feature is awesome but when combined with naivity the device can do things that are equally naive.
I'll be 100% behind this project when it has as much control over a device as Tasker does. Recipes in JavaScript and not having to "program" on the device itself are exactly the kinds of things I wish Tasker could do. The modeOfTransport monitor is pretty attractive too.
Beyond all that, I'm curious about on{X}'s battery usage. That's a huge selling point for always-on processes like this.
This looks really interesting. And yes, there's other options on Android to do it, but Microsoft looks like they've taken a different focus on it.
I do wonder at the 'less strict security model' part though. I'd think more 'less strict process model' would be a bit more accurate as it's a processing issue, not so much security issue.
I've yet to sign up to the service (until an alternative means of authentication is available), so I'm not sure if it's an obvious question but I'm curious about the metadata required to render a script as a recipe. Is this inferred from the script itself or is it manually input at some stage in the script's creation? I'm referring to this type of thing, where the bracketed words are treated as parameters:
"Launch the [music] app when I am [walking]"
Also, are these parameters bound to the script at runtime or is a new script generated for each variant?
This looks very promising. Like others have noted, even on the Play Store they are getting battered with negative reviews because of Facebook only authentication.
Your sarcasm is warranted, in my opinion. I trust this on my phone about as much as I .. well .. trust .. my Android-controlled .. Googleplex'ing .. info-companion reporting agent ..
Point is: yeah, your phone is spying on you. Of course "Microsoft Israel" wants you to automatically data-enter your daily activities into their massive connected network.
For the rest state: I assume that most people have their phone by their beds at night. I have a locale rule that puts my phone into airplane mode during the hours I'm normally asleep. This is much more easily/accurately expressed as "phone at rest for 15m". Similarly, I'd like to sync news when I pick up the phone to leave in the morning (I don't always unlock the phone when I do) so it can sync over wifi.
I'd also like to monitor signal strength. I do so in Locale and shut down the 3g data connection if the signal strength is under 25%. This combined with the airplane mode at night and an undervolted kernel gets my (old, otherwise stock) Droid Incredible up to 3 days of battery life through normal use.