4 ms·

Loopt for Android... with background location!

20 points by bootload 18y ago

stcredzero 18y ago
Apple could compete with background functionality without giving up tight control over resource use by background processes. Apple could implement a service, where certain code could execute, with each application allocated constrained time slices. Compile the registered callbacks to run on top of a VM, and you can make it impossible for an App to resource starve the system or crash in obnoxious ways. App writers would have a very strong incentive to create frugal callback functions so that they can be assured of consistent results. (Otherwise one function call could span multiple time slices.)
- litewulf 18y ago
  Weirdly, Android (and most other operating systems) have the ability to run background processes without anywhere near as complicated a system. They just implement preemptive multi threading, that way if some threads need more and some need less, they all get the CPU they need. (well, in general). In fact the API you suggest seems needlessly complex Why a "VM"? Why register callbacks? Just let tasks run without a UI thread. Let the process with the currently visible UI thread have priority. Simple, done. (Glossing over the fact that doing things the way Apple does it allows for them to make better performance and battery-life guarantees, which is something not solved with your API as the user "cost" is taken out on other applications generally, as users don't know that their battery is worse because of you, or that there browser doesn't scroll as smoothly because of your bad background thread.)
  - thwarted 18y ago
    That's one thing that is often missing, some kind of quick process listing. People would eventually associate their battery life with the list of programs running or installed, and would be able to make more informed choices about which apps to install and/or use. It would also give an incentive to app programmers to not be so aggressive, as their aggressive app will be associated with low battery life or unresponsive UI. An app that uses GPS could tie into the time of day and week and change its polling frequency based on a pattern of past movement behavior. If it sees a pattern that everyday between 11am and 1pm it has bigger changes in location than in the morning or afternoon, your lunch trip would be updated more often. Or with accelerometer support could detect that that is not moving and poll for location less frequently. I'm sure some apps are already doing stuff like this.
    - litewulf 18y ago
      (disclaimer: I've only used a cellphone and never made one.) I think the problem is much deeper than you'd think. Its very difficult to know the battery cost of an action (some CPU ops take less power iirc), and also I'd imagine that certain execution patterns would be more efficient than others. For example, GPS fixes have some caching involved, so two applications with very similar GPS access patterns could possibly halve their power consumption by simply being scheduled back to back. Further, I'm not sure whether CPU is really the killer. CPU drain affects latency, which is bad, but for example keeping the radio running (data access), or keeping say accelerometer sensors on (perhaps the generate constant interrupts that interfere with the system's low power state.) I have an Android phone, and there is some screen that displays uptime statistics and also "time awake" which I think is an indicator for the proportion of the time the CPU is maxed, and even when I run top on my phone I have NO idea what it means or whats at fault. This is partly a tools problem and also partly a problem of some things being products of some particular interleaving. Another thought is that you have to be very careful about what you measure. Even in the desktop, lots of IO will probably show up as IO waits in your process, so latency is suffering even though the process itself is unrunnable (and worse, the blame would fall on the kernel's IO scheduler probably, thus hiding the blame further. And what if you want to write something but your system is already busy? Who's at fault, the other guys in the IO queue? What if all the apps in the queue are being nice and its just say a DB engine with raw disk access? Complicated complicated stuff.)
      - stcredzero 18y ago
        Really the point of my "ultra paranoid VM" idea that I brought up in the other thread is that there are ways that Apple could put a strict upper bound on the amount of CPU that user background apps can use. I just said it in far too many words, using less than optimal tools.
        litewulf 18y ago
        :) cool I understand what you're saying.
  - stcredzero 18y ago
    Yes, there's always ordinary preemptive multi threading. My idea is more of a "proof by example." Even if somehow conventional tools are not enough, there are still ways that Apple can guarantee totally paranoid control, but still give developers background processes. Also, my scheme is precisely about user applications not getting all the CPU they need. They'll be absolutely guaranteed to only get the miserly little bit we give them. This will come in the form of a single user background process that runs in totally predictable time slices and -- from the POV of the OS -- never throws an exception. (User background code will throw an exception, but it would be virtual.) Thus, we are guaranteed to never get exception handling overhead from the background apps. Likewise, we are saving context switching overhead by using "green processes". One would be able to achieve a completely paranoid level of sandboxing this way. The purpose of my post is not to do engineering for Apple. It's to show there's no reason for Apple to not give us background processes!
    - litewulf 18y ago
      I really don't understand the advantages of your approach. I'm willing to believe I'm just dumb though ;) (One comment on the basic approach: many languages that use green threads don't scale well in multicore due to issues like lock contention or IO wait.) Preemptive multithreading still leaves the OS with final control (for your "miserly time slice" comment. Which I find very problematic for things like say Loopt where for example you will spend more time waiting for a GPS fix or on network latency than actual computation time...) How does a "virtual" exception handler become cheaper than any other implementation? It seems the work required is roughly the same (catch dangerous situations, jump to the correct handler). I suppose there would be lower context switching costs with the use of green threads (skip a user->kernel->user transition), but I suspect it would require programming without any synchronous anything (all IO would have to be asynchronous probably in order for threads to "yield" back to the virtual task scheduler). (Sorry kind of rambling, I'm pretty much curious about every sentence you wrote ;) I don't think traditional multiproccessing models really pose any control problems that are solved by running a single user thread that does its own scheduling IMO)
      - stcredzero 18y ago
