Am new to android, am developing application with websevices using json parsing with httpget method,cant use http post method in android actually.
It working fine normally, but many time it shows the error on emulator like activity not responding force close activity.when i put that url in browser it shows the result .but i don't know why this activity not responding error came.
I think the httprequest took more time to retrieve the data from server,but am not sure. any one help me to how to avoid this error or how to minimize this .
I want know what are the possibilities to get this activity not responding error.
Thanks,
Lakshmanan
You need to perform blocking operations such as I/O in a separate thread - see the below linked resource:
http://developer.android.com/guide/practices/design/responsiveness.html:
In Android, the system guards against applications that are insufficiently responsive for a period of time by displaying a dialog to the user, called the Application Not Responding (ANR) dialog, shown at right in Figure 1. The user can choose to let the application continue, but the user won't appreciate having to act on this dialog every time he or she uses your application. It's critical to design responsiveness into your application, so that the system never has cause to display an ANR dialog to the user.
To avoid ANR (Application Not Responding) dialog,
Your business logic code is inside doBackground() of AsyncTask and You may also need to override onPostExecute(),etc. After that it is better to invoke the async task in a Service (bound or normal service).
Service:
(bound service or normal service based on your requirement)
From, android office documentation:
A service is "bound" when an application component binds to it by calling bindService(). A bound service offers a client-server interface that allows components to interact with the service, send requests, get results, and even do so across processes with interprocess communication (IPC). A bound service runs only as long as another application component is bound to it. Multiple components can bind to the service at once, but when all of them unbind, the service is destroyed.
Related
So I currently have an application independent of Play which may take a long time in its execution.
I want to put a UI on top of it using Play where the application may be invoked and to display some of the details of the execution inside of the application to the user. I would like the page to be updated automatically as the execution proceeds e.g. if a variable in the application increments this would be reflected on the page.
I'm not sure where to begin with this - do I need to split the application up into models + controllers ? Or do I just need to have code in a controller to instantiate the classes I have already coded and call the methods I need ?
What about constantly showing the execution state on the page?
Any resources I should know about/read ? Code examples?
Thanks
You may have already done so, but a good starting point is to create a skeleton Play application using the play new command, while referring the creating a new application section. You will have "views" (HTML template pages) and one controller (in Application.scala). You could add more controllers, but as you will have just a single page that should suffice.
You can add jars from your app (if it's a JVM app) to the lib directory of your Play application. From this: "Or do I just need to have code in a controller to instantiate the classes I have already coded and call the methods I need?" it sounds like you would be happy to have your app run in the process of the Jetty + Play server. Check out the Global object for starting your app at process startup.
Check out the section on comet sockets for sending updates from the Play app to the browser. You'll need a bit of Javascript in the web page.
Do you want to have this application running outside of play, perhaps on another server? Can you modify the application, or is this 3rd party software?
If so, you have to have some way to send data back and forth between your play front end and your application. You can either have your application expose a websocket, and then your play front end and your application can push data back and forth to each other. You can then have your client page have a websocket open to you play front end, and then play can push the updates to the client. If your application can't support a websocket, you could also expose some URLs on your front end for the application to POST to. You can then use some sort of message bus or database mechanism (RabbitMQ, redis, Mongo capped collection, or even just a shared Queue object) so that the front end websocket can get those updates and send them to the client.
I have an application in Asp.net MVC where at some point I would like to display a modal dialog to the user that would display process execution progress indicator.
The process behind the scenes does a lot of database data processing (based on existing data it generates lots of resulting records that get written back to database as well). Process may take anything from a brief moment to a very long time (depending on existing data).
Application will initiate this process asynchronously (via Ajax request) and display progress in the same manner.
The problem
I've read a bit about Async controllers where one can asynchronously start a process and will informed about the end of it but there's no progress indication and I'm not really sure how browser timeouts are handled. As far as the client goes an async request is the same as synchronous one. Client will therefore wait for response (as I understand it). the main difference being that server will execute something in async manner so it won't block other incoming requests. What I should actually do is:
make a request that would start the process and respond to the client taht process has started.
client would them periodically poll the server for process progress status getting immediate response back with percentage value (probably as JSON)
when progress would be 100% it would mean that it ended so client would know to make a request for results.
I'm not convinced that async controllers work this way...
The thing is that I'm not really sure I understand async controllers hence am not sure which approach should I use approach this problem as just described? I see two possibilities myself:
Asp.net MVC Async controllers if they can work this way
Windows Service app that processes data on request and reports its progress - this service would be started by writing a particular record to DB using a normal controller action; that would start it and then service would be writing its progress status to DB so my Asp.net MVC app would be able to read it on client process polling requests.
I haven't used Asynch controllers myself in a project. However here's a link to someone who has.
asynchronous-processing-in-asp-net-mvc-with-ajax-progress-bar
I have personally used Number 2 in a large production project.
Number 2 was a Service App running on a separate server using OpenSSH to communicate between the two servers. We'd poll for progress periodically to update the progress bar to the clients UI via AJAX.
Additionally by separating your web server from your long running process you are separating your concerns. You web server is not interested in writing files to disk, handling IO, etc and so shouldn't be burdended with such.
If your long running process has to be killed or fails then this wont affect your web server handling requests, and processing transactions.
Another suggestion would be for an extremely long running process is not to burden the client with waiting, give them an option to come back later to see the progress. I.e. send them an e-mail when its done.
Or actually show them something interesting, in our case we had a signed Java Applet show exactly what their process is doing at that exact moment.
I have an iPad app that works both on and offline but when I am offline there are web service calls that will need to be made once online availability is an option again.
Example:
A new client is added to the app, this needs to be sent to the web service but since we are offline we dont want to slow the user down so we let them add locally and keep going but we need to remember that that call needs to be made to the web service when we can. Same thing for placing orders and such.
Is there some sort of queue that can be setup that will fire once we have connectivity?
I don't think the overhead of a heavyweight tool like MSMQ is needed for a simple action. You can use Core Data, persist managed objects with the data needed to call the web service, and only delete each managed object after a successful post. There might or might not be a way to capture an event when connectivity starts, but you can certainly create a repeating NSTimer when the first message is queued and stop it when there are no messages in the queue.
This library handles offline persistent message queueing for situations like you describe. It says alpha from a year ago, but I have confirmed it is used in production apps:
https://github.com/gcamp/IPOfflineQueue
I have a web application that I am adding workflow functionality to using Windows Workflow Foundation. I have based my solution around K. Scott Allen's Orders Workflow example on OdeToCode. At the start I didn't realise the significance of the caveat "if you use Delay activities with and configure active timers for the manual scheduling service, these events will happen on a background thread that is not associated with an HTTP request". I now need to use Delay activities and it doesn't work as is with his solution architecture. Has anyone come across this and found a good solution to this? The example is linked to from a lot of places but I haven't seen anyone else come across this issue and it seems like a bit of a show stopper to me.
Edit: The problem is that the results from the workflow are returned to the the web application via HttpContext. I am using the ManualWorkflowSchedulerService with the useActiveTimers and this works fine for most situations because workflow events are fired from the web app and HttpContext still exists when the workflow results are returned and the web app can continue processing. When a delay activity is used processing happens on a background thread and when it tries to return results to the web app, there is no valid HttpContext (because there has been no Http Request), so further processing fails. That is, the webapp is trying to process the workflow results but there has been no http request.
I think I need to do all post Delay activity processing within the workflow rather than handing off to the web app.
Cheers.
You didn't describe the problem you are having. But maybe this is of some help.
You can use the ManualWorkflowSchedulerService with the useActiveTimers and the workflow will continue on another thread. Normally this is fine because your HTTP request has already finished and it doesn't really matter.
If however you need full control the workflow runtime will let you get a handle on all loaded workflows using the GetLoadedWorkflows() function. This will return acollection of WorkflowInstance objects. usign these you can can call the GetWorkflowNextTimerExpiration() to check which is expired. If one is you can manually resume it. In this case you want to use the ManualWorkflowSchedulerService with the useActiveTimers=false so you can control the last thread as well. However in most cases using useActiveTimers=true works perfectly well.
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.