I want to know how to make an iOS application run at startup.
I've encountered the method of UIBackgroundModes, but it isn't relevant anymore and required compiling with an older SDK.
Also I've read about the PushKit framework, but it seems to be that the application will be launched upon an event occurrence and not pro-actively.
Is there any way to make the application run at system startup pro-actively (not as a response to some event occurrence) ?
Related
I have a iOS App created with React-Native that includes a Unity app that may be opened and closed several times during the use of the React-Native app.
The Unity app has a Photon Pun. All works very well the first time we open the Unity app.
But the Photon Pun does not connect properly to the master server the second time one opens Unity within the same process.
I figured out that the internal class PhotonHandler gets started and enabled when we first start Unity. It gets disabled when we stop Unity. But then it never enables again. The problem is maybe that the enabling happens through the constructor of PhotonNetwork. This is the stack trace:
Photon.Pun.PhotonHandler:OnEnable()
UnityEngine.GameObject:AddComponent()
Photon.Pun.PhotonHandler:get_Instance()
Photon.Pun.PhotonNetwork:StaticReset()
Photon.Pun.PhotonNetwork:.cctor()
PhotonManager:OnEnable()
Components get added and enabled in constructors and disabled when we run unloadApplication. But many game objects then remain disabled when we start Unity again because all instances are already created.
How can I enable them again?
A little bit of background
Unity is exported for iOS, built and the resulting UnityFramework is embedded into the iOS app.
We then start unity using unityFramework.runEmbedded(withArgc: CommandLine.argc, argv: CommandLine.unsafeArgv, appLaunchOpts: [:])
How we solved it on android
On Android we are able to start unity in a separate process and then completely kill this process while the main app keeps running. The problem disappeared there as soon as we did that.
I am happy for every little hint.
I was wonder if possible to keep the app always rescue from backgroud? I am use an app writed using flutter in iOS, sometimes when I switched this app to the background, when next use it, will open a fresh state and lost the last state. is it possible to make the app always could keep the last state except exit app by user. So that the app would keep all the state of the last seem by the user.
You cannot prevent the operating system from killing your app. iOS kills apps to increase battery life and to free memory.
What you can do is to store some state to the file system with packages like shared_preferences or hive.
If you are using BLoC, you might also find the hydrated_bloc package useful.
I'm currently working on a location based Cordova + Meteor (iOS) mobile-app, where I need to keep an eye on the user's location, even when the app is terminated.
For this I have tried to implement the cordova-background-geolocation-lt plugin, but I'm having issues: https://github.com/transistorsoft/cordova-background-geolocation-lt/issues/221
Because of this I am thinking of writing my own native (obj-c/swift) plugin (partly using code from this answer) that will get user's location and send it to the server.
My question is:
From this answer:
When iOS wants to return the location update to the app, it will help you to relaunch the app and return a key UIApplicationLaunchOptionsLocationKey to the app delegate method didFinishLaunchingWithOptions.
When app is killed/terminated/suspended - Is it possible to relaunch only part of the Cordova app - only native code that is responsible for background geolocation tracking and posting it to the server without fully relaunch the whole app - JS part & Meteor part?
There is an Apple article here about background tasks: https://developer.apple.com/library/content/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html
Meteor generates the IOS code, but you can use XCode to modify the project and code somewhat, or I think you are correct in your approach to creating a plugin, because then you are in the native environment and can do these things.
I was able to succesfully use this plugin in my Meteor + Cordova project after resolving this issue: https://github.com/transistorsoft/cordova-background-geolocation-lt/issues/221 . It turned out that this issue was due to the Meteor's local server suspension after the app enters background state. It is specific to the Meteor-Cordova projects
One of the benefits of Appium is that I can run tests against the app without compiling in any instrumentation. But, there's a feature I want to turn off in my app when Appium is the user.
How can Appium can send information directly to the app, to tell it that Appium is driving? This needs to happen shortly after launch, so hiding a secret switch somewhere is not a good option.
You can use the processArguments capability to pass application launch arguments through Appium to your application. Inside your application you can read the launch arguments and values using NSUserDefaults.
I have a very unreasonable requirement from my overlord.
I developed a little application in JavaME. It is OK.
He is testing the app in different models of the BlackBerry. In some models, after the installation of the .jad, the phone ask for re-boot, in others, you could use the app just after the installation.
As a new requirement the app must be functional without re-booting.
Could you tell me how to do this? and with which code of JavaME? Have not found any relevant information (in code) about it.
Notice that the app is developed with Java and NOT with the BB SDK. Even more, I don't know the architecture of the BB's to see why in some cases it needs re-booting (neither the architecture of the other mobiles that work with JavaME!!).
If the application has not been installed on a device previously (or the device has been rebooted after the application has been removed) then you should not have to reboot after installation. There are a number of reasons why removal or replacement of (upgrading) an application will require a reboot. They all boil down to the OS has only one instance of the JVM and it is still holding references to objects that are defined in the application.
A very simple application that has not run since the last garbage collection may be replaced without rebooting. Any application that registers a listener or other objects with the the OS, or runs in the background will usually require a reboot.
To test what a new customer would experience having never used your application before try this:
If the application is installed on the device, remove it.
If the device does not reboot, reboot it (Alt-Caps-Del or battery pull).
Once it has finished restarting install the application.