I need a simple way to detect when a target has been found or lost so that I can segue to a different Controller.
This question has been asked in several forums, but there was never a satisfactory answer. This particular post seems to be the most detailed, but it is over three years old.
https://developer.vuforia.com/forum/ios/trackableeventhandler-equivalent-ios
I can't find any documentation related to this on the Vuforia site.
One of the methods that must be implemented by the VuforiaManagerDelegate is:
func vuforiaManager(_ manager: VuforiaManager!, didUpdateWith state: VuforiaState!)
When a target is found (an image is recognized by Vuforia) this property will change from 0 to 1 (or more, if multiple targets are identified):
numberOfTrackableResults
So it is simply a matter of checking if state.numberOfTrackableResults > 0 { your code here }
on TrackableEventHandler script there is a function called OnTrackableStateChanged
you can sign up to this and do whatever you wanna do directly here or in OnTrackingFound();
public void OnTrackableStateChanged(
TrackableBehaviour.Status previousStatus,
TrackableBehaviour.Status newStatus)
{
if (newStatus == TrackableBehaviour.Status.DETECTED ||
newStatus == TrackableBehaviour.Status.TRACKED ||
newStatus == TrackableBehaviour.Status.EXTENDED_TRACKED)
{
OnTrackingFound();
}
else
{
OnTrackingLost();
}
}
Related
I'm working on a blazor server-side project and I have a component that gets passed a model (pickedWeek) as a parameter. I can use the model fine in-line with the html, but OnInitializedAsync always thinks that the model is null.
I have passed native types in as parameters, from the Page into a component, this way without an issue. I use a NullWeek as a default parameter, so the number getting used in OnInitializedAsync only ever appears to be from the NullWeek. In case this is related, there is a sibling component that is returning the Week model to the Page through an .InvokeAsync call, where StateHasChanged() is being called after the update. It appears that the new Week is getting updated on the problem component, but that OnInitializeAsync() either doesn't see it, or just never fires again- which maybe is my problem, but I didn't think it worked that way.
For instance, the below code will always show "FAILURE" but it will show the correct Week.Number. Code below:
<div>#pickedWeek.Number</div>
#if(dataFromService != null)
{
<div>SUCCESS</div>
}
else
{
<div>FAILURE</div>
}
#code{
[Parameter]
public Week pickedWeek { get; set; }
protected IEnumerable<AnotherModel> dataFromService { get; set; }
protected override async Task OnInitializedAsync()
{
if (pickedWeek.Number > 0)
{
dataFromService = await _injectedService.MakeACall(pickedWeek.Id);
}
}
}
#robsta has this correct in the comments, you can use OnParametersSet for this. Then, you will run into another issue, in that each rerender will set your parameters again and generate another call to your service. I've gotten around this by using a flag field along with the the OnParametersSet method. Give this a shot and report back.
private bool firstRender = true;
protected override async Task OnParametersSetAsync()
{
if (pickedWeek.Number > 0 && firstRender)
{
dataFromService = await _injectedService.MakeACall(pickedWeek.Id);
firstRender = false;
// MAYBE call this if it doesn't work without
StateHasChanged();
}
}
Another alternative is to use the OnAfterRender override, which supplies a firstRender bool in the the method signature, and you can do similar logic. I tend to prefer the first way though, as this second way allows it to render, THEN sets the value of your list, THEN causes another rerender, which seems like more chatter than is needed to me. However if your task is long running, use this second version and build up a loading message to display while the list is null, and another to display if the service call fails. "FAILURE" is a bit misleading as you have it as it's being displayed before the call completes.
I've also found that a call to await Task.Delay(1); placed before your service call can be useful in that it breaks the UI thread loose from the service call awaiter and allows your app to render in a loading state until the data comes back.
I have a Groovy class with a single static method:
class ResponseUtil {
static String FormatBigDecimalForUI (BigDecimal value){
(value == null || value <= 0) ? '' : roundHalfEven(value)
}
}
It has a test case or few:
#Test
void shouldFormatValidValue () {
assert '1.8' == ResponseUtil.FormatBigDecimalForUI(new BigDecimal(1.7992311))
assert '0.9' == ResponseUtil.FormatBigDecimalForUI(new BigDecimal(0.872342))
}
#Test
void shouldFormatMissingValue () {
assert '' == ResponseUtil.FormatBigDecimalForUI(null)
}
#Test
void shouldFormatInvalidValue () {
assert '' == ResponseUtil.FormatBigDecimalForUI(new BigDecimal(0))
assert '' == ResponseUtil.FormatBigDecimalForUI(new BigDecimal(0.0))
assert '' == ResponseUtil.FormatBigDecimalForUI(new BigDecimal(-1.0))
}
This results in 6/12 branches covered according to Sonar/JaCoCo:
So I've changed the code to be more...verbose. I don't think the original code is "too clever" or anything like that, but I made it more explicit and clearer. So, here it is:
static String FormatBigDecimalForUI (BigDecimal value) {
if (value == null) {
''
} else if (value <= 0) {
''
} else {
roundHalfEven(value)
}
}
And now, without having changed anything else, Sonar/JaCoCo report it to be fully covered:
Why is this the case?
I don't know if it applies to your concrete example, but keep in mind that code coverage tools typically don't work well for alternative JVM languages unless they support them explicitly. This is because virtually all of those languages generate extra byte code that may only get executed in certain cases. For example, Groovy might generate byte code for a slow path and a fast path, and might decide between them automatically, without the user having a say.
The situation might improve with Groovy 3.0, which will be designed around Java invokedynamic, meaning that less "magic" byte code will have to be generated. Meanwhile, I've heard that Clover has explicit Groovy support, although I don't know how up-to-date it is.
So, as it turns out, the Jacoco plugin for Sonar explicitly looks for Java code. I know this, as I debugged through it. It decodes the jacoco exec file and assumes any file is a JavaFile, which it doesn't find, and then says you have no coverage information.
Because of this, I grabbed the source code to the Jacoco plugin (it vanished from their Subversion repository, and never appeared on Github that I could find) and folded it into a new Groovy plugin. My updated one uses Codenarc 0.18.1 (which increases the Narc's from 32 to 305) and recognizes any kind of Jacoco file - the code in the existing plugin is unnecessarily wrong.
The source is here: https://github.com/rvowles/sonar-groovy - just build it and put it in your extensions/plugins directory.
I'm very new to Android and Kotlin so I may be getting something very simple wrong, but as far as I can see when I call BluetoothLeScanner.startScan() none of the possible callback methods of the ScanCallback class which I've created is ever called.
I've understood that at API level 23 & above just putting the location permissions in the manifest may not be enough so I've written code to handle that & am satisfied that my App has both COARSE and FINE location permissions
Here's my override of the OnScanResult method:
override fun onScanResult(callbackType: Int, result: ScanResult?) {
super.onScanResult(callbackType, result)
mScan = true
}
I've put a break point in each of the callback methods and when I hover over these breakpoints while the code is running, I see the message "No executable code found at line..." That's a pretty disturbing message (and I suspect is pointing to where the problem lies) but (a) how can there be no code there when everything builds OK and (b) what do you do about it?
Update on that: I think that message is a red herring. I've now moved the break points to elsewhere within the callback functions and I no longer see the 'no executable code' message. Looks like Android Studio lets you put a break point on a line with no actual code in it!
So we're back to the original question - why are we getting no callbacks?
Looks like this is now solved:
(1) I did find a setting on the phone as distinct from turning on Location. It was enable Bluetooth scanning. However it actually made no difference (2) What looks to have been the real issue is a misunderstanding of the meaning of the string which you pass to the ScanFilter Builder with setDeviceName(). There is a string in our hardware Bluetooth module which we're trying to scan for which is called device name, and I was scanning for that. When I looked instead for the Beacon advertising data, it found it.
Many thanks for suggestions (only 1 I think)
Giving permissions in the manifest is not the same as the app using it.
For ble you need to give the location and bluetooth permission. Then:
in the app(on the phone) browse your open apps
find your app and click the 3 dots in the top left
Click app info
Permissions
Toggle location to on
Also the following is a handy bit of code:
public void checkPermission() {
if (Build.VERSION.SDK_INT >= 23) {
if (checkSelfPermission(Manifest.permission.ACCESS_FINE_LOCATION) == PackageManager.PERMISSION_GRANTED && checkSelfPermission(android.Manifest.permission.ACCESS_COARSE_LOCATION) == PackageManager.PERMISSION_GRANTED) {
} else {
ActivityCompat.requestPermissions(this, new String[]{
Manifest.permission.ACCESS_FINE_LOCATION,
Manifest.permission.ACCESS_COARSE_LOCATION,}, 1);
}
}
}
#Override
public void onRequestPermissionsResult(int requestCode, #NonNull String[] permissions, #NonNull int[] grantResults) {
if (requestCode == 1 && grantResults[0] == PackageManager.PERMISSION_GRANTED && grantResults[1] == PackageManager.PERMISSION_GRANTED) {
} else {
checkPermission();
}
}
Ps Be safe all
I am facing some troubles when processing the NM_CUSTOMDRAW message on 64 bit machines. We have an CListCtrl derived class with a CHeaderCtrl derived header (linked via PreSubclassWindow).
In the CHeader derived class we do some custom painting. This works for a 32bit build. But when I build a 64bit variant the drawstage remains CDDS_PREPAINT.
So I am posting here to get some help on this issue. I tried a lot of combinations of result values, drawstage handling in the OnCustomDraw ... but all of them still receive only the CDDS_PREPAINT drawstage.
Here you have my current testcode for OnCustomDraw:
void CListViewCtrlExHeader::OnCustomDraw(NMHDR* pNMHDR, LRESULT* pResult)
{
LPNMCUSTOMDRAW lpnmcd = (LPNMCUSTOMDRAW )pNMHDR;
*pResult = CDRF_DODEFAULT;
if (lpnmcd)
{
switch (lpnmcd->dwDrawStage)
{
case CDDS_PREERASE:
{
TRACE(_T("CDDS_PREERASE\n"));
*pResult |= CDRF_NOTIFYPOSTERASE;
break;
}
case CDDS_POSTERASE:
{
TRACE(_T("CDDS_POSTERASE\n"));
break;
}
case CDDS_PREPAINT:
{
TRACE(_T("CDDS_PREPAINT\n"));
*pResult |= CDRF_NOTIFYPOSTPAINT;
break;
}
case CDDS_POSTPAINT:
{
TRACE(_T("CDDS_POSTPAINT\n"));
break;
}
default:
{
TRACE(_T("CDDS_OTHER\n"));
break;
}
}
}
}
The only purpose of this header ctrl is painting above the default painting, so there is not much code in there. The painting of the CListCtrl derived class does not not do anything special, it lets CListCtrl handle the OnPaint message. The CListCtrl derived class does contain an OnCustomDraw section. But since it works on 32 bit, I doubt the problems should be searched there, on the other hand I mention it since I am out of options...
I found some posts with similar issues (only64 bit or drawstage remains) but none of them worked for me. One of these solutions was an incorrect definition of NMCUSTOMDRAW struct, but mine is the MFC version and no complaints found for 64bit for it. Another was that result did not get processed because of where the component was placed, but then it should not work on 32 bit too. Other solutions are specific for handling the OnCustomDraw messages and results, but that seems to be fine for my testcode...
Kind Regards,
Kevin
I have been trying to follow this example (download the source code from a link on the site or here, but I keep running into an error that seems embedded in the example.
My procedure has been as follows (after installing the AppFabric SDK and other dependencies):
Download the source
Create a Service Namespace on the AppFabric.
Import the project into a new Windows Azure project with one Worker Role, make sure that it all compiles and that the default Worker Role Run() method starts and functions.
Configure the method GetInterRoleCommunicationEndpoint in InterRoleCommunicationExtension.cs with the ServiceNameSpace and IssuerSecret from my AppFabric Service Namespace (IssuerName and ServicePath stay default). This is a hard-wiring of my own parameters.
Copy/paste the initialization logic from the "SampleWorkerRole.cs" file in the demo into the OnStart() method of my project's Worker Role
Comment-out references to Tracemanager.* as the demo code does not have the Tracemanager methods implemented and they're not crucial for this test to work. There are about 7-10 of these references (just do a Find -> "Tracemanager" in entire solution).
Build successfully.
Run on local Compute Emulator.
When I run this test, during the initialization of a new InterRoleCommunicationExtension (the first piece of the inter-role communication infrastructure to be initialized, this.interRoleCommunicator = new InterRoleCommunicationExtension();), an error is raised: "Value cannot be null. Parameter name: contractType."
Drilling into this a bit, I follow the execution down to the following method in ServiceBusHostFactory.cs (one of the files from the sample):public static Type GetServiceContract(Type serviceType)
{
Guard.ArgumentNotNull(serviceType, "serviceType");
Type[] serviceInterfaces = serviceType.GetInterfaces();
if (serviceInterfaces != null && serviceInterfaces.Length > 0)
{
foreach (Type serviceInterface in serviceInterfaces)
{
ServiceContractAttribute serviceContractAttr = FrameworkUtility.GetDeclarativeAttribute<ServiceContractAttribute>(serviceInterface);
if (serviceContractAttr != null)
{
return serviceInterface;
}
}
}
return null;
}
The serviceType parameter's Name property is "IInterRoleCommunicationServiceContract," which is one of the classes of the demo, and which extends IObservable. The call to serviceType.GetInterfaces() returns the "System.IObservable`1" interface, which is then passed into FrameworkUtility.GetDeclarativeAttribute(serviceInterface);, which has the following code:
public static IList GetDeclarativeAttributes(Type type) where T : class
{
Guard.ArgumentNotNull(type, "type");
object[] customAttributes = type.GetCustomAttributes(typeof(T), true);
IList<T> attributes = new List<T>();
if (customAttributes != null && customAttributes.Length > 0)
{
foreach (object customAttr in customAttributes)
{
if (customAttr.GetType() == typeof(T))
{
attributes.Add(customAttr as T);
}
}
}
else
{
Type[] interfaces = type.GetInterfaces();
if (interfaces != null && interfaces.Length > 0)
{
foreach (object[] customAttrs in interfaces.Select(iface => iface.GetCustomAttributes(typeof(T), false)))
{
if (customAttrs != null && customAttrs.Length > 0)
{
foreach (object customAttr in customAttrs)
{
attributes.Add(customAttr as T);
}
}
}
}
}
return attributes;
}</code><br>
It is here that the issue arises. After not finding any customAttributes on the "IObservable1" type, it calls type.GetInterfaces(), expecting a return. Even though type is "System.IObservable1," this method returns an empty array, which causes the function to return null and the exception with the above message to be raised.
I am extremely interested in getting this scenario working, as I think the Publish/Subscribe messaging paradigm is the perfect solution for my application. Has anyone been able to get this demo code (from the AppFabric CAT Team itself!) working, or can spot my error? Thank you for your help.
Answered in the original blog post (see link below). Please advise if you are still experiencing problems. We are committed to supporting our samples on best effort basis.
http://blogs.msdn.com/b/appfabriccat/archive/2010/09/30/implementing-reliable-inter-role-communication-using-windows-azure-appfabric-service-bus-observer-pattern-amp-parallel-linq.aspx#comments