I have a project which lets the user to select from the ADFs existing on a Tango-enabled device, to allow them to correctly localize in a number of different spaces.
My code (Unity 5.5, C#, Farandole SDK) essentially performs manual Tango startup with a null AreaDescription as the entry flow. If the user then selects an ADF, I'm calling TangoApplication.Shutdown() then TangoApplication.Startup(newArea).
in Eisa, this works. In Farandole, I get a permissions failure.
if, using Farandole, I explicitly request permissions (after the Shutdown) and wait for the permissions response to come back before calling Startup, the system appears to re-localise against the new ADF, but the Tango system is re-registering callbacks every time around through Startup without unregistering them, meaning I get my callbacks called multiple times for each ADF that I switch to.
What is the correct process to switch between ADFs? Should a shutdown be required before calling Startup, and if so, what is the correct way to shutdown the TangoApplication to avoid multiple callbacks?
I am interested in this answer too. The way I would do it, is reload the scene with the new ADF, just like it is done in the AreaLearning example, so TangoManager and TangoPoseController are reset.
Related
I'm building my first CloudKit application, and am using CKFetchRecordZoneChangesOperation on startup to get any new records changed while the current device was offline.
I am also calling CKFetchRecordZoneChangesOperation when I receive a subscription notification of changes.
It is possible the subscription notification could come in before the startup call finishes. I am currently using a lock to prevent the 2nd call from starting until the recordZoneFetchCompletionBlock handler is called, signalling that the first one is done. This works, but it also smells a bit hacky.
The application I am working on downloads and parses a large xml file to populate UI elements, namely search and a spinner. This is done through an async task. If the user decides to switch out of the application during this, the information is downloaded correctly, but then when the application is resumed, the UI will not be updated.
Is this because the changes can't be made while the application is not active? What is the best way to go about checking whether the UI was not updated on resume? Or instead should I be doing something with the Async task, checking whether the UI thread is available? I'm having a hard time debugging this because it involves leaving the application which ends the debugger.
You can achieve this scenario through the broadcast receive.
Follow the step:
Solution 1:
Step 1;
Register the broadcast receiver before executing the Asyntask.
Step 2:
send Broadcast in onPostExecute method of Asyntask.
step 3:
And then you can able receive your broadcast message in your activity.
and do whatever you want.
Solution 2:
Otherwise you can use Interface Call back for this Scenario.
Hope It will help you.
It should'nt. App being in background means View objects may or may not be there. Actually the entire process may be stopped or just deleted by android.
Use a Service to truly do processing in background. When processing is complete but UI is not there, post a notification to let user know, OR, save the results and provide it to UI the next time it binds to your service and ask for same thing (a.k.a caching).
The application in background may not be live. The O.S may destroy it in case of memory constrains.
The trick is to try an alternate logic.
When the application moves from background to foreground onresume() is called ,you could try saving the data to db and update the content on the resume call.
FYI.onPause() and OnResume() is called when the application goes background and foreground respectively.
I can get the app ID from my running activity via activity.getTaskId(). It will report back 185. If I go to another app, and start my activity from a share button, it will be placed IN THAT apps stack. If I do activity.getTaskId() it will report back 192 for example. I am assuming that an application process can only have one main task stack associated with it. How do I get that tasks ID? I want to be able to know "Hey I'm running outside of your apps task stack".
I contemplated doing this by polling the taskId the first time my activity is created and set that as a member variable to my Application Class, but if my app is killed, and then started first from another application, it will have the incorrect task id as the "AppTaskStackId". I haven't found any API for this.
A different approach might be to have both an exported and non-exported activity. The exported activity would simply be forwarded on to the non-exported activity, but with an extra denoting that it was started externally. And then when starting the activity internally, you always call the non-exported activity without that "isExternal" extra.
And then, in the non-exported activity, you can check for the existence of that extra to determine if the activity was started internally or externally.
The only way I could find to get even close to what you are trying to accomplish would be with the following code in, say, your Activity's onCreate:
ActivityManager m = (ActivityManager) getSystemService(Context.ACTIVITY_SERVICE);
List<RunningTaskInfo> runningTaskInfoList = m.getRunningTasks(1);
if(!runningTaskInfoList.isEmpty()) {
String callingPackageName = runningTaskInfoList.get(0).baseActivity.getPackageName();
}
Here callingPackageName would be set to the package name of your app if the activity has been invoked from another activity in your own app, or is the main activity of your app.
However, if the activity was started by another app, say using the share function, then callingPackageName would be the package name of the calling app, so all you have to do is check if this is equal to your app's package name by calling getPackageName().
Also note that:
Your app will now need the android.permission.GET_TASKS permission
The documentation for this method states:
Note: this method is only intended for debugging and presenting task management user
interfaces. This should never be used for core logic in an application, such as deciding between
different behaviors based on the information found here. Such uses are not supported, and will
likely break in the future.
So I'm not sure how reliable this is or if it is even useful to you.
A recently (API 29) added TaskInfo:
https://developer.android.com/reference/android/app/TaskInfo
should help here.
I've decided to integrate OpenFeint into my new game to have achievements and leaderboards.
The game is dynamic and I would like user to be rewarded immediately for some successful results, but as it seems for me, OpenFeint's achievements are a bit sluggish and it shows visual notification only when it receives confirmation from the server.
Is it possible to change something in settings or hack it a little bit to show notification immediately as soon as it checks only local database if the achievement has not been unlocked it?
Not sure if this relates to the Android version of the SDK (which seems even slower), but we couldn't figure out how to make it faster. It was so unacceptably slow that we started developing our own framework that fixes most of open feint's shortcomings and then some. Check out Swarm, it might fit your needs better.
There are several things you can do to more tightly control the timing of these notifications. I'll explain one approach and you can use this as a starting point to explore further on your own. These suggestions apply specifically to iOS apps. One caveat is that these suggestions refer to internal APIs in OFSDK 2.8 for iOS and not ordinarily recommended for high level use and subject to change in future versions.
The first thing I recommend is that you build the sample app with your own product key. Use the standard sample app to experiment before applying the result to your own code.
You are going to get the snappiest response by separating the notification pop-up UI from the process of submitting the achievement. This way you don't have to worry about getting wrapped up in the logic for deciding whether the submission is going just to the local db or is doing the full confirmation on an async network transaction.
See the declaration of "showAchievementNotice" in "OFNotification.h". Performing a search in the sample app, you will see that this is the internal API used for displaying the achievement pop-up when an achievement is earned. It does not actually submit the achievement. You can call this method directly as it is called from "OFAchievementService.mm" to directly control when the message appears. You can then use the following article to disable the pop-up from being called when the actual submission occurs:
http://support.openfeint.com/dev/notification-pop-ups-in-ios/
This gives you complete freedom to call the submission at a later time provided you keep track of the need to do so. For example, you could locally serialize a flag to take care of the actual submission either after the level is done or the next time the app starts up. Don't forget that the user could quit out of a game without cleanly finishing a level.
I am attempting to show a form from a service on Vista (using .NET winforms)
Obviously the form would not show to the console user, as services are isolated in session 0.
However the experiment is to see if it is possible to "show" an invisible form and obtain a window handle & message loop
I have tried but when I issue form.Show(), only the form.Load event fires not .Shown or .FormClosing
Is there any way to capture windows messages in this way as a user application would?
I have not attempted to make the service 'interactive' as I do not wish to interact with the logged-on user.
Yes you can show a form on a service's desktop. It will not be shown to any logged in user, in fact in Vista and later OSes you cannot show it to a user even if you set the service to 'interactive'. Since the desktop is not interactive the windows messages the form receives will be slightly different but the vast majority of the events should be triggered the same in a service as they would be on an interactive desktop (I just did a quick test and got the form load, shown, activated and closing events).
One thing to remember is that in order to show a form your thread must be an STA thread and a message loop must be created, either by calling ShowDialog or Applicaton.Run. Also, remember all external interaction with the form will need to be marshaled to the correct thread using Invoke or BeginInvoke on the form instance.
This is certainly very doable but is really not recommended at all. You must be absolutely sure that the form and any components it contains will not show any unexpected UI, such as a message box, under any circumstances. The only time this method can really be justified is when you are working with a dubious quality legacy or 3rd party tool that requires handle creation in order to function properly.