The following pertains to the RIM BlackBerry API.
If your app has a memory resident portion and, optionally, a UI portion, and the user downloads an update OTA, the system will, correctly, tell the user that a device reboot is needed in order to fully install the application.
The user then has the option to say "no thanks, I'll restart later when it's more convenient for me".
At this point, the app running is still the older version, and will remain so until a reboot, which can occur hours or days later.
The question is, if the app is of the design where, if a new version is available, it's not "healthy" for the old version to be running (for example, in a situation where the data exchange format has changed between the client/server portion of the app), how do you programatically determine if the device is in this "reboot pending" state so that when the user attempts to continue to use the older version of the software, you can display a warning to the effect that a reboot is still required, and disallow further use of the old version until the reboot takes effect.
It would be preferable if the solution, if one exists, is RIM OS 4.1+, but it would be understandable if there's a new API call somewhere in RIM 4.5+ that I'm not aware of.
as far as I know there is no way to check if the device is in a "reboot-pending" state.
But you can use the MODULE_FLAG_DELETE Flag to check if the module is scheduled for a deletion. The Reboot does nothing else than to delete the old module and insert the new one.
Good Luck,
rAyt
Related
I made an app deployed internally at my company. It is placed outside conference rooms and allows the user to see if it's open, schedule room time, view other rooms, etc. Given its nature and use, the app is always the active one on the device and is placed into guided access mode to prevent passers-by from playing around with it. However, the update process is rather tedious since despite our MDM solution, we have to go around and take each device individually out of guided access mode in order for the app to be updated. I've been looking into supervised mode for each device (using the Apple Configurator tool), but I wanted to ask if there was anyone here with experience trying this who could point me in the right direction in case that idea doesn't bare fruit. Is there perhaps a way to trigger the app (and guided access) to close remotely and open, also remotely, once updated? Naturally, this would go against Apple's guidelines, but this app will never touch the app store, so any solution at all is feasible. I saw a few answers on this site from over two years ago saying it isn't possible, but perhaps something has changed to allow this possibility between then and now seeing as so much has changed around deployment in the past few years.
I would do something like that:
Have a device in supervised mode
Set Guided mode through configuration profile (rather than manually doing it). App Lock payload does that.
And when you need to upgrade the app:
Try to upgrade it without disabling guided mode. As I remember, you can install applications silently on a supervised device. So, there is a chance that it will upgrade it and restart it (because of Guided mode) after that.
If it won't restart the app on upgrade try following:
Remove App Lock profile
Upgrade app
Install App Lock profile again
This should work.
We need to test our app in the context of an iOS upgrade (e.g., 5.1 -> 6.0). Unfortunately, Apple doesn't allow downgrading devices. We thought of doing it in the simulator, but different versions of the simulator are different environments in themselves. I think we can copy the bundle from one simulator to the other, but that won't migrate the keychain (will it?).
Thanks!
To test a transition from one state (before) to another (after), you need a way to put the app in the before state.
Your app surely won't be running while the OS is being updated, so you really only need to worry about the app starting up and discovering that the OS has been updated. There are a couple options:
Copy all your app's data files from a device running the "old" iOS version (5.1 according to your question) to a device running the new (6.0) version. The organizer in Xcode will let you easily copy your app's "container" from a device to your Mac or vice versa.
Make your app write it's data in the "old" format. It's not uncommon for an app to have methods for reading and writing data in different formats depending on the environment, so it's often easier to get your app to write data out in the old format than to actually copy from an old device.
Whichever path you choose, think about any other places (like user defaults) where you might made OS version-dependent changes and set those back to values that correspond to the previous OS. This applies especially to keychain items, which aren't stored in your app's sandbox.
Unit testing frameworks (like Apple's XCTest framework) generally have a setup mechanism that you could use to reset your app to the before state, including copying files, adding and removing keychain items, setting defaults items, etc. You can then add unit tests that run whatever code might be involved in an update and test the results. With a set of easily repeatable tests you'll be able to debug any problems more easily.
However you approach it, the goal is to put the app in the same state that it would be in if it were running for the first time after an OS update occurred. You don't have to worry about simulating the actual OS update, you only need to trick the app into thinking that the update has just happened.
For now, you can still install iOS 8.2. When a new version is released, Apple leaves both versions open for installation for a short time. While that "signing window" is open you can upgrade a device, test, and then restore it from an image of the older version. So you could do some intensive testing while the window is open, but obviously that's not a long-term solution (it typically lasts only a few days).
If you have the budget for it, you could install 8.2 on a device, put a big sticker on it saying "do not upgrade", and keep it on 8.2 for as long as it's relevant. Install your app on that device and take a backup (with backup encryption enabled so that keychain entries will be included), then restore that backup to another device that's on 8.3 - this is basically the same procedure you'll go through when doing an upgrade/restore through iTunes so it should be pretty close. It won't be exactly the same as an OTA update on-device of course, but for that, see option 1 above (and see it soon).
I want to know if there's any trouble in creating a version control on my iOS app, because I'm going to make some huge upgrades in my webservices code and don't want that any user try to access the old version and the app crashes or don't work properly.
My idea is to create a service that capture the app version and than, if its an old version, the user can't access the app until the new version is installed.
I know that some android apps do this, but I didn't find any iOS app with this control.
Thanks!
Your app has a version, and you're writing the web service, so I don't see why you couldn't have your web service check the version and respond with a message that tells the app to show a message asking the user to upgrade.
That said, it would be much, much nicer for your users if you design the web service so that it detects the app version and then provides appropriate functionality for whichever version the user has. You might not want to continue support for the older version forever, but your users would probably appreciate having some time to upgrade when they choose to rather than when your app forces them to.
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.
I've been experiencing unexplained connection issues with my BB app. This only happens on a Curve 8520, and only on some of them. There is no noticeable pattern so i cant determine what causes it. The app prompts me to check my internet connection even though all other apps / browsers are working fine.
The only solution is to do a manual hard restart after installation. This solved the problem and the app runs seamlessly 100% of the time.
Is there a way to prompt the user to restart the phone after initial installation has been completed? Ex. Like some RIM products, after you've installed it prompts you to restart now or later, if you select yes it does a complete / hard restart.
AFAIK when a BlackBerry application is set "Run on startup" it runs automatically as it is installed.
And you may use requestPowerOff method of Device class to turn the device off and automatically turn it on (this is controlled by the method parameter).