I was wondering if anyone knew how iSimulate automatically registers/hooks itself into a debugged iDevice application? It's as simple as including the static library (and a couple of frameworks) and it just works. There are no methods or functions to call. How is this possible?
Short answer: using categories in Objective-C, you can extend or augment any class in the system, including core classes and NSObject itself. (Similar to "monkey patching" in Ruby for example.)
The actual communication is most likely a broadcast, sending packages that don't expect to get an answer back. When you start your app, it just starts intercepting these packages. So it's the simulator app that hooks into the iSimulate stream, rather than iSimulate somehow "reaching into" your app.
Have a look at the open source accelerometer simulator project. You could easily extend it to broadcast touches too, and basically duplicate what iSimulate does. And you learn about the nifty side of Objective-C.
Related
I agree that this question is duplicate. Please bear with me. I was also among you all to believe that is not possible to programatically turn on/off bluetooth.
But using GKPeerPickerController if bluetooth is not on user will be prompted to turn it on. Fair enough to turn on the bluetooth.
I was betting with my belief that we can not turn off the bluetooth programatically as there is no way. But this application does that so I didn't had choice to refuse.
I just want to confirm whether it is possible or not and if yes how to turn off the bluetooth using GKPeerPickerController or any other public api way ?
I know this isn't the answer you want, but no, you can't turn off bluetooth programmatically with Apple-approved APIs.
There have been a number of apps approved on the App Store this year that have done this.
But, they keep getting removed by Apple shortly after release, once they (Apple) realize what's going on. They're certainly using private APIs.
Either developers are foolish enough to think that they won't be noticed, or they are simply hoping to pull in a couple weeks of revenue before Apple pulls the app, which could be enough to pay back their cost, with some profit.
The issue is that there's a number of ways to check whether an app is using private APIs. If developers are using objective-C frameworks in the normal way, that's an easy check. In fact, Xcode does some of this automatically when you use it to upload app binaries to iTunes Connect. But, it's not a complete check. Once at Apple, the reviewers perform another check, which I've been able to deduce is more sophisticated than what Xcode does.
However, that check is still not perfect, and I'm of the opinion that it's not necessarily a matter of a lazy reviewer just forgetting to perform the check. Objective-C gives you some techniques for obfuscating method calls. Depending on how you use these techniques, you might get past the reviewers . In my experience, I have every reason (wink, wink) to believe that Apple is not running every app on a fully instrumented version of iOS, which could log all function calls, and defeat even the best attempt to hide private API usage via obfuscation techniques.
So, I can pretty much guarantee you that this explains the apps you've found on the App Store that turn off Bluetooth. Public GameKit APIs let you turn Bluetooth on, but not off.
Disclaimer: I've never worked for Apple, and no Apple insiders gave me information. But, I have gotten private APIs through the review process.
Please try below code and I think it will also work for you.
Class BluetoothManagerClass = objc_getClass( "BluetoothManager" );
BluetoothManager *btCont; = [BluetoothManagerClass sharedInstance];
[btCont setPowered:NO];
You need to add BluetoothManager class/framework in your project.
Thanks
I am writing an iPhone app, and I have a remote server that will deliver content. I would like to have my app poll the server once per day to see if there is new content, even if it's not running or in the background. I would also like to do this without setting up an APNS. Any advice?
You can't do that, either when your 'not' running or if you are running in the background. The best you could do is to download once per day when your app is first run / pushed to the foreground.
You could use remote notifications to "prompt" the user to bring the app to the foreground so that it could download something?
With the current apple IOS guidelines, that is about the best you can do.
I read that you are trying to avoid using APNS, but I am wondering if you are trying to avoid it for the right reasons, especially when it is designed to efficiently solve the scenario you are describing. I've seen many developers seek alternative solutions to APNS simply because the technology appeared to be complex to use after looking at Apple's documentation. The online documentation does go into a lot of details, right down to the binary protocol level.
But just to be sure you know, there are open-source libraries whose only purpose is to shield you from all these technical details. Some libraries are more complex than others, but some are remarkably user-friendly. If you have not done so already, you might like to take a look at JavaPNS and other similar projects.
I've worked on several iPhone applications which all require some subset of the same services: RemoteIO audio, GPS, push notifications, face sensor activation, idle timeout disabling, etc, etc. The application delegate callback methods become bloated with all of this initialization code which is slightly different in each app.
So my question is: is there a library for handling all this? Some system that lets me say, "this app uses services A, B, and C, and they should launch in this order"? The services would be defined so that they'll automatically get the application lifecycle callbacks they need, like the application going into the background, audio interruptions, etc.
This is pretty ill-defined, which is why I'm hesitant to write this code yet. If someone else has solved the problem then I can avoid duplicating all of the mistakes they made on their approach to a solution.
The only one i could think of would be three20, but not sure if that isn't a bit too much. ( check http://api.three20.info/annotated.php)
I want to add something (eg. the related city name) into the UI view when I make a phone call or received a phone call on iPhone. However, I can't figure out a good solution for this idea. Could anyone who has experience on this subject gives me some suggestions?
My currently solution is, try to write an extension based on mobile substrate and hook functions in SpringBoard. So many difficulties existed and following are my current big questions,
How to develop such a extension? I downloaded some examples from google, unfortunately they cann't even be compiled on my toolchain.
I can't figure out which ui view for the related screen I should use to insert my own component. I get header files of SpringBoard via class-dump, but no docs and no comments about its usage. Could someone share his discoveries with me?
How to build a trusted cross-compiling enviroment on leopard? All kinds of confusing errors pop up when I try to build others's codes. I've tried Zdziarski's instrunctions in his book, it works with iPhone OS 1 and can compile common projects with open sdk, but how should I do to make it works when comipiling ms plugins?
Also, is there any other solution to translate my ideas to codes? I start iPhone development one month ago, no experience with cocoa/Obj-C before. So your suggestions are very appriciated.
~ Link Bian (卞林扣)
Email/MSN: linkou.bian#gmail.com
I think you are asking for too much. It wont be possible to manipulate incoming/outgoing call screens. Ethically, that is.
Zdziarski is a hacker and from his book, you will get many undocumented API calls which will make Apple reject your app. Same goes for Erica Sadun's iPhone Developer's Cookbook.
Something that really helped me get dylibs compiled was using SkylarEC's Xcode template and just appended an extension of '.dylib' onto the binary and sshing it into /Library/MobileSubstrate/DynamicLibraries. I suggest hooking SBCallAlert or SBCallAlertDisplay to get the id of the caller which is usually just an NSString. Play around with it a little bit, those are all the visualizing methods of a call. If you put in an nslog in your custom override method, you can view the output in iPhoneConfgurationUtilitie (windows) or the console in Xcode. From there you would most likley need an index of area codes to comare the callers to. I don't believe you can add subviews to the call, on I intercept and reissue the strings for the views already there.
But you know, apple doesn't like this :P
lemme know if this helps
I'd much rather code an app using pure C api such as OpenGL, rather that Cocoa Touch. So I'm wondering: is it feasible? Will I be able to maintain the same user experience that you get with Interface Builder?
None of the UI components have OpenGL equivalents. Is it possible? Yes. Is it sensible? No - you would be much better off learning how to use IB and the UIView classes. Coding the UI in OpenGL would be like painting your house with an artist's brush, using hand-made paint instead of Dulux.
Unless you are working on a game, users will expect your user interface widgets to work the same way they do in other applications. You can never emulate that properly, especially if apple decides to fix certain issues in future firmware upgrades, etc...
You will also need Cocoa for integrating with the system in general to store data, prefs and so forth. Is there any specific reason for your reluctance to use Cocoa? If it's because you feel an aversion to learning objective-c, then you really ought to give it a proper chance. It's a great language for building ui apps. If you are trying to port an existing app, then I would suggest building a wrapper that will interact properly with the iphone and call your c code from there.
This is not a fruitful answer (for that, see AirSource's) and rather a comment on your answer about not using Objective-C, but I learned Objective-C a few months after C# and I find I work well in both. Give it a chance and it will surprise you. There's a learning curve and they are different, but the interface tools in particular are so far ahead that you'll probably find it worth your while. It will definitely be better for you and for your app's users than hand-rolling it in OpenGL.
Depends on your app. Mine's an "immersive" game, so I'm using openGL
instead of CocoaTouch,
with a sprinkling of Core Graphics/UIKit calls to generate nice textures.
If I had to display any kind of standard, non-trivial widget, I'd use CocoaTouch.