I am currently deploying to IOS, but plan to deploy to Android and other platforms down the road.
I need to know whether the system volume is turned off so that I can show a relevant icon on the screen.
Within Unity, is there a way to determine whether the system volume is muted?
I am not aware of Unity functionality that would allow you to do that (because AudioSource is tied to object, not to "application" itself) - but maybe there is some magical utility that allows you to do that. The problem is that even checking in pure iOS is not as easy as checking one property, since system itself does not indicate it, or at least it does not work for later version (iOS7, 8 - and possibly 9)
Anyway, I personally think that you have to resort to system specific implementation for both Android and iOS (and whatever you want to support). For iOS, there are great posts that go to great detail, I suggest you check them:
https://hoishing.wordpress.com/2014/05/08/mute-checking-in-ios7/
Detecting Silent Switch in iOS 7 issue
Hope it helps a little, though I guess I did not bring any good news :)
Related
So I know it's possible on a jailbroken iOS device to inject a dylib into a running process and interpose/hook system functions. I'm wondering if it's possible on a non-jailbroken device to interpose system functions at either link or run time, assuming I'm the one building the app? Maybe the equivalent on linux of using dlfcn and LD_PRELOAD?
An example: I want to take an app I've built that uses various Cocoa/Core Foundation abstractions for filesystem access and wrap the underlying open/read/write/close calls. I know about swizzling in Objective-C, but I'm looking for something at the libc level so I capture everything. This is for something test/debug related so it doesn't need to be App Store friendly. Thanks!
No, it's not possible (to my knowledge) on non-jailbroken iOS device. All traditional forms of dynamic loading (interposing, dlopen/dlsym, etc.) have been removed.
Since you mention that your needs are related to test/debug, you might want to try to make use of DTrace if your problem exists on simulator. You can use DTrace on simulator, but not on real iOS device.
I want to upgrade my existing apps to iOS 5.0 and above.
I want suggestions and detailed guide line for main points.
what changes I should make in my existing code to make it fully
compatible as new iOS coding standards.
For e.g.
Should I change all external frameworks and my custom classes
for making it compatible for ARC?
I should make changes into sqlite database creation.
Should I replace old framework of Twitter & Facebook?
What kind of changes I should do with Graphics?
In-short, Please provide guideline and suggestion that are important for making older app fully compatible with New iOS standards.
Guys thanks for providing your comments & reply for this question.
By Looking at your response, I think you guys are only focusing on the
above given points. I want general suggestions from your experience.
i.e. what things we should change in info.plist, what changes should
be done in graphics. how we can improve app by adding automatic ARC
support etc ...
Main thing is how we can make it compatible for different resolutions
of iPhone / iPad (i.e. for iPhone 5 and other devices).
If possible then please provide graphics changes guidelines with
resolution for new iPhone 5 Device and iPad Mini Device.
Your help / suggestions / Guidelines will be greatly appreciated!
Should I change all external frameworks and my custom classes for making it compatible for ARC?
It depends entirely upon you. ARC is a compile-time feature that is meant to obviate the task of manual memory management. It doesn't eliminate it by any stretch of the imagination, but it is miles safer than anything we as programmers could ever hope to write most of the time. It is possible to mix ARC and non-ARC frameworks and libraries in an application.
I should make changes into sqlite database creation.
iOS has always shipped with libSQLite3, so there is absolutely no work required for you to "upgrade" this aspect of your application. You might consider a move to core data, if only because again, it obviates large portions of interfacing with SQLite.
Should I replace old framework of Twitter & Facebook?
Again, it depends. If you plan on supporting older OSes which do not come with the new iOS social features and frameworks, then I'd leave it as is. The new API is far more limiting than accessing the actual API for each of the given social services, but it is also far easier to implement, especially for things like simple wall posts.
What kind of changes I should do with Graphics?
Graphics files must (optimally) come in 2 flavors with an optional third format for the new iPhone: standard, retina, and stretched retina. While opting into retina-graphics is completely optional, it is recommended that you provide high-resolution assets to provide the best user experience. In regards to the actual graphics library (CoreGraphics), the framework handles the scaling of elements drawn to the screen.
- Should I change all external frameworks and my custom classes for making it compatible for ARC?
If your frameworks are out dated then, YES you need to update it so
its compatible for iOS 5 and above. For ARC, its not necessary. If you
don't wanted to handle memory management then you can.
- Should I replace old framework of Twitter & Facebook?
YES please.
- What kind of changes I should do with Graphics?
You need to change graphics for ratina display. Google about it.
I have this idea of writing an application to automatically sync files to a specific place for an ipad every time the ipad is plugged in the computer.
The problem is I've never developed a software like this before. Right now I have these two big questions:
- How to detect when an ipad is plugged in the computer?
- How to connect to and copy files over the ipad?
To make things clear, the application I want to develop should have similar functions like iTools (not iTunes).
Does anyone here have experiences in developing this kind of application? Would you please share with me how to start with this project, because I'm clueless :(
There is a rather simple option; use a internet based service to accomplish this task - just as DropBox, iCloud and similar services do it already. Maybe you can get a lot closer to your goals by simply connecting to the API of DropBox, SugarSync or alike.
Using a direct (USB-) connection to the device will be rather tough to implement and, to my knowledge, will prevent you from selling the resulting software through Apple's channels. I am not saying that it was impossible (see iExplorer) but I am saying that such endeavor will involve a lot of reverse engineering of undocumented functions to a degree that might be considered illegal in certain countries. Additionally, maintaining such software will be very demanding as Apple frequently introduces changes within their communication protocol/s.
It's a great thing that it's possible to compile an SWF into iOS native app. I think AIR is now the best option to write e.g. small games or interactive books. Of cause AIR app will be slowler than the same app written on e.g. objective C. The question is how slower AIR app will be. Can simple AIR apps be launched e.g. on iPhone 3G or iPAd 1?
And another question is, can arbitrary flash app be compiled into iOS native app?
Will be grateful for any thoughts!!!!!
Performance of AIR vs. Objective C:
For pure script execution, AIR apps perform rather slower than native, including on iOS. However, in virtually all cases the limiting factor of your app's performance will be rendering, not script, so it depends entirely on what you do visually in your content. This is why Crooksy suggested you look at Starling. Without Starling (or similar libraries that make use of the GPU), it's pretty challenging to get decent performance out of an iPad1. It can be done, but it takes expertise and incurs extra work. It will be much better to start with the huge performance boost of using Starling or similar.
Can arbitrary flash app be compiled into iOS native app?
As long as it's made with AS3, then it should compile. For whether it works, two main caveats come to mind: First, a handful of APIs don't work on mobile devices. (I think printing is one example.) Second, if you read in any SWFs at runtime, all actionscript inside them will be ignored. (Not for technical reasons, it's an Apple requirement.) So if your content is split into a bunch of SWFs you'll need to bundle them together at packaging time, and if you absolutely depend on reading in SWFs with script from the network at runtime, you're going to hit a wall.
Hope that helps!
Check out the new Starling frame work.
http://gamua.com/
Here's the start of a nice tutorial series (episodes 1 and 2)
http://www.hsharma.com/tutorials/
Lee Brimelow also has a few tutorials
http://www.gotoandlearn.com/
Regarding converting Flash apps into iOS compatible apps, yes that is possible but it depends on what the app actually does as to whether any modifications will be needed before it will perform correctly on a device.
While I understand that in order for an iPhone application to be accepted on the App Store, one requirement is that only documented libraries are to be used.
If this is the case, how are certain applications such as "Night Camera" and "Camera Plus" using a camera control that seems to be something other than the one contained within UIImagePickerController?
I have heard of certain cases where a developer has been given "special" access to certain headers that allow for features that would otherwise be impossible if constrained to only using documented libraries. However, given how opaque the application selection process is for the App Store, I would prefer to stick to what is recommended rather than take my chances.
Anyone care to shed some more light on this?
Have you seen this dicussion?
http://blog.airsource.co.uk/index.php/2008/11/11/views-of-uiimagepickercontroller/
and this sample code for a custom picker?
http://www.codza.com/custom-uiimagepickercontroller-camera-view
hope it helps.
You might want to check out a classdump of apple's private framework headers. Run this perl script:
http://arstechnica.com/apple/news/2008/11/dumping-the-iphone-2-2-frameworks.ars
and navigate to the PhotoLibrary directory under PrivateFrameworks. Some of the classes in here look pretty promising for direct camera access.
Using the undocumented API could hurt your chances of passing through the app store, but it's all very subjective - If your product is good, apple will probably let it slide through. I'd recommend making friends with a developer evangelist at Apple.
The UIImagePickerController is a UIViewController subclass that manages a view hierarchy. You are free to play around with the view hierarchy, as those apps are, but it is risky considering that Apple does not document it and could change it on any OS update.
I have not heard of anyone being given special access to libraries, but I have read that there is a minor distinction between undocumented classes and methods and private frameworks. Undocumented classes are a gray area, but private frameworks are definitely not allowed.
The simple explanation is that apps in the store are not supposed to use unsupported APIs, but this is not checked consistently. The apps you mentioned are either using unsupported functions/classes/methods or else are playing with the view hierarchy-- which is itself undocumented even though it can be done with standard APIs.
You could do what they do, and take your chances with it. Just be aware of the risks. Your app might (a) be rejected from the store, (b) be accepted but later booted (this has happened for unsupported API use), (c) be accepted and not booted but break the next time Apple has a new iPhone software update (since unsupported APIs or view hierarchies can change without warning). Or you could get lucky and have none of this happen.