Wi-Fi switch suggestion and exit request.
18 views
Skip to first unread message
cebweb
Apr 30, 2009, 11:08:14 PM4/30/09
to SteelAndroid
I was wondering how hard it would be to implement an option for steel
to enable WI-FI when launched and then turn it off again when using
the exit command. I am picturing something like the half dozen "quick
settings" programs out there but integrated into steel as to not worry
about opening another program. Ideally I imagine a stand alone program
that will run in the background and scan for user specified
applications. If those apps are launched it activates WI-FI for the
period of time that app is being used, but that is a whole other
barrel of fish and a more complicated. Also could a long press on the
back button activate the exit steel command? Using the same style of
command that the home key uses to access 'recent applications'.
Currently I am spamming the back button or opening a new window just
to close the app.
to enable WI-FI when launched and then turn it off again when using
the exit command. I am picturing something like the half dozen "quick
settings" programs out there but integrated into steel as to not worry
about opening another program. Ideally I imagine a stand alone program
that will run in the background and scan for user specified
applications. If those apps are launched it activates WI-FI for the
period of time that app is being used, but that is a whole other
barrel of fish and a more complicated. Also could a long press on the
back button activate the exit steel command? Using the same style of
command that the home key uses to access 'recent applications'.
Currently I am spamming the back button or opening a new window just
to close the app.
schwiz
May 1, 2009, 8:26:57 AM5/1/09
to SteelAndroid
google is taking away the ability for developers to switch things like
wifi on and off in the cupcake patch which is being rolled out any
day. >:(
wifi on and off in the cupcake patch which is being rolled out any
day. >:(
kolbysoft
May 1, 2009, 10:00:24 AM5/1/09
to SteelAndroid
Sad but true, all hail our engineering mastermind overlords at G.
Michael
Michael
cebweb
May 1, 2009, 10:38:44 AM5/1/09
to SteelAndroid
Well that is crap. Did they give a reason? Can I get a link?
kolbysoft
May 1, 2009, 11:16:29 AM5/1/09
to SteelAndroid
Here, to fully appreciate the developer sentiment, read the whole
discussion, including the replies from Google:
http://groups.google.com/group/android-developers/browse_thread/thread/562ae51484545074/fdbde0e630526e30?q=fail+%232&lnk=ol&
Michael
discussion, including the replies from Google:
http://groups.google.com/group/android-developers/browse_thread/thread/562ae51484545074/fdbde0e630526e30?q=fail+%232&lnk=ol&
Michael
taa1
May 2, 2009, 8:32:39 PM5/2/09
to SteelAndroid
Oh no, say it isn't so, Google! Ugh. (P.S. Thanks for the link.)
On May 1, 8:16 am, kolbysoft <kolbys...@gmail.com> wrote:
> Here, to fully appreciate the developer sentiment, read the whole
> discussion, including the replies from Google:http://groups.google.com/group/android-developers/browse_thread/threa...
On May 1, 8:16 am, kolbysoft <kolbys...@gmail.com> wrote:
> Here, to fully appreciate the developer sentiment, read the whole
schwiz
May 3, 2009, 12:20:15 AM5/3/09
to SteelAndroid
im hoping they will go back on this and just make it so developers
need to request permission for the api to do these things. I get that
they don't want people switching these things on and off without users
knowing, but there were plenty of programs that did it with the user
knowing about it. Why ruin it for everyone because of a few bad
apples.
need to request permission for the api to do these things. I get that
they don't want people switching these things on and off without users
knowing, but there were plenty of programs that did it with the user
knowing about it. Why ruin it for everyone because of a few bad
apples.
Reply all
Reply to author
Forward
0 new messages