lallysingh 18y ago
The note about Loopt on Android not giving you an anonymous xmit feature makes sense, as the iPhone version requires that you explicitly activate it to transmit your location to strangers.
martythemaniak 18y ago
For a long time I've maintained that Apple's position on system access and background process APIs was purely political - in that there is no technical or security/privacy reasons for 3rd party apps being locked out - just Jobs' control-freak personality. Both Android and BlackBerry allow such access to 3rd party apps and it makes a whole lot more stuff possible than on the iPhone. My own little Android app (http://phonalyzr.com http://phonalyzr.com) is another example. Rather than background processing, it needs access to contact/call log info. On Android and BlackBerry the OS notifies the user the app will access that and the user can make a decision, on the iPhone that decision has been made for the user by Jobs. When people start to see stuff like Loopt working better on Android or similarly open devices and when none of Jobs' scare tactics (malicious apps, viruses bringing down networks etc) come to pass, perhaps the iPhone will open up a bit more.
- ardell 18y ago
  The open nature of Android certainly has advantages over the iphone, but Apple secured a pretty hefty first-mover advantage. Also, they got it right from the start (or V2) with a great design, whereas Android still feels very much in alpha. Background processes are a big win and would be a huge factor for me, but I'd need to see some improvement of handset design before I'm ready to switch. The real question is when will we see a more polished Android phone?
  - litewulf 18y ago
    (Google did not have first-mover advantage with their search engine. First mover advantage helps, but it also helps if you have something else, like sexiness.) Android handsets definitely lack a certain polish, both software and hardware side. Its quite a pickle.
  - axod 18y ago
    I agree. There's no reason to switch until there's a sexy good build quality phone. The G1 certainly isn't it.
sahaj 18y ago
i would think it would take more resources and battery power to constantly ping a server, rather than just run a low priority task in the background. think about it, you'd have to constantly ping the server, if a notification came in about a new message, then the messaging app would have to be launched, this would take more resources than just having a light background task running, that pings the server as needed. i wonder is apple will ever open up background tasking. i would think they would eventually have to, otherwise they'd be alienating a lot of functionality from the users.
ig1 18y ago
anyone know when this is going to be available outside the US ?
lacker 18y ago
One annoying thing is that this keeps the GPS running all the time, which really hurts the battery on the G1. You can disable this in the global Settings, but then you have to re-enable for any other app. Instead, they should just turn on GPS once every five or ten minutes, especially if I'm not moving.

