Feature request: application based trigger

[Julian]

Hey Mark and users,

What do you think of the idea of incorporating a taskmanager into
JuiceDefender that allows for 3g and or WiFI to stay enabled as long
as certain apps are running.

This would be especially helpful with chat apps that obviously lose
connection once JD turns off the data connection.

Greetz Jules

[Surfinette]

+1
Fully agreed and this has been already requested for by me or others
in various forms, either black list or white list.... There is also
the case where you use only one app for a long period of time (ebook
reader or video reader) during which data and wifi connections are not
needed.

However, in the short term I believe Mark is still concentrating of
perfecting the current features of JD...

[loggy]

Hi,
I would also love this feature.
As for now I always have to disable JD while running for example g-mon.

[D.r.a.g.o.n]

I think this would be a great option, as I use chat programs for work.

[Stefano Z.]

+1

[Omar Yousif]

The latest version is hitting the performance of the phone significantly. Battery improvements are there but responsiveness while the screen is active is very noticeable.

[Smokem_I]

+1

On Jul 9, 2010 11:48 AM, "Stefano Z." <ditta...@gmail.com> wrote:

+1

On Fri, Jul 9, 2010 at 8:06 PM, D.r.a.g.o.n <d.r.a.g...@gmail.com> wrote:

> I think this would...

[Pawlye]

+1, although I know Mark said this would be next to impossible.

-E

[Nitin Philip]

I'm not sure how this would work with Android, considering how background apps/processes work. For instance, I can set JD to never disable APN when Skype is running, but Skype runs as a hidden/background process almost all the time unless brought into foreground. This means that JD would never turn off the APN if you have Skype added to the whitelist.

I used Skype here as an example, but I'm fairly sure a lot of other apps run the same way to speed up startup times. (Also why people are obsessed with pointless task killers)

[Austin Hsu]

Well, an app can be running and active, running and in background, and then just simply "cached." Android caches program it thinks you'll be using to improve start up times with no impact on memory. I don't see it being a problem if it's cached, but if it's active and in backgroud....

I honestly think we should worry about making the core program perfect, and some of these features should be extra program add ons. Only because we can't guarantee these apps will play nice with each other, especially for those of us running roms with root access. For now, the toggle widget is good. Trust me, I would love my phone to be nearly autonomous as well. :P

[Nitin Philip]

That's true, JD could, in theory filter out the 'cached' processes and only take active (visible, secondary service etc) processes into account. I have no idea if this will actually work or cause more problems, hopefully Mark can work his magic and figure out something. (I really need JD to stop turning my WiFi off when Pandora is playing)

I also agree that the priority right now should be getting JD to work reliably on the bazillion Android phones out now, and future CDMA based phones too..

[Mark Lowne]

You ask - Latedroid delivers, LATE! :D

I utterly disregarded the wise advice of focusing on fixing bugs
before attempting crazy stuff like this - but for a good reason!
(which is, I was - and still am - going insane with the whole UJ
situation and needed a break; and what's more relaxing than attempting
to write improbable-looking code in a completely unknown area?)

So, find your beloved and repeatedly +1ed 'Apps' trigger in v1.8.2! -
and, if it works, in later builds as well (fingers crossed!)

Technicalities: there's indeed no way of telling a 'useful' background
app from a 'useless' one - one which is there just because it was
"cached" by Android or because it went ahead and started its own
service which just sits there with the sole purpose of wasting RAM (as
99.99% of apps do).
Soooo, the trigger *only* takes into account *visible* apps - apps
that are either currently in the foreground (i.e. you're actively
interacting with them), *or* that registered a notification in the
status bar. Hopefully the latter category will take care of all the
cases where it makes sense to keep the connectivity enabled (e.g.
music streaming apps with their 'play' notification, or ongoing chats,
or the like) - while the former one will handle the 'blacklist' case
(games, offline reading, etc.) nicely.

As a quick aside, the CPU trigger might now work in unintended ways
(most notably underclocking the CPU while you play 'blacklisted' games
- i.e. at the worst possible time) - so it'll need some rewriting.

It might be a good idea to keep the discussion for the new trigger on
this thread, as newer builds will have to deal with other fixes and
improvements (most notably Location).

On Fri, Jul 9, 2010 at 11:42 PM, Nitin Philip <nitin...@gmail.com> wrote:
> That's true, JD could, in theory filter out the 'cached' processes and only
> take active (visible, secondary service etc) processes into account. I have
> no idea if this will actually work or cause more problems, hopefully Mark
> can work his magic and figure out something. (I really need JD to stop
> turning my WiFi off when Pandora is playing)
> I also agree that the priority right now should be getting JD to work
> reliably on the bazillion Android phones out now, and future CDMA based
> phones too..
>

