Is there any info about the voltage or electrical field being sensed by the Iphone's capacitive screen that can be used in a program?
Might this data be kept in a log or accessible via function calls?
It's abstracted away - you can't get at it, or see it. I wouldn't be surprised if it was actually abstracted away in hardware, rather than software. As far as I know it's not logged anywhere either (that would be one huge log file if it did).
Even if it is possible to see it from software (which is very unlikely), the only place where it would be accessible is from within the kernel. For apps, it is impossible to access raw touchscreen data.
Related
I am thinking about a web app to detect the presence of the other iPads/iPhones. This is purely theoretical at the moment, i have no idea how to do this.
My question is what is my best technology/language method of doing this?
Is it going to be bluetooth or gps? How does the App Bump work?
Thanks for any suggestions posted...
Bump's FAQs: http://bu.mp/faq
According to their FAQs, when your phone has the Bump app up and ready, the app listens to the accelerometer for a sharp stop (your hand with your phone in it stopping when it hits the other person's hand with their phone in it), at this point, exact date time information as well as GPS position and characteristics of the bump are sent off to Bump's servers to compare other information from other bump users to see what other bump account shares most of that information. Bluetooth is not used in any capacity to make this happen, not for the transfer or the recognition of who to transfer to.
Your website may have to do the same thing. Have every instance report to your server, and then report back from the server where other people are.
Of course this goes without saying that I'm sure you were thinking about privacy settings and other layers of personal security.
Options I'd explore:
Bonjour discovery. In principle devices that can see each other via Bonjour could actually be in different continents, but usually it means 'same wireless network' and therefore at least 'same building'.
Game kit. Actually, this either uses Bluetooth or the local network, so is probably going to have similar results to Bonjour discovery but in less code.
I wouldn't try location services like Core Location (actually I would, but only if the above don't work), as the results probably aren't going to be fine enough. Especially indoors: the Maps app on my phone places me in a circle of about 50 metres radius with my actual location being on the outer edge of said circle. Someone on the next street with similar resolution could, as far as the app is concerned, be adjacent to me.
I want to build an app that can communicate to some external third party hardware. I come to know that External Accessory framework can help me out in that, but I have few confusions……
Do I need to register ‘Made For iPod’ program before I start?
Do I need the third party hardware before I start, or I can start without hardware?
Is there any alternative to test the app, if the hardware is not currently available?
You could do that. But they don't approve everyone who registers like in the iOS program. It takes (in my experience) a lot of time and they have requirements that not everybody can met. You don't need to apply if the hardware is ready. The MFI program is for hardware developers. If you don't make hardware I wouldn't even try to get into MFI. It's a waste of time and money.
If you write an official app for the accessory, the company that makes it should give you a prototype so you can get started ASAP.
I would highly suggest to get the hardware. And if this is the first accessory project for you and the company then I would consider to go there and start writing the basic code on site, where you can get your hands on the developer.
The communication works with streams. I never tried it but I think you could write the whole protocol specific communication with network connections and then replace the networking stuff with the EASession once you have the hardware.
If you want to test the External Accessory framework you should have a look at EADemo. I never tried (and I don't have a accessory near me to test) but I think this should work with all accessories. But in my opinion everything EA Framework related is the easy part of the whole process.
Summary: Get the hardware. If you'll get the hardware in two weeks do the User Interface part now. If you can't get your hands on the accessory within two weeks you should beg for a prototype.
Regarding your comment to the other question: Test equipment is available when you are a member of MfI.
If you want legitimately produce and certify your third party hardware, you will need to apply for 'Made For iPod’ program. You will get and API and documentation to do that.
Unfortunately your chances to be approved are very low.
I'm working on an enterprise iPhone application for a client, the issue at hand is customer information will show up on the phone. My client is worried that the information could be caught using the iphone screen capture feature (home + power button), then emailed or synced from the phone. Is there any way to disable the screen capture feature? Can this be done programatically or is is possible through a configuration profile?
if your customer could retain the ownership of a handset, they can restrict Screen Capture feature using iPhone Configuration Utility. Make sure you don't give these phones to any one outside of this organization, otherwise you are in violation of your Enterprise legal agreement with Apple.
Since this is for an enterprise app, perhaps you could put a transparent overlay view atop everything, that in a drawRect went opaque when it detected the layer was being asked to render for a screen shot (perhaps by looking back up the stack trace?)
You might try setting debug points in every possible view and layer drawing methods, and see if anything is triggered by a screenshot.
Screen capture can be enabled/disabled for iPads/iPhones that are managed via the iPhone OS Configuration Utility. See page 33 at http://manuals.info.apple.com/en_US/Enterprise_Deployment_Guide.pdf where it says:
** Allow screen capture: When this option is turned off, users are unable to save a
screenshot of the display.*
In other words, in enterprise deployments where the "customer" owns the iPads (or requires employee-owned devices to be configured by IT) screen capture can be suppressed at a device level.
It's also possible to detect if screen capture has happened and to record this (so perhaps a manager can pay a friendly visit).
It is not possible to suppress screen capture under program control. Apple prefers to exercise tight control and grudgingly yields a bit to enterprises. It doesn't yield much to developers. (How do you like being a sharecropper on Apple's plantations?)
Seriously, there are good reasons to control screen capture. In the education space, we'd like to use iPads as secure testing devices. In a proctored test environment, the proctor can make sure a student doesn't have a camera or notepapers to carry away test questions. Therefore the major remaining risk to test item security is the screen capture. If you couldn't suppress it, students could quickly snap every test question they encounter and email them to their buddies (or post them online or sell them to a test-prep company).
For random consumer iPads used under uncontrolled conditions, developers don't have this capability. Them's the breaks :-).
No, there isn't. The user is always able to perform this function.
Yes, you can do this in at least two ways. Internet Testing Systems (ITS) of Baltimore has an iPad testing app in the store, interestingly it is "PEARSON NNAT2 -Stanford 10 - OLSATS", a Pearson app that can be used to take any of these three tests. see https://itunes.apple.com/us/app/pearson-nnat2-stanford10-olsat8/id546817211?mt=8 -- it is free and you can download it.
If you simply require your user to put the device into Guided Access mode after starting the app and before proceeding, using UIAccessibilityIsGuidedAccessEnabled(), you can then prevent the user from using "print screen" -- OR from switching to any other task. Examsoft is a vendor that uses this approach.
These features are generally of concern to test publishers and assessment delivery vendors; I have a blog post and screen shots the ITS approach, and code to emulate the Examsoft approach, here: http://mindstormtools.com/2013/02/23/ipads-for-assessment-test-delivery-profile/ and http://mindstormtools.com/2013/02/20/ipads-for-assessment-guided-access/
I have a iPhone app which needs to have a self destruct option. This app is going to be use on sensitive locations and holds some algorithms which are not to be known by anybody except the iPod Holder.
What would be the most "complete" way of deleting the app?
I was thinking of some how writing zeros to the nib file. or the actual application.app but I believe this folders are write protected and sandboxed.
Anybody have any ideas of better ways to achieve this?
Elaboration (Taken from original poster's comments):
This is for a jailbroken iPhone.
These devices are going to be provided to military personnel this device falling into enemy hands would be the least of my concerns. It's going to have a button so wipe the app once the app is written to zero or better yet corrupted with garbage all over the "exe" the app has no way of working and it would require inspection of the iPod flash chip with equipment that i 100% know the wrong people wont have
If you are openly storing the code that contains this algorithm within your application, there's nothing stopping the "wrong people" from jailbreaking the device and copying the complete file structure of the device before you run your "wipe" process.
Additionally, if you are dealing with a U.S. Government customer, I doubt that they will approve of the purchase of a jailbroken device, given that the vendor of such a device has claimed that jailbreaking is illegal. Whether or not this will hold up in court, the government tends to be conservative in these matters and err on the side of caution. Because Apple is a large U.S. company and a vendor to the government, I wouldn't expect the government procurers to take the jailbreakers' side in this.
My recommendation would be to encrypt the particular algorithms within a file in your application's bundle, and require the user of this application to decrypt this file into memory with the correct (difficult) password. That way, even if the "bad guys" were to gain access to the application, they wouldn't have everything they need to access these algorithms and would have to brute-force the password on the encrypted portion. This could be done on a standard, non-jailbroken device.
The U.S. Army is rolling out iPods in the field, with custom applications on them, so I'm sure that you're not the first person facing this challenge. If this work is being funded through a Department of Defense SBIR grant (or similar), you may even be able to contact your contracting officer and see if they can put you in touch with people at the appropriate agency who may be able to help you out with this (or even determine if it an issue to begin with).
I'm going to go out on a limb here and say you may not want to use the iphone for this type of app. There are intentional limitations to this exact type of action on the iphone and in springboard. If you are doing something so sensitive that it can't fall into unauthorized hands my recommendation would be to use a different and more customizable/controllable platform.
Unless you're working from a jailbroken device, you're probably going to run into problems here.
Even if you can find a way to automatically delete the app, you're still running the risk of those algorithms getting into the wrong hands - you would essentially be running into the same problems that Apple has with jailbreaking - once the device is in someone else's hands, it only takes the proper amount of motivation for the data to be accessed.
The only way to secure your algorithms is to pass the data to a remote server and get the results. There's still a possibility of a security breach, but it's much, much lower.
I don't know how well this would work, but you could store the algorithm as a file inside the application bundle, run the algorithm from that file possibly using a scripting language or something, and delete that file if you need to.
The folders are sandboxed, but your application is in there. On my jailbroken iPhone I see that all the permissions are owned by mobile so I don't see any reason why you can't just overwrite all the files with zeroes and then delete them.
The application bundle is effectively read-only, perhaps you should store some of the information in an encrypted form somewhere on a network.
Even if you find a way to write over the app in the flash memory, you really aren't erasing the app. Flash memory chips use wear leveling algorithms to reduce writes to the same blocks and so when you write out zeroes they are typically written to a new block of memory and not to the same block used before, so you really aren't erasing anything. The data can still be recovered from the flash chip (by a pro).
Another option is to separate out the parameters of the algorithm so that the algorithm is no longer sensitive (or at least not usable) and provide the parameters encrypted in a file. Then provide the key to authorized users via the network and don't store that key into flash, only RAM. They would need to get the key every time they start the app. Only give the key to authorized users. Of course, you'll also need to encrypt that key for transmission over the network with another key... There are systems for doing this, don't invent your own, in any case you'll need a crypto expert to do this right.
I would use the built in encryption to store the data, with a key the user has to enter to decrypt it. Without the key it doesn't matter if the data blob is recovered from the device.
A coworker displayed the route he used to commute to/from work on Google Earth
but won't tell me how he did it. I have a laptop with GE installed.
Can you tell me how to do this. I guess I need something to collect the coordinates,
and then create somesort of tracks but any pointers would be helpful.
Also, can this be done in real time. I nother words, can I update my location on
GE while driving?
You can drag and drop xml-files with coordinates onto GE. These files can be created with most GPS software/systems.
http://en.wikipedia.org/wiki/GPS_eXchange_Format
I just figured out how to do this. You will need a USB GPS Receiver. I also got a program called "Earth-Bridge" which allows generic USB GPS units to send their data in realtime to Google Earth.
Just install Earth Bridge, and then Install your Drivers for the USB receiver, and then plug in your Receiver and start Earth Bridge. The GPS will take about 45-60 seconds the first time to get a lock on your position but after that it is pretty good at staying up to date.
Since the GPS uses an internal serial to USB you have to deal with a virtual com port, just make sure you check your instructions on the USB and configure it correctly in Earth Bridge to use the right com Port, baud rate, etc...
Sometimes, the GPS shows me out in the ocean (or somewhere completely different from where I am) and I wait about a minute for it to lock on but it won't get a lock. Then there is a button on Earth Bridge "Reload in Google Earth" and it will usually fix it right away.
A good GPS receiver (the one I bought and love) is here on Amazon for about 38USD.
Google Earth speaks KML, or keyhole markup language. It is nothing more than an XML file with a specific schema.
from wikipedia: http://en.wikipedia.org/wiki/Keyhole_Markup_Language
You don't need an XML package to build it. you can just write out to a text file if you want to. You will still obviously need a GPS to pull the coords from.
you could even go so far as to write a blackberry app. to use its on-board GPS to do this. i've been contemplating doing this for a while to track my walks. my plan is to then automatically upload the tracklog to the web where i can view it later or my wife can view it real-time.
This is an old post, but I have been doing this with the MotionX-GPS iPhone app for years. You record & save a track on the app, and then email it to yourself. The email has an .KMZ attachment, which can open directly in Google Earth to display your track in glorious detail. I have a friend who has tracked all of his flight training with this. It's way Cool!