I have a list of bluetooth devices that can be turned off and on. When on they appear in the tableview and get removed when turned off. My bluetooth manager object contains the device list and whenever the list is updated a notification is triggered to update the tableview. Adding doesn't seem to be a problem, those appear instantly, but when I remove something from the list it doesn't seem to get removed from the tableview.
Is this expected behavior or does updating the tableview not work with this method?
private void DeviceCollectionChanged(object sender, NotifyCollectionChangedEventArgs e)
{
updateDevices();
}
private void updateDevices()
{
Console.WriteLine("Update in iOS");
deviceTable.Source = new DeviceTableSource(bleHandler.getModelList().ToList());
deviceTable.ReloadData();
}
I know reloading isn't optimal as it redraws the entire table but the list is limited to 6 devices and shouldn't change very often.
Here's how I was able to get it to remove correctly. It came down to a threading issue.
InvokeOnMainThread(() => {
deviceTable.ReloadData();
});
Related
I am trying to implement a Textbox that can show fractions with GWT.
Therefor I have an Canvas were I can draw what I want and receive KeyEvents and MouseEvents.
But on Ipad (Safarie and Chrome) the software keyboard does not show, so I created an Composite and combined the Canvas with a Textbox witch gets the focus after each key or mouse Event on the Canvas.
But the softkeyboard does not show up every time so I tried a bit and can see, that the Textbox seems to get the focus (it gets a blue boarder) but does not always show the cursor.
This does not happen on my Notebook.
Is there any difference between being focused and showing the cursor?
I tried:
Setting the Cursor position
set the Text of the Textbox.
Any help would be appreciated,
Christoph
public void setFocus(boolean b) {
// if (hasFocus) {
Scheduler.get().scheduleDeferred(new ScheduledCommand() {
public void execute () {
t.setFocus(b);
}
});
Scheduler.get().scheduleDeferred(new ScheduledCommand() {
public void execute () {
box.setFocus(true);
box.setText("x");
box.setCursorPos(0);
// box.setVisible(false);
// box.setVisible(true);
}
});
// t.setFocus(b);
// box.setFocus(b);
// }
}
The iOS browsers don't allow the focus to be set programmatically unless directly in response to a user interaction (i.e. a touch). I believe the reason is to prevent websites bringing up the virtual keyboard for no reason.
The downside is that it clobbers setFocus() for websites that want to use it for legitimate reasons. You can't call setFocus() in a deferred command because that doesn't count as a direct response to the user interaction.
(To be more precise, you can call setFocus() in a deferred command, but it won't have the desired effect as you found out.)
We're using Appium with iOS Simulator and test functions written in Java.
We have an iOS App with screen 1 containing a UICollection view, and tell Appium to click on one of its elements.
This opens screen 2 (and the scrolling animation takes about 500 ms), which also contains an UICollection view. I want to find out the size of the UICollection view of the second screen with Appium.
The problem is that Appium is too fast and executes the findElements() method directly after the click, which causes it to find the UICollection view of the first screen.
clickOnElementOnFirstScreen();
webDriver.findElements( By.className( "UIACollectionCell" ) ).size();
// is supposed to find the UICollection view on the second screen,
// but actually finds the UICollection view on the first screen
Appium provides several waiting functions. However as far as I can see all of them are intended to be used in this fashion:
"wait until element at location X / with name X becomes visible"
If I try to use these waiting functions, they don't wait at all because they immediately find the UICollection view of the first screen, which has the same location and name as the one on the second screen.
The only solution I have found is to use Thread.sleep:
Thread.sleep(1000);
webDriver.findElements( By.className( "UIACollectionCell" ) ).size();
But we don't want to use Thread.sleep in code that will run on the client's server on hundreds of tests.
We might be able to modify the App and enter metadata into the views so that Appium is able to distinguish them, but this situation occurs in several places and the App is being programmed by the client, so we want to avoid this too.
What is a simple and safe way to wait for the new screen to appear, without modifying the code of the iOS App?
I have found only dirty workaround for this issue.
static waitFor(Duration duration) {
try {
def WebDriverWait wait = new WebDriverWait(mobileDriver, duration.standardSeconds)
wait.until(visibilityOfElementLocated(By.xpath("//Fail")))
//Wait until false case is visible to ensure proper timeout
} catch (Exception e) {
}
}
Another workaround/solution that has been posted on the Appium forums is:
First search for some other element that distinguishes the 2. screen from the 1. screen; once that is visible, it's safe to search for the originally desired element.
I have a Today Widget for my app, however I have been told about an issue with it.
Basically, what seems to be happening (I can't test this for myself) is that the widget will sometimes just display 'unable to load' and other times it will just display with a height of 0.
I can't really see why this is happening. I've tested it out on my device and the simulator for weeks now and have never ran into this issue.
I was wondering if it could possibly be down to the refresh code:
func widgetPerformUpdateWithCompletionHandler(completionHandler: ((NCUpdateResult) -> Void)!) {
// Perform any setup necessary in order to update the view.
var defaults = NSUserDefaults(suiteName: "group.AffordIt")
var newCheck = defaults.boolForKey("new")
if newCheck == true {
completionHandler(NCUpdateResult.NewData)
} else {
completionHandler(NCUpdateResult.NoData)
}
}
'newCheck' is true whenever something changes within my app that needs to be displayed in the widget.
Does anyone know what the possible causes of these issues are?
"unable to load" message appears if your extension crashes often. You can try to re-enable it by removing and adding the extension again.
Are you using your own view controller and xib instead of using storyboard? If yes, it is probably that you didn't set the preferredContentSize in your view controller.
try to put the following code in the init function of ur view controller:
self.preferredContentSize = CGSizeMake(320, 100);
I have just began the extension programming today so I am not sure is it really helpful for u or not. Here is the result in my own widget:
Press Edit button in today extensions
Remove your extension
Add your extension again.
I am trying to make my program use less resources when I send it to the background through overriding the onClose() function. My first step is to stop it painting text and gauge fields.
I've been reading this doc on Efficiency,
"Eliminating unnecessary processing on the device"
"You can use methods to stop animating or repainting the screen when the screen is not visible, and resume when the screen is visible again. You can override Screen.onExposed(), which is invoked when your application's screen is on top of the display stack and displayed to the user. You can override Screen.onObscured(), which is invoked when your application's screen is not displayed to the user or is obscured by another screen."
I know if I use isForeground(), it will stop it from painting if my app is in the background, but will it do the same if it is obscured by another app? It seems much more simpler to use isForeground()
private boolean isExposed;
protected void onExposed()
{
isExposed = true;
}
protected void onObscured()
{
isExposed = false;
}
public void batteryStatusChange(int status)
{
// TODO Auto-generated method stub
if ((status & DeviceInfo.BSTAT_LEVEL_CHANGED) != 0)
{
//is there a difference between the two if's?
//if(isExposed)
//if(UiApplication.getUiApplication().isForeground())
{
batteryStatusField.setText(getBatteryLevel());
bitGauge6.setValue(DeviceInfo.getBatteryLevel());
}
}
}
public boolean onClose()
{
UiApplication.getUiApplication().requestBackground();
return true;
}
In general, isForeground() tells you if your app is running in the foreground. However, as you've implemented it, the isExposed variable only tells you when the screen that it belongs to has been exposed, or obscured (because you're setting it in the Screen.onExposed() and Screen.onObscured() methods).
For your app, maybe you only have one Screen subclass?
Most apps will have many screens. So, in that situation, the isExposed variable would only be telling you whether or not one (of many) screens is showing.
If your app only has the single Screen, then either technique should work for you.
However, as I said in my comment, if the code you've posted is showing all that you're doing in the batteryStatusChange() callback, then I don't think you really need to worry about performance. It's good to be considerate of performance on mobile devices, but neither of the UI calls you make in that method should incur any significant performance cost.
batteryStatusField.setText(getBatteryLevel());
bitGauge6.setValue(DeviceInfo.getBatteryLevel());
I have a application with a screen manager class that is causing me some problems.
The application makes requests to the server to perform searches and allows the user to view results.
The application has worked fine on all OS versions up to 4.5 where we are sudden having
problems viewing a screen under certain circumstances.
It occurs when the user has performed a search and they wait for the results.
While waiting for results, they press the trackball which displays a menu.
This is not needed to display the results, it just happened that the user decided to press it.
When the results come back from the server, the results screen should automatically be displayed. On OS 4.5, the code displays the results screen runs but then the application completely falls over. If the user doesn't press the trackball while waiting, the application works fine.
Looking at the logs, they show no exception being thrown and the only suspect line being
System data:VM:DPNAv=78,p
By adding in some more log lines I have discovered that the code is reaching the
UiApplication.getUiApplication().popScreen(screen);
line in the method hideScreen(Screen screen) but when called from hideCurrentScreen(). By adding in some more debugging I find that the active screen at this point is DefaultMenuScreen (as the menu button has been pressed)
So it seems the problem is that I am trying to pop one of my own screens from the display
stack when the DefaultMenuScreen one is the active one. I repeat that this code did work on OS previous to 4.5. By running the same code on the 8300 with OS 4.2.2 with the debugging statements, I can see that the same thing happens, the active screen is the DefaultScreen but removing my own screen does not cause the whole application to crash.
The one way round this I could see, was to change the hideCurrentScreen() to just remove the active screen but this does not seem like the correct way to do it.
Has anyone else had experience of this? Can anyone tell me why this is happening? What are we meant to do if we cannot remove our screens when a DefaultMenuScreen is the active one?
This occurs in both device and simulator for 8310 and 9700.
The screen manager code is as follows.
public class ScreenManager
{
private Hashtable screens;
private String currentScreenName;
public ScreenManager()
{
screens=new Hashtable();
}
/**
* Description of the Method
*
*#param sCardName Description of Parameter
*/
public boolean showScreen( String sScreenName )
{
boolean bSuccess=false;
if (sScreenName != null && sScreenName.length() > 0 )
{
MainScreen screen=(MainScreen)screens.get(sScreenName);
if (screen!=null)
{
// We have a new screen to display so pop the current screen off the stack
hideCurrentScreen();
// If the screen is on the stack then pop the screens until we get our target screen
// otherwise just push the screen onto the stack.
if (screen.isDisplayed())
{
Screen activeScreen=null;
synchronized(UiApplication.getEventLock())
{
activeScreen=UiApplication.getUiApplication().getActiveScreen();
}
while (screen!=activeScreen && activeScreen!=null)
{
activeScreen=hideScreen(activeScreen);
}
bSuccess=(screen==activeScreen);
}
else
{
synchronized(UiApplication.getEventLock())
{
UiApplication.getUiApplication().pushScreen(screen);
bSuccess=true;
}
}
}
}
if (bSuccess)
{
this.currentScreenName=sScreenName;
}
else
{
Logger.warning("ScreenManager: Failed to display screen ["+ sScreenName +"]");
}
return bSuccess;
}
private Screen hideCurrentScreen()
{
Screen activeScreen=null;
if(currentScreenName!=null)
{
MainScreen screen=(MainScreen)screens.get(currentScreenName);
activeScreen=hideScreen(screen);
}
return activeScreen;
}
private Screen hideScreen(Screen screen)
{
Screen activeScreen=null;
if (screen!=null && screen.isDisplayed())
{
Logger.finest("Hiding Screen ["+currentScreenName+"]");
synchronized(UiApplication.getEventLock())
{
UiApplication.getUiApplication().popScreen(screen);
activeScreen=UiApplication.getUiApplication().getActiveScreen();
}
Logger.finest("Hid Screen ["+currentScreenName+"]");
}
return activeScreen;
}
//Rest of code omitted
}
The only way round this I managed to find was what I mentioned in the question. When I want to remove the current screen. I need to check it is the same as the active screen. If it is not the same then I just remove the active screen until I reach the screen I am looking for. This would only happen if a menu or pop up was displayed. Also, I need to add checks to my custom pop-up code to make sure it does not try and remove a screen that has already been removed.
It seems a bit messy but could not find any other alternatives.
The way we pop screens in our app is to explicitly pop the screen you want off the stack, as opposed to just the top-most screen. This either requires keeping track of which screens you have on the stack, or some code to iterate through the screens on the stack and search for the particular screen you want to pop off.