We are planning to use sqlite pcl library for WinRT store app using this project: https://sqlitepcl.codeplex.com/ . All the api is blocking. Will there be a problem during app store review by Microsoft, if we use it?
Of course the api will be wrapped in Task.Run, somethin glike:
public Task InsertTestSetForUser(TestItem testItem, long userid)
{
return Task.Run(() => InsertTestSetForUserInternal(testItem, userid));
}
I knwo that there is an impl of sqlite with async API, but that would not be portable out of the box for Xamarin, which we use for porting to iOS and Android.
There are a few requirements your app has to meet. The three most important ones regarding your question (imho) are these:
Your app has 5 seconds to start on the splash screen. If your database setup takes longer, consider using an extended splash screen or a background task.
The app must render the first screen or a splash screen within 5
seconds after launch.
Your app must be responsive within 20 seconds (which is basically 5 + 15 seconds).
Within 20 seconds after launch, the app must be responsive to user
input.
If there is an operation on the UI that takes more than 3 seconds to process, you have to use some kind of status indicator (e.g.: an indeterminate progress bar).
If an app performs an operation that causes the device to appear to be
unresponsive for more than three seconds, such as downloading data
over a network connection or transitioning between a screen or page,
the app must display a visual progress or busy indicator.
So you see: There is no definition what blocking really means in the certification process. Just be sure to use Tasks for long operations that are triggered from the UI and display some kind of process / status to the user when the operation takes longer than expected. As long as your app stays responsive it will not fail certification (passing the WACK test is important, though).
For more information see: http://msdn.microsoft.com/en-us/library/windows/apps/hh184840(v=vs.105).aspx
Related
I am struggling to figure out the best approach for handling large, long-running uploads in my Ionic + Capacitor mobile app.
Specifically, I am uploading a few dozen photos (~30+) to Firebase storage and one or more videos (1-2 minutes) to Vimeo all at roughly the same time. Users may even have several batches of these uploads running simultaneously (the user can choose when to do their uploads). On a good connection the entire upload process takes < 1 minute, but I have to account for slow/spotty connections, as well as users going online and offline.
The uploads work pretty much perfectly when the app is in the foreground, but the issues begin when the user exits or completely closes the app during the upload. I don't have a reliable mechanism to ensure my uploads continue running.
I am using Capacitor v2 at the moment, so I am trying to use the BackgroundTask plugin to attempt to keep uploads alive as long as possible, but this has proven to be unreliable.
https://capacitorjs.com/docs/v2/apis/background-task
const uploadPromises = []; // Array of promises used to track each individual upload
// Start uploading things, adding each unresolved upload to 'uploadPromises'
const { isActive } = listenForCapacitorAppStateChange(); // This is a redux-saga emitter
if (!isActive) {
const taskId = BackgroundTask.beforeExit(async () => {
// Use the background task to wait for all upload promises to resolve
await Promise.allSettled(uploadPromises);
// Alert OS that background task is finished
BackgroundTask.finish({ taskId });
});
}
I am also checking when the app is restored to resume any uploads that didn't finish for some reason, but this is frustrating because users may start uploading, exit the app, and then come back some time later to find their upload is still incomplete and sitting idle that whole time!
Now I am reading about Capacitor v3 and see that they've completely removed the BackgroundTask plugin, but the v2 docs make that plugin seem very important:
This is especially important on iOS as any operations would normally
be suspended without initiating a background task.
Since my solution seems hacky at best, and is not very reliable, and now the Capacitor team is removing the plugin entirely, that leads me to believe I am missing a completely different (ie. better) solution to this problem.
Does anyone know of an existing solution? Do I need to write my own plugin to kick off a proper background service for Android and iOS just to keep my uploads alive? I haven't come across a community plugin yet that seems to cover this.
I'm writing an Xamarin Forms App(C#) that has a UI, which takes data from a user and passes it's data to a background thread/service to be sent to a server.
The datafirst gets saved to a local database for safe keeping. (Cleanup will be later)
I need a service or something that will guarantee delivery of the data, even if the application is minimized or shut down (swiping it off the screen).
Am I looking for something that does not exist?
I have tried an IntentService, which seemed to do what I wanted but stopped if I killed the UI.
I tried a real Service, which also stopped if I killed the UI, but I may not have set it up properly.
Also, a service seems to run on the UI thread. What good is that? I can't get it to run as a BackgroundWorker either using StartService inside the worker, so I tried running the service as normal and in the StartCommandResult OnStartCommand, calling the data fetch/save method as a Task or Thread. It works as long as the app stays active.
I looked at AsyncTask too, as well as AlarmManager.
What am I missing???
Checkout the background jobs functionality in the Shiny Framework - it's specifically built for use cases like yours
https://github.com/shinyorg/shiny
Full how to video with the creator here
https://www.youtube.com/watch?v=aLtk-VlGicY
Background: I have an ASP.NET Core App and have an API method that takes a file name of a blob that the frontend has uploaded to Azure Blob. It then needs to create a thumbnail version of the blob and return the name of the newly uploaded thumbnail Blob. Sometimes, for exactly the same file size it can take up to 40 seconds to complete. Mostly, it's around 400ms.
Below is the end to end from App Insights, I have a few things I don't understand:
1) The request duration is 37.5 s but yet the other operations add up to nowhere near this time
2) Why are there calls to master db? We are using EF6 with multiple contexts
3) The app is using an Azure App Service and SQL Azure. I don't understand why the response time is so inconsistent.
Any help would be much appreciated!
I've noticed multiple time that the first request after an application is deployed to Azure or after a long period that no requests were made to the application, it takes significantly longer to get a response.
As far as I remember it was related to start-up time of the site (if you're using an App Service on Windows based underlying VM it still uses IIS as a reverse proxy).
I solved the issue by configuring health checks that occasionally perform requests to the app.
Also, in addition to Application Insights (which logs information only after the application has started), you can try the tools listed here to see more information.
Hope it helps!
1.
The way the request timeline is displayed gives you only the time-span for the whole request (37.5s) and the individual time-spans for each dependency.
A dependency being another call that sends its run-time to the application insights.
In your example each call to the database is automatically tracked as a dependency. The code running after each database call is not though.
So e.g. requesting a database entry which takes 200ms and then issuing a Thread.Sleep of 2 seconds and requesting another database entry which takes 300ms would result in a 2 second gap between the two database-call dependencies which will each be listed with 200/300ms respectively.
You can use TelemetryClient.TrackDependency to wrap parts of your own code into its own dependency. This way you will see your own code as an entry on the request timeline.
2.
Depending on your EntityFramework database-initialisier EF will connect to the master db on context creation. (E.g. to create the database if it does not exist).
3.
Try tracking your own code to find out what parts of it are slow. EF has a few performance issues to consider, try to understand the performance caveats of the libs you use. If your calls are inconsistently slow it might be an issue with resources being over-utilized or caches being emptied too early (like for EF warm vs. cold queries).
I need to run a long running task like report export, report import feature which will take few minutes to hour to complete the task. I want to start the task as soon as user gives command from the asp.net mvc view.
I found various web portals, but I couldn't find the exact solution I was looking for or might be I didn't got their idea (or, limited by my experience). I don't need something that runs at certain time interval or at certain time-stamp of the day/week. I only need the background job to be executed on user request and update the task as completed in DB after it's done. So, the background job need to be always triggered by user only.
I assume the ideal solution will be something like, Background service/job is always in ready state to accept trigger from my web application in some kind of port and as soon as it receives command from web application, it (a) either send everything to job when requested for action (b) or, just poke job to start its task (based on the updated db table entry made just before the call action) . So, the user can browse through other pages in the application and can view the progress of all such tasks in one of the view (where he can even cancel or see the completed task). Note, that there can be simultaneous request for the job from different web users which should be treated as separate job (As data export differs based on user access-rights).
I want to go with the simple method, with 100% assurance of task to be done/not done as recorded in db (no crashing of service). What are the best approaches (except azure jobs) as i want to implement the service within same server and I have access to the server/virtual machine to install windows services/packages if needed.
Take look at this great article that Hanselman wrote:
How to run Background Tasks in ASP.NET
Also Hangfire is a mature library that can make development of application long running process more easy.
Hangfire is an open-source framework that helps you to create, process and manage your background jobs, i.e. operations you don't want to put in your request processing pipeline
I want to load data from the web, when my application starts, and
actually wait for the data, because the data will affect the Apps Appearance.
I am using WindowsPhone and c#.
The Problem I have is, that all WebRequest.BeginGetResponse type methods are Asynchronous,
but when I block my main Thread to wait for a result, the "asynchronous" method seems to be blocked to.
Is there an easy way to wait for the result?
Maybe an API that allows better control at Downloading files from the web?
Based on your response in the comment above, I would recommend the following:
Show your splashscreen if you have one, then a loading screen.
Don't block the UI thread, for three reasons:
You don't need to
You need the UI thread to keep going so you can show indeterminate progress or some other type of loading animation
Windows Phone will kill your app if the UI thread is locked for a certain amount of time
After you've loaded your loading screen, start your BeginGetResponse.
After EndGetResponse is completed, do what you need to and then navigate to the main page of the application.
Good luck!