Is there an exit routine that will be called by the runtime every time a blackberry app signals that it wants to exit, similar to MIDlet.destroyApp(boolean) for traditional midlets?
If none exists, how do you ensure for instance that a particular task gets executed just before a blackberry app exits?
I think you are looking for onClose() method
public class MyMainScreen extends MainScreen {
public MyMainScreen() {
super();
}
public boolean onClose() {
// Your code here
}
}
public boolean onClose()
Indicates a close event has occurred.
The default implementation is
activated by specifying DEFAULT_CLOSE.
It will call onSavePrompt if the
screen is dirty, then call close() if
sucessful.
Related
I am trying to create a Xamarin.Forms app that will run on both iOS and Android. Eventually I need instances of the app to communicate with each other via Bluetooth, but I'm stuck on getting the iOS side to do anything with Bluetooth. I originally tried to work with Plugin.BluetoothLE and Plugin.BLE, but after a week and a half I was not able to get advertising or scanning to work on either OS with either plugin, so I decided to try implementing simple Bluetooth interaction using the .NET wrappers of the platform APIs, which at least are well documented. I did get scanning to work fine on the Android side. With iOS, though, what I have right now builds just fine, and runs on my iPad without errors, but the DiscoveredPeripheral handler is never called, even though the iPad is just a few inches from the Android tablet and presumably should be able to see the same devices. I have verified this by setting a breakpoint in that method, which is never reached; and when I open the Bluetooth Settings on the iPad to make it discoverable the app version on the Android tablet can see it, so I don't think it's an iPad hardware issue.
It seems obvious that there is simply some part of the process I don't know to do, but it's not obvious (to me) where else to look to find out what it is. Here is the code for the class that interacts with the CBCentralManager (as far as I understand from what I've read, this should include everything necessary to return a list of peripherals):
using MyBluetoothApp.Shared; // for the interfaces and constants
using CoreBluetooth;
using System;
using System.Collections.Generic;
using System.Threading.Tasks;
using Xamarin.Forms;
[assembly: Dependency(typeof(MyBluetoothApp.iOS.PeripheralScanner))]
namespace MyBluetoothApp.iOS
{
public class PeripheralScanner : IPeripheralScanner
{
private readonly CBCentralManager manager;
private List<IPeripheral> foundPeripherals;
public PeripheralScanner()
{
this.foundPeripherals = new List<IPeripheral>();
this.manager = new CBCentralManager();
this.manager.DiscoveredPeripheral += this.DiscoveredPeripheral;
this.manager.UpdatedState += this.UpdatedState;
}
public async Task<List<IPeripheral>> ScanForService(string serviceUuid)
{
return await this.ScanForService(serviceUuid, BluetoothConstants.DEFAULT_SCAN_TIMEOUT);
}
public async Task<List<IPeripheral>> ScanForService(string serviceUuid, int duration)
{
CBUUID uuid = CBUUID.FromString(serviceUuid);
//this.manager.ScanForPeripherals(uuid);
this.manager.ScanForPeripherals((CBUUID)null); // For now I'd be happy to see ANY peripherals
await Task.Delay(duration);
this.manager.StopScan();
return this.foundPeripherals;
}
private void DiscoveredPeripheral(object sender, CBDiscoveredPeripheralEventArgs args)
{
this.foundPeripherals.Add(new CPeripheral(args.Peripheral));
}
private void UpdatedState(object sender, EventArgs args)
{
CBCentralManagerState state = ((CBCentralManager)sender).State;
if (CBCentralManagerState.PoweredOn != state)
{
throw new Exception(state.ToString());
}
}
}
}
Can anyone point me in the direction of understanding what I'm missing?
EDIT: O...K, I've discovered quite by accident that if I do this in the shared code:
IPeripheralScanner scanner = DependencyService.Get<IPeripheralScanner>();
List<IPeripheral> foundPeripherals = await scanner.ScanForService(BluetoothConstants.VITL_SERVICE_UUID);
twice in a row, it works the second time. I feel both more hopeful and much more confused.
The underlying problem was that in the first instantiation of PeripheralScanner, ScanForService was being called before State was updated. I tried many ways of waiting for that event to be raised so I could be sure the state was PoweredOn, but nothing seemed to work; polling loops simply never reached the desired state, but if I threw an Exception in the UpdatedState handler it was thrown within milliseconds of launch and the state at that time was always PoweredOn. (Breakpoints in that handler caused the debugging to freeze with the output Resolved pending breakpoint, which not even the VS team seems to be able to explain).
Reading some of the Apple developer blogs I found that this situation is most often avoided by having the desired action occur within the UpdatedState handler. It finally soaked into my thick head that I was never seeing any effects from that handler running because the event was being raised and handled on a different thread. I really need to pass the service UUID to the scanning logic, and to interact with a generic List that I can return from ScanForService, so just moving it all to the handler didn't seem like a promising direction. So I created a singleton for flagging the state:
internal sealed class ManagerState // .NET makes singletons easy - Lazy<T> FTW
{
private static readonly Lazy<ManagerState> lazy = new Lazy<ManagerState>(() => new ManagerState());
internal static ManagerState Instance { get { return ManagerState.lazy.Value; } }
internal bool IsPoweredOn { get; set; }
private ManagerState()
{
this.IsPoweredOn = false;
}
}
and update it in the handler:
private void updatedState(object sender, EventArgs args)
{
ManagerState.Instance.IsPoweredOn = CBCentralManagerState.PoweredOn == ((CBCentralManager) sender).State;
}
then poll that at the beginning of ScanForService (in a separate thread each time because, again, I will not see the updates in my base thread):
while (false == await Task.Run(() => ManagerState.Instance.IsPoweredOn)) { }
I'm not at all sure this is the best solution, but it does work, at least in my case. I guess I could move the logic to the handler and create a fancier singleton class for moving all the state back and forth, but that doesn't feel as good to me.
According to AppCenter's instructions when adding crash reporting and analytics to a Xamarin Android app:
Inside your app’s MainActivity.cs, add the following using statements.
using Microsoft.AppCenter;
using Microsoft.AppCenter.Analytics;
using Microsoft.AppCenter.Crashes;
In the same file, add the following in the OnCreate() method.
AppCenter.Start("xxxx-xxxx-xxxx-xxxx-xxxx",
typeof(Analytics), typeof(Crashes));
However, I have a splash activity that runs before MainActivity that is prone to crashing - and the crashes won't get reported if the splash activity crashes before MainActivity gets the change to start and call AppCenter.Start.
So I also added AppCenter.Start to the start of SplashActivity. Does this mean I should remove AppCenter.Start from MainActivity in case I am starting multiple instances? Or are AppCenter instances separate to each activity and I need to add AppCenter.Start to every activity in the project (e.g. including my settings page activity)?
Add a new class and inherit it from the Application class something like below:
#if DEBUG
[Application(Debuggable=true)]
#else
[Application(Debuggable = false)]
#endif
public class MainApp : Application
{
public MainApp(IntPtr javaReference, JniHandleOwnership transfer) : base(javaReference, transfer)
{
}
public override void OnCreate()
{
base.OnCreate();
}
}
Override the OnCreate method, now this method will be executed every time an activities OnCreate method is executed.
So you can simply add the crash analytics code here something like:
public override void OnCreate()
{
base.OnCreate();
AppCenter.Start("xxxx-xxxx-xxxx-xxxx-xxxx",
typeof(Analytics), typeof(Crashes));
}
I am working with 2 resolutions one touchScreen and other Non- touch
i have designed a Screen which has 10 custombuttons are added to a VerticalFieldManager
The CustomButtonField class extends Field class
i have used 2 methods fieldChange() and touchEvent() for touchScreens
the problem is whenever i do click on button it gets activated correctly for touchevent()
but then the fieldChange() method also gets called immediately afterwards
what should i do??
what's the problem ??
Check the answers of the question BlackBerry touchEvent outside Field triggers fieldChanged provided by Paul Sylliboy and Arhimed.
In those answers, there was a method which only updates a boolean variable to identify that a touch event occured, and based on the value of that boolean an action is executed on the fieldChanged or navigationClick method.
BB UI Framework calls navigationClick(int status, int time)
automatically if there is any touch event after execution of
protected boolean touchEvent(TouchEvent message). And
navigationClick(int status, int time) calls the method
fieldChangeNotify(0) which causes fieldChange() (in the question)
or public void fieldChanged(Field field, int context) to be called.
EDIT: Using simpler code.
I have a blackberry app that until recently (I upgraded to 6.0.0.600 on my torch) could be deleted. Now I can't even if I use javaloader -u erase (module in use) and the UI context menu or physical menu has no option for delete. The code below just requires an app descriptor with an alternate entry point on startup with parameters "startVibrate". The entry points code is below.
package mypackage;
import net.rim.device.api.system.Alert;
import net.rim.device.api.system.ApplicationDescriptor;
import net.rim.device.api.system.ApplicationManager;
import net.rim.device.api.ui.container.MainScreen;
import net.rim.device.api.ui.UiApplication;
/**
* This class extends the UiApplication class, providing a
* graphical user interface.
*/
public class ScheduleAppDemo extends UiApplication
{
public static void main(String[] args)
{
if (args != null && args.length > 0 && "startVibrate".equals(args[0]))
{
scheduleVibrate();
}
else
{
ScheduleAppDemo app = new ScheduleAppDemo();
app.enterEventDispatcher();
}
}
public ScheduleAppDemo()
{
ScheduleAppDemoScreen screen = new ScheduleAppDemoScreen();
pushScreen(screen);
}
public class ScheduleAppDemoScreen extends MainScreen
{
public ScheduleAppDemoScreen()
{
setTitle("Schedule app demo");
}
}
private static void scheduleVibrate()
{
Alert.startVibrate(2550);
ApplicationDescriptor current = ApplicationDescriptor.
currentApplicationDescriptor();
current.setPowerOnBehavior(ApplicationDescriptor.DO_NOT_POWER_ON);
ApplicationManager manager = ApplicationManager.getApplicationManager();
manager.scheduleApplication(current, System.currentTimeMillis()
+ 60000, true);
}
}
Basically what this shows you is that it vibrates every minute. Unfortunately evidence says it appears the Application Manager keeps the background process running during the time and then just calls it again when it's time to run occurs again. This is the sample app from RIM. Deleting all Alternate Entry Points in the Application descriptor.xml allows the app to be deleted. Other than modifying that, reloading the cods, and then deleting it; how can I delete the app.
The behavior is 'correct', in as far as this is exactly how an application with an alternate entry point would behave in the field.
When an application has an alternate entry point, deleting it only marks it for deletion. The actual deletion occurs when the device is restarted and the .cods are reloaded.
This is why, when a user tries to delete an application that has an alternate entry point with a running process in the background, a dialog box always pops up letting the user know that the application will be removed on restart, and asking whether they would like to reboot now.
Until the device is rebooted, the background process will continue to run.
I'm writing a stopwatch application for BlackBerry (which is similar to the BlackBerry built-in StopWatch). There is a timer label displaying current time in the format MM:SS:T (minutes, seconds, tenth of second). The label is refresh each 100 millisecond with TimerTask.
The application works well and the time is display correctly, however, there are some moments the timer label is not updated at the predetermined interval (each 100 milliseconds). The timer label pauses (not counting) for a while and continues counting (while still displays the time correctly)
My thought is the TimerTask is not executed to update the timer label during this pause. Do you know why the app act this way, and how to fix it?
Below are the Thread to update the timer label:
public class ThreadUpdateTime extends Thread
{
private MyMainScreen myMainScreen;
private Timer updateTimerLabelTimer = new Timer();
public ThreadUpdateTime(MyMainScreen parent)
{
myMainScreen=parent;
}
public void run()
{
try {
updateTimerLabelTimer.schedule(new RecordTimer(myMainScreen), TIMER_DELAY, TIMER_INTERVAL);
} catch (Exception e) {
//put alert here
}
}
public void iStop()
{
updateTimerLabelTimer.cancel();
}
}
the timerTask:
public class RecordTimer extends TimerTask
{
private MyMainScreen myMainScreen;
public RecordTimer(MyMainScreen parent)
{
myMainScreen=parent;
}
public void run()
{
myMainScreen.iUpdateTimerLabel();
}
}
and the iUpdateTimerLabel method:
public void iUpdateTimerLabel()
{
//calculate : sign, sMin, sSec, sTenth
synchronized(Application.getEventLock())
{
lblSpotTime.setText(sign+sMin+":"+sSec+"."+sTenth+" ");
}
}
First is to measure it... log the timestamps when your timertask begins and ends, and see if it's really the TimerTask that's really the problem. With that in hand, a couple of things that occur to me are,
Is your task blocking (maybe on
some UI thing)?
Are there other tasks in the same
Timer instance? I don't know if it's specified as such, but tasks probably all run on a single thread, so if another task is getting in the way, your tasks may not run at the exact specified interval.
Is your TimerTask properly synchronized with the UI event loop (i.e., is it updating the label in the correct runLater() or whatever method provided by the blackberry UI)? If you aren't doing this, the UI event loop may not notice that you've changed the label. I think on the Blackberry, the right thing is invokeLater() or maybe invokeAndWait(), depending on what you're trying to accomplish.
Edited after code posted:
A couple of useful and relevant resources are here.
OK, I'd still say to instrument your code with some logging or println calls to output
timestamps when it runs.
Not sure why the schedule() call is inside its own Runnable... you don't need that, but maybe your application is doing that for some reason I can't see. If you think you're creating an explicit thread for the timer, you're not. You can probably just create the Timer and call schedule() from whatever application thread is setting this up. Timer contains a captive thread that will do this work, and introducing Yet Another Thread is probably redundant and confusing.
I still think you may want to do something like:
Another reminder to actually MEASURE what the timer is doing rather than relying on my speculation...
code inside the TimerTask:
public void iUpdateTimerLabel()
{
//calculate : sign, sMin, sSec, sTenth
// synchronized(Application.getEventLock())
UiApplication.getUiApplication().invokeLater(
new Runnable() {
#Override
public void run() {
lblSpotTime.setText(sign+sMin+":"+sSec+"."+sTenth+" ");
}
});
}
Your synchronized call may be enough to keep things from blowing up, but it's not really the preferred means. If the Timer thread is dedicated to this single purpose, as it appears, you can probably replace invokeLater() with invokeAndWait() if you like.
Someone else may be able to elucidate the difference between just holding the UI lock and actually running on the UI thread, but my guess is that the latter forces an invalidate(), and the former does not. This would explain why your label changes are only showing up sporadically.