[Ignacio]

Sounds great :)

Enviado desde mi "peazo móvil"

> That's true, JD cou...

[cdtan99]

I've just started using the apps trigger and I love it. One feature
request for this is if it's possible to have a delay before
connectivity is disabled. Better if the delay time can be specified by
the user. Maybe the delay can be cancelled should the user click on an
app that specifically requires disabling the connectivity. This is
useful in my case esp. when there's a delay in downloading apps from
the market and when waiting for a link in the homescreen when using
chrome-to-phone. Immediate disabling of connectivity sorta defeats
multitasking.

On Jul 17, 5:02 am, Mark Lowne <marklo...@gmail.com> wrote:
> You ask - Latedroid delivers, LATE! :D
>
> I utterly disregarded the wise advice of focusing on fixing bugs
> before attempting crazy stuff like this - but for a good reason!
> (which is, I was - and still am - going insane with the whole UJ
> situation and needed a break; and what's more relaxing than attempting
> to write improbable-looking code in a completely unknown area?)
>

> So, find your beloved and repeatedly +1ed 'Apps'triggerin v1.8.2! -

> and, if it works, in later builds as well (fingers crossed!)
>
> Technicalities: there's indeed no way of telling a 'useful' background
> app from a 'useless' one - one which is there just because it was
> "cached" by Android or because it went ahead and started its own
> service which just sits there with the sole purpose of wasting RAM (as
> 99.99% ofappsdo).
> Soooo, thetrigger*only* takes into account *visible*apps-apps
> that are either currently in the foreground (i.e. you're actively
> interacting with them), *or* that registered a notification in the
> status bar. Hopefully the latter category will take care of all the
> cases where it makes sense to keep the connectivity enabled (e.g.

> music streamingappswith their 'play' notification, or ongoing chats,

> or the like) - while the former one will handle the 'blacklist' case
> (games, offline reading, etc.) nicely.
>

> As a quick aside, the CPUtriggermight now work in unintended ways

> (most notably underclocking the CPU while you play 'blacklisted' games
> - i.e. at the worst possible time) - so it'll need some rewriting.
>
> It might be a good idea to keep the discussion for the newtriggeron
> this thread, as newer builds will have to deal with other fixes and
> improvements (most notably Location).
>
>
>
> On Fri, Jul 9, 2010 at 11:42 PM, Nitin Philip <nitinphi...@gmail.com> wrote:
> > That's true, JD could, in theory filter out the 'cached' processes and only
> > take active (visible, secondary service etc) processes into account. I have
> > no idea if this will actually work or cause more problems, hopefully Mark
> > can work his magic and figure out something. (I really need JD to stop
> > turning my WiFi off when Pandora is playing)
> > I also agree that the priority right now should be getting JD to work
> > reliably on the bazillion Android phones out now, and future CDMA based
> > phones too..
>

> > On Fri, Jul 9, 2010 at 3:38 PM, Austin Hsu <austin.hsu...@gmail.com> wrote:
>
> >> Well, an app can be running and active, running and in background, and
> >> then just simply "cached." Android caches program it thinks you'll be using
> >> to improve start up times with no impact on memory. I don't see it being a
> >> problem if it's cached, but if it's active and in backgroud....
>
> >> I honestly think we should worry about making the core program perfect,
> >> and some of these features should be extra program add ons. Only because we

> >> can't guarantee theseappswill play nice with each other, especially for

> >> those of us running roms with root access. For now, the toggle widget is
> >> good. Trust me, I would love my phone to be nearly autonomous as well. :P
>

[Charles Tan]

Also when you have to switch from one "enabled" app to another and you have to pass through the homescreen to click on the app, the app trigger is too quick on the draw and makes you wait for it to enable again when you click on the new app.

[Charles Tan]

I'd think I just found a bug on the app trigger. When I enabled connectivity for Swiftkey beta, the connectivity became permanently enabled. Even if the screen is off, even after a fresh restart, even if I'm using an app that specifically calls for disabling connectivity.

[Austin Hsu]

Unlike the iPhone, you do not have to go back to the home screen to open another app if you've opened it recently. Press and hold the "Home" button and it shows you all recently opened apps. Remember, we have true multi-tasking. I don't remember how many apps stock Android holds, probably 6. My ROM allows me to pick a few different numbers, I think I'm currently displaying my 12 most recently used apps.