20 points by bootload 18y ago

Apple could compete with background functionality without giving up tight control over resource use by background processes. Apple could implement a service, where certain code could execute, with each application allocated constrained time slices. Compile the registered callbacks to run on top of a VM, and you can make it impossible for an App to resource starve the system or crash in obnoxious ways. App writers would have a very strong incentive to create frugal callback functions so that they can be assured of consistent results. (Otherwise one function call could span multiple time slices.)

litewulf 18y ago
Weirdly, Android (and most other operating systems) have the ability to run background processes without anywhere near as complicated a system. They just implement preemptive multi threading, that way if some threads need more and some need less, they all get the CPU they need. (well, in general). In fact the API you suggest seems needlessly complex Why a "VM"? Why register callbacks? Just let tasks run without a UI thread. Let the process with the currently visible UI thread have priority. Simple, done. (Glossing over the fact that doing things the way Apple does it allows for them to make better performance and battery-life guarantees, which is something not solved with your API as the user "cost" is taken out on other applications generally, as users don't know that their battery is worse because of you, or that there browser doesn't scroll as smoothly because of your bad background thread.)
- thwarted 18y ago
  That's one thing that is often missing, some kind of quick process listing. People would eventually associate their battery life with the list of programs running or installed, and would be able to make more informed choices about which apps to install and/or use. It would also give an incentive to app programmers to not be so aggressive, as their aggressive app will be associated with low battery life or unresponsive UI. An app that uses GPS could tie into the time of day and week and change its polling frequency based on a pattern of past movement behavior. If it sees a pattern that everyday between 11am and 1pm it has bigger changes in location than in the morning or afternoon, your lunch trip would be updated more often. Or with accelerometer support could detect that that is not moving and poll for location less frequently. I'm sure some apps are already doing stuff like this.
  - litewulf 18y ago
    (disclaimer: I've only used a cellphone and never made one.) I think the problem is much deeper than you'd think. Its very difficult to know the battery cost of an action (some CPU ops take less power iirc), and also I'd imagine that certain execution patterns would be more efficient than others. For example, GPS fixes have some caching involved, so two applications with very similar GPS access patterns could possibly halve their power consumption by simply being scheduled back to back. Further, I'm not sure whether CPU is really the killer. CPU drain affects latency, which is bad, but for example keeping the radio running (data access), or keeping say accelerometer sensors on (perhaps the generate constant interrupts that interfere with the system's low power state.) I have an Android phone, and there is some screen that displays uptime statistics and also "time awake" which I think is an indicator for the proportion of the time the CPU is maxed, and even when I run top on my phone I have NO idea what it means or whats at fault. This is partly a tools problem and also partly a problem of some things being products of some particular interleaving. Another thought is that you have to be very careful about what you measure. Even in the desktop, lots of IO will probably show up as IO waits in your process, so latency is suffering even though the process itself is unrunnable (and worse, the blame would fall on the kernel's IO scheduler probably, thus hiding the blame further. And what if you want to write something but your system is already busy? Who's at fault, the other guys in the IO queue? What if all the apps in the queue are being nice and its just say a DB engine with raw disk access? Complicated complicated stuff.)
    - stcredzero 18y ago
      Really the point of my "ultra paranoid VM" idea that I brought up in the other thread is that there are ways that Apple could put a strict upper bound on the amount of CPU that user background apps can use. I just said it in far too many words, using less than optimal tools.
      - litewulf 18y ago
        :) cool I understand what you're saying.
- stcredzero 18y ago
  Yes, there's always ordinary preemptive multi threading. My idea is more of a "proof by example." Even if somehow conventional tools are not enough, there are still ways that Apple can guarantee totally paranoid control, but still give developers background processes. Also, my scheme is precisely about user applications not getting all the CPU they need. They'll be absolutely guaranteed to only get the miserly little bit we give them. This will come in the form of a single user background process that runs in totally predictable time slices and -- from the POV of the OS -- never throws an exception. (User background code will throw an exception, but it would be virtual.) Thus, we are guaranteed to never get exception handling overhead from the background apps. Likewise, we are saving context switching overhead by using "green processes". One would be able to achieve a completely paranoid level of sandboxing this way. The purpose of my post is not to do engineering for Apple. It's to show there's no reason for Apple to not give us background processes!
  - litewulf 18y ago
    I really don't understand the advantages of your approach. I'm willing to believe I'm just dumb though ;) (One comment on the basic approach: many languages that use green threads don't scale well in multicore due to issues like lock contention or IO wait.) Preemptive multithreading still leaves the OS with final control (for your "miserly time slice" comment. Which I find very problematic for things like say Loopt where for example you will spend more time waiting for a GPS fix or on network latency than actual computation time...) How does a "virtual" exception handler become cheaper than any other implementation? It seems the work required is roughly the same (catch dangerous situations, jump to the correct handler). I suppose there would be lower context switching costs with the use of green threads (skip a user->kernel->user transition), but I suspect it would require programming without any synchronous anything (all IO would have to be asynchronous probably in order for threads to "yield" back to the virtual task scheduler). (Sorry kind of rambling, I'm pretty much curious about every sentence you wrote ;) I don't think traditional multiproccessing models really pose any control problems that are solved by running a single user thread that does its own scheduling IMO)
    - stcredzero 18y ago

