Is it possible to run Safari in the background on the iPhone?
Specifically, our client would like to monitor a user's location via HTML5 GPS capabilities and measure the speed of movement.
The reason for avoiding native implementation in iOS is because the client wishes to create a cross-platform service using HTML5.
Is this possible?
I don't believe Safari continues to execute when it's backgrounded. (This is supported by a recent thread on the Apple discussion board.)
That said, it would be fairly trivial to do this in a proper iOS application, although you'd obviously need existing knowledge of Objective-C, some of the main Cocoa/UIKit classes, the Xcode environment, etc.)
Related
Might be i am using a wrong title but i will try to explain here what i want.
In iOS i need to implement a functionality to get notify if the user is using their iOS device.
My app will be running in background using location services and i need to find out if the the user is using their device. It is doable as i have looked into this application which is sending notifications in background to the drivers who is suing their devices while driving.
https://itunes.apple.com/fr/app/cellcontrol/id661169580?l=en&mt=8&ign-mpt=uo=2
So i need similar kind of functionality to find out if a user is using iOS device or not. If anyone of you can suggest me any approach then it would be great for me to start.
Thank you!
Note: I have tried to find out touch events in background but that is not possible as i have done some research on this.
You won't be able to receive touch events when the app is in background using public API's. However, you can do that with the help of mobileSubstrate library ( http://iphonedevwiki.net/index.php/MobileSubstrate - The MobileHooker component is the one that would be used). by hooking your process to the OS. As an example, the display recorder app in Cydia tracks global gestures while recording the screen. This will be a cydia tweak and you will need to jailbreak your device to do all that.
Coming to your specific use-case, the example app you cited should be using one of the exceptions for background applications mentioned in https://developer.apple.com/library/ios/documentation/iphone/conceptual/iphoneosprogrammingguide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html (see the section - "Implementing Long-Running Background Tasks"), probably the one to receive updates from external accessories.
I have an application that requires location tracking and I think it fits squarely within one of the allowable background models. However, I need to post to a network service when there are significant changes of location. I've seen write-ups that state network access is prohibited in background processing, but I didn't read that in Apple's docs.
Does anyone know if it's kosher (wrt Apple policies) to make occasional and very quick network updates in a background process?
Good point, according to the Apple documentation only the following usages are allowed in background and each service should be registered:
audio—The app plays audible content to the user while in the background. (This content includes streaming audio or video content
using AirPlay.)
location—The app keeps users informed of their location, even while it is running in the background.
voip—The app provides the ability for the user to make phone calls using an Internet connection.
newsstand-content—The app is a Newsstand app that downloads and processes magazine or newspaper content in the background.
external-accessory—The app works with a hardware accessory that needs to deliver updates on a regular schedule through the External
Accessory framework.
bluetooth-central—The app works with a Bluetooth accessory that needs to deliver updates on a regular schedule through the
CoreBluetooth framework.
Other than this services, you can create a Finite-Length Task in the Background that actually give you the possibility to end a network process.
This can be important if your app is performing some important task,
such as writing user data to disk or downloading an important file
from a network server.
Regarding your question, it's not really clear if you can or not can do a quick network connection if you've a location service running in background. I would say YES for a short connection, but not totally sure. Since iOS 4.0 this usage was denied and clear in documentation, now that part has been removed.
Yes if you use background for just quick connection. Apple won't allow you to run in the background as you want.
NO If your app does not fall in the Voip, music or GPS category; then you can't run in background.
more here: Update my app when it is in background
You could use ASIHTTPRequest.
ASIHTTPRequest has a property setShouldContinueWhenAppEntersBackground:. default is NO, you may turn on YES so you have background network process.
Apple documentation seems a bit unclear on the strict policy. There are definitely applications in the app store that make sporadic network calls while running in the background as a location-based application. An example is the Geoloqi application.
Is it possible for me to programmatically access a smartphone's sensors (e.g. accelerometer, compass, etc. on an Android or iPhone device) through a browser webpage and JavaScript? I know that the W3C Devices standard can allow access to the camera.
HTML5 is likely to contain a sensor API. Until this is fully standardized, vendors provide their own APIs such as Apple does for mobile Safari.
There's no need for full blown solutions like PhoneGap or similar if it is Ok for you to restrict yourself to a specific vendor/device. If not, frameworks like PhoneGap provide you with a unified, device independent API.
You should be aware of the Performance constraints that apply to Javascript applications running inside the browser of a mobile device. Depending on your type of application and the amount of processing you intend to do on the sensor data, you are better off writing a native application
See https://developer.apple.com/library/safari/iPad/#documentation/SafariDOMAdditions/Reference/DeviceMotionEventClassRef/DeviceMotionEvent/DeviceMotionEvent.html for some reference documentation.
The answer is both "yes" and "no". Each phone manufacturer/OS combination behaves as it sees fit here - for example, the GPS on an iPhone can be accessed, but the compass not:
accessing iPhone compass with JavaScript
You can use something like PhoneGap to do this, I believe.
Check out this chapter called "Controlling the iPhone with JavaScript" from the book Building iPhone Apps with HTML, CSS, and JavaScript
This demo considers the iPhone movements on the three axis using the event.accelerationIncludingGravity object:
http://www.omiod.com/iphone/acceleration-demo.php
So far Safari on iPhone is the first to implement it, but I see Android filling this gap very soon.
Today, the focus of a cell phone's capabilities is drifting away from plain making a phone call.
And somehow, this shows in the API's too. Therefor I'm wondering: if I want to write an app that e.g. pitches up, records, scrambles... an incoming call - you know, the voice on the other side -, what aspect of the API should I use?
I looked into Android, into Windows Phone, iPhone... (briefly), but had no luck. Is this just unintended usage?
This is also not possible with Windows Phone 7. There were, however, API methods for interacting with incoming and outgoing calls and texts in Windows Mobile.
The reason this is not possible in Windows Phone 7 comes down to a deliberate decision around data security and the aim that apps on the phone shouldn't be able to do something without the user specifically knowing about it. This prevents, amongst other things, malicious apps having information about or access to potentially sensitive data.
This is not possible in Android, except maybe via firmware modifications.
There’s no way to do that with the iPhone SDK. It may be possible through jailbreaking, but I’m not familiar enough with it to speak on it.
Given the limited accessibility of in-call audio but ready access to microphone/speaker and data on current smartphones, would probably be easiest to do this as part of a VOIP calling application.
I've been doing mobile app development for a long time (2001?), but the systems we worked with back then were dedicated mobile development environments (Symbian, J2ME, BREW). iPhone SDK is a curious hybrid of Mac OS X and Apple's take on mobile (Cocoa Touch).
But it is missing some stuff that other mobile systems have, IMO. Specifically:
Application background processing
SMS/MMS application routing (send an SMS to my application in the background)
API for accessing phone functions/call history/call interception
I realize that Apple has perfectly valid reasons for releasing the SDK the way they did. I am curious what people on SO think the SDK is missing and how would they go about fixing/adding it, were they an Engineering Product Manager at Apple.
The biggest shortcoming in my opinion is support for separating licensing from distribution.
What I mean by this is that it should be possible to download a trial version of an application and later purchase a license for that application (from an API call inside the application or from the app store). This would make it much easier to try-before-you-buy and get rid of the current duplicates of many applications with 'lite' versions.
I think lack of push notifications for apps is the big thing we're missing right now. With push, you can register your application to perform a task (like getting the most recent data from a web service) even when it's not running, at a time and frequency the OS decides is best. In an ideal world, along with the existing concept of iPhone apps loading quickly and resuming where you last left off, this solves the problem of not running in the background. I know some tasks will be more difficult or maybe impossible with this strategy, but it's still a pretty good compromise between third party applications and the iPhone's limited hardware.
Originally push was scheduled for last September, but it was removed from the beta SDK and not spoken of since then.
API's I'm personally looking for:
Apple80211 as a public API (private, current API is fine if documented)
Access to Volume buttons (semi-accessible via Celestial, private, needs new API)
Access to Calendar (private, API status unknown)
Access to Bluetooth + SPP profile (status unknown)
Access to Camera (directly, API status unknown)
Access to JavaScript runtime (directly, not through UIWebView, API status unknown)
WebKit access that's lower-level than UIWebView (private, current API is fine)
Access to Music Library (private, current API is fine)
Garbage Collection.
CoreData is missing.
You've mentioned some of the big ones - copy & paste (or in fact any way for apps to collaborate) is another huge omission.
It also seems to lack a desktop synch framework (at least if it exists I can't find it).
Language independence and especially lack of scripting is another pet peeve - objective-c is all very well but more languages to choose from would be good.
Inability to dynamically extend apps, via scripts or otherwise, is another big omission. This is partly an SDK/OS issue, partly licensing.
My list ordered by priority:
Mapping abstraction (the MapKit looks awesome), but that would require a new Google Maps TOS
Music library
Camera (photo + video) Access to more
UIViews, Apple designed some pretty nice custom ones for their apps
Better UIWebKit abstraction
The features I see missing that it should have is
Access to SMS
Direct Access to Google Maps App. You should be able have access to this so you could extend your application to use the built in features provided by Google Maps.
Access to the Bluetooth functionality of the phone.
Access to the Calendar. Why not allow access to simply post a calendar event for the user.
Access to Active Sync. It would great if we could directly access this and communicate back to the Exchange Server.
Core Image. They provide Core Animation but Core Image is missing. I hope that this is added to the API soon.
These are some of the features that my clients have access for in the past and are supprised when they are not available.
We definitely miss a Calendar API and SMS access. So many applications could leverage such APIs. The iPhone allows users to have everything in their pocket, but it's almost useless as long as developers cannot leverage this integration in their apps.
A language with proper namespaces.
A limitation that bugs me is lack of access to system features that require root or setuid. For example: opening privileged IP ports.
I'm not sure there is a good solution to this, as long as Apple's policy is to keep the device locked-down.
Allow program to set some kind of local timed event for your application to bring up an alert and launch your app if the user agrees (like any calendar app). You could do that with push notifications but there are many cases I'd hate to have to rely on a whole server infrastructure and network connectivity just to basically do some timed thing.
Some idea of what direction the user is facing. I cannot believe the GPS chip the newer iPhones use are not capable of reporting direction.
I would personally love to see
Access to the CoreTelephony Framework (Currently private). Which allows access to all the phone functions (Especially sending MMS / SMS).
Some sort of ability to run stuff in the background. While push notifications is ok for most things, but it is a bit hard to leverage CoreLocation (i.e. have the app show a notification at a certain location). Of course this would probably need an on/off button or app specific like push is.
animation view which will be reduce developer to make a cool app , of course the core business local still need consider more , but the view layer could more easy to use ....