Nov

28

iPhone proximity sensing IS in the API

6 years ago, at the end of November | Leave a Comment

There seems to have been a lot of misinformation flying about of late. With Google releasing a new version of their app incorporating proximity sensing, some blogs have claimed this is breaking AppStore rules by using undocumented hidden (non public) API calls. I’m here to tell you that’s just rubbish. All that has happened is the people reporting it haven’t even bothered to check. Want to prove this to yourself?

1. Start Xcode and pick one of the templates.
2. Load up the AppDelegate code and skip to ‘applicationDidFinishLaunching’.
3. Type ‘application.’ (note the full stop after the word application)
4. Hit escape and you’ll get a list, scroll down to items starting with P
5. Oh look there it is…

For those without Xcode here’s a picture.

Oh, that must be the non-public public api...

Oh, that must be the non-public public api...

For those that want to see the what the documentation says


proximitySensingEnabled

A Boolean value that determines whether proximity sensing is enabled.

@property(nonatomic, getter=isProximitySensingEnabled) BOOL proximitySensingEnabled

Discussion
YES if proximity sensing is enabled; otherwise NO. Enabling proximity sensing tells iPhone OS that it may need to blank the screen if the user’s face is near it. Proximity sensing is disabled by default.

Availability

Available in iPhone OS 2.0 and later.

Declared In
UIApplication.h

Unfortuneately once some people grab hold of false information no facts will get in their way. Anyone that knows me will tell you that I’m really not fond of either Google or Apple, but let’s just get stuff right shall we.


Update:
I’ve had some discussion on irc and it was felt that I should point out that proximityStateChanged is used and following some additonal chatter on IRC with UncleBob who pointed out that “It’s not private in the OBjC sense just the Apple documented SDK sense. ” he then went on to say “the whole thing is definately a peanut-gallery cockfest” which sums it all up really.



»crosslinked«


[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon] [Twitter]

Tagged with:
November 28, 2008 11:43

Sep

22

Follow Me Wallpaper

6 years ago, at the end of September | 3 Comments

Last night I tried a little experiment on my jailbroken iPhone. Since I’d already started poking about playing with my own Winterboard themes and have been tracking my iPhone’s location for a while now, I thought I’d see what happened if I mixed the two. So, how about wallpaper that followed you? Follow Me It turns out that combining the two is relatively straight forward. Google now provide a mechanism for getting what they call static maps which will allow you to get an image centered on a set of coordinates. You can also add your own markers if you want.

There are some limitations on the number and size of the maps that you can retrieve so I employed a very simple caching mechanism to ensure I didn’t annoy Google. This certainly helps speed things up when testing and also enabled me to identify a small issue I was having.
Read more…




[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon] [Twitter]

Tagged with:
September 22, 2008 11:50

Jul

24

Twitter == FAIL

6 years ago, at the end of July | Leave a Comment

I’ve finally had enough of Twitter. I have no idea why people put up with its failures, its continuing inability to do IM updates or its inability to cope with their traffic volumes. It’s just broken. I’m moving to identi.ca which seems to be a lot more robust and at least lets me use IM. The also have a twitter compatible API sorted out. A perfect replacement. Hope to see you there soon.




[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon] [Twitter]

Tagged with:
July 24, 2008 12:58

Nov

21

Here I am, right here

7 years ago, mid-November | 7 Comments

Some time ago I wrote what I called the “Ramius” edition of my tracker application for the TomTom Go. The limitations of the Go SDK caused more than its fair share of grief and I shelved the project, hoping to revive it later. Now I’m thinking that it’s time to bring it back to life.

At the moment I’m selling my house in The Netherlands and moving back to the UK. Until the house sells I flit between the UK and Holland every couple of weeks. I’ve taken to using the Chunnel for this because it means I can drive through the night rather than have to bend to the ferry or flight schedules. The trouble is, my wife gets worried that I’m going to crash and burn. She does this every time I do the trip, in either direction. She wont go to bed until she knows that I’ve at least got to the Tunnel.

I brought the original code out of my archive and started looking at it, removing anything that was TomTom specific. I’m pretty sure that I’ll have a workable solution fairly soon, I may butcher the openmoko-agpsui2 application a bit too, just to add a face to the tracker application code. Obviously, it will need a network connection of some sort so I’ll be looking at starting and stopping a gprs connection, or using wifi when the GTA02 arrives.

On the topic of gprs and network connections, I was mulling over some points in my mind about this. Nobody wants their Neo to pull an iPhone, and give us all large bills because of roaming, so there needs to be some mechanism where the user can deny or allow access to things like gprs connections. These could be based on dates, times, even locations with the built in gps. The problem is not that it is difficult to do, the problem is that we need to be able to force applications to use an API to open gprs and wifi conections, and possibly even access the gps. There’s a whole kettle of fish here. Openmoko is opensource, not the Google kind of ‘opensouce’, the real kind. That in itself poses a few questions and perhaps some not so nice answers.

If we want to force people to use an API, then we have to make sure that they can only use the API and not bypass it. If they can bypass it, it’s useless because the malicious ‘l33t h4x0r’ is going to abuse your connection. The problem is, since we are opensource, the same abuser can simply replace the API. Sure you still have to install the application, but just think about it. Right now how many places do you update your Neo from with ipkg? If any one of those gets compromised or the owner deliberately alters packages, the first you’ll know of it is when you bill hits the mat with a thud rather than the usual ‘ftht’.

We can think about signed images or signed packages etc but that is not really going to help, this is opensource. As an application developer I’m going to want to publish applications, I don’t really want to have to get them certified or signed by someone else just so other people can use them. If you alert the user that an application or package is not signed, you know that they’ll just click ‘ok install it anyway’ and ignore it.

I think I’m going to have to ponder this one a little longer.




[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon] [Twitter]

Tagged with:
November 21, 2007 14:49

Current Electricity Use (15min)


iPhone/Webkit RSS Reader

Links


Tags

1-Wire android api Apple arduino currentcost DDAR development DVD FIC freerunner G1 google Google Phone gphone gprs GPS hardware image image builds inspiration iphone jailbreak kiosk linux Mac monitoring Music neo 1973 Nokia openmoko opensource OSX Pachube personal qtopia rhubarb rikki Rio slimp3 slimserver software tracking Trolltech u-boot


Twitpic


Graphy Stuff






Nasty Spam Monkeys