lallysingh 18y ago

The note about Loopt on Android not giving you an anonymous xmit feature makes sense, as the iPhone version requires that you explicitly activate it to transmit your location to strangers.

martythemaniak 18y ago

For a long time I've maintained that Apple's position on system access and background process APIs was purely political - in that there is no technical or security/privacy reasons for 3rd party apps being locked out - just Jobs' control-freak personality. Both Android and BlackBerry allow such access to 3rd party apps and it makes a whole lot more stuff possible than on the iPhone. My own little Android app (http://phonalyzr.com http://phonalyzr.com) is another example. Rather than background processing, it needs access to contact/call log info. On Android and BlackBerry the OS notifies the user the app will access that and the user can make a decision, on the iPhone that decision has been made for the user by Jobs. When people start to see stuff like Loopt working better on Android or similarly open devices and when none of Jobs' scare tactics (malicious apps, viruses bringing down networks etc) come to pass, perhaps the iPhone will open up a bit more.

ardell 18y ago
The open nature of Android certainly has advantages over the iphone, but Apple secured a pretty hefty first-mover advantage. Also, they got it right from the start (or V2) with a great design, whereas Android still feels very much in alpha. Background processes are a big win and would be a huge factor for me, but I'd need to see some improvement of handset design before I'm ready to switch. The real question is when will we see a more polished Android phone?
- litewulf 18y ago
  (Google did not have first-mover advantage with their search engine. First mover advantage helps, but it also helps if you have something else, like sexiness.) Android handsets definitely lack a certain polish, both software and hardware side. Its quite a pickle.
- axod 18y ago
  I agree. There's no reason to switch until there's a sexy good build quality phone. The G1 certainly isn't it.

sahaj 18y ago

i would think it would take more resources and battery power to constantly ping a server, rather than just run a low priority task in the background. think about it, you'd have to constantly ping the server, if a notification came in about a new message, then the messaging app would have to be launched, this would take more resources than just having a light background task running, that pings the server as needed. i wonder is apple will ever open up background tasking. i would think they would eventually have to, otherwise they'd be alienating a lot of functionality from the users.

ig1 18y ago

anyone know when this is going to be available outside the US ?

lacker 18y ago

One annoying thing is that this keeps the GPS running all the time, which really hurts the battery on the G1. You can disable this in the global Settings, but then you have to re-enable for any other app. Instead, they should just turn on GPS once every five or ten minutes, especially if I'm